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?)
I can't come with any reason why the author would have ever changed ES to DS at that point in the code. (Also, if there was a need they would have been better served with a "push ds / pop es" construct instead. Using si as an intermediate like that is lunacy. It feels very un-idiomatic for x86 assembler. Seeing "mov es, si" kinda made my head hurt a little.)
I got lucky here with the compiler detecting the problem given that it wasn't just limited to using a null pointer. Depending on the buffer offset being handed back, it could have hit anywhere in the data segment.
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.
> There's also the weirdness of tunneling protocols like PPPoE which only exist to tunnel Ethernet through non-Ethernet systems.
Isn't PPPoE the opposite — carrying a non-Ethernet protocol over Ethernet?
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?)
I can't come with any reason why the author would have ever changed ES to DS at that point in the code. (Also, if there was a need they would have been better served with a "push ds / pop es" construct instead. Using si as an intermediate like that is lunacy. It feels very un-idiomatic for x86 assembler. Seeing "mov es, si" kinda made my head hurt a little.)
> ** 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 got lucky here with the compiler detecting the problem given that it wasn't just limited to using a null pointer. Depending on the buffer offset being handed back, it could have hit anywhere in the data segment.
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"
The wrong "pointer" for `rep movsb` is in the assembly code (of the packet driver).
Besides the sibling answer, it probably wouldn't fit into MS-DOS execution model.