Am Sonntag, 28. Januar 2007 03:24 schrieb Waldemar Brodkorb: > Hi, > > On Tue, 23 Jan 2007 at 9:33 +0100, Klaus Reimer wrote: > > Hello, > > > > I'm using FreeWRT 1.0 on a Asus WL-500g Premium and have a strange > > problem which seems to be related to the bittorrent protocol (or maybe > > the way how Azureus implements it). I'm not ABSOLUTELY sure about this > > but I could reproduce it several times. > > > > After I had installed FreeWRT I did not experience any problems in the > > first 2 days. Even downloading multiple Gigs of data via SCP worked > > flawlessly. Then I started the bittorrent client Azureus. After some > > hours of work (Down and upstream around 10KB/s) I lost the Internet > > connection and I could no longer access the router via LAN or WLAN. > > After resetting it everything was working again. Azureus continued with > > it's work. Some hours later the router was again no longer available. A > > reset fixed it again. > > > > The next day I did not use Azureus and the Internet connection was > > stable, the router was accessible all the time. The next day I used > > Azureus again and the router died again. The next day it worked > > flawlessly because I did not use Azureus. I begin to see a pattern here. > > > > Yesterday I noticed another strange thing. Azureus was running again and > > I was online in Second Life. Then I noticed that I could no longer > > access websites, Azureus stopped working and I could again no longer > > access the router. But Second Life was still working for some minutes. > > Normally I can no longer move in there when the Internet connection is > > lost but I could even teleport to other regions, so Second Life > > definitely had an Internet connection. But after some minutes this one > > died, too. So maybe for some time existing connections are still working > > while new connections are blocked. > > > > Any idea what can cause this? Because the router always dies only when > > Azureus is running I'm pretty sure its related to the bittorrent > > protocol. Maybe bittorrent opens lots of connections during the time the > > client is running and the router keeps track of all these connections > > (to masquerade them) and then some internal table is full and netfilter > > stops working? Are there tools to prove this? Can I display the current > > NAT translation table? > > > > Or does FreeWRT use a special NAT module for the bittorrent protocol > > which can cause such problems? Unfortunately I don't have a serial > > console yet so I can't see any console messages after the router dies. > > There is no special NAT module for bittorrent protocol. Are you > loaded any traffic shaping modules? (kmod-sched package) > Can you try to install rmeote syslog and may be net-snmp to analyze > the problem further? > > The problem seems to be related to: > http://www.freewrt.org/trac/ticket/165 > > The user reported to use Limewire. I never use p2p stuff, because I > am to lazy, so I never recognized any problems on my routers. > > I would like to get this bug fixed. Did the tipps from Torge helped? > May be net-snmp statistics will show, that the memory is full and > the system reboots with OOM.
I think it could be the conntrack table. On my asus WL500gP conntrack gets loaded with this output: -> ip_conntrack version 2.1 (5953 buckets, 5953 max) - 360 bytes per conntrack This means that it can handle 5953 connections, and after this the table is full and new connections will be dropped. This "max" value can be manipulated via /proc/sys/net/ipv4/ip_conntrack_max, but be aware that you need some free memory if you increase the amount of connections that conntrack can handle. You might try to double the amount of connections, but please don't try to get a million connections working on a embedded device :) But In real life this can cause a non accessable router easly, because even ssh (or other mechanisms) gets unreachable due to the router dropping every new connection (even if the new connection wouldn't need nat at all). This might result in some bittorrent downloads still retrieving data (because that are old connections already in the conntrack table), but everything else gets more or less unusuable. Because you don't have a vga out or something like this, this can feel like the router crashed. It would be good if you could take a look at the output of: "cat /proc/net/ip_conntrack | wc -l", because if it's getting close to 5953 (or your actual conntrack table size) when you have your p2p stuff running, then this is most likely your problem. p2p networks really can cause a lot of connections (depending on the client configuration) and 6000 connections (remember, half-open & half-closed connections are also counting) isn't really so much. ah, and you don't have that from me, but this is a quite easy way to DoS a linux firewall. Even bigger machines doesn't handle millions of connections, especially if the admin doesn't know about it and is using the default ip_conntrack_max proc value). So all you have to do is opening a lot of connections. Use a destination that doesn't answer to your syn pakets at all, so that the firewall will have that in it's conntrack table with an "unreplied" state for quite a time. If you do this long enough the firewalls conntrack table is full and is not working anymore for new connections. Depending on the configuration of the firewall, this can be done from internal or even external. :) bye, Ralph _______________________________________________ freewrt-users mailing list freewrt-users@freewrt.org https://www.freewrt.org/lists/listinfo/freewrt-users
