• November 29, 2021, 08:25:09 AM
  • Welcome, Guest
Please login or register.

Login with username, password and session length
Advanced search  

News:

This Forum Beta is ONLY for registered owners of D-Link products in the USA for which we have created boards at this time.

Pages: 1 [2] 3 4 ... 10

Author Topic: Alternate OpenWRT firmware for the DGL-5500 (HOW TO)  (Read 58521 times)

FurryNutz

  • Poweruser
  •   ▲
    ▲ ▲
  • *****
  • Posts: 49863
  • D-Link Global Forum Moderator
    • Router Troubleshooting
Re: Alternate firmware for their DGL-5500
« Reply #15 on: January 21, 2015, 02:04:37 PM »

There is posts that I made in regards to v1.12 B05. You'll find on page 1 of that thread. Any Bugs found after the Fixes listed for that build would be noted in the following new list generated for the next version of FW I tested.
Logged
Cable: 1Gb/50Mb>NetGear CM1200>DIR-882>HP 24pt Gb Switch. COVR-1202/2202/3902,DIR-2660/80,3xDGL-4500s,DIR-LX1870,857,835,827,815,890L,880L,868L,836L,810L,685,657,3x655s,645,628,601,DNR-202L,DNS-345,DCS-933L,936L,960L and 8000LH.

Lops

  • Level 1 Member
  • *
  • Posts: 11
Re: Alternate firmware for their DGL-5500
« Reply #16 on: January 22, 2015, 04:51:16 AM »

Any news? Did anyone here try the alternate FW yet?
Logged

FurryNutz

  • Poweruser
  •   ▲
    ▲ ▲
  • *****
  • Posts: 49863
  • D-Link Global Forum Moderator
    • Router Troubleshooting
Re: Alternate firmware for their DGL-5500
« Reply #17 on: January 23, 2015, 07:49:21 AM »

Logged
Cable: 1Gb/50Mb>NetGear CM1200>DIR-882>HP 24pt Gb Switch. COVR-1202/2202/3902,DIR-2660/80,3xDGL-4500s,DIR-LX1870,857,835,827,815,890L,880L,868L,836L,810L,685,657,3x655s,645,628,601,DNR-202L,DNS-345,DCS-933L,936L,960L and 8000LH.

murraydr44

  • Level 2 Member
  • **
  • Posts: 25
Re: Alternate firmware for their DGL-5500
« Reply #18 on: January 23, 2015, 12:03:08 PM »

The new firmware is installed and seems to run.  The router was packed away, since WAN ping reply is missing.
Logged

FurryNutz

  • Poweruser
  •   ▲
    ▲ ▲
  • *****
  • Posts: 49863
  • D-Link Global Forum Moderator
    • Router Troubleshooting
Re: Alternate firmware for their DGL-5500
« Reply #19 on: January 23, 2015, 12:28:53 PM »

Was any virtual server rules set up. Virtual Sever is supposed to help with NAT traffic that isn't normally allowed by the NAT and firewall.

The new firmware is installed and seems to run.  The router was packed away, since WAN ping reply is missing.
Logged
Cable: 1Gb/50Mb>NetGear CM1200>DIR-882>HP 24pt Gb Switch. COVR-1202/2202/3902,DIR-2660/80,3xDGL-4500s,DIR-LX1870,857,835,827,815,890L,880L,868L,836L,810L,685,657,3x655s,645,628,601,DNR-202L,DNS-345,DCS-933L,936L,960L and 8000LH.

dtaht

  • Level 1 Member
  • *
  • Posts: 13
Re: Alternate firmware for their DGL-5500
« Reply #20 on: February 17, 2015, 01:15:40 PM »

In terms of benchmarking sqm-scripts with fq_codel vs streamboost I don't really regard:

"I bought this router solely for StreamBoost and it handles QoS/traffic shaping perfectly.

My GF was playing LoL last night and her ping didn't budge from 33ms when I downloaded an update for my laptop.  This scenario is exactly why I bought the router, "

as definitive. The real proof of any effective shaping system is manage bandwidth appropriately when both up and download are saturated.  Certainly I can understand that a principal desire of many users is to have fast gaming traffic while not being hurt by downloads, and streamboost has always been optimized for that scenaro.  sqm-scripts on the other hand, was designed to be simple, scalable, non-snoopy, fire-and-forget, and degrade VERY gracefully under enormous simultaneous up and down loads. Instead of classification, fq_codel uses "fair queueing" to break up all flows into separately scheduled packets, and to give a boost to the typical "sparse" characteristics of voip/dns/gaming traffic is uses what we call "flow queueing", here documented in the IETF draft:

https://tools.ietf.org/html/draft-hoeiland-joergensen-aqm-fq-codel-01

Additionally sqm-scripts can give a boost to self classified traffic from the hosts for additional prioritization better than pure fq, rather than rely on a central, proprietary database. It has been tested to hundreds of simultaneous users at a variety of rates ranging from 384k dsl to 10+ gbit (on hardware that can run that fast). (well, not hundreds of users at 384k!!!, nor hundreds of megabits on low end routers!)

I note I am *all in favor* of working code to hold latencies low on ANY qos system and if whatever is branded as streamboost is doing well - awesome! I am quite ironically amused qca found a business model for doing DPI on their customers traffic...

I took apart the GPL drop (god, linux 2.6.36.4???) for this firmware and it does indeed look like they´ve replaced fq_codel with something more oriented around hfsc + priority queues, probably on a per station basis. There are a couple issues with this approach - notably it starts to fall apart as you add devices, it doesn´t do ecn, probably doesn´t  manage queue lengths well for protocols like backtomymac, RDP and X11, and gets really hard to manage up and downloads effectively as you do endless degrees of classification, no matter how robust the ruleset.  They completely missed DSL frame compensation also.

I had done some early tests of this hardware and it collapsed completely on simultaneous up/downloads, but have not tried it in quite some time, and gave away this router to someone more deserving.

So I would welcome some benchmarks of this version of streamboost vs sqm-scripts that test a rigorous variety of scenarios on this hardware, with both the chaos calmer and current firmware. For all I know, they got it right this time! And honestly, I would applaud - with honest benchmarks at hand. In particular I am very interested in finding out how fast on the download side the various QoS systems can operate.

The test the bufferbloat community primarily uses is called netperf-wrapper, and the rrul, tcp_upload, tcp_download, and voip tests. Things like speedtest are pretty useless, and that and netalyzer do not scale much past 20 mbit.

Again, almost anything that can make the horribly overbuffered modern dsl, cable, and fiber devices behave better is a win, IMHO. It makes for a much better internet experience.

Here are some examples of sqm + fq_codel in practice, on cable modems, some of which exhibit 1.2seconds of latency under load, without shaping.

http://burntchrome.blogspot.com/2014/05/fixing-bufferbloat-on-comcasts-blast.html
http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html

« Last Edit: February 17, 2015, 03:09:38 PM by dtaht »
Logged

FurryNutz

  • Poweruser
  •   ▲
    ▲ ▲
  • *****
  • Posts: 49863
  • D-Link Global Forum Moderator
    • Router Troubleshooting
Re: Alternate firmware for their DGL-5500
« Reply #21 on: February 17, 2015, 01:21:13 PM »

Thanks for posting and giving feedback with your experiences. Very nicely detailed information.

Glad your router is working well for you.

Please visit again.

 ;)
In terms of benchmarking sqm-scripts with fq_codel vs streamboost I don't really regard:

"I bought this router solely for StreamBoost and it handles QoS/traffic shaping perfectly.

My GF was playing LoL last night and her ping didn't budge from 33ms when I downloaded an update for my laptop.  This scenario is exactly why I bought the router, "

as definitive. The real proof of any effective shaping system is manage bandwidth appropriately when both up and download are saturated.  Certainly I can understand that a principal desire of many users is to have fast gaming traffic while not being hurt by downloads, and streamboost has always been optimized for that scenaro.  sqm-scripts on the other hand, was designed to be simple, scalable, non-snoopy, fire-and-forget, and rely on the hosts to mark their own traffic appropriately, rather than rely on a central, proprietary database. It has been tested to hundreds of simultaneous users at a variety of rates ranging from 384k dsl
to 10+ gbit (on hardware that can run that fast)

I note I am *all in favor* of working code to hold latencies low on ANY qos system and if whatever is branded as streamboost is doing well - awesome! I am quite ironically amused qca found a business model for doing DPI on their customers traffic...

I took apart the GPL drop (god, linux 2.6.36.4???) for this firmware and it does indeed look like they´ve replaced fq_codel with something more oriented around hfsc + priority queues, probably on a per station basis. There are a couple issues with this approach - notably it starts to fall apart as you add devices, it doesn´t do ecn, probably doesn´t  manage queue lengths well for protocols like backtomymac, RDP and X11, and gets really hard to manage up and downloads effectively as you do endless degrees of classification, no matter how robust the ruleset.  They completely missed DSL frame compensation also.

I had done some early tests of this firmware and it collapsed completely on simultaneous up/downloads, but have not tried it in quite some time, and gave away this router to someone more deserving.

So I would welcome some benchmarks of this version of streamboost vs sqm-scripts that test a rigorous variety of scenarios on this hardware, with both the chaos calmer and current firmware. For all I know, they got it right this time! And honestly, I would applaud - with honest benchmarks at hand. In particular I am very interested in finding out how fast on the download side the various QoS systems can operate.

The test the bufferbloat community primarily uses is called netperf-wrapper, and the rrul, tcp_upload, tcp_download, and voip tests. Things like speedtest are pretty useless, and that and netalyzer do not scale much past 20 mbit.

Again, almost anything that can make the horribly overbuffered modern dsl, cable, and fiber devices behave better is a win, IMHO. It makes for a much better internet experience.

Here are some examples of sqm + fq_codel in practice, on cable modems, some of which exhibit 1.2seconds of latency under load, without shaping.

http://burntchrome.blogspot.com/2014/05/fixing-bufferbloat-on-comcasts-blast.html
http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html
Logged
Cable: 1Gb/50Mb>NetGear CM1200>DIR-882>HP 24pt Gb Switch. COVR-1202/2202/3902,DIR-2660/80,3xDGL-4500s,DIR-LX1870,857,835,827,815,890L,880L,868L,836L,810L,685,657,3x655s,645,628,601,DNR-202L,DNS-345,DCS-933L,936L,960L and 8000LH.

dtaht

  • Level 1 Member
  • *
  • Posts: 13
Re: Alternate firmware for their DGL-5500
« Reply #22 on: February 17, 2015, 01:30:02 PM »

I would just LOVE some benchmarks! and

tc -s qdisc show

output from each system afterwards.

« Last Edit: February 17, 2015, 01:31:57 PM by dtaht »
Logged

FurryNutz

  • Poweruser
  •   ▲
    ▲ ▲
  • *****
  • Posts: 49863
  • D-Link Global Forum Moderator
    • Router Troubleshooting
Re: Alternate firmware for their DGL-5500
« Reply #23 on: February 17, 2015, 01:36:16 PM »

Any chance you can provide any testing results?
Logged
Cable: 1Gb/50Mb>NetGear CM1200>DIR-882>HP 24pt Gb Switch. COVR-1202/2202/3902,DIR-2660/80,3xDGL-4500s,DIR-LX1870,857,835,827,815,890L,880L,868L,836L,810L,685,657,3x655s,645,628,601,DNR-202L,DNS-345,DCS-933L,936L,960L and 8000LH.

dtaht

  • Level 1 Member
  • *
  • Posts: 13
Re: Alternate firmware for their DGL-5500
« Reply #24 on: February 17, 2015, 02:18:37 PM »

The original firmware for this product did not successfully complete many tests.  It does look like it has improved dramatically, so I placed another order for one. Can toss off a benchmark next weekend, probably.

I tend to regard the bufferbloat problem on the ISP link as solved (with tons of products in the pipeline), although it is taking forever for DOCSIS 3.1 to deploy...

( http://www.cablelabs.com/wp-content/uploads/2014/06/DOCSIS-AQM_May2014.pdf )

That makes the next big problem wifi.  We think we have come up with a whole bunch  (not just fq_codel) of ways improving wifi´s latencies and efficiencies on the mac layer with multiple stations active, and as it happens the DIR-860L is one of the leading candidates for some of the new ideas for wifi we outlined at my last talk at the IEEE 802.11 working group meeting.

http://snapon.lab.bufferbloat.net/~d/ieee802.11-sept-17-2014/11-14-1265-00-0wng-More-on-Bufferbloat.pdf

Work on make-wifi-fast hopefully starts in april, and I hope d-link pays some attention as we go along.
« Last Edit: February 17, 2015, 05:42:29 PM by FurryNutz »
Logged

mrjezza

  • Level 2 Member
  • **
  • Posts: 34
Re: Alternate firmware for their DGL-5500
« Reply #25 on: February 17, 2015, 08:41:37 PM »

I took apart the GPL drop (god, linux 2.6.36.4???) for this firmware and it does indeed look like they´ve replaced fq_codel with something more oriented around hfsc + priority queues, probably on a per station basis.


http://snapon.lab.bufferbloat.net/~d/draft-taht-home-gateway-best-practices-00.html#rfc.section.4.4:
"Streamboost(tm) implements a 5 band fq-codel based system, which does deep packet inspection using a regularly updated classification table"

Is this not correct?
Logged

dtaht

  • Level 1 Member
  • *
  • Posts: 13
Re: Alternate firmware for their DGL-5500
« Reply #26 on: February 17, 2015, 11:30:30 PM »

(incidentally, I am the author of that, and it never made it to the ietf because, in part, qca did not want to participate in the fq_codel standardization process. Based on our discussion today and further analysis after I get a DGL-5500 to play with later this week I will revise or remove that section of the document entirely)

The original versions of streamboost that I looked at were, indeed, structured with 3-5 fq_codel queues (each queue has up to 1024 subqueues). The version of streamboost that won an award at  the cable show certainly was built that way. I think (but am no longer sure) that the streamboost in the original firmware for this device was fq_codel based - but in my testing I could crash it in a matter of minutes at any workload, and I gave up and moved on to other things like finishing cerowrt and helping push improvements like corrected DSL compensation up to openwrt and the Linux mainline.  (as best as I recall the benchmarks that did complete showed a clear fq_codel signature without ecn, very similar to the ones I linked to earlier on fixing cable modems)

It really would not surprise me, that based on market research, that various parties decided that optimizing only for  consumer´s  hot buttons (netflix, gaming) was more important than general purpose quality of experience on all traffic - I have had an encounter recently with another home router maker where they proudly showed off their "optimal" netflix and gaming results, and they hadnt noticed, at all, that whatever they were using had destroyed 70% of the potential upload bandwidth, and that it fell over completely on traffic they couldnt classify properly, and on traffic types they weren't  testing for, like web and and RDP traffic. I see from other comments on this forum on this device that these sort of problems on other traffic also seem to be happening.

I can also imagine that the ancient kernel used on the DGL-5500 led to other problems that were, indeed, codel related. The algorithm requires fast timestamping abilities that did not enter the linux kernel until the 3.x era, in particular.

In poking at the DGL5500A1_GPL112 GPL drop today, there is a binary package bwcd-nocodel_g4791e7c-2_ar71xx.ipk which indeed does not reference codel anywhere in it,  although other bits of the package do insert the modules, there is no sign of codel or fq_codel being patched into this kernel at all. And there were so many bugs in that version htb I can see why they used hfsc instead....

So I suspect that streamboost "the brand" now has two or more forks of the underlying code, and you can no longer be certain what lies underneath, nor predict how well it works in the general case. Only more investigation and benchmarking can tell. Or someone getting enough into the router to run a tc -s qdisc show.
« Last Edit: February 18, 2015, 01:47:03 AM by dtaht »
Logged

mrjezza

  • Level 2 Member
  • **
  • Posts: 34
Re: Alternate firmware for their DGL-5500
« Reply #27 on: February 18, 2015, 03:58:55 PM »

After I posted the link I realised the similarity between your username and the URL haha

Shame that this router isn't using fq_codel because it seems like the way to go.

From the reading I did last night, I've understood that much of the CeroWRT work around bufferbloat is now part of OpenWRT.  Could you explain what is still unique to CeroWRT and what advantages running it on a WNDR3800 would have to flashing OpenWRT onto the DGL5500?
Logged

dtaht

  • Level 1 Member
  • *
  • Posts: 13
Re: Alternate firmware for their DGL-5500
« Reply #28 on: February 18, 2015, 07:22:27 PM »

After I posted the link I realised the similarity between your username and the URL haha

Shame that this router isn't using fq_codel because it seems like the way to go.

From the reading I did last night, I've understood that much of the CeroWRT work around bufferbloat is now part of OpenWRT.  Could you explain what is still unique to CeroWRT and what advantages running it on a WNDR3800 would have to flashing OpenWRT onto the DGL5500?

None. Everything important in cerowrt 3.10.50-1 (the current stable version) is upstream. Cerowrt is a research project. If you want to help build up the next generation of the internet edge devices, please feel free to come play with us, but be prepared for a lot of stuff to break along the way. :)

I have to get a rant out of my system:

In addition to cerowrt...

I'm also the co-founder of the bufferbloat project, the implementer of codel, contributor to a whole bunch of internet drafts and rfcs, and the designer or architect of a whole bunch of the predecessors to other embedded software you use every day... I worked on early linux based handhelds, and during my time at montavista software especially I worked on a metric ton of things that are now everywhere, examples: if you use a panasonic tv, or see an x-windows prompt on an airline seatback, those are my fault. Using sip or asterisk for voip? partially my fault. I worked really hard on stablizing the toolchains for mips, ppc, and arm platforms during that era, also, which is what has made the later explosion of linux into all the embedded spaces possible.

I am NOT taking sole credit! Lordy there were 10s of thousands of people involved in taking linux from 0 embedded devices in 1996 to billions in 2015.  I know and worked with dozens and dozens of people that really deserve more credit than they get, for the world as it exists today.

But I can point to things like the above and below that sprang directly from my efforts.

My main claim to fame before bufferbloat was that the creation of the entire home gateway and wifi router industry is partially due to my wireless efforts in the 90s and early 00s. [1]. Not that anyone in the industry bothers to send a christmas card! I do sometimes wish I had the same kind of pull I had in the early 00s. CEOs, CTOs and VCs used to call me back.

These days I tend to think of the current sad state of home gateways and wifi as also *my fault* [2]. I should have tried to standardize wondershaper [3], I should have fought harder against wifi packet aggregation when it was first proposed in 04, and I for damn sure should have tried to get it right in 06. Instead I was happily retired and living on a beach in south america while the edge of the internet went to hell [4]. I was annoyed at 802.11e EDCA, but I didn´t even notice how screwed up 802.11n was under contention until late 2010. Nor did I release that home gateways were going to hell, particularly after the great recession closed all the embedded linux shops like montavista and embedded alley and so on that were doing the good bringup work.

So me and my merry band of some original internet pioneers, and a ton of volunteers, and a few clued companies like google, redhat and comcast, have been trying to fix all that, ever since 2010. [5]. I got sucked into doing the cerowrt portion of the bufferbloat project because it was obvious we needed to be implementing tons of new code on deployable hardware, and nobody else stepped up to the plate that had sufficient spare time to drive it to completion.

My reaction when Vint Cerf, Jim Gettys, Dave Reed, Paul Vixie, Stuart Cheshire, Van Jacobson, or esr ask me to do *anything*, and offer me a spot on their couch(es) to do it - my response is... "yes, I'll get on it - when do you need it by?". [6]

What would your reaction be if even one of these people asked a favor of you? Why don't the internet megacorps of the world accord these people the same respect - especially when they lay out exactly what they have been doing wrong, and exactly, how fix it, and fall all over themselves to make the technologies available for free? Jeebus.

I would rather dearly like to go back to my beach, but there is one major thing left to do in addition to crossing the chasm, fixing wifi. I am fully aware it is going to take another 4-5 years to flush the bad products out of the marketplace.

Anyway... rant over....

The only advantage to cerowrt 3.10.50-1 remaining is that we have been breaking records for stability and uptime. [8]. I think those sort of records are also being achieved across the board in the openwrt mainline so it is not very important. Otherwise every important feature and technology developed in cerowrt and of interest to normal users is in openwrt chaos calmer, and the linux mainline kernel, and downstream in products that are tracking that stuff closely, unlike :ahem: dlink.

These included vastly better ipv6 support, DNSSEC support for dnsmasq, better wifi drivers, and the newly developed fixes for bufferbloat (debugged HTB, BQL & fq_codel - and as tests all the other proposed aqm variants such as pie are in it). I am really, really happy, in particular to have made Vint happier with ipv6, paul with dnssec, and jim with fq_codel. The preliminary ietf homenet support is not really there, though. Sigh. [9]

So there is now nearly no point in using cerowrt. Find a currently shipped ath9k based product on openwrt´s supported list, put on barrier breaker or chaos calmer and go to it. And/Or nag d-link to catch up. :) I do not as yet have an opinion on the DGL-5500's overall quality, or its chipset, or its firmware sorry. Maybe its great now. I am easy! But given the unbelievable number of improvements to linux since 2.6.36 I have grave doubts. I will go test it this week.

The previous target of cerowrt´s efforts had, among other things, been flown to 120,000 feet [7] which made me feel comfortable about using it for my userbase. I plan to fly whatever hardware we choose for the next iteration of cerowrt to the same height, or higher - and bake it, freeze it, etc - before deciding to use it.

I am delighted (as cerowrt the research project  became a success disaster... ) that I can now point people that want to develop cool new products to multiple more polished, stabler, upstream distros (like openwrt, dd-wrt, ipfire, gargoyle, etc), and leave us researchers alone to go back to finding solutions (and breaking stuff!) for the remaining problems we have identified.

Whenever cerowrt resumes development (april maybe, funding willing) the hope is to implement all the solutions we have come up for wifi's problems on some more modern piece of hardware. IF the DGL-5500 running openwrt is suitable, and stable enough, awesome. I mentioned another dlink product we are considering in an earlier post, it really depends on how deep we can get our hands into the wireless portion of the firmware. It is going to ath9k based for sure for one side of the project and we are still in the final selection process for the other chipset.

I had a bit of fun writing this rant, and getting some of this out of my system, and of the links below, I really, really wish, more people had a deeper intuitive understanding  of how wifi really works (second half of my talk at mit) [2], because the world is desperately short on people that can fix it. Wifi is really cool, I am looking forward to making it better, and hope more people can contribute to the process of making the edge of the internet better, for everyone.

[1] http://the-edge.blogspot.com/2010/10/who-invented-embedded-linux-based.html
[2] https://www.youtube.com/watch?v=Wksh2DPHCDI&feature=youtu.be "see second half of MIT talk on what´s wrong with wifi"
[3] http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die
[4] https://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/
[5] http://cero2.bufferbloat.net/cerowrt/credits.html
[6] http://esr.ibiblio.org/?p=4196 "holding up the sky"
[7] http://snapon.lab.bufferbloat.net/~d/spacerouter.JPG
[8] https://lists.bufferbloat.net/pipermail/cerowrt-devel/2015-February/004022.html
[9] https://datatracker.ietf.org/wg/homenet/documents/ - homenet is attempting to standardize fixes for mdns and ipv6 enabled home gateways
« Last Edit: February 18, 2015, 09:25:27 PM by dtaht »
Logged

murraydr44

  • Level 2 Member
  • **
  • Posts: 25
Re: Alternate firmware for their DGL-5500
« Reply #29 on: February 27, 2015, 12:30:11 PM »

Last night, I tested the DGL-5500 with Streamboost turned off, then on.   Hardware used: Huawei HG610 modem in bridged mode, Nexx WT3020 with OpenWRT  Chaos Calmer installed and qos turned off, to handle just pppoe while the  DGL-5500 router was being tested,  Netgear WNDR3800 with CeroWRT installed in order to run the netperfrunner.sh test script.   For comparison, the Nexx WT3020 with qos-scripts and sqm was tried  at 15/10 Mbps.
The netperfrunner.sh results summary is below:
Streamboost off: 39/71/125/122/156/193 msec Min/10%/Med/Avg/90%/Max Latency, 10.78/10.07 Mbps down/up
Streamboost on: 38/90/135/129/160/184 msec  Min/10%/Med/Avg/90%/Max Latency, 11.12/10.06 Mbps down/up
qos-scripts only: 39/40/043/043/046/051  msec Min/10%/Med/Avg/90%/Max Latency, 14.09/9.45Mbps down/up
sqm only:           37/38/039/040/043/048 msec  Min/10%/Med/Avg/90%/Max Latency,  4.08/4.13 Mbps down/up

Note that sqm uses up a lot of bandwith compared to qos-scripts.
DGL5500A1_FW113B04.bin firmware was installed just prior to testing.
Logged
Pages: 1 [2] 3 4 ... 10