Changing the default subnet route.

[Roy Marples]

Following up with a test case which shows what I think is a kernel bug.
I've tested this on NetBSD-4.0.1, 5.0BETA and 5.99.4 - all the same.

# ifconfig re0 alias 192.168.1.10/24
# ifconfig ral0 alias 192.168.1.20/24
# route change 192.168.1.0/24 -ifp ral0
change net 192.168.1.0
# ifconfig re0 -alias 192.168.1.10/24
# ifconfig re0 alias 192.168.1.10/24
ifconfig: SIOCAIFADDR: File exists
# ifconfig re0
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 1 mtu
1500
capabilities=3f80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx>
enabled=0
address: 00:50:8d:bb:da:f8
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet6 fe80::250:xxxx:xxxx:xxxx%re0 prefixlen 64 scopeid 0x1

As you can now see, it's impossible to add or remove any address in the
192.168.1.0/24 range to re0 until the subnet route itself is removed.

If this is NOT considered to be a kernel bug then could someone please
tell me how I should go about changing the connected route (as it's
described in the source)?

Attached is a simple shell test program.

Thanks

Roy

[Christos Zoulas]

-=-=-=-=-=-
-=-=-=-=-=-
Following up with a test case which shows what I think is a kernel bug.
I've tested this on NetBSD-4.0.1, 5.0BETA and 5.99.4 - all the same.
# ifconfig re0 alias 192.168.1.10/24
# ifconfig ral0 alias 192.168.1.20/24
# route change 192.168.1.0/24 -ifp ral0
change net 192.168.1.0
# ifconfig re0 -alias 192.168.1.10/24
# ifconfig re0 alias 192.168.1.10/24
ifconfig: SIOCAIFADDR: File exists
# ifconfig re0
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 1 mtu
1500
capabilities=3f80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx>
enabled=0
address: 00:50:8d:bb:da:f8
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet6 fe80::250:xxxx:xxxx:xxxx%re0 prefixlen 64 scopeid 0x1
As you can now see, it's impossible to add or remove any address in the
192.168.1.0/24 range to re0 until the subnet route itself is removed.
If this is NOT considered to be a kernel bug then could someone please
tell me how I should go about changing the connected route (as it's
described in the source)?
Attached is a simple shell test program.
Thanks
Roy

Send-pr please.

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Christos Zoulas
Send-pr please.

Filed as kern/40133.

I think the issue is because IFA_ROUTE isn't moved correctly as I've
looked closely at address addition/deletion but not yet route changing.

Thanks

Roy

[Roy Marples]

Post by Roy Marples

Post by Christos Zoulas
Send-pr please.

Filed as kern/40133.
I think the issue is because IFA_ROUTE isn't moved correctly as I've
looked closely at address addition/deletion but not yet route changing.

Well, I was wrong about the cause :)
The error is that in_addprefix assumes that only it will add subnet
routes. So any manually added routes will cause this error. Attached is
a patch to fix this (in.diff).
Also, I think that for deleted routes, we should scrub the IFA_ROUTE
flag from the ia, and preserve it when when changing routes. This has no
bearing on the issue at hand, but does make sense imo.
Comments?

No comments for a while then :)
OK to commit?

Thanks

Roy

[Christos Zoulas]

On Dec 21, 12:59pm, ***@marples.name (Roy Marples) wrote:
-- Subject: Re: Changing the default subnet route.

|
| --MIMEStream=_0+292444_14480001722886_5140273272
| Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-N+PfJQTYfdKQo23O+37E"
| Mime-Version: 1.0
|
|
| --=-N+PfJQTYfdKQo23O+37E
| Content-Type: text/plain
| Content-Transfer-Encoding: quoted-printable
|
| On Sun, 2008-12-14 at 00:06 +0000, Roy Marples wrote:
| > On Sun, 2008-12-07 at 18:24 +0000, Roy Marples wrote:
| > > On Fri, 2008-12-05 at 17:04 +0000, Christos Zoulas wrote:
| > > > Send-pr please.
| > >=20
| > > Filed as kern/40133.
| > >=20
| > > I think the issue is because IFA_ROUTE isn't moved correctly as I've
| > > looked closely at address addition/deletion but not yet route changing.
| >=20
| > Well, I was wrong about the cause :)
| > The error is that in_addprefix assumes that only it will add subnet
| > routes. So any manually added routes will cause this error. Attached is
| > a patch to fix this (in.diff).
| >=20
| > Also, I think that for deleted routes, we should scrub the IFA_ROUTE
| > flag from the ia, and preserve it when when changing routes. This has no
| > bearing on the issue at hand, but does make sense imo.
| >=20
| > Comments?
|
| No comments for a while then :)
| OK to commit?

I say yes.

christos

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Christos Zoulas
| No comments for a while then :)
| OK to commit?
I say yes.

Committed!

Once dhcpcd-4.0.7 is pulled into NetBSD-5 then we can safely update to
dhcpcd-4.99 now that the kernel works fine with the routing manipulation
strategy.

I'd like to see those two fixes pulled into NetBSD-5 (maybe -4 also?) as
well, so that I can put dhcpcd-5 into pkgsrc without fear. Should I
request this in a few weeks to give the patches time to settle?

Thanks

Roy

[Christos Zoulas]

On Dec 21, 7:20pm, ***@marples.name (Roy Marples) wrote:
-- Subject: Re: Changing the default subnet route.

|
| --MIMEStream=_0+142055_5877576989891_65629817192
| Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-YV3rlH3n0GxnzrfB+brQ"
| Mime-Version: 1.0
|
|
| --=-YV3rlH3n0GxnzrfB+brQ
| Content-Type: text/plain
| Content-Transfer-Encoding: quoted-printable
|
| On Sun, 2008-12-21 at 11:01 -0500, Christos Zoulas wrote:
| > | No comments for a while then :)
| > | OK to commit?
| >=20
| > I say yes.
|
| Committed!
|
| Once dhcpcd-4.0.7 is pulled into NetBSD-5 then we can safely update to
| dhcpcd-4.99 now that the kernel works fine with the routing manipulation
| strategy.
|
| I'd like to see those two fixes pulled into NetBSD-5 (maybe -4 also?) as
| well, so that I can put dhcpcd-5 into pkgsrc without fear. Should I
| request this in a few weeks to give the patches time to settle?
|

Yes, waiting a bit is a good idea.

christos

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Arnaud Lacombe]

Hi,

Index: sys/netinet/in.c
===================================================================
RCS file: /cvsroot/src/sys/netinet/in.c,v
retrieving revision 1.128
diff -u -p -r1.128 in.c
--- sys/netinet/in.c 7 Nov 2008 00:20:18 -0000 1.128
+++ sys/netinet/in.c 13 Dec 2008 23:56:43 -0000
@@ -1006,6 +1006,11 @@ in_addprefix(struct in_ifaddr *target, i
error = rtinit(&target->ia_ifa, RTM_ADD, flags);
if (error == 0)
target->ia_flags |= IFA_ROUTE;
+ else if (error == EEXIST)
+ /*
+ * the fact the route already exists is not an error.
+ */
+ error = 0;
return error;
}

Is there any reason this couldn't be special-cased from userland ?
From a quick view at the code, the error code is not critical in
in_ifinit(), and the only implication of the error is that
pfil_run_hooks() is not called in in_control().

Thanks

- Arnaud

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Arnaud Lacombe
Is there any reason this couldn't be special-cased from userland ?

Sure.
According to the tools uses in my test case (ifconfig/route) AND in
dhcpcd no error actually returned until it's too late and the address is
stuck to the interface - it cannot be added or removed.

Or are you implying that userland should never install, modify or delete
an automatic subnet route?

Thanks

Roy

[Arnaud Lacombe]

Post by Roy Marples
Or are you implying that userland should never install, modify or delete
an automatic subnet route?

of course not... just that the error is there for something. Ignoring
it at the kernel level is not the best things to do. Couldn't it be
possible to make the error available (or check for this case) before
it's too late and act in consequence ?

- Arnaud

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Arnaud Lacombe

Post by Roy Marples
Or are you implying that userland should never install, modify or delete
an automatic subnet route?

of course not... just that the error is there for something. Ignoring
it at the kernel level is not the best things to do.

The for loop above ignores the error for automatic routes already added
to same subnet. Why should manually added routes be excluded from this?

That is the source of the error.

Post by Arnaud Lacombe
Couldn't it be
possible to make the error available (or check for this case) before
it's too late and act in consequence ?

How? The code to add and/or remove the IP address now fails. The only
fix (that I found) is to remove all addresses and routes relating to the
subnet and starting over which is hardly optimal.

Thanks

Roy

[David Young]

Post by Roy Marples

Post by Christos Zoulas
Send-pr please.

Filed as kern/40133.
I think the issue is because IFA_ROUTE isn't moved correctly as I've
looked closely at address addition/deletion but not yet route changing.

Well, I was wrong about the cause :)
The error is that in_addprefix assumes that only it will add subnet
routes. So any manually added routes will cause this error. Attached is
a patch to fix this (in.diff).
Also, I think that for deleted routes, we should scrub the IFA_ROUTE
flag from the ia, and preserve it when when changing routes. This has no
bearing on the issue at hand, but does make sense imo.

It seems that the latter patch alone should have fixed the problem.
Why didn't it?

Dave

[David Young]

Post by Roy Marples
Following up with a test case which shows what I think is a kernel bug.
I've tested this on NetBSD-4.0.1, 5.0BETA and 5.99.4 - all the same.
# ifconfig re0 alias 192.168.1.10/24
# ifconfig ral0 alias 192.168.1.20/24
# route change 192.168.1.0/24 -ifp ral0
change net 192.168.1.0
# ifconfig re0 -alias 192.168.1.10/24
# ifconfig re0 alias 192.168.1.10/24
ifconfig: SIOCAIFADDR: File exists
# ifconfig re0
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 1 mtu
1500
capabilities=3f80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx>
enabled=0
address: 00:50:8d:bb:da:f8
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet6 fe80::250:xxxx:xxxx:xxxx%re0 prefixlen 64 scopeid 0x1
As you can now see, it's impossible to add or remove any address in the
192.168.1.0/24 range to re0 until the subnet route itself is removed.

How does this behavior of IPv4 ifaddrs compare with IPv6?

Dave

[Roy Marples]

Post by David Young
How does this behavior of IPv4 ifaddrs compare with IPv6?

A quick test shows that IPv6 behaves correctly here.

ifconfig bge0 inet6 fee1:: alias
ifconfig iwi0 inet6 fee1:: alias
route change -net -inet6 fee1::/64 -ifp iwi0
ifconfig bge0 inet6 fee1:: -alias
ifconfig bge0 inet6 fee1:: alias

However the
fee1:: MACADDR UHL
route is not changed which could be a bug.

Thanks

Roy

[David Young]

Post by Roy Marples

Post by David Young
How does this behavior of IPv4 ifaddrs compare with IPv6?

A quick test shows that IPv6 behaves correctly here.
ifconfig bge0 inet6 fee1:: alias
ifconfig iwi0 inet6 fee1:: alias
route change -net -inet6 fee1::/64 -ifp iwi0
ifconfig bge0 inet6 fee1:: -alias
ifconfig bge0 inet6 fee1:: alias

Did IPv6 work correctly prior to your change to rtsock.c?

Post by Roy Marples
However the
fee1:: MACADDR UHL
route is not changed which could be a bug.

Does the corresponding IPv4 route change?

The fact that IPv6 (sort of) works, now, reinforces my hunch that
your change to in.c was unnecessary, because your change to rtsock.c
was sufficient.

Dave

[Roy Marples]

Post by David Young

Post by Roy Marples

Post by David Young
How does this behavior of IPv4 ifaddrs compare with IPv6?

A quick test shows that IPv6 behaves correctly here.
ifconfig bge0 inet6 fee1:: alias
ifconfig iwi0 inet6 fee1:: alias
route change -net -inet6 fee1::/64 -ifp iwi0
ifconfig bge0 inet6 fee1:: -alias
ifconfig bge0 inet6 fee1:: alias

Did IPv6 work correctly prior to your change to rtsock.c?

From memory, yes it did as the inet6 does does not appear to use
IFA_ROUTE. But I don't have a non-patched kernel handy to test with just
yet.

Post by David Young

Post by Roy Marples
However the
fee1:: MACADDR UHL
route is not changed which could be a bug.

Does the corresponding IPv4 route change?

Why should it? All the above commands referenced -inet6 and should not
affect IPv4 in any way or form.

Post by David Young
The fact that IPv6 (sort of) works, now, reinforces my hunch that
your change to in.c was unnecessary, because your change to rtsock.c
was sufficient.

Pretty sure it's necessary, but when I can build a working kernel
without my patch I'll let you know for sure.

Thanks

Roy

[Roy Marples]

Post by David Young
The fact that IPv6 (sort of) works, now, reinforces my hunch that
your change to in.c was unnecessary, because your change to rtsock.c
was sufficient.

The change to in.c is still necessary, the test script bails with the
same error without it but with the rtsock.c patch. With both patches it
works fine.

Thanks

Roy

[David Young]

Post by Roy Marples

Post by David Young

Post by Roy Marples

Post by David Young
How does this behavior of IPv4 ifaddrs compare with IPv6?

A quick test shows that IPv6 behaves correctly here.
ifconfig bge0 inet6 fee1:: alias
ifconfig iwi0 inet6 fee1:: alias
route change -net -inet6 fee1::/64 -ifp iwi0
ifconfig bge0 inet6 fee1:: -alias
ifconfig bge0 inet6 fee1:: alias

Did IPv6 work correctly prior to your change to rtsock.c?

From memory, yes it did as the inet6 does does not appear to use
IFA_ROUTE. But I don't have a non-patched kernel handy to test with just
yet.

I see IFA_ROUTE all over netinet6/in6.c. :-)

Post by Roy Marples

Post by David Young

Post by Roy Marples
However the
fee1:: MACADDR UHL
route is not changed which could be a bug.

Does the corresponding IPv4 route change?

Why should it? All the above commands referenced -inet6 and should not
affect IPv4 in any way or form.

What I meant was, when you run the corresponding IPv4 script, does
a IPv4 route corresponding to that IPv6 route change, or not?

IPv4 and IPv6 should work quite a lot alike in order to avoid
surprises.

Dave

[Roy Marples]

Post by David Young

Post by Roy Marples

Post by David Young

Post by Roy Marples

Post by David Young
How does this behavior of IPv4 ifaddrs compare with IPv6?

A quick test shows that IPv6 behaves correctly here.
ifconfig bge0 inet6 fee1:: alias
ifconfig iwi0 inet6 fee1:: alias
route change -net -inet6 fee1::/64 -ifp iwi0
ifconfig bge0 inet6 fee1:: -alias
ifconfig bge0 inet6 fee1:: alias

Did IPv6 work correctly prior to your change to rtsock.c?

From memory, yes it did as the inet6 does does not appear to use
IFA_ROUTE. But I don't have a non-patched kernel handy to test with just
yet.

I see IFA_ROUTE all over netinet6/in6.c. :-)

What I meant to say is that I don't see IFA_ROUTE assigned in the same
way for IPv6 as for IPv4. The only assignment in in6.c is for p2p or
loopback according to the comments.

However, the above test works fine on an unpatched kernel for IPv6 which
suggests the correct fix for IPv4 is indeed in in.c.

Post by David Young

Post by Roy Marples

Post by David Young

Post by Roy Marples
However the
fee1:: MACADDR UHL
route is not changed which could be a bug.

Does the corresponding IPv4 route change?

Why should it? All the above commands referenced -inet6 and should not
affect IPv4 in any way or form.

What I meant was, when you run the corresponding IPv4 script, does
a IPv4 route corresponding to that IPv6 route change, or not?
IPv4 and IPv6 should work quite a lot alike in order to avoid
surprises.

Why would you expect changing an IPv4 route to affect an IPv6 route or
vice versa?

Thanks

Roy

[David Young]

Post by Roy Marples

Post by David Young

Post by Roy Marples

Post by David Young

Post by Roy Marples
However the
fee1:: MACADDR UHL
route is not changed which could be a bug.

Does the corresponding IPv4 route change?

Why should it? All the above commands referenced -inet6 and should not
affect IPv4 in any way or form.

What I meant was, when you run the corresponding IPv4 script, does
a IPv4 route corresponding to that IPv6 route change, or not?
IPv4 and IPv6 should work quite a lot alike in order to avoid
surprises.

Why would you expect changing an IPv4 route to affect an IPv6 route or
vice versa?

I don't. I do expect for these two scripts to behave similarly in
their own domains, however:

ifconfig bge0 inet6 fee1:: alias
ifconfig iwi0 inet6 fee1:: alias
route change -net -inet6 fee1::/64 -ifp iwi0
ifconfig bge0 inet6 fee1:: -alias
ifconfig bge0 inet6 fee1:: alias

*** *** ***

ifconfig re0 alias 192.168.1.10/24
ifconfig ral0 alias 192.168.1.20/24
route change 192.168.1.0/24 -ifp ral0
ifconfig re0 -alias 192.168.1.10/24
ifconfig re0 alias 192.168.1.10/24

Dave

[Roy Marples]

Post by David Young

Post by Roy Marples
Why would you expect changing an IPv4 route to affect an IPv6 route or
vice versa?

I don't. I do expect for these two scripts to behave similarly in
ifconfig bge0 inet6 fee1:: alias
ifconfig iwi0 inet6 fee1:: alias
route change -net -inet6 fee1::/64 -ifp iwi0
ifconfig bge0 inet6 fee1:: -alias
ifconfig bge0 inet6 fee1:: alias
*** *** ***
ifconfig re0 alias 192.168.1.10/24
ifconfig ral0 alias 192.168.1.20/24
route change 192.168.1.0/24 -ifp ral0
ifconfig re0 -alias 192.168.1.10/24
ifconfig re0 alias 192.168.1.10/24

With the two patches they now do :)
Well, there is the exception of the IPv6 fee1:: MACADDR UHL route bug
but I'd say that's outside the scope of the initial topic. I also don't
know enough about IPv6 to say if it's a bug or what part of the
kernel/userland is to blame for it.

Thanks

Roy