syscall: ParseRoutingSockaddr crushes notified network addresses

[gopherbot]

by p@google.com:

What does 'go version' print?

go version devel +0f7c69d6c367 Mon May 12 17:19:02 2014 -0400 darwin/amd64

What steps reproduce the problem?

Parse RTM_NEWADDR messages on a mac.

If possible, include a link to a program on play.golang.org. (I attached one as a file)

1.  read the PF_ROUTE socket
2.  parse messages using syscall.ParseRoutingMessage and syscall.ParseRoutingSockaddr
3.  turn wifi off and on


What happened?

You'll get back a netmask and a bogus address.
The pkg code is wrong, see fix below.

What should have happened instead?

You get back a netmask and a good address.

Please provide any additional information below.

go/src/pkg/syscall/route_bsd.go:156

was:
        if m.Header.Addrs&rtaIfaMask&(1<<i) == 0 {

should be:
        if m.Header.Addrs&(1<<i) == 0 {

Otherwise the subsequent loop gets confused about what address it is parsing, i.e, it
doesn't skip over the ones its trying to ignore.   Easy fix.

Attachments:

1. broken.go (1474 bytes)

[gopherbot]

Comment 1 by p@google.com:

Looking more closely, the same bug also exists in:
route_darwin.go, route_dragonfly.go and route_freebsd.go.

[ianlancetaylor]

Comment 2:

Labels changed: added repo-main, release-go1.4.

[mikioh]

Comment 3:

I'm not sure what you are suggesting. So which are you suggesting; a)
ParseRoutingSockaddr should parse SockaddrDatalink, b) ParseRoutingSockaddr should not
parse prefix state change announcements that hold only prefix mask, c) both of a and b,
d) other.
I'm fine with (a) but am not keen on other.
P.S. I'd recommend you to capture not only RTM_{NEW,DEL}ADDR but RTM_{NEW,DEL}ROUTE for
dealing with network facility (especially link and its belongings) changes on Darwin. On
other BSDs, interface announcements (a series of IFAN_XXX messages) would be great help.

Attachments:

1. soso.go (1894 bytes)

[mikioh]

Comment 4:

Ah, I now see your point. At least ParseRoutingSockaddr should not crush the notified
network addresses.

[gopherbot]

Comment 6:

CL https://golang.org/cl/105220043 mentions this issue.

[mikioh]

Comment 7:

i've just sent a cl for fixing this issue. pls have a look at
https://golang.org/cl/105220043 if you have a spare time.
> Easy fix.
it needs a bit more work for parsing conventional bsd routing messages and socket
addresses.

[rsc]

Comment 8:

mikioh, what happened with this? It looks like the CL 105220043 was deleted because it
was in syscall. Did go.sys get the fix?

Status changed to Accepted.

[gopherbot]

Comment 9:

CL https://golang.org/cl/164140044 mentions this issue.

[rsc]

Comment 10:

This issue was closed by revision 96e9e81.

Status changed to Fixed.

[mikioh]

Comment 11:

thanks for the fix. seems like there are still a few bugs related to the kernel-internal
form which is similar to nlri encoding. fortunately it won't hurt the net package and
its network interface api because looks like nlri-like encoding is used for both
unicast/multicast route messages and network-layer adj. messages. perhaps we might need
to encourage people not to use ParseRoutingMessage for scraping various routing messages.
ps: i now have no plan to contribute for go.sys.