From: Nix <ni...@es...> - 2004-12-15 17:02:35
|
Ever since upgrading to the 2.4.27-1 UML-applied-to-2.4.28 (from 2.4.24-2-applied-to-2.4.26), I've been seeing decidedly peculiar network interaction. Notably, the UML ceases responding to network packets for up to a minute and a half at a time, then restarts again just as quietly: the console-on-network-port freezes at the same time. The UML continues running and packets get queued on either side of the... blockage, and are allowed through when it lifts. Example, pinging every five seconds (this one happened to be a fairly short blockage): 64 bytes from 192.168.14.1: icmp_seq=57 ttl=64 time=1.1 ms 64 bytes from 192.168.14.1: icmp_seq=58 ttl=64 time=1.3 ms 64 bytes from 192.168.14.1: icmp_seq=59 ttl=64 time=1.3 ms 64 bytes from 192.168.14.1: icmp_seq=60 ttl=64 time=1.3 ms 64 bytes from 192.168.14.1: icmp_seq=61 ttl=64 time=7993.1 ms 64 bytes from 192.168.14.1: icmp_seq=62 ttl=64 time=14206.3 ms 64 bytes from 192.168.14.1: icmp_seq=63 ttl=64 time=9219.6 ms 64 bytes from 192.168.14.1: icmp_seq=64 ttl=64 time=4219.6 ms 64 bytes from 192.168.14.1: icmp_seq=65 ttl=64 time=1.3 ms The blockages happen quite intermittently, but I'd estimate the mean time between blockages to be about ten minutes. The UML has two network interfaces, both bridged tun/tap interfaces: the one I'm pinging down here, and another, bridged to an ADSL router, traffic-shaped, and firewalled with iptables. (This may be an iptables bug: I'll build a UML without iptables and with only one interface tonight, and see if the problem still occurs.) Anyone seen anything like this before? Any suggestions as to how I might debug it? -- `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.' |