Subject: /etc/ifaliases causes routing, xntpd heartburn in 1.2.1
To: None <port-sparc@netbsd.org>
From: Greg Earle <earle@isolar.Tujunga.CA.US>
List: port-sparc
Date: 10/06/1998 03:40:57
This isn't necessarily port-specific, of course, but since it's happening
on this particular platform, I thought I'd ask here first.
I'm doing quasi-proxy arp'ing for my machine at home from my machine at work.
Well, it's a little more complicated than that. My home address is assigned
to be 128.149.x.y with an MX for myself and a higher MX for my former PPP
link at work. Well, that host went away, and I had to switch the PPP link
to my officemate's machine and change my address at home to be 128.149.x+z.y
instead. The higher MX went away too, so now I had this problem of hosts
connecting to send e-mail wanted to go to the 128.149.x.y address. Well,
my SS20 at work is on 128.149.x, so I thought, hey, if I put 128.149.x.y
in my /etc/ifaliases, I can get the hosts trying to connect directly to my
home machine to send mail to connect to my work machine instead. Then I
can deal with forwarding the mail to my house directly from my work box.
Kludgey as hell ('til I get my domain name and IP address changed), but hey,
it works.
There's only one problem. Well, two.
For some reason, the presence of this 128.149.x.y entry in my /etc/ifaliases
file causes the system to add a direct network route for all of 128.149.*.*
at boot time. It never used to do this before. So now when I reboot, I
have to manually remember to route delete this network route and re-add just
the correct subnet route to 128.149.x.*. If I forget this, then my forwarding
of mail over to my officemate's SS20 (128.149.x+z.n) fails because it can't
get there from here. I don't know what's making the kernel install this
bogus full unsubnetted network route. My box's address is 128.149.x.y and the
proxy I'm using in /etc/ifaliases is 128.149.x.y+2.
This also seems to have killed "xntpd". Whenever "xntpd" tries to start up,
it claims it can't because the address is already in use. If I fire it up
in debug mode I see:
netbsd4me# xntpd -A -d -d -d -d
tick = 10000, tickadj = 40, hz = 100
kernel vars: tickadj = 40, tick = 10000
adj_precision = 40, tvu_maxslew = 3960, tsf_maxslew = 0.010385c6
create_sockets(123)
bind() fd 4, family 2, port 123, addr 00000000, flags=1
flags for fd 4: 0106
bind() fd 5, family 2, port 123, addr 8095[x][y], flags=1
flags for fd 5: 0106
bind() fd 6, family 2, port 123, addr 8095[x][y+2], flags=1
flags for fd 6: 0106
bind() fd 7, family 2, port 123, addr 7f000001, flags=0
flags for fd 7: 0106
create_sockets: ninterfaces=4
interface 0: fd=4, bfd=0, name=wildcard, flags=0x1
sin=0.0.0.0 bcast=0.0.0.0, mask=255.255.255.255
interface 1: fd=5, bfd=0, name=le0, flags=0x1
sin=128.149.x.y bcast=128.149.x.255, mask=255.255.255.0
interface 2: fd=6, bfd=0, name=le0, flags=0x1
sin=128.149.x.y+2 bcast=128.149.x.255, mask=255.255.255.0
interface 3: fd=7, bfd=0, name=lo0, flags=0x4
sin=127.0.0.1 mask=255.0.0.0
init_io: maxactivefd 7
bind() fd 9, family 2, port 123, addr 8095[x]ff, flags=0
flags for fd 9: 0106
and the attempt to open the next socket fails with
Oct 6 03:02:42 netbsd4me xntpd[14100]: bind() fd 10, family 2, port 123, addr
8095[x]ff, in_classd=0 flags=0 fails: Address already in use
i.e. it tries to bind to the broadcast address twice.
Are either of these behaviors fixed in 1.3.2?
- Greg