Hacker News Reader

Comment by protocolture | Hacker News Reader

ISP: No you should definitely have ICMP available for testing.

SAAS Engineer: Leave it on so I can tell when your shit goes down without having to consult your service status page.

Sysadmin: I really dont care what you do, just enable it when you raise a complaint with your ISP so they can tell you what you broke.

Residential: Your TP Link hyper dreadnought super hawk that is taking up every inch of the 5ghz indoor spectrum in your home is probably already blocking icmp for you. Its probably also already part of a botnet. YMMV.

View on HN

> Sysadmin: I really dont care what you do

Dropping ICMP breaks path MTU discovery (PMTU). It's the biggest reason why sites break when accessed (or served) over VPNs. This is often mitigated on the server, or in NAT-ing routers, by clamping TCP MSS, but that doesn't really resolve the problem. It doesn't fix it for UDP, nor likely for double VPN scenarios, etc, plus you're just losing bandwidth that way.

Some people make fatalistic arguments that even if they allow ICMP, something downstream may not have, so it's futile. But the networks in the middle rarely if ever block ICMP; those engineers know better. The real issue is on the ends. If you're a sysadmin dropping ICMP, you're half the problem. Fix ICMP on your end, and half the problem goes away. The other half of the problem are those NAT-ing routers, firewalls, and VPNs that don't handle ICMP properly. You can't fix those, but plenty of residential and commercial equipment on the other end, as well as VPN setups, actually do the right thing. Don't make perfect the enemy of better.

You are absolutely correct, but also, I am already having to clamp MTU for most business customers anyway, for a hundred reasons.

The issue is that sysadmins make this the ISP's issue anyway. They wont do any kind of investigation but simply yell at the telco. Telcos are ready willing and able to clamp. Its as natural as breathing at this point.

The only thing that gets me is when the some small business refuses to enable ICMP for troubleshooting when they raise a complaint. You have to come to the table at least that far.

> small business refuses to enable ICMP for troubleshooting

Depending on your definition of small business, asking someone "hey can you enable ICMP real quick" is like asking them "hey can you build a rocket ship while skydiving?"

Comes from all sides. Mom and Pop running a small store, refuse on the grounds of not wanting to change a setting on their router.

Small as in <100 employees. The IT guy doesnt want to change anything, hes been there 20 years and never changed that setting. Or he needs to go through change management which he is also adverse to.

the problem is ICMP can be abused for attacks like ICMP flood, ICMP smurf, because src.ip can be easily spoofed.

its very easy and cheap to saturate a link with flood traffic, but fixing this issue requires large investments in big expensive firewalls that can block these stupid attacks

> ICMP smurf

IP stacks haven't responded to broadcast pings for ≥20 years now. If you find one that does, please report it so it can get fixed.

> because src.ip can be easily spoofed

Operators have been pushing to get BCP38 everywhere for ≥ 20 years now. If you find one that doesn't do it, please report it so I can depeer and shame them on public mailing lists.

> ICMP flood

So you'll just get flooded with UDP instead (cf. sibling comment).

DNS and SNMP with a spoofed src IP have higher amplification factor and the root of the problem here are ISP which allow they customers to spoof src IP.

Are you blocking UDP, too?

> Residential: Your TP Link […] is probably already blocking icmp for you.

If it does, it generally won't pass telco CPE certification, i.e. Comcast and the likes won't be selling it to you in any bundle. Blocking ICMP Fragmentation Needed / ICMPv6 Packet Too Big is a hard fail on all of those, other message types can vary.

(Source: I work in this area.)

[Ed.: to be clear, there is no single "telco CPE certification"; each telco decides this on their own. A bunch of them form groups/"alliances" though, and a lot of the certification requirements are the same everywhere.]

Inbound echo request and echo reply are almost always blocked in my experience.

Which is ≈mostly≈ fine; I'm just saying people in appropriate places (deciding which CPEs get sold to you) have gotten rather touchy about the PMTU bits. And rightfully so!

Absolutely.

I supported a mid size WISP for 2 years and something like 60% of the issues they sent my way were ultimately resolved with MSS Adjust or MTU clamping.

> Your TP Link hyper dreadnought super hawk that is taking up every inch of the 5ghz indoor spectrum in your home is probably already blocking icmp for you. Its probably also already part of a botnet

The more spiky black angular antennas you put sticking up on a router that makes it resemble a science fiction movie arachnid-form robot, the faster it goes. This seems to be the universal design language now.

For routers that consumers purchase themselves, the design language seems to have been optimized to look amazing and cool and grab the attention of someone browsing the aisles at the local Best Buy.

I bought a TP Link router to run in AP mode for WiFi 7. It has none of those antennae sticking out. It does have a little grid of LEDs on the front that I have set to the UwU face option though...

My newest router doesn't have any of that shit and works just as well, with at least as much range, as the one it replaced, which had six(!) of those insectoid antenna things.

I wouldn't be surprised if the damn antennas are just empty. They don't seem to serve any purpose.

They aren't for range, but for MIMO (exploiting that the signal bounces differently between the antennas either end of the connection, while some antenna pairs behave poorly, others may well be perfect, so it essentially matches them (through a mixing matrix, to be more abstract/generic) to form good pairs that are also independent from another, so they can simultaneously run different data streams over different antennas to severely increase speed.

It also compensates for interference dead spots when you hold your phone into such a spot.

The long sticks typically radiate in the plane normal to the stick, i.e., if you make them all perfectly vertical, they are focused to the same floor. Individual ones can be rotated readily to cover special spots, especially if you have more than 4 antenna.

> The long sticks typically radiate in the plane normal to the stick, i.e., if you make them all perfectly vertical, they are focused to the same floor.

I generally recommend just maximizing angles between them, i.e. 90° between 2 or 3 antennas. Wall attenuation & reflections will equalize it out, and you have a lower chance of dead zones. The ≥4th one —on the same radio— is YOLO. Annoyingly enough, for some devices they don't tell you which antenna is on which radio.

Considering a single radio, the antennas are for MIMO, which in theory is supposed to multiply bandwidth by number of antennas (i.e. 3 antennas = 3× bandwidth). In practice this is highly reliant on signal propagation characteristics in your rooms, particularly including position (and angle!) of all antennas (both senders and receivers). The second antenna is useful, third maybe, fourth is gonna be quite questionable.

However, they also have more than 1 radio these days, and sharing the antennas on them not exactly beneficial; if you have one 2.4GHz, 5GHz and 6GHz radio each, you might as well optimize the antennas for each radio. And even if it's the same band, separate antennas allow you to have distinct radios cover distinct space with different RF propagation characteristics.

(They're not empty, or at least I haven't found any fake ones yet.)

I wish I knew more about RF engineering to comment, but the impression I get is that they cause more problems with interference than they solve.

Reply on news.ycombinator.com