D-Link DGL-4300 LAN Receive Errors
Discuss this article | winhlp.com home
A new gaming router—D-Link DGL-4300 (and DGL-4100)
Last change: 2007-11-17. Copyright © 2006-2008 Hans-Georg Michna
Discussion contributions may be published on this web page.
Table of contents
If you have one of these routers and just want to know how to use them with peer-to-peer file sharing programs, here's some advice.
Read the interesting page http://www.jerrykindall.com/gamefuel.html. It contains quite useful hints. Here's one excerpt from the page as an example:
Update: Version 1.5 and later of the DL-4300 firmware has a validation script in it that prevents "overlapping" rules from being entered (i.e. you can't have two rules that might apply to the same connection). It doesn't allow a ruleset like the one I describe to be entered anymore. Fortunately, this script is only in the browser; the router itself doesn't actually care. So all we need to do is change the JavaScript in the browser to skip the validation step. Create a bookmark in your browser with this as the URL:
javascript:function pageVerify() { return 1; }
Name it "Disable GameFuel Validation" or somesuch. Hit that bookmark immediately after loading the Advanced/Gamefuel page. It'll disable the validation and let you add whatever rules you want. You'll have to access the bookmark to run the script each time you go to the Gamefuel page, of course.
Do you know more? Please add your observations and solutions to the discussion of this page.
Enjoy! The router has a lot of potential and should work pretty well already. The rest of this article consists of technical details.
Something which every gamer experiences when he shares the Internet connection with others is that heavy uploads or downloads can interfere badly with gaming. What happens is that somebody starts a file transfer, and immediately the gamer experiences severe lag, sometimes making game play impossible.
There is a solution for this. It is usually called Quality of Service, but this expression is used for various methods and not well defined. It is essentially a function of the router, through which the LAN (Local Area Network) connects to the Internet through the network of an ISP (Internet Service Provider). In D-Link DGL-4300 parlance it is called Game Fuel.
What is behind this? Why exactly does a download or upload by another LAN user interfere with gaming?
The fundamental cause is that the channel (upload or download) gets overloaded, which is normal, and a queue forms inside a router (and possibly also in the computer running the BitTorrent client). All packets have to line up and wait until all preceding packets have been transferred, in first-in-first-out fashion. This means that the typically small and not too many game packets have to wait until all preceding upload data packets have been sent. And for each TCP connection there is a stream of very small packets in the opposite directions, called ACK (acknowledgement) packets. If these are delayed, the entire connection can slow down too. UDP doesn't have these, but the programs may have their own acknowledgement system that may work in a similar fashion.
Unfortunately the local router can't do much about downloads, because the download queues are in other routers, for example in the ISP's network. The only thing it can do is accelerate TCP ACK packets that are going the other way. However, for ADSL connections the download is usually not so problematic, because there are often other bottlenecks like slow servers or short receive windows. And in ADSL connections the download speed is usually several times higher than the upload, so the waiting times for the queues are usually several times shorter. Still a heavy download can impede gaming, and there isn't much you can do about that.
But in the upload direction your router can do a surprising lot. It can keep track of connections and prioritize them according to user rules (by IP address or by IP port) or by data load, and let the gaming and ACK packets jump the queue. It can even fragment a data packet to be able to insert a game packet in between, after an even shorter time. In the case of the D-Link DGL-4300 and similar routers the automatic prioritization works surprisingly well, so you may not have to enter any specific rules at all.
All text on this page also applies to the similar DGL-4100, which has no WLAN.
I bought a D-Link DGL-4300, to replace an ageing DrayTek Vigor 2500We, and tested it. The DGL-4300 is a gaming router that is advertised as having the ability to give priority to game traffic and thus avoid game lag while other heavy traffic bogs down the Internet connection.
First tests showed that the new router can indeed do that quite impressively and even fully automatically, i.e. without having to enter special settings for each game. I applaud D-Link for this achievement and was quite happy with the new router at first.
If the problem described below can be fixed, this may well be one of the best routers for a typical home or very small office network, and I hope to be able to report more on the success side later.
Then I noticed a new problem. During normal operation the router would suddenly lag and stop working for long fractions of a second.
Further investigation revealed that the router produced up to 2% errors on the LAN receive side during the times when that happened, and showed very poor performance during these times.
D-Link DGL-4300 LAN Receive Errors
For example, the normal upload throughput of around 60 KB/s dropped to about half, 30 KB/s during phases when the error occurred.
By the way, don't look too hard at the WIRELESS STATISTICS errors. A WLAN always has errors. Moreover, while you don't have a computer using it, a lot of TX packets will be dropped.
So I returned the router and swapped it for a new one of the same type. I made sure I did not receive the same device. (Yes, some dealers do that.)
If anybody reads this and observes the same problem on his DGL-4300 or even knows of a solution, please add your observations and solutions to the discussion of this page! Received information may be published on this web page. Please tell me your numbers in the Received and Errors fields, so I can calculate the percentage. I personally would consider one in thousand acceptable.
If you have this same router, but don't have this problem (i.e. you see zero errors), I'd be grateful for a short email too.
Initial tests of the second router showed no such errors, but after about a week of use I noticed that the errors showed up again, and I observed around 1% errors on the LAN receive side.
To make sure that these errors are not caused by my network installation, I made several tests, like connecting different computers, one by one, through different LAN cables directly to the router, enabling or disabling its firewall and even resetting the router back to the factory configuration, switching off all DECT and mobile phones in the vicinity, etc.
When the errors occur at all during the time span of observation, then they already show up when repeatedly clicking on the [Refresh Statistics] button.
The second router is no better. These statistics show almost 1% errors, which is
too much.
The errors again caused secondary problems that lead to unacceptably low performance.
Another measurement after a longer time shows that the percentage of errors is not getting smaller.
Error percentage stays high after another week. This is more than 1%.
The errors do not always occur. In a test where I repeatedly click on the [Refresh Statistics] button, the router often works perfectly for a minute, then there is a sequence of errors, typically 6 to 12 per click, until about 120 new errors have accumulated, then the router produces no more errors and works perfectly for another minute. During the error bursts the router often becomes unresponsive, so I have to wait an extra second for the refreshed statistics page.
In another test I disconnected the router from the Internet, and reconnected. After that the router worked perfectly for a long time, almost a whole day, and produced not a single error. But when I rechecked much later, there were already 0.7% errors again.
2006-10-08 – The errors got worse. Today I saw over 4% errors and the Internet connection gradually became unusable. I have taken the router out and replaced it with the old DrayTek Vigor 2500We, which, within its capabilities, works well.
As so often, we again observe a typical case of poor quality in consumer products. If the problem cannot be solved, I will have to return the second router as well and swap it for a different one by a different manufacturer (only to face totally different problems?).
Often the time spent on identifying and trying to solve a problem like this vastly outweighs the price of the router even for just one customer like me. I don't dare to estimate the total economic cost of quality lapses like this.
The router's log shows no unduly high load, just some typical virus activity. Occasionally I observed a port scan with a number packets per second, but I have made sure that the error occurred during times when there was no such activity, so it cannot be the cause.
There was a very long email exchange between various D-Link subsidiaries and me. Some of these emails are quite embarrassing for D-Link, and one prompted the following sentence from me, "Forward this email immediately to somebody who is able to read and write."
From some other information I surmise that it is particularly the A3 hardware version that is fraught with this defect. Users of the hardware versions A1 and A2 report no such problems, and I suspect that all published tests were done with these earlier versions.
Indeed my choice of this router doesn't seem to have been too bad—the router is praised for its good characteristic by those who had the luck to get a working one.
My recommendation to those who intend to buy this type of router is to wait a few weeks until the waves have subsided and a new, working batch is on the shelves, perhaps a hardware version A4.
Finally I returned the second defective device and received a third, which the German support crew nicely tested for a few days before sending it to me.
Indeed the third unit is so far still free of the nasty LAN RX Error defect and has been working here since 2006-10-30 without showing even a single one of these errors. After many millions of transferred IP packets, the LAN RX Error counter shows a resounding zero. So I could at long last go about testing the Game Fuel function, for which I bought the router.
The third router is free of the LAN RX Errors.
Initial test results with Azureus (a BitTorrent client) providing the background load were not very encouraging. I have tested it with firmware version 1.7, a newer one than version 1.6W, which was loaded on the first two devices.
Game Fuel is a quite promising technology that is probably meant to give priority to gaming and ACK packets and let them jump the sending queue. I have to say probably, because I could not find any precise documentation anywhere.
One fundamental Game Fuel function is Automatic Classification. If enabled, the router gives connections different priorities, apparently mainly depending on their data rate. Connections with a lower data rate get a higher priority and vice versa.
Since you cannot make Game Fuel rules for all BitTorrent connections, you have to rely on that function to give Torrents a lower priority. For this to work, you have to make sure that the BitTorrent connections have a higher data rate than any simultaneous game connections. The two essential means to achieve that are to have no more than 3 active torrents and to reduce the number of upload slots in the BitTorrent client to about 3 as well, yielding a maximum of 9 simultaneously active connections. I have observed severe gaming lag when the number of BitTorrent upload slots was increased to 4, because apparently then each upload connection can have a lower data rate than, for example, a World of Warcraft game connection. Essentially you should reduce the number of upload slots as far as possible, as long as you still get an acceptable upload data rate.
One big plus of the router is that you can see the connections with their dynamically changing priorities, so you can check whether the router actually does what it was meant to do. The big minus in the connections list is that you don't get any traffic information, so you have no clue why the router gives higher or lower priorities to the connections. It is also not possible to sort or filter the list, so with a limit of 4096 connections it is a bit awkward to check anything. I usually copied the connection list into Excel and used Excel's auto-filter to get results. I would recommend that D-Link spruce up the web interface with a a little dose of sorting and filtering Javascript.
Stress tests were done with Azureus (a BitTorrent client), with DHT enabled, and only uploads (download bandwidth zero), to keep things simple. Azureus was set to open approximately 1,000 connections including DHT (Distributed Hash Table, Distributed Database), which is a quarter of what the router is advertised to do, and flood the upload bandwidth (512 Kbit/s DSL in my case), without any speed limits and without automatic throttling. On the router, Dynamic Fragmentation was switched off in most tests, after finding that it seems to make matters worse.
Azureus was set to open a maximum of 320 of its own connections plus some 800 Distributed Database (DHT, see below) connections, which all have very low traffic.
Azureus auto-speed settings
To set Azureus to maximal speed, disable Auto-Speed in Options, Transfer : Auto-Speed and in Options, Transfer set the upload speed to zero, which means unlimited speed.
To set Azureus to auto-throttled speed, enter the settings as indicated by the two screen shots.
I found that, when set to Automatic Classification, the router indeed prioritizes connections automatically, but when you let it run for some time, up to 10 hours, it begins to choke and eventually chokes the Internet connection entirely. It apparently gives several Azureus connections a medium priority around 128, which leads to a situation where you cannot even open the router's own administration interface, provided by a web server built into the router. All other Internet connections stalled as well. It was impossible to connect into the home LAN from the outside or open a web page from the inside. It is a pure catastrophe. The function was absolutely unusable in these tests.
Next I devised a simpler test. I activated Azureus, including DHT, on a separate computer and made a very simple Game Fuel rule: give all connections from or to that IP address the lowest priority (255).
Again I turned up Azureus and let it flood the upload bandwidth. At first it worked excellently, but again over the course of 10 hours all other connections went from good to bad to choking to dead. Before the lights went out entirely, I checked the connections, only to find that the router gave all new Azureus connections a higher priority of 128, rather than 255, as it was instructed to do. Since several other connections got priorities lower than 128, they may have got drowned out by the many Azureus connections.
The router also gives opening and closing connections the higher priority of 128, but what I observed was that a large number of established connections (Status = EST) had kept priorities around 128, ignoring the Game Fuel rule.
So in a third test I disabled the dynamic priorization entirely, which means that all connections get the fixed medium priority of 128, while the Azureus IP address gets 255.
Game Fuel rule for the Azureus computer with IP address 192.168.0.6
Again the same result: Many new Azureus connections get priority 128, rather than 255 as instructed. After a few hours the network is dead, because Azureus has many more connections than everything else.
Excerpt of active connections list. First and last row has the wrong priority 128.
In one analyzed snapshot with 1,128 connections, 173 connections from or to the computer running Azureus with the IP address 192.168.0.6 had the priority 128. 20 of these connections were outgoing, the rest was incoming. So at least 20 connections were prioritized too high, and several of these were long-running, not just opened recently. This is enough to drown out connections from other computers in the LAN. It is an obvious defect of the router.
You can download the entire list in zipped Excel format. It is already set up with Excel's AutoFilter set to filter out the 173 established ("EST") connections with priority 128. If you add an AutoFilter to Dir = Out in column G, you can immediately find the 20 outgoing connections that have the wrong priority.
The conclusion is that the router cannot handle any upload flood condition with many connections, perhaps because it doesn't obey its Game Fuel rules. Don't bother with Game Fuel rules—they just don't work reliably.
I enabled Automatic Classification again for another test and this time enabled the automatic speed control of Azureus. All other settings remained equal, particularly the Game Fuel rule of priority 255 for the computer running Azureus. After 10 hours the number of outgoing Azureus connections with status EST and priority 128 had grown to 41, and web browsing from other computers had already become difficult, particularly since those connections typically get priorities much lower than 128. You can also download this entire list in zipped Excel format with Excel's AutoFilter already set to show only the 41 outgoing Azureus connections with status EST and the wrong priority of 128.
Throttling Azureus doesn't seem to work with the Game Fuel Automatic Classification, because the router gives pings a high priority, lets them jump the queue, and thus blinds the Azureus ping lag sensors. Thus it is no surprise that these tests yield the same result as the unthrottled Azureus.
I can only get the network into a functioning condition when I throttle Azureus and disable the routers Automatic Classification or, better, switch off Game Fuel altogether. The Azureus auto-speed plug-in does the trick, but then I must disable Game Fuel.
The Game Fuel rule I have used in the test (see above) doesn't cut it either, because it requires to throttle an entire computer, not just Azureus. Since Azureus can use any port to establish an outgoing connection, you cannot filter by port. (Only incoming connections have to use a predetermined port.) And when you try to rely on Automatic Classification alone, your Internet connection is dead within minutes.
And due to the router giving some Azureus connections the wrong priority of 128, even the Game Fuel rule of low priority to the entire computer running Azureus doesn't work. For example, I tried to use a remote desktop through the router in this test, and the connection started well, but then apparently got its priority lowered due to a high data rate (correct behavior), and may have been overwhelmed by the 40+ Azureus connections with the higher priority of 128 (incorrect behavior).
In that situation I could not even open the router's own administration interface from the outside, which is a point that I think should be improved. I think the router should give connections to its own admin interface the highest possible priority. I had to quickly shut down Azureus over another, new connection, otherwise I would have lost control altogether.
DHT (Distributed Hash Table) is the Azureus version of the distributed database that makes Azureus more or less independent on established trackers by using distributed tracking of torrents.
On Azureus DHT opens many short-lived UDP connections (several each second) and requires an open (inbound) port. In fact, most of the 1,000+ connections of Azureus in my tests are DHT connections. It is conceivable that the constant flood of new connections overwhelms or at least delays the router's Game Fuel function.
DHT seems to be the core of the Game Fuel problems. With DHT disabled, Game Fuel works. However, this makes Azureus less useful. On the other hand, the Azureus flavor of DHT is not compatible with any other BitTorrent clients, so it is not recommendable anyway.
Nonetheless the only currently known workaround for the Game Fuel problems with Azureus is to disable DHT. The alternative is to switch to any other good client like µTorrent or the original BitTorrent, which is easy to use, yet powerful. Their version of DHT works well with the router's Game Fuel function.
Keep the number of global connections within limits, because this router doesn't have unlimited processing power and can be overwhelmed by too many connections. These, for example, are my BitTorrent settings in µTorrent:
Another factor is very important and may have contributed to the Azureus test results. Since the Automatic Classification of Game Fuel is apparently based on the data rate of each connection, you have to keep the data rate in the active BitTorrent data connections high.
Two methods to achieve this:
This would concentrate the entire BitTorrent upload data rate on 9 simultaneously active connections. The result is that the data rate in each of these connections is high, and therefore the Game Fuel Automatic Classification function gives them a low priority, which is what we want. Thus these connections don't get in the way of gaming or any other lower-traffic connections.
The worst defect is indicated by the error message shown below.
This typically happens when you try to enter two or more Game Fuel rules. Since you often have to leave one side open (any IP address, i.e. 0.0.0.0 to 255.255.255.255, or any port, i.e. 0 to 65535), such rules always overlap each other and raise the error. The following example arises when a new Game Fuel rule is entered and the Save button clicked:
From a purely theoretical point of view the router is right. The rules do overlap, and a connection is conceivable, to which both rules apply.
In practice, however, this case does not occur. These rules never apply to the same connection. In this example it is theoretically conceivable that somebody runs Azureus on the KGS game server and establishes an incoming Azureus connection, but I'd publicly eat my bedsheet if that ever happened. And even then Azureus would never use the game port 2379 on the server and a game connection would not go out from the local Azureus port 51377. In other words, it is practically impossible.
The difficulty is only a problem of the user interface that creates this error message and prevents the saving of the second rule.
So there is an obvious solution for the next firmware update. D-Link, please change the firmware such that conflicting rules are accepted and, if the router ever encounters an actual case of a connection, to which more than one rule applies, apply the rule with the highest priority. Or, if that's simpler, apply the first or the last or just any of the conflicting rules. It simply doesn't matter in practice.
And don't forget to document it. Some users want to know.
Meanwhile you can use the workaround described at the top of this page, at the end of the chapter "Quick user advice".
The Game Fuel function has a few other bugs as well, but those are not as serious and can be worked around. One is that you cannot resave any Game Fuel rule whose port range begins with zero. You can save it the first time, but any resave throws an error message.
The current workaround is to skip the zero and let the port ranges begin with 1, thus 1-65535, but it would be nice if this were fixed in the next firmware version.
Another very similar error is that you cannot resave any Game Fuel rule whose protocol is set to ANY (rather than TCP or UDP). Again you can save it, but any subsequent attempt to resave all Game Fuel settings fails with an error.
The current workaround is to click on the edit icon to the right of the offending rule, select protocol = ANY, then click on the Save button to resave the same rule. Repeat this procedure for all rules with protocol = 0. Finally click on the Save Settings button at the top. Again it would be nice to see this fixed.
A little shortcoming is that the help page explains the connection state abbreviations, such as EST, but it omits a very frequent one—the hyphen (–).
The missing information is that the hyphen appears only in UDP connections, which have no connection state. In fact, UDP is a connectionless protocol. The router only tracks pseudo connections for the purpose of its Game Fuel function.
D-Link, please add a short explanation of the meaning of the hyphen to the help page.
Since these errors and shortcomings are conspicuous and concern normal user interface
actions, it is fairly obvious that this function was never thoroughly tested. D-Link
obviously works like some software companies. They invent something and throw it
at customers, while it is still very unreliable. Perhaps we cannot expect more from
a $100 device. If anybody from D-Link reads this, consider using me as a beta tester.
I find all defects quickly.
If you've read till here, you might as well log in to the router in question and see for yourself. Log in here with User Name = User and Password = gamefuel . Please don't use this for longer than necessary; I believe, only one person can be logged on at a time.
2007-03-19 – Greg Coleman wrote:
I have had several of these routers and have been rather pleased. However, try a VPN connection out. Some people cannot get it to work at all. I can, but with a very strange issue.
Using Windows 2003, allowing VPN connections in to our Domain.
Using Windows XP Pro as a client to connect to the Windows 2003 Software VPN (RRAS).
Allows the correct PPTP ports and firewall mappings to the server.
Connects fine, however if you disconnect, you must wait 8-10 minutes to connect again, as the client/server will state no response from the VPN Server.
Reboot the router after a disconnect, and you can connect immediately. The problem lies squarely on the DGL-4300, with no fix in sight.
If this worked properly I would be very happy.
All this said, the router definitely has its pluses.
I briefly investigated an alternative to the D-Link router, which also offers traffic shaping, the Buffalo WBMR-G54. I just read the QoS chapter in the manual and found that it is somewhere between unintelligible (header offset, bit mask, bit pattern) to unusable for me, because it doesn't allow, for example, prioritization by entering a port number range.
I'm still open to proposals of routers with good traffic shaping for a BitTorrent plus gamers plus ordinary users mix. Even if a router were several times more expensive (the D-Link DGL-4300 is cheap at around $100), I would still consider it.
I'm also open to all other kinds of useful information. Please add your observations and solutions to the discussion of this page.
Hans-Georg
Copyright © 2006-2008 Hans-Georg Michna