Bridge test functions fail on s390x

[dswarbrick]

Another batch of tests are failing on s390x (and presumably other bigendian archs).

=== RUN   TestBridgeDecodeRaw
=== RUN   TestBridgeDecodeRaw/STP_state
    bridge_test.go:227: unexpected bridge (-want +got):
          &driver.Bridge{
          	... // 2 identical fields
          	MaxAge:        nil,
          	AgeingTime:    nil,
        - 	StpState:      s"enabled",
        + 	StpState:      nil,
          	Priority:      nil,
          	VlanFiltering: nil,
          	... // 28 identical fields
          }
=== RUN   TestBridgeDecodeRaw/VLAN_filtering
    bridge_test.go:227: unexpected bridge (-want +got):
          &driver.Bridge{
          	... // 4 identical fields
          	StpState:      nil,
          	Priority:      nil,
        - 	VlanFiltering: s"enabled",
        + 	VlanFiltering: nil,
          	VlanProtocol:  nil,
          	GroupFwdMask:  nil,
          	... // 26 identical fields
          }
--- FAIL: TestBridgeDecodeRaw (0.00s)
    --- FAIL: TestBridgeDecodeRaw/STP_state (0.00s)
    --- FAIL: TestBridgeDecodeRaw/VLAN_filtering (0.00s)
...
=== RUN   TestBridgePortDecodeRaw
=== RUN   TestBridgePortDecodeRaw/port_state
    bridge_test.go:422: unexpected bridge port (-want +got):
          &driver.BridgePort{
        - 	State:    s"forwarding",
        + 	State:    nil,
          	Priority: nil,
          	Cost:     nil,
          	... // 22 identical fields
          }
=== RUN   TestBridgePortDecodeRaw/port_cost
    bridge_test.go:422: unexpected bridge port (-want +got):
          &driver.BridgePort{
          	State:    nil,
          	Priority: nil,
        - 	Cost:     &100,
        + 	Cost:     nil,
          	Mode:     nil,
          	Guard:    nil,
          	... // 20 identical fields
          }
--- FAIL: TestBridgePortDecodeRaw (0.00s)
    --- FAIL: TestBridgePortDecodeRaw/port_state (0.00s)
    --- FAIL: TestBridgePortDecodeRaw/port_cost (0.00s)

[jsimonetti]

We seem to regress very often for other endian architectures.
Since you keep finding them, could you help me figuring out if we can catch these errors earlier?
I assume we need an actual VM for this, right? Something that could run in CI would be great, but I would need to look into how this could be made to work in action runners.

[dswarbrick]

I usually become aware of the test failures since I maintain the golang-github-jsimonetti-rtnetlink package in Debian, which is tested on all archs that are officially supported by Debian - including s390x.

I believe the underlying cause is that the github.com/mdlayher/netlink package is not compatible with big-endian archs. I have opened a few issues against that package in the past, but rather than fixing the root cause, the author usually opts to simply skip the tests on big-endian. This is obviously ignoring the issue, since it is highly likely that programs which use that package on big-endian hosts will malfunction due to bogus encoded / decoded values.

Many kernel structs pertaining to network stuff contain a mixture of native-endian and network byte order (big-endian). Occasionally, structs may explicitly contain little-endian members (even on big-endian hosts). Quite often a simple binary.Encode() / binary.Decode() of a byte slice into a struct is inadequate, since individual struct members may have different endianness.

The other issue that needs to be solved is that test fixtures which contain byte slices most likely need to have separate little-endian / big-endian versions.