Running one of the examples on a tun interface and unable to parse the Ethertype

[rwygand]

Hi,

I'm running the packetdump example on a tun interface on a virtualized linux machine hosted on macos via virtualbox.

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1350 inet 10.0.0.1 netmask 255.255.255.0 destination 10.1.0.1 inet6 fe80::c67e:fd45:7d39:cd00 prefixlen 64 scopeid 0x20<link> unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Per the example, I'm just running a ping against 10.1.0.2, but the code is unable to parse the EtherType into Ipv4. Instead I see lots of

[tun0]: Unknown packet: 40:00:40:01:f6:9d > 45:00:00:54:30:08; ethertype: EtherType(2560) length: 84

I'm relatively new to a lot of the concepts here, so perhaps something is setup incorrectly with my tun device? I'm wondering if anyone has any experience like this, or could point me into the right direction?

I should mention that tcpdump on that same host seems able to correctly resolve the ethertype.

Much thanks

[stappersg]

On Mon, Jul 10, 2023 at 11:24:14AM -0700, Rob Wygand wrote: ... or could point me into the right direction?

Test first with a more regular interface. When seen it working as expected, switch back to `tun0` as interface. In other words: first test with an ethernet interface, then a "tun". Regards Geert Stappers -- Silence is hard to parse

[rwygand]

I have done, I should have mentioned. Running on a standard virtualized interface works as expected. E.g.,:

[enp0s3]: TCP Packet: 192.168.4.109:22 > 192.168.4.35:64897; length: 220 [enp0s3]: TCP Packet: 192.168.4.35:64897 > 192.168.4.109:22; length: 32 [enp0s3]: TCP Packet: 192.168.4.35:64897 > 192.168.4.109:22; length: 68

But the tun interface, as I mentioned, has those invalid EtherType octets.

[stappersg]

On Mon, Jul 10, 2023 at 12:47:16PM -0700, Rob Wygand wrote: I have done, I should have mentioned. Running on a standard virtualized interface works as expected. E.g.,: `[enp0s3]: TCP Packet: 192.168.4.109:22 > 192.168.4.35:64897; length: 220 [enp0s3]: TCP Packet: 192.168.4.35:64897 > 192.168.4.109:22; length: 32 [enp0s3]: TCP Packet: 192.168.4.35:64897 > 192.168.4.109:22; length: 68` But the tun interface, as I mentioned, has those invalid EtherType octets.

Acknowledge

[rwygand]

I doubt now that this is the right place to ask this, as it's very clearly an issue with the underlying TAP interface -- TAP's just Layer 3, so I'm not sure what it's actually filling in for the EtherType (or any of the Ethernet Frame, honestly), so I'm working on determining that. I suspect that I should just be disregarding anything in Layer 2 for TAP devices.

[rwygand]

And then I figured it out, I think.

I'm running Linux on a virtual machine, inside VirtualBox running on a Mac. I took a closer look at the main() routine in the example and notice that a lot of special case MacOs code was there, but none of it was running, obviously. I had also noticed that my host os had tun devices created, so I became suspicious that the Linux tun devices were actually hosted in MacOS. After some debugging, I ensured the MacOS special-case code was run (e.g., setting the payload_offset to zero and faking the ethernet frame) and everything worked flawlessly.