DNS problems with Netgear FVS equipment

A follow-up on the recent DNS-related stuff:

I figured out today that my router had a hand in those weird random connection problems. What made me especially nervous was the almost systematic way that DNS and other random UDP packets vanished from the ‘net during browsing or testing with various tools. The requests were shown to be sent in both the Wireshark protocols and the router packet capture, but an answer never arrived. As it turns out, Enterprise-class devices have their firewall preconfigured to block UDP flood from inside the local network.

The definition of “flood” used here is:

“20 simultaneous, active UDP connections from a single computer on the LAN”


Now, somehow my setup managed to step over that line, and from what I gather on the ‘net I am not the only one experiencing this. Sometimes the system will run clean for a few days, then bug in increasing frequency until I get fed up with it and kill the whole DNS process plus cache. Apparently, this fixes the problem for some time as a good reset almost always does, but it is no permanent solution.

To debug, first turn on the attack-related logging functions in the router and clear the logs. Then call up “nslookup” on Windows based systems and fire some random URL DNS requests in fast sequence. In my case, after four requests the firewall kicks in and UDP flood warnings appear in the log. Maybe Windows 7 just leaves the ports open a little too long, I don’t know and I haven’t checked. However, since this feature has been turned off in the firewall settings I had no further DNS problems, and the speed of browsing has increased a little.  Hopefully that was all there was to it.

Another point of interest: Some Netgear devices have developed a habit of kicking lots of NBSTAT-packets on the LAN, one about every 5 seconds or so. Seems to belong to some type of NETBIOS detection mechanism, though the sense escapes me. The packets are of unicast-type and therefore disrupt everything one could possibly have in the way of wake-on-unicast, which linux supports to wakeup devices from standby if they are talked to directly. NETBIOS features are nowhere to be found in the configuration menu, so I guess at some point the checkbox for that must have gotten mislabeled. The one responsible is “ARP broadcast” found with the LAN settings. Turning it off quiets things down a lot.

But: You lose the capability to show unknown devices in the LAN clients list for simple management of DHCP fixed leases. You can still turn on ARP for a few minutes if you need to detect anything, though.

Faulty IRC DNS lookup

I’ve been having some problems connecting to IRC through the miranda client on Win 7 lately.

Miranda features several “serverlists” for different IRC networks – QuakeNet in my case. Some of the lists work, some don’t, some work at some times. Now, upon clicking edit only one fixed web address shows up. The way this works is, the DNS server knows multiple IP subentries for those servers. You can check with some web-based lookup tools that show all of those entries. Windows’ own command (“nslookup <address>”) only shows the one delivered by the server, as it needs only one precise IP to communicate.

Multiple entries exist to balance load between servers, they are delivered round-robin. If you flush your dns cache locally (Win 7 wants you to do “ipconfig /flushdns” on the console in admin mode, for example) a new IP is acquired – and this one is ideally different from the one before. Now, because Windows does not clear the cache between requests for several logical reasons (it’s a cache, right?) the client program obviously also knows only one of the possible IPs. All the better if exactly that IP is down.

It took me quite some time to figure out where the problem was (all the while thinking there may be something wrong with the router or the net is just in a weird mood today). After checking the DNS entries sequentially using ping and a connection attempt through Miranda, I found to my surprise that while some lists work partially others are simply dead.

irc.quakenet.org 1/8 working Compilation of all subranges
se.quakenet.org 1/3 working
de.quakenet.org 1/2 working
uk.quakenet.org 1/3 working

Remember that this data is momentary from the time I checked the servers. The status might be different now. Anyways, this is some russian roulette!

The lists may fluctuate though, I am pretty sure I got a connection using the german list at some time. It is also possible, that the lists are updated dynamically from time to time, but I haven’t seen it so far.

Fixing this mess is quite easy: just edit or add a list in Miranda for the corresponding network and enter the exact IP. You best find that one yourself by pinging, start with one of the shorter lists you are comfortable with. You will experience trouble if that server goes down, but at least then you will know what the heck is wrong right from the start. Saves time and nerves.