Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net: TestInterfaces fails on FreeBSD 11-CURRENT #11641

Closed
swills opened this issue Jul 9, 2015 · 10 comments

Comments

Projects
None yet
5 participants
@swills
Copy link

commented Jul 9, 2015

Full error is:

--- FAIL: TestInterfaces (0.00s)
interface_test.go:74: route ip+net: invalid network interface name

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Jul 9, 2015

@mikioh mikioh closed this Jul 9, 2015

@mikioh mikioh added the OS-FreeBSD label Jul 9, 2015

@mikioh mikioh added this to the Unreleased milestone Jul 9, 2015

@mikioh mikioh changed the title test: 1.5beta1 from source on FreeBSD: net/interface_test.go failure net: TestInterfaces fails on FreeBSD 11-CURRENT Jul 9, 2015

@swills

This comment has been minimized.

Copy link
Author

commented Jul 9, 2015

What version of Go are you using (go version)?

go version go1.5beta1 freebsd/amd64

What operating system and processor architecture are you using?

FreeBSD amd64

What did you do?

tar -xzvf go1.5beta1.src.tar.gz
cd go/src
env CC=cc GOROOT_BOOTSTRAP=/usr/local/go bash all.bash

What did you expect to see?

Test pass

What did you see instead?

--- FAIL: TestInterfaces (0.00s)
interface_test.go:74: route ip+net: invalid network interface name
FAIL
FAIL net 13.270s

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Jul 10, 2015

Thanks. Please let us know your kernel version in next time. The root cause is simply go's routing message parsers still use NET_RT_IFLIST+if_msghdr instead of NET_RT_IFLISTL+if_msghdrl, and seems like the under-development kernel doesn't return correct RTM_IFINFO messages like the following:

# cd $GOROOT/src/syscall
# go test -v -run=Route
    route_bsd_test.go:70: 3 0 ifp [6/unspec/4614 t/n/a/s=2/0/152/0]
    route_bsd_test.go:70: 3 0 ifp [6/unspec/4614 t/n/a/s=2/0/152/0]
    route_bsd_test.go:70: 3 0 ifp [24/unspec/0 t/n/a/s=0/0/152/0]
    route_bsd_test.go:70: 3 2 ifp [6/unspec/4614 t/n/a/s=2/0/152/0]
@swills

This comment has been minimized.

Copy link
Author

commented Jul 10, 2015

Ah, I see. Kernel versions is FreeBSD 11.0-CURRENT #0 r284988: Wed Jul 1 03:59:20 UTC 2015 I'll see if I can produce a patch.

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Jul 10, 2015

I'm not sure whether FreeBSD net subsystem guys want to drop NET_RT_IFLIST in 11-CURRENT. If so, go's routing message parser will use NET_RT_IFLISTL eventually. According to https://www.freebsd.org/releng/index.html, July 2016 is the current scheduled date. So it may happen in go1.7.

@l-d-x

This comment has been minimized.

Copy link

commented Aug 20, 2015

For go1.5 The problem is types_freebsd.go strucht if_data8 and its output ztypes_freebsd_amd64.go ifData do not have matching fields to FreeBSD 11, specifically the position of ifi_datalen which is now uint16_t. In short, types_freebsd.go needs to be fixed up to support FreeBSD-11.

Earlier versions of go uses SizeofIfMsghdr (fixed size):

func (any *anyMessage) parseInterfaceMessage(b []byte) *InterfaceMessage {
    p := (*InterfaceMessage)(unsafe.Pointer(any))
    return &InterfaceMessage{Header: p.Header, Data: b[SizeofIfMsghdr:any.Msglen]}
}

where as 1.5 does (referencing p.Header.Data.Datalen)
:

    return &InterfaceMessage{Header: p.Header,
            Data: b[int(unsafe.Offsetof(p.Header.Data))+int(p.Header.Data.Datalen) : any.Msglen]}

types_freebsd.go:

// this needs:
#undef ifi_epoch
// and
#undef ifi_lastchange to work also.

struct if_data8 {
        u_char  ifi_type;
        u_char  ifi_physical;
        u_char  ifi_addrlen;
        u_char  ifi_hdrlen;
        u_char  ifi_link_state;
        u_char  ifi_spare_char1;
        u_char  ifi_spare_char2;
        u_char  ifi_datalen;
        u_long  ifi_mtu;
        ...
};

FreeBSD if.h:

struct if_data {
    /* generic interface information */
    uint8_t ifi_type;       /* ethernet, tokenring, etc */
    uint8_t ifi_physical;       /* e.g., AUI, Thinnet, 10base-T, etc */
    uint8_t ifi_addrlen;        /* media address length */
    uint8_t ifi_hdrlen;     /* media header length */
    uint8_t ifi_link_state;     /* current link state */
    uint8_t ifi_vhid;       /* carp vhid */
    uint16_t    ifi_datalen;    /* length of this data struct */
    uint32_t    ifi_mtu;    /* maximum transmission unit */
        ....
};
@gopherbot

This comment has been minimized.

Copy link

commented Sep 19, 2015

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

rsc added a commit that referenced this issue Dec 5, 2015

syscall: route_freebsd switch routing socket sysctl to use NET_RT_IFL…
…ISTL

Switch IfMsghdr and IfaMsghdr to their 'l' variants, make the IfData layout
to be based on FreeBSD-11.0 (freebsdVersion >= 1100011).
Using freebsdVersion, detect the appropriate layout at runtime and decode
routing socket messages into the new IfData layout.

Fixes #11641

Change-Id: Ic7ec550f00c0d15f46a36f560d835e4f138f61e1
Reviewed-on: https://go-review.googlesource.com/14757
Reviewed-by: Russ Cox <rsc@golang.org>

@bradfitz bradfitz reopened this Dec 5, 2015

@bradfitz

This comment has been minimized.

Copy link
Member

commented Dec 5, 2015

This was reverted for breaking the build.

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Dec 5, 2015

This is a duplicate of #7849. Also release-11 branch is not created yet. No need to rush adapting heavily under development kernels because freebee net guys still have a chance to modify abis.

@mikioh mikioh closed this Dec 5, 2015

@gopherbot

This comment has been minimized.

Copy link

commented Dec 5, 2015

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

@golang golang locked and limited conversation to collaborators Dec 14, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.