Yep, I realised after I sent it, my packets were dropped when I had something I thought was similar.
Sorry for the noise. On Fri, 2004-12-17 at 01:01 +0000, Nix wrote: > On Thu, 16 Dec 2004, Antoine Martin spake: > > Looks to me like this is a routing problem, check your arp tables and > > your routes. It may be that something is occasionally causing a packet > > to come out of the wrong interface/wrong mac, which confuses the lower > > network layers. > > Alas, I don't think it's that simple :( > > My arp tables are simple; virtually everything has the MAC of the ADSL > router. > > Every packet going out of the wrong interface gets syslogged, and I see > no such syslog messages, just heaps of NFS timeout messages. > > (See <http://www.esperi.demon.co.uk/nix/iptables> for my firewall rules; > a few sensitive external IP addresses have been elided. Look at the log > rules therein.) > > ip addr: > > 1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 brd 127.255.255.255 scope host lo > 2: teql0: <NOARP> mtu 1500 qdisc noop qlen 100 > link/void > 3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop > link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff > 4: gordianet: <BROADCAST,MULTICAST,ALLMULTI,UP> mtu 1458 qdisc pfifo_fast > qlen 100 > link/ether 00:60:97:79:e2:c1 brd ff:ff:ff:ff:ff:ff > inet 192.168.14.1/24 brd 192.168.14.255 scope global gordianet > 5: adsl: <BROADCAST,MULTICAST,ALLMULTI,UP> mtu 1458 qdisc cbq qlen 10 > link/ether 00:60:97:79:e2:c1 brd ff:ff:ff:ff:ff:ff > inet 194.247.41.52/24 brd 255.255.255.255 scope global adsl > inet 192.168.14.159/32 scope global adsl > > > ip route: > > 192.168.14.160 dev adsl proto static scope link src 192.168.14.159 > 194.247.41.0/24 dev adsl proto kernel scope link src 194.247.41.52 > 192.168.14.0/24 dev gordianet proto kernel scope link src 192.168.14.1 > 224.0.0.0/4 dev gordianet scope link > default via 194.247.41.52 dev adsl > > > (note an arcaneness: the ADSL router is on 192.168.14.160, the same > subnet as all the stuff on the other interface: it's accessed via a > different source address (to avoid being masqueraded). > > > ... hm. Some more info. This is definitely an interface-specific thing. > The blockages appear to affect different interfaces at different times: > i.e., one interface freezes, in both directions --- and it's not just > one destination, it's everyone except for myself. e.g., pinging the > broadcast address on the local net: > > 64 bytes from 192.168.14.1: icmp_seq=343 ttl=64 time=9.7 ms > 64 bytes from 192.168.14.16: icmp_seq=342 ttl=64 time=5010.4 ms (DUP!) > 64 bytes from 192.168.14.14: icmp_seq=342 ttl=64 time=5011.0 ms (DUP!) > 64 bytes from 192.168.14.18: icmp_seq=342 ttl=64 time=5011.5 ms (DUP!) > > I'm starting to suspect the host's TUN/TAP here, y'know: the fact that > it's a simultaneous bidirectional freeze, and that the packet to myself > (automatically sent directly to myself by the kernel) is *not* delayed > is possibly significant. > > (But there were no TUN/TAP changes between 2.4.26 and 2.4.28. Damn. > Maybe it's TCP Vegas or something? *clutches at straws in > ChangeLog-2.4.2[78]*) > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ User-mode-linux-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
