page@ulowell.cs.ulowell.edu (Bob Page) (09/26/87)
I just added a dmr-11 to a 4.3 system, and can't talk to it. I say:
ifconfig il0 inet 129.63.1.1 broadcast 129.63.1.0 -trailers netmask 0xffff0000
ifconfig dmc0 inet 128.188.230.2 128.188.230.1 -trailers netmask 0xffff0000
and after starting routed, 'netstat -rn' shows:
Destination Gateway Flags Refcnt Use Interface
127.0.0.1 127.0.0.1 UH 0 14 lo0
128.188.230.1 128.188.230.2 UH 0 0 dmc0
128.188.230.2 129.63.1.1 UH 0 29 il0
129.63.1.1 129.63.1.1 U 0 198 il0
128.188 128.188.230.1 UG 0 0 dmc0
129.63 129.63.1.1 U 1 2914 il0
I can use the 129.63 network, but can't get to the 128.188 net. Routed
sets up the 128.188.230.2 route via 129.63.1.1; it's not in my gateways
file. I can ping my dmc at 128.188.230.2 but don't believe it; netstat
shows all the traffic is going through il0. I can't talk to 128.188.230.1,
and if I delete the route from 129.63.1.1 to 128.188.230.1 I can no longer
ping the dmc. Any attempt results in a "Network is unreachable" message.
How can I set up the routes so I can get to the 128.188 network?
I'm running stock 4.3 routed. Thanks in advance.
..Bob
--
Bob Page, U of Lowell CS Dept. page@ulowell.{uucp,edu,csnet} narten@PURDUE.EDU (Thomas Narten) (09/27/87)
Bob,
Here is a 4.3 kernel problem that would give the symptoms you
describe. I don't take credit for finding the bug, but I did remember
to save it where I could find it! One way you can verify that this is
really your problem is to see if things work if you *don't* run
routed. Routed will time out routes for interfaces that aren't
working. An interface "doesn't work" if no routed packets are received
with a source address on the network. If UDP packets are being sent
with an incorrect source address, this will certainly confuse routed.
Thomas
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.bugs.4bsd,comp.unix.wizards
Subject: 4.3bsd can mistake p-to-p interfaces
Message-ID: <717@mcgill-vision.UUCP>
Date: 29 Mar 87 09:26:28 GMT
Organization: McGill University, Montreal
Lines: 50
Posted: Sun Mar 29 04:26:28 1987
We are running mtXinu 4.3+NFS, and there is a bug in netinet/in_pcb.c.
I can't be certain, but I expect that this is present in 4.3 because it
is an obvious mistake once noticed; in fact earlier in the file there
is another opportunity for the same bug but someone noticed it. The
symptom is that packets being sent over UDP sockets, such as used by
routed(8), get stamped with the wrong "from" address. This is because
in_pcbsetaddr() is calling ifa_ifwithdstaddr() with the socket address
it is looking for, instead of a socket address with a zero port number.
Ifa_ifwithdstaddr is then comparing the entire 14 bytes of sockaddr
data to the data in the ifaddr entry, and of course the sockaddr in the
ifaddr entry has a zero port number. So the compare fails. The
earlier code I referred to is a similar call to ifa_ifwithaddr(); look
for yourself for the fix used. The fix I used is similar; here is the
original code:
if (ia == 0) {
ia = (struct in_ifaddr *)
ifa_ifwithdstaddr((struct sockaddr *)sin);
if (ia == 0)
ia = in_iaonnetof(in_netof(sin->sin_addr));
if (ia == 0)
ia = in_ifaddr;
if (ia == 0)
return (EADDRNOTAVAIL);
}
and here is my fixed version (I know it isn't pretty, I didn't care
about esthetics when I fixed it):
if (ia == 0) {
int oldport;
oldport = sin->sin_port;
sin->sin_port = 0; /* for ifa_ifwithdstaddr */
ia = (struct in_ifaddr *)
ifa_ifwithdstaddr((struct sockaddr *)sin);
if (ia == 0)
ia = in_iaonnetof(in_netof(sin->sin_addr));
sin->sin_port = oldport;
if (ia == 0)
ia = in_ifaddr;
if (ia == 0)
return (EADDRNOTAVAIL);
}
der Mouse
Smart mailers: mouse@mcgill-vision.uucp
USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!musocs!mcgill-vision!mouse
think!mosart!mcgill-vision!mouse
ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu