puc-rio.br network [was Re: Duplicating a coroutine]

[Mouse <mouse@...>]

>>>> Oddly, [www.inf.puc-rio.br] doesn't answer pings, and mtr to it
>>>> gets to 139.82.59.22, which has forged rDNS, before failing.
>>>> Maybe the machine is sick?
>>> rDNS looks sane to me, though: [...]
>> But 139.82.59.22 has forged rDNS now: it reverse-resolves to
>> rdc3.rdc.puc-rio.br and nothing else, but rdc3.rdc.puc-rio.br
>> forward-resolves to 139.82.181.59 and nothing else.
> Ah, right, I forgot to check [...]

> I guess receiving TCP ACKs rules out TTL issues, unless maybe it's
> very near the limit.

Agreed.  And it's nowhere near the limit; the ACKs arrive at my house
router with a TTL of 51, according to tcpdump.  Which is about right
for what mtr is showing me, assuming there are few-to-no hops between
139.82.59.22 and www/ogum.

> Could maybe be a PMTU issue, especially considering that PUC Rio's
> gateway seems to be dropping ICMP Echo packets.  I bet you're routing
> over a VPN tunnel.

Not as far as I know.  But I do appear to be behind some kind of
lowered-MTU link; snooping a normally-working bulk data connection
between home and outside, I see 1440 octets of TCP payload, whereas a
similar connection within my house LAN shows 1448.  Probably the PPPoE
hop; when I check ppp0 on the PPPoE handler machine, its MTU is 1492,
with the far end's MTU presumably set similarly.

> I had to interrupt the latter as it made no progress.

It looks moderately conclusive, then: www.inf.puc-rio.br is behind a
PMTU-D black hole - and isn't doing PMTU-D black hole detection.

> I can download from archive.org, though:

Not too surprising; presumably the archive.org machine you're fetching
from _isn't_ behind a PMTU-D black hole, or, if it is, it does black
hole detection.  (Snooping the traffic could tell you which, if you
care enough to bother.)

> So it definitely seems like a PUC Rio network issue, presumably the
> 139.82.59.22/rdc3.rdc.puc-rio.br gateway dropping all ICMP packets,
> including Fragmentation Needed, not just Echo packets.

Likely, but not necessarily; it could be a misconfigured (or broken
enough to not allow sane configuration) firewall appliance; some of
them (incorrectly) don't decrement TTL and some others don't send back
time-expired ICMPs.  If either of those is between rdc3 and ogum, that
could explain it too.  Another possibility is that ogum is running an
OS with builtin firewalling and has that firewalling misconfigured.

But, yes, dropping all ICMPs is a relatively common misconfiguration
for less-competent network admins to perpetrate.

It does seem as though something at puc-rio.br is misconfigured.  Maybe
Roberto can get it fixed (or worked around, eg by setting ogum's
outbound interface MTU lower), but maybe not; my time in academia
taught me many things not learnt in the classroom - and one of them is
that internal politics can be a fearsome beast.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse@rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B