71–80 of 83 posts
What really grinds my gears is that a networking team believes the culprit is a static DNS that "conflicts" with their DNS. Like... "My car won't start." "Oh, OK, have you tried waiting for the traffic lights to go green, as designed by the Principal Road Engineer?"
Feels like some stateful device within someone's network mishanding the connection state, like the author guesses. It's interesting that your side thinks the three-way handshake worked, but the remote side continues to resend the [SYN, ACK] packets, as if they've never received the final [ACK] from you. Had a hellish time troubleshooting a similar problem several years ago with F5 load balancers - there was a bug in…
I wouldn't be surprised if someone (your Uni) is mistakenly blocking some 169.x.x.x data since 169.254.0.0/16 is used for local IPs. Someone put the wrong subnet mask in a firewall rule or ACL someplace.
This would prevent initial SYN To reach the server too.
99% MTU size. Had this recently specifically with TLS due to large initial packets containing certificates. Results could even depend on user agent, some fail some will work. try to reduce MTU on client, 1280 is a good starting point.
Earlier quoted context omitted.
I mean, yes, that was my instinctive response based on just the title. It's always the MTU. But in this case the packet that's being lost is a pure ACK.
Looks to me like the TLS client hello is being lost, which is why the server is sending duplicate SYN+ACKs.
Somewhat related anecdote: Some 10 years back I was working for a solar company doing SCADA stuff (monitoring remote power plant equipment, reporting generation metrics, handling grid interconnect stuff, etc). We had a big room with lots of monitors that looked like a set in a Hollywood film, no doubt inspired by them. You could see all the solar installations all around the world that we monitored. The monitoring cr…
What really grinds my gears is that a networking team believes the culprit is a static DNS that "conflicts" with their DNS. Like... "My car won't start." "Oh, OK, have you tried waiting for the traffic lights to go green, as designed by the Principal Road Engineer?"
My guess is it either got some boilerplate response from L2 instead of actually going to a network engineer or it did go to a network engineer but they're connecting from a different network with different traffic management and don't see the issue. At my old uni, L1 were paid students, L2 were paid staff, and L3 were the actual netops/sysadmins so sometimes L2 would try to close something out that needed escalated.…
What really grinds my gears is that a networking team believes the culprit is a static DNS that "conflicts" with their DNS. Like... "My car won't start." "Oh, OK, have you tried waiting for the traffic lights to go green, as designed by the Principal Road Engineer?"
All that explanation is just ritual -- it does not need to make sense.
Earlier quoted context omitted.
ICMP (the protocol ping uses) is a totally separate protocol from TCP and UDP. Blocking ICMP can break of lot of things and offers no real benefits outside of a handful of specific edge cases. BTW your assumption "a successful ICMP ping = TCP and UDP work" is an extremely common one that I too had before I was taught otherwise.
> BTW your assumption I did not assume. The comment to which I was responding suggested it was the destination IP that was the problem. Generally (but not always) an IP filter would be applied irrespective of protocol. I also pointed out that the initial SYN and reply SYN/ACK are getting through the hypothesized bogon filter and those are part of TCP. I don't think the bogon filter is a hypothesis that fits the evide…
I've never seen this (all protocols by default) in any environment I've personally worked with, but perhaps I've had a unique experience.