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
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
`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.'
Get latest updates about Open Source Projects, Conferences and News.