Am Dienstag, 30. Januar 2007 21:18 schrieb Klaus Reimer: > Klaus Reimer wrote:
Hi Klaus, > > Haven't configured syslog yet to log onto my notebook. I'll configure it > > this evening and hope it will tell me something interesting before it > > dies. > > So I gave it another try, configured remote syslogging and additionaly > wrote a script which logged the free memory every 5 seconds to syslog. > Here are the famous last words of the router (and some previous logging > lines so you can see how the memory usage increases): thank you very much! This should help a lot... > Jan 30 19:30:40 hellsgate.home root: Free Memory: 11988 > ... > Jan 30 19:40:35 hellsgate.home root: Free Memory: 11796 > ... > Jan 30 19:51:15 hellsgate.home root: Free Memory: 11792 > ... > Jan 30 20:00:02 hellsgate.home root: Free Memory: 11784 > ... > Jan 30 20:10:06 hellsgate.home root: Free Memory: 11640 > ... > Jan 30 20:20:20 hellsgate.home root: Free Memory: 11496 > ... > Jan 30 20:30:04 hellsgate.home root: Free Memory: 11360 > ... > Jan 30 20:40:03 hellsgate.home root: Free Memory: 11176 > ... > Jan 30 20:50:07 hellsgate.home root: Free Memory: 11012 > ... > Jan 30 20:55:09 hellsgate.home root: Free Memory: 10984 > Jan 30 20:55:14 hellsgate.home root: Free Memory: 10960 > Jan 30 20:55:19 hellsgate.home kernel: dst cache overflow > Jan 30 20:55:19 hellsgate.home root: Free Memory: 10964 > Jan 30 20:55:21 hellsgate.home kernel: dst cache overflow > Jan 30 20:55:23 hellsgate.home last message repeated 4 times > Jan 30 20:55:24 hellsgate.home root: Free Memory: 10960 > Jan 30 20:55:24 hellsgate.home kernel: NET: 1 messages suppressed. > Jan 30 20:55:24 hellsgate.home kernel: dst cache overflow > Jan 30 20:55:34 hellsgate.home kernel: NET: 85 messages suppressed. > Jan 30 20:55:44 192.168.36.1 kernel: dst cache overflow > Jan 30 20:55:54 192.168.36.1 root: Free Memory: 10960 > > The memory usage increases but It doesn't look like it has anything to > do with the crashing router. This increase may be normal because Azureus > sees lots of different IPs during the session, resolves them into > hostnames (cached by dnscache), conntrack tables, what ever. I hope (and I am quite sure) your system doesn't resolve each reverselookup, because this is totally useless for the communication. But you are right, the memory doesn't seem to be the problem here. > What exactly means "dst cache overflow"? And what is "NET: 85 messages > suppressed"? Maybe I need to increase some logging level to see these > suppressed and maybe important messages? The easy thing to explain is the "NET: 85 messages suppressed" message you are seeing. This is just a kind of spam protection of your kernel/syslog. It means that there normaly would have been 85 more messages in your syslog saying you that the dst cache overflowed. It keeps the log a bit shorter :) The "dst cache overflow" is the really improtant info here. I think it has something to do with the route cache of your system. Every linux system remebers what route it used for reaching a destination. It looks like this table is full on your system and that's why it's "crashing". Maybe it's not even really crashing but only becomes unreachable via tcp/ip. hard to say without serial connection to your router. And I am not a kernel developer and I do not know what normaly should happen when the route cache is full, but I guess something more clever like flushing old information would be the correct solution for this kind of problem. Maybe here is something broken in the network stack of the freewrt kernel. At least it seems so to me. > Also interesting to see that DNS resolving no longer works in the last > two log lines sent by the browser. So the router was already dying while > it still was able to sent log lines before it died completely. or it flushed the routing information who to reach your client pc and wasn't unable to relearn it because of the overflowing routing cache... hmmm. :) you could try to fix this by running "ip route flush cache" every minute or so, but this only a workaround for your problem, not a real soulution. regards, Ralph _______________________________________________ freewrt-users mailing list [email protected] https://www.freewrt.org/lists/listinfo/freewrt-users
