On Wed, 27 Aug 2008, Dâniel Fraga wrote: > On Wed, 27 Aug 2008 23:32:34 +0300 (EEST) > "Ilpo Järvinen" <ilpo.jarvinen@xxxxxxxxxxx> wrote: > > > Ok. Though this all opens more questions than answers... :-(, why isn't > > there any traffic in neither of the tcpdumps then (not in the client's > > nor in the server's). > > Very strange. In this topic, I saw the discussion about some > routers messing with traffic and frto related stuff, right? My server > is behind some routers that I don't know (because it's not me who > controls these routers). So if the problem is with some of these > routers, I'm afraid we can do nothing about that. Sure, but that still doesn't explain at all why the expected traffic doesn't show up anywhere (ie., the working mail after nmap resolution). Such a router cannot prevent us tcpdumping both ends. My point is that we would always see the packet at least in the sending end's tcpdump. And, would we have the traffic from the end-point tcpdumps, we could trivially figure out what the middlebox did to the traffic. > > I don't think it was bad at all... :-) I just meant that there wasn't any > > other visible traffic, which is very very strange because nothing port 995 > > related (or anything else) seems to happen during the nmap... Which > > network interfaces the server has? Could things get routed through some > > other iface during the time of trouble (and during the nmap solution), > > that would explain why it isn't visible in the tcpdump which is for the > > specific interface. > > fraga@teleporto ~$ ip route list > 10.1.0.6 dev tun2 proto kernel scope link src 10.1.0.5 > 10.195.195.1 dev tun1 proto kernel scope link src 10.195.195.2 > 192.168.102.0/24 via 10.1.0.6 dev tun2 > 200.211.201.0/24 dev eth1 proto kernel scope link src > 200.211.201.248 189.38.0.0/16 dev eth0 proto kernel scope link src > 189.38.18.122 default via 189.38.18.121 dev eth0 > > Well, if that's the problem I'll be very ashamed for wasting > your time. Anyway, eveything should go to eth0 interface, through > 189.38.18.121 gateway. > > The eth1 interface (200.211.201.248) is an old interface which > we do not use anymore. So I'm right now deactivating it (I should do > that for a long time ago). Let's see if the problem remains or not > (although I have other servers with multiple interfaces and everything > is fine, since, as far as I understand, what matters is the default > gateway -- I think that there's no reason to Linux send something to > eth1 interface since there's only one default gateway). Agreed, it shouldn't happen. Do you have a static setup for the IPs or is there dhcp component which could in theory cause some routing table alterations, again I find that unlikely but in the meantime I start to run out of ideas how the client and server can speak with each other without leaving any traces about it (I hope you really used exactly the tcpdump command you told in the mail linking to those stall logs). > Anyway I'm dropping eth1 interface. I'll wait a few days before > confirming if that's the problem or not. > > Thanks again. There's some NAT somewhere btw because the client uses 192.168.0.2 as source address but I don't think that currently has some relevance (it might timeout some connections after an idle period, which is usually of configurable length). -- i.
