1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Disconnection under heavy load ?

Discussion in 'HyperWRT Firmware' started by xond, Nov 29, 2004.

  1. xond

    xond Network Guru Member

    After having flashed my WRT54G to Hyperwrt2b3, I noticed that I have very frequent disconnections of my wireless PCs when I start some P2P (e-mule) transfers. The solution is to deactivate the connection on the clients PC and re-activate them.
    Apparently, no problem in more normal situations of web browsing of FTP downloading.

    I don't remember this was the case with earlier versions, although I haven't flashed to previous version bask to do formal checking.

    Any clue to make connections stable even under heavy downloading ?

    (WIN XP on all clients, WPA-PSK, SSID visible)


  2. Toxic

    Toxic Administrator Staff Member

    obviously there are limitations on file sharing with clients. there will never be "unlimited" connections. try limiting the amount of client that connect. to lower bandwidth priorities.

    dunno if this will work in hyperwrt but it does with sveasoft firmware.

    try using the command shell and enter this there.,
  3. dellsweig

    dellsweig Network Guru Member

    Do you have logging enabled?? If so the reboot could be due to klogd filling buffers. One of the cron based fixes for logging on hyperwrt would cause multiple klogd processes to hang around - each using resources until the router re-boots.
  4. xond

    xond Network Guru Member

    Many thanks for your help.

    @dellsweig : logging is not enabled.

    @Toxic : I have tried your trick. I don't know whether it has worked since nothing particular happened. However, no disconnection today despite many concurrent downloads with e-mule. It seems promising. A few days of testing and we will know wether this has improved the stability of wireless connections.

  5. xond

    xond Network Guru Member

    I still have random disconnections. Actually they do not especially occur when P2P sharing as I previously thought.
    Since I do not recollect having these disconnections with older firmwares, I am going to try them back.
  6. Ouaibe

    Ouaibe Network Guru Member

    Try this script in the startup shell :

    sleep 2
    echo "4096" > /proc/sys/net/ipv4/ip_conntrack_max
    sysctl -w net.ipv4.ip_conntrack_tcp_timeouts="1800 3600 120 60 120 120 10 60 30 120"
    It will change the max connexion of the Ip stack to 4096 as said by Toxic and the TTL to 1 hour (vs 5 days by default if i'm not mistaken).
    TTL, often overlooked, is the key for P2P stable connections on hardware firewalls.[/quote]
  7. xond

    xond Network Guru Member

    I am going to try it immediately.
    Thanks for your help.

    What bothers me is that wireless connections were very stable before being now very unstable. May be the hardware has become defective ?
  8. Panders

    Panders Guest

    Have the same problem with the latest hyperWRT.
    Lost connection. Must reactivate to get connection.
  9. xond

    xond Network Guru Member

    I have tried various firmwares to no avail.
    Even Sveasoft alchemy ...from which after flashing back to hyperwert 2b3 I have never been been able to ressucitate my WRT54G.... I could not ping it even though I tried every trick on hyperwrt website to revive it. I had to buy a new one. Beware.

    I wonder whether my problems are linked to using WPA, as some old threads might suggest it. When disconnection occurs there is no response from the network or from internet even though WIN XP indicates a good signal.
  10. bfibandit

    bfibandit Guest

    I am at my wit's end with this router. I have issues when I have any bittorrent transfers going. I've tried the stock firmware, hyperwrt, and sveasoft satori with the same results. The router will refuse any new connections for a few minutes. The torrent transfers continue normally and the web config remains accessible, but browsing the internet is out of the question. Mysteriously, everything returns to normal for a few minutes, and then the cycle repeats. I've gone through and turned off any unneccessary features that would cause extra stress on the router (firewall, wireless security, logging, etc.) and also set up the QoS so that HTTP traffic gets high priority at all times. Nothing helps. Has anybody actually solved this problem?

    Any help is GREATLY appreciated!

  11. Ouaibe

    Ouaibe Network Guru Member

    Have you considered the possibility to RMA it? It could be a hardware failure, i have seen such problems post on BBS before and it was back to normal after an RMA procedure.
  12. koitsu

    koitsu Network Guru Member

    For a few months now, I've been fighting with a similar problem -- although it was not specific to Torrent traffic. I'll provide a description of the problem, which will make anyone here who's decently familiar with IP networking cringe and say "...err... what?"

    Using HyperWRT, I forward TCP port 3389 (Remote Desktop) to one of my local PCs. I do not use wireless anywhere on my network, everything is wired. While at work, I usually RD into my home PC to check Email, etc. etc. -- segregating work and home is a very very good thing.

    Anyways, I noticed that whenever I would do something UI-intensive on my home PC (via RD) that my RD session would stall for possibly 30-45 seconds -- and in some cases, disconnecting me. The most common thing that would do this would be RDing into my home PC, running PuTTY, SSHing to my co-lo box, then running something that would output a _lot_ of terminal traffic (i.e. a mergemaster, dmesg over and over and over, etc.). Not bursty traffic per se, but a large sum of traffic as a whole. This would kill my RD, sometimes it would also disconnect me from my co-lo box, and even sometimes drop me from an IRC server I maintain.

    A couple days ago, I became ultimately fed up with this problem, and decided to debug it while at work (since I can't effectively debug it while at home). I fired up 3 different consoles (cmd.exe) and ran ping -t to different destinations in my network -- one was to (my WRT54GS w/ HyperWRT), one was to (my DSL bridge (yes, a bridge that monitors layer 4 traffic, heh)), and one was to a router a few hops upstream, but still on the SBC (my ISP) network. I then ran PuTTY, ssh'd to my co-lo box, and generated a lot of terminal traffic.

    What I found was dropped packets to (WRT54GS+HyperWRT),, and the router on SBCs network. One packet did make it through, but had a RTT delay of over 2500ms. Again, I point out that the PC running these pings is physically wired to my WRT54GS. The fact that I was seeing _dropped packets_ to a machine on my LOCAL NETWORK baffled me. I immediately thought it was something with kernels the WRT54GS rely on (an old version of Linux -- this isn't for debate, folks. It *IS* old), but decided to take a different route first: assuming my Windows box was being a bitch.

    I had a couple of troubleshooting ideas in my head:

    1. Tinker with some of the IP stack settings in Windows XP, particularly MTU size, TCP window size, and look for any throttling variables XP supported for TCP SYN packets (i.e. too many SYNs in a short period of time, which might make XP assume there was a DoS going on).
    2. Tinker with my NIC driver settings, particularly Ethernet frame size, 802.1p (layer 3 QoS), IRQ throttling settings, WOL, and frame checksumming (which is known to be broken on a lot of different mainstream NICs). FYI, the NIC I use is an on-board 3Com 3C940 Marvell (motherboard is Asus P4C800 Deluxe).
    3. Replace the NIC with something else to see if it's a driver or hardware problem. Preferrably, the Intel NIC I had laying around from one of my servers...

    I actually skipped #1, because I didn't want to go digging through the Registry. I hate the damned thing. I figured I'd deal with that while I was at home. But, I did check local MTU, which was set to 1500 (100% correct).

    #2 resulted in a lot of fun. I turned off support for 802.1p, disabled hardware flow control (sym+asym), disabled hardware frame checksums, disabled IRQ throttling, and disabled WOL -- all to no avail. I put these options back to their appropriate defaults.

    Next up was adjusting the receive/transmit buffer size for Ethernet frames. Both were set to a value which baffled me: 50. This, IMHO, is an incredibly low value for a NIC. The permitted range was 25 to 200; I figured a more appropriate value would be around 125 or 150.

    Surprise surprise -- this fixed the problem I was having. :)

    Just thought this story might help some out, and might give people a new perspective on what to be looking for. I'm honestly not sure why one would need to increase Linux's concurrent TCP session count from 1024 to 4096 to solve Torrent problems, but I digress.

    Hope this helps, FWIW...
  13. agent86

    agent86 Guest

    Setting the receive/transmit buffers?

    I'm having this same problem, or at least a very similar one. My WRT54G resets under a relatively heavy load, but only when Windows XP machines are on the network. All these machines are wired. I've read about a similar problem with wireless setups, and now this. My question is, how exactly does one go about setting the receive/transmit buffer sizes for Ethernet frames? I have looked in the "Advanced" tabs of a couple machines' NICs, but only one had a similar setting, and the fields' ranges were 64-128.

    I appreciate anyone's help.
  14. RoundSparrow

    RoundSparrow Network Guru Member

    How do you change this value?


Share This Page