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