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]*) -- `The sword we forged has turned upon us Only now, at the end of all things do we see The lamp-bearer dies; only the lamp burns on.' ------------------------------------------------------- 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
