>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
>debugging yesterday.

	can you check netstat -s?  is there anything streange appear on output?

>The interfaces here are:
>
>[~] martin@rumolt > ifconfig -a
>vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>        address: 00:80:c8:f9:e4:37
>        media: Ethernet autoselect (none)
>        status: active
>        inet 212.8.203.81 netmask 0xfffffff8 broadcast 212.8.203.87
>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 212.8.203.81 --> 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 212.8.203.81 --> 212.8.192.1 netmask 0xffffffff
>isp1: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
>
>The multiple 212.8.203.81 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?

	I think I did.  but I don't think this breaks in your case (sorry
	if I was wrong).
	http://cvsweb.netbsd.org/bsdweb.cgi/syssrc/sys/netinet/ip_input.c
	1.99 -> 1.100

	The rationale here is like this.  Suppose a packet with
	ip_src = S, ip_dst = D have reached to a node.
	- with 4.4BSD, a node will accept the packet if D matches any of
	  interface addresses configured, regardlees from IFF_UP status
	  of the interface.  a packet will get accepted even if D matches
	  an interface address configured on top of !IFF_UP interface.
	- 1.4.1 changes this to ignore IFF_UP interface.  There was a
	  mistake in it.  If D matches an interface address configured on top
	  of !IFF_UP interface, and if the node is a router, the packet
	  will be forwarded in the kernel (on loopback interface) until
	  it reaches TTL = 0.  PR9387 describes it.
	- PR9387 was not perfect, when D matches to multiple interface
	  addresses, and one of them are IFF_UP and one of them are !IFF_UP.
	  1.99 -> 1.100 tries to address this case, by following behavior:
	  (1) accept if D matches an interface address 
	  (2) handle multicast/whatever cases properly, if D is multicast
	  (3) if none of the above are successful, do the following:
		if (the node is router) {
			if D matches my address on !IFF_UP interface, drop it
			otherwise, forward it
		} else
			drop it
	  This follows same mindset as 1.4.1 (!IFF_UP interface address should
	  be ignored), just prevent infinite in-kernel forwarding loop.

itojun