robertgraham

This blogpost comments on Linus's latest tirade by reading the code.

For example, it explains the specific problem of technical debt on failing to mask of high order bits by casting the low part to (u16). Years from now, when this leads to a bug, you'll no longer be able to fix the macro because inevitable some code will by that time depend upon high order bits in the low part.

My guess is that your original SYN did not go to the target, but was redirected somewhere close by. I'd look at the TTL value in the IP header of your first SYN-ACK, and play with such things as traceroute.

Such redirection is often done on a specific port basis, so that trying to access different ports might produce a different result, such as a RST packet coming back from port 1234 with a different TTL than port 443.

There is so much cheating going with Internet routing that the TTL is usually the first thing I check, to make sure things are what they claim.

The first two answers are 8 and 0.

They are technically `undefined` according to the C standard, but are the behavior of every mainstream compiler. So much of the world's open-source code depends upon these that it's unlikely to change.

Using clang version 15.0, the first 2 produce no warning messages, even with -Wall -Wextra -pedantic. Conversely, the last 3 produce warning messages without any extra compiler flags.

The behavior of the first two examples are practically defined even if undefined according to the standard.

Now, when programming for embedded environments, like for 8-bit microcontrollers, all bets are off. But then you are using a quirky environment-specific compiler that needs a lot more hand-holding than just this. It's not going to compiler open-source libraries anyway.

I do know C. I knowingly write my code knowing that even though some things are technically undefined in the standard, that they are practically defined (and overwhelmingly so) for the platforms I target.

Nobody (yet) has mentioned Microsoft PWB - Microsoft's Programmers Workbench for their C compiler, around 1990. It's what all the Microsoft engineers themselves used when writing code for Windows, WinNT, OS/2, etc. It was essentially perfect for its time.

Ethernet doesn't use TCP/IP. Ethernet is it's own network. It has nothing to do with TCP/IP.

Other things use Ethernet. Routers, when connected to each other, often use a local Ethernet network to communicate.

Think of the TCP/IP Internet as it's own network, ignoring how routers physically talk to each other. Sometimes it's a directly link, a wire. Sometimes it's carrier pigeons. Sometimes it's WiFi. Sometimes it's Ethernet. Whatever it is, it's local to between the routers and does not extend outside that.

Well, you sort of demonstrate my point.

The writers the OSI Model wrote a specific blueprint, not an "observation of natural laws". When they said "session", they didn't mean the same things you conceive of. Instead, they meant a very specific problem of connecting dumb terminals to simplex links.

What you now call "sessions" is what OSI called "associations", and OSI defined them to be part of the "Application Layer".

I'm not sure you've even read the OSI Model. For example, the "Presentation Layer" is not defined to do the data format translation, but only to NEGOTIATE a common represenation. The actual data translation is still done in the Application.

This is the problem. People have not read and understood the entire model. They've not heard of "associations" and believe the OSI's use of "sessions" means anything they might call "session". They believe OSI was written as theory when it was not. They believe anything OSI terms they don't understand mean something else, mean some sort of timeless theory.

They are seduced by their own ignorance of the model.

I use RFC 791, the original Internet model.

RFC 1122 is a retconned version of the Internet model that tried to change terminology to fit OSI.

Yea, it's not about engineers constructing systems. I mean, engineers do frequently pretend their creations fit the OSI model, but they work backwards to make it appear to conform to orthodoxy.

The issue is about education. People teach the model, or some variation of it. It teaches misconceptsion, such as how Ethernet and the Internet are integrated in a single network stack rather than being independent networks. It leads to professionals in IT and cybersecurity who continue to hold this misconception.

It's wrong to think of them as different functions of the same network. Instead, they are differnet networks.

Ethernet and the Internet both provide the function of forwarding packets through a network to the target destination address. The MAC protocol and IP protocol provide the same theoretical function.

Where they differ is that Ethernet was designed to a be a local network, whereas the Internet is designed to be an internetwork. All it demand from local networks is that they get packets from one hop to the other. Ethernet does this for the Internet, but so do carrier pigeons.

The same is true for HTTP. Instead of thinking of it as a component of the network, think of it as something that rides independently on top of the network. In a hypothetical future whe we've replaced the Internet with some other technology, the web would still function.

You can't. Nobody knows what the session layer does. Most falsely believe that layer handles sessions.

I discuss this point several times. I claim the model is not useful, specifically because the layering abstraction for hte lower layers is a misconception rather than the truth.

For example, I describe how the OSI Model claims that layer #2 and #3 describe different functionality in the same network stack. I claim the opposite, how they describe roughly the same functionality in differnet networks.

Namely, both Ethernet and the Internet forward packets based upon addresses. The difference is that Ethernet does this locally while the Internet does this locally. Otherwise, the theoretical concept of packets, forwarding, and addresses are the same.

The book has an extensive section on history.

I claim that by 1981, the OSI Model was already obsolete and that it didn't fit well, that was not a good teaching tool, that it has done more to beffudle than enlighten students. The problem being is that if you learned according to the modle, you are not aware of what you misundertood.

Elsewhere in the text I describe how OSI chose a word at random, that they never meant by it what we now call "sessions". It could've been 'dialog layer' or 'interaction layer". I recommend they should've chosen "Intercourse Layer".