because it emulates an Ethernet packet driver but it is really just SLIP over a serial port
Today, the same is true of many other physical-layer protocols that developed later, such as WiFi and the GSMA mobile standards; they seem to have converged on the Ethernet frame format at the software interface, presenting the appearance of an Ethernet NIC to software, because that's the easiest way to make use of existing network stacks. There's also the weirdness of tunneling protocols like PPPoE which only exist to tunnel Ethernet through non-Ethernet systems.
I made a Mobitex radio modem driver for Linux in 1998. I made it look like Ethernet, faking out the full 14 byte ethernet header in the sk_buff. Without that, a whole bunch of things don't work. Starting with ARP; if you look like Ethernet, you get ARP. Then you have things like MAC filtering (ebtables, now nftables), bridging, Tools like tcpdump like familiar headers, otherwise they need patching.
Mobitex has three-byte addresses, like the vendor space of Ethernet, so I just picked some OUI (or was it just three null bytes?)
> ** NULL assignment detected
That's without any hardware support (MMU) on DOS; compiler-generated code does the null checks.
Without it, you get unpredictable results for that bit of UB; the program can trample bytes around the null address.
I wonder if you could've tried "Fil-C" compiler to catch the bug
one of those things that "I heard about recently, would love a practical test, but have no current need to try on"
because it emulates an Ethernet packet driver but it is really just SLIP over a serial port
Today, the same is true of many other physical-layer protocols that developed later, such as WiFi and the GSMA mobile standards; they seem to have converged on the Ethernet frame format at the software interface, presenting the appearance of an Ethernet NIC to software, because that's the easiest way to make use of existing network stacks. There's also the weirdness of tunneling protocols like PPPoE which only exist to tunnel Ethernet through non-Ethernet systems.
I made a Mobitex radio modem driver for Linux in 1998. I made it look like Ethernet, faking out the full 14 byte ethernet header in the sk_buff. Without that, a whole bunch of things don't work. Starting with ARP; if you look like Ethernet, you get ARP. Then you have things like MAC filtering (ebtables, now nftables), bridging, Tools like tcpdump like familiar headers, otherwise they need patching.
Mobitex has three-byte addresses, like the vendor space of Ethernet, so I just picked some OUI (or was it just three null bytes?)
> ** NULL assignment detected
That's without any hardware support (MMU) on DOS; compiler-generated code does the null checks.
Without it, you get unpredictable results for that bit of UB; the program can trample bytes around the null address.
I wonder if you could've tried "Fil-C" compiler to catch the bug
one of those things that "I heard about recently, would love a practical test, but have no current need to try on"