Falsehoods Programmers Believe About LANs | Hacker News Reader

Falsehoods Programmers Believe About LANs

dreamstation.systems

57 pointsrobinpie68 comments

Falsehood People Believe about Programmers:

Programmers think the models they use are perfect.

I’d say this one is frequently true, and is one of the things that distinguishes senior from junior programmers.

Mostly programmers think a system will act predictably given the same inputs. Most of computing doesn't work without that assumption.

You're conflating "predictable" with "reproducible".

"Predictable" assumes there is an observer making a guess, but we all live by the knowledge that our assumptions may be wrong. We care less about that, and more about whether the system behaves consistently.

Consistent behavior is either a bug or a feature depending on what was expected. The system just is, man, and that's what we need.

"Nobody sits like this rock sits. You rock, rock. The rock just sits and is. You show us how to just sit here and that's what we need."

Programmers certainly believe that, but they quickly learn not to.

Unfortunately there are also (senior) programmers who believe that their model is correct and it’s the reality (spec, client, user, etc) that’s wrong.

Let’s be clear though: all of those other things are probably wrong too.

I get the idea, but this isn't necessarily useful as advice and toys with definitions. It's ESPN levels of conversation-baiting. Lots of assumptions can be reasonably made about residential LANs without being true of enterprise LANs/DMZs.

If a residential LAN is RFC1918 and has no NAT, then it is still a LAN... without internet access.

Then the "A & !A" fallacy of "MAC addresses can’t be changed. MAC addresses can be changed."

Just kind of a mess. Would be more interesting to explore the edge cases rather than throw out half-truths and 0.05% instances.

I like the GNOME 2006 era though.

Read it as chain of thoughts not as a list

Both A and !A can be fallacies if sometimes A.

The biggest fallacy here, though, and not stated, is that "LAN" is a meaningful concept.

The loosest definition might be "isolated network or leaf node of the internet" if one considers a non-natted DMZ to be a lan.

If one thinks all the assumptions in the article are bogus, then I agree there's no definition of the term.

>99% of the time, being natted and/or having private address space is the definition.

This feels like a bastardization of the already questionable "Falsehoods ___ believe about ___" format.

How so? It's pretty within the format IMO.

Maybe I'm pulling at a fake distinction here but the progenitor blog posts of this format that I'm thinking of were incorrect models of constructs that almost everyone uses in their everyday life constantly ( names, dates, time etc )

Whereas I find it kinda unlikely that someone both knows what a DHCP server is, and holds a belief that there is only ever exactly one on their network?

Hmmm, In my experience programmers are often not particularly good at networking, and this can result in all kinds of bad assumptions (or awkward workarounds for things that could be much better solved at the network level).

Maybe I don't remember the names, dates, and others correctly but I don't think they had things like

> Wi-Fi and Ethernet clients are equivalent peers on the LAN. > Wi-Fi and Ethernet clients aren’t equivalent peers on the LAN.

To be honest I don't know what this is supposed to be telling me. They can or can't be on the same VLAN? They could have different or the same QoL? If we hammer traffic on both at the same time bad things may or may not happen?

> Only IPv4 is running on my LAN. > Only IP is running on my LAN. > Okay, only IP, IPX/SPX, Phase IV, AppleTalk, VINES, NetBEUI, or SNA are running on my LAN. > Seriously?

Practically I'm not sure how this affects someone writing a networked application. Sure, IPv4/IPv6, but if I get a bug report in the year 2026 that my application is broken because it doesn't work on the AppleTalk network, it gets a WONTFIX.

Sure, maybe if I'm writing a low-level network driver or maintaining a mainframe application these are things I have to care about. I think that may be the difference between the other posts and this post - non-experts in Onomastics and Chronology deal with names and dates all the time, hence resulting in issues like government websites not accepting Ng as a last name because it is less than 3 characters or not allowing entering February 29th as a birthday.

That format is considered harmful.

Falsehoods Programmers Believe about Weblog Posts

* there is something called a LAN

* two people who say they are on the same LAN agree on what the LAN is

Not sure what a "LAN" is but it happened to me at work that I thought .0 is not a valid host address until I learned about Layer-3 only networks. So also no ARP. I guess this is still a LAN although it's probably an "Enterprise LAN".

> Layer-3 only

huh? 1.2.3.0/23 is a valid host address, it doesn't have to be Layer-3 only or whatever. it's just basic subnetting.

> My LAN uses IP addresses.

I've never heard of a LAN without IP addresses. Is that a thing? I'd assume that no IP addresses means you can't even use TCP/IP at all, right? Is there something else you'd use instead?

IPX/SPX is not IP based.

Can that still be used from modern operating systems? Maybe only Linux?

I suspect recentish versions of Windows still have the driver available, just not installed by default.

However the article is about falsehoods programmers believe about LANs. If you are writing some kind of driver and assume all traffic you receive is IP traffic and don't verify the header, you are going to have a bad time.

Quite common to run unnumbered IS-IS backbones. Whether this can rightfully be considered a "LAN" is up for debate.

You can send packets over Ethernet, without IP. That's what people did before IP was invented and took over most networked communication. It's less convenient, because you can't reuse the IP stack, so almost nobody does.

Ethernet uses frames, not packets. A falsehood that programmers believe about networking is that everything is a packet. In fact, the "PDU" or protocol data unit for each OSI layer is defined and named differently.

So Ethernet communicates with frames. You can simply send frames across a purely Ethernet network. Or, you can take a PDU from an upper layer, encapsulate it as Ethernet frame, and send it across. Most LAN protocols are flexible like that.

https://en.wikipedia.org/wiki/Frame_(networking)

https://en.wikipedia.org/wiki/Network_packet

https://en.wikipedia.org/wiki/Protocol_data_unit#Internet_pr...

And TFA provides a list of upper-layer protocols that may be encountered on a LAN today: "IP, IPX/SPX, Phase IV, AppleTalk, VINES, NetBEUI, or SNA".

NetBIOS and NetBEUI are particularly interesting here, because NetBIOS Frames did use IEEE 802.2 LLC, while NBT uses TCP/IP for NetBIOS transport.

https://en.wikipedia.org/wiki/NetBIOS

A falsehood networkers believe about programming is that you have to call things what the relevant standard calls them, and you have to obey all the random differences that come from different people writing the different standards. IP packets and Ethernet packets aren't the same thing, but IP packets and IP frames are the same thing, because packets and frames are the same thing.

You're just mixing up completely different things and thinking you're saying something meaningful. In reality, you're just confusing yourself and those around you.

We’re standing at a table and there’s an apple and orange there. You pick up the apple, take a bite and say “This orange tastes great.” We all know what you’re trying to say but you’re still wrong.

IP and Ethernet were developed around the same time and also became the dominant standards around the same time. But they were mostly unrelated, so you had token ring networks running TCP/IP and Ethernet networks running IPX and all sorts of other combinations. So it's not quite as simple as that. I don't think there's ever been a time when there was a significant adoption of Ethernet without using it in combination with some L3 protocol.

I'm not sure how much of a "LAN" that would be but some telecom clustering solutions use protocols other than TCP/IP (some don't even care if they run over Ethernet or ATM)

I love the number of people who are commenting about how the article is wrong, and then finding out that they are actually wrong.

Some of these seem a bit obscure. I wish the author had given detailed examples or linked to pages with details on the points.

>Two hosts on the same subnet can reach each other without leaving the LAN.

Barring "very buggy software," when is this false?

Yeah… I feel like “falsehoods X believe about Y” need to omit anything a reasonable X would consider to be a bug.

Edit: fair point. Maybe not.

I think generally the point of the phrasing is to make you stop considering it a bug,

Falsehoods programmers believe about programming: you don’t have to work around other people’s bugs.

It might not be your fault but it sure as hell will be your problem.

VPNs

I read that like the meme:

<guy with messy hair>Aliens</guy with messy hair>

Port- or Client-isolation on Ethernet switches and Wi-Fi access points respectively. Often seen in corporate environments and (properly configured) guest networks.

I feel like the point of those is conceptually "take these things off the LAN." If we allow for that, what even is a LAN?

You are correct. It explicitly breaks the LAN, does not provide a LAN, only an internet gateway in most cases.

I feel like the better of this is maybe "will" instead of "can"

Switches and firewalls can do all kinds of things. Probably the most common case is that public/guest wifi networks often have client isolation set up so that different devices on the network can't contact each other. Same subnet, but only access to the gateway and the internet in practice.

(Also can happen if ARP is not working correctly, which can be a right PITA to debug).

Some tunnel that extends the subnet somewhere else. Guess it depends on how you define lan.

There are recent "client isolation" features that prevent P2P communication. Some hosting providers also block customers on the same LAN from attacking each other.

Indeed. You might share a subnet with other customers of your ISP, but your ISP probably doesn't let you ARP poison them.

This isn't even that recent. I remember doing ARP poisoning exactly once and then being surprised that it didn't work everywhere.

Indeed. You might share a subnet with other customers of your ISP, but your ISP probably doesn't let you ARP poison them.

This isn't even that recent. I remember doing ARP poisoning exactly once and then being surprised that it didn't work everywhere.

I think the falsehood here is that same IPv4 subnet = same link layer network, but that doesn't have to be the case.

Did arp poisoning in school and used a tool to show images from websites people visited on the projector. Teacher thought it was fun until someone went to goatse.

LAN spread across sites with a WAN in the middle of it. But that's why I said in my comment that a LAN isn't actually a real thing.

Most consumer wifi routers I’ve used have a setting to prevent peer-to-peer traffic. Whether this still counts as being on the same subnet is kind of a philosophical question.

An IP subnet is just a block of addresses anyway. Any two addresses both are and are not in the same block, depending on how big of a block you choose.

Only if you don’t consider the subnet mask as part of the IP address configuration.

This just lists every possible configuration permutation. Nothing insightful here.

> There is one DHCP server.

There'd better be or your network is probably hosed.

In theory it's fine to have multiple DHCP servers as long as they don't step on each other. But in reality a bunch of the things mentioned in this post are ways for the network to be hosed. Unfortunately, enough LANs are semi-hosed that it's worth working around known problems.

That works mostly, you'll have problems if you have duplicate IP addresses though.

Windows supports dhcp failover, where multiple dhcp servers can exist on the same subnet.

You don’t have to have one. My first LAN didn’t. I had no idea what I was doing and picked 17.0.0.0 addresses for local ones and I couldn’t connect to Apples website.

https://datatracker.ietf.org/doc/html/draft-ietf-dhc-failove...

At work I manage a network with two DHCP servers. One is a dnsmasq that assigns the IP address, hostname, and basic network parameters to all network devices, and the other is a LTSP server (https://ltsp.org/) that provides network boot images only for certain devices that require it. It might not look pretty, but it works really well.

What really matters is that there's a coherent policy for assigning addresses, which is absolutely compatible with having multiple DHCP servers on the same subnet (e.g. each server configured to hand out non-overlapping IP ranges).

It's less about the IP ranges they're giving out not overlapping and more about the requests that they respond to not overlapping (or at least that they don't contradict one another). The classic 'someone plugged a consumer wifi router into the office/university network' problem often is made worse because the consumer wifi router gives out different addresses.

Well, consumer Windowses (XP Home? It’s been a while) used to hose networks because they were "helpfully" running their own DHCP server.

Nothing burger of a post

Reply on news.ycombinator.com