Subject: RE: inet stopped working?!?
To: Brett Lymn <email@example.com>
From: Martin Husemann <firstname.lastname@example.org>
Date: 02/17/2000 06:42:57
> At a guess I would say that the kernel is not seeing interrupts from
> the card - does dmesg report the card on the same interrupt et al with
> the new and old kernels?
No, that's not the problem.
First, the machine with the new kernel sees the ARP packets from the other
systems. Second, even ISDN connections don't work - they establish the ISDN
connection, but can't get packets through. And I can assure you the kernel
needs to see several interrupts from the ISDN card before it will have an
ISDN layer 3 connection established.
It's a generic inet bug. Does it not manifest on other machines? Then I'll
have to dig into it, but I couldn't afford this machine to be down for
The interfaces here are:
[~] martin@rumolt > ifconfig -a
vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
media: Ethernet autoselect (none)
inet 184.108.40.206 netmask 0xfffffff8 broadcast 220.127.116.11
lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 32976
inet 127.0.0.1 netmask 0xff000000
ipr0: flags=2811<UP,POINTOPOINT,SIMPLEX,LINK1> mtu 1500
inet 18.104.22.168 --> 192.168.110.42 netmask 0xffffffff
ipr1: flags=2810<POINTOPOINT,SIMPLEX,LINK1> mtu 1500
isp0: flags=a051<UP,POINTOPOINT,RUNNING,LINK1,MULTICAST> mtu 1500
inet 22.214.171.124 --> 126.96.36.199 netmask 0xffffffff
isp1: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
The multiple 188.8.131.52 interface have triggered a generic IP routing bug
before (the last-minute-fix which caused one of the first patches against
1.4 back then), somebody changed something in that area lately?