Openflow13 breaks when parsing Packet_In message

[mulias]

The openflow13 message parser breaks with a stack trace that looks like this:

"invalid bounds in Cstruct.BE.get_uint16 32,4 off=4 len=2"
"Called from file "openflow/lib/OpenFlow0x04.ml", line 838, characters 26-48"
"Called from file "openflow/lib/OpenFlow0x04.ml", line 1855, characters 16-41"
"Called from file "openflow/lib/OpenFlow0x04.ml", line 2350, characters 28-42"
"Called from file "openflow/lib/OpenFlow0x04.ml", line 2351, characters 24-42"
"Called from file "openflow/lib/OpenFlow0x04.ml", line 2357, characters 20-41"
"Called from file "openflow/lib/OpenFlow0x04.ml", line 3535, characters 30-59"
"Called from file "openflow/lib/OpenFlow0x04.ml", line 7012, characters 34-58"

Note that the line numbers match up with commit 7e2316b, not the current file.

[arjunguha]

FYI, this is a PACKET_IN message, when it receives some sort of IPv6 packet. We often run Frenetic in VMs that have IPv6 disabled.

[fugitifduck]

Strange, it passed the unit test last year.
As I understand, there is a problem on the cstruct ofp_uint48 (defined at https://github.com/frenetic-lang/ocaml-openflow/blob/master/lib/OpenFlow0x04.ml#L799 ).
On what Arch do you run openflow ?

[arjunguha]

This was witnessed running OpenVSwitch on Ubuntu 14.04

[fugitifduck]

is it possible to have a sample of the IPv6 packet ?
(and by arch I mean x86 or x64)

[arjunguha]

64-bit. We didn't capture the precise packet, unfortunately.

[fugitifduck]

I can't identify the issue on ocaml-openflow code. Maybe the packet was malformed ? (or the ofp_uint48 struct was wrongly code, but there will be issue in other messages).

[mcanini]

This should be fairly easy to reproduce, if it is indeed related to IPv6. Just activate a mininet VM and do not switch off IPv6.
Did you try that?