Hello Julian, > > So you're saying it looks like it works right, but it doesn't ? Hm, ok. > > So are the times when it doesn't work totally random, or is there some > > logic in it ? > > Nothing is random :) The problem comes when the cached > route entry expires (/proc/sys/net/ipv4/route/gc_timeout) or the > cache is flushed as result of a user command such as adding/deleting > IP address or flushing the routes explicitly with "ip route cache flush". > The result is clear: the routing cache forgets the path and the NAT > code does not care. Hm, OK. I checked the value on my system and it's set to 300, which IIRC would mean 5 minutes (it's in seconds, right ?). The ssh connection set up takes only about 2 seconds. Isn't it highly unlikely that the cache would have a timeout in that interval, *reliably*, every time ? > > > I hope there will be effect > > > > On first inspection, no. Is there some way I can debug incoming packets ? > > What else can I give as feedback ? > > You have to be able to analyze with tcpdump what is going on. OK, I used both iptraf and tcpdump to check what is going on, and I find something very odd. Traffic does indeed go out on two interfaces, as traceroutes and output of last on the boxes I ssh to show. But using both tcpdump and iptraf, I only see non-tcp data going over eth2. None of the tcp-connections show up on eth2. They do on eth1. The only difference I can see is that ifconfig shows eth2 to be "UP BROADCAST NOTRAILERS RUNNING", while eth1 is "UP BROADCAST RUNNING MULTICAST". Other than that, the total received traffic is roughly the same on both interfaces (which is weird, since I still cannot connect from the outside over eth2), while the transmitted data for eth1 is 10 times larger than for eth2. I'm not sure if this is because somehow traffic going out over eth2 is not "registered" right (as seen by tcpdump and iptraf) or because of something else. I'm not that experienced using tcpdump, so I can't tell. Also, I don't know enough about the lesser-used output from ifconfig since I never needed it before ;) Is there something that could explain this weird behaviour ? Or are there some hints or guides to use tcpdump correctly in debugging this particular problem ? All of this, btw, is done with my patched kernel including your patches (just to make sure ;) ) Thanks in advance, Thomas -- The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/ <-*- -*-> "You don't need a girlfriend, you need a maid !" "Isn't that the same thing ?" "Uh uh, baby, you're in the wrong century." <-*- thomas@apestaart.org -*-> URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/
