TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

TCP connection timeout mystery

137 点作者 dmarto大约 1 年前

23 条评论

Existing4190大约 1 年前
I&#x27;m suspicious about the IP 169.150.221.147 My guess: there is some misconfigured bogons IP filter and instead of 169.254.0.0&#x2F;16 (rfc3927) there is something like 169.0.0.0&#x2F;8 configured to be blocked on some firewall<p>I once was a customer of an ISP that mistakenly blocked the whole 192.0.0.0&#x2F;8 net, which caused some confusion, but they fixed it after I pointed it out.
评论 #39819858 未加载
评论 #39820035 未加载
评论 #39821928 未加载
Izmaki大约 1 年前
What really grinds my gears is that a networking team believes the culprit is a static DNS that &quot;conflicts&quot; with their DNS.<p>Like...<p>&quot;My car won&#x27;t start.&quot;<p>&quot;Oh, OK, have you tried waiting for the traffic lights to go green, as designed by the Principal Road Engineer?&quot;
评论 #39820979 未加载
评论 #39821792 未加载
评论 #39823039 未加载
评论 #39834594 未加载
Hikikomori大约 1 年前
Think I was able to reproduce it. I configured my router to drop established connections for IP 169.150.221.147 in my policy attached to my wan interface for outgoing traffic (important detail, inbound would drop the syn&#x2F;ack instead). For reference its an Ubiquiti Edgerouter that uses iptables to filter traffic.<p>In the linked picture [0] I have packet #436 selected, its a retransmission of the handshake syn&#x2F;ack with seq=0 ack=1, repeating a few times later, same as OP.<p>So as others suggested, likely a misconfigured BOGON rule with 169.0.0.0&#x2F;8, but also matching outbound established connections rather than new&#x2F;any state for some reason.<p>[0] <a href="https:&#x2F;&#x2F;i.imgur.com&#x2F;AwJGI3W.png" rel="nofollow">https:&#x2F;&#x2F;i.imgur.com&#x2F;AwJGI3W.png</a>
评论 #39822289 未加载
johnklos大约 1 年前
I&#x27;m rather surprised that Berkeley Student Tech Services would keep people around who either don&#x27;t know how DNS works or know, but who make up excuses to dismiss a problem.<p>The problem really should be escalated and the nonsense answer pointed out, because if they care (and they should), they&#x27;ll want to educate the person who gave that response.
评论 #39821803 未加载
oasisbob大约 1 年前
Feels like some stateful device within someone&#x27;s network mishanding the connection state, like the author guesses.<p>It&#x27;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&#x27;ve never received the final [ACK] from you.<p>Had a hellish time troubleshooting a similar problem several years ago with F5 load balancers - there was a bug in the hashing implementation used to assign TCP flows to different CPUs. If you hit this bug (parts per thousand), your connection would be assigned to a CPU with no record of that flow existing, so the connection would be alive, but would no longer pass packets. Would take a long time for the local TCP stack to go through its exponential retries and finally decide to drop the connection and start over .
评论 #39820735 未加载
评论 #39823260 未加载
outsidein大约 1 年前
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.<p>try to reduce MTU on client, 1280 is a good starting point.
评论 #39819264 未加载
评论 #39820372 未加载
评论 #39820889 未加载
评论 #39819572 未加载
评论 #39823307 未加载
评论 #39819103 未加载
评论 #39819905 未加载
LinuxBender大约 1 年前
A raw packet capture would be useful to look deeper. Actually 2. One of the IP in question and one of any other site. Both from the problem source network. I would wager one of these things is not like the other but I need the .cap files as there is not enough information in the screenshot. The output of <i>ss -emoian</i> as text and not a screenshot may also be useful to grab just after the connections are attempted to both destinations.
nzach大约 1 年前
My guess would be something related to your campus having more than one external connection available.<p>Maybe from the server&#x27;s point of view the SYN and ACK are coming from distinct addresses and this is tripping them up ?<p>I have 2 internet connection in my home and would encounter some strange bugs whenever I used both connections at the same time. I never debbuged theses cases but they always disappeared when I just used 1 connection and left the second as a backup.
krypd0h大约 1 年前
I wouldn&#x27;t be surprised if someone (your Uni) is mistakenly blocking some 169.x.x.x data since 169.254.0.0&#x2F;16 is used for local IPs. Someone put the wrong subnet mask in a firewall rule or ACL someplace.
评论 #39821003 未加载
gjf大约 1 年前
First off, the HTTP HTTP 301s to the HTTPS site, so HTTPS is still the likely trigger.<p>Second, I see that whatever client he&#x27;s using is specifying a very old TLS 1.0. If its not MTU (which others have mentioned), then my guess would be a firewall with a policy specifying a minimum TLS version, and dropping this connection on the floor.
评论 #39821542 未加载
评论 #39820975 未加载
robertgraham大约 1 年前
My guess is that your original SYN did not go to the target, but was redirected somewhere close by. I&#x27;d look at the TTL value in the IP header of your first SYN-ACK, and play with such things as traceroute.<p>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.<p>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.
nneonneo大约 1 年前
Please provide a raw .pcap file! There&#x27;s a lot of information missing from the screenshot.
joelmeckert大约 1 年前
Sounds to me as if they have a Palo Alto NGFW at the edge, filtering the traffic. UC Berkeley appears to be running a Palo Alto for at least part of their infrastructure.<p><a href="https:&#x2F;&#x2F;security.berkeley.edu&#x2F;services&#x2F;bsecure&#x2F;bsecure-remote-access-vpn" rel="nofollow">https:&#x2F;&#x2F;security.berkeley.edu&#x2F;services&#x2F;bsecure&#x2F;bsecure-remot...</a>
dark-star大约 1 年前
Wow. What an embarassing answer by the &quot;Berkeley Student Tech Services&quot;...<p>That is on the same level as e.g. the customer hotline at a phone company (&quot;did you try turning it off and on again?&quot;), I would have thought that Berkeley of all university has higher standards than that
评论 #39820714 未加载
nlewycky大约 1 年前
The symptoms match my experience with a mid-network firewall&#x2F;router that is not aware of TCP window scaling stripping out the scaling factor while leaving the window scaling feature enabled. See <a href="https:&#x2F;&#x2F;lwn.net&#x2F;Articles&#x2F;92727&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lwn.net&#x2F;Articles&#x2F;92727&#x2F;</a>
sargstuff大约 1 年前
&quot;Adventures with asymmetric routing and firewalls&quot;[1] might provide some useful insite&#x2F;information[1].<p>[1] : <a href="http:&#x2F;&#x2F;www.growse.com&#x2F;2020&#x2F;01&#x2F;23&#x2F;adventures-with-asymmetric-routing-and-firewalls.html" rel="nofollow">http:&#x2F;&#x2F;www.growse.com&#x2F;2020&#x2F;01&#x2F;23&#x2F;adventures-with-asymmetric-...</a>
roamerz大约 1 年前
Maybe it’s not a network issue at all - might be related to a purposeful action taken by a network device (ips or web filter etc) that is killing the connection based on some rule set.
评论 #39819742 未加载
bediger4000大约 1 年前
Clamp MSS to path MTU discovery?
评论 #39818646 未加载
nathanyz大约 1 年前
Lots of good things to investigate already in the thread. I would throw in the potential for an anycast routing issue. TCP is stateful and if there is asymmetric routing, maybe the packets are coming from one anycast device, but the returning packets are routing to a different one.<p>Would suspect some of the other responses first though, but if they don&#x27;t help this could be a possibility if they are using anycast.
评论 #39821854 未加载
deeviant大约 1 年前
Somewhat related anecdote:<p>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).<p>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 crew put out a call for engineers, stat, and as I walked into the monitoring room I could see perhaps 1&#x2F;10th of the power plant icons on the wall we red &quot;lost communication&quot;, one plant went green to red right in front of me.<p>This started a shitstorm with all hands be summoned. Long story short, somebody decided the best way to get an external IP for one of our remote gateways was to use curl command to a whatismyip.com type service, but instead of targeting Google (or you know, a server under our control), it hit some random ISP in Italy. The ISP most have eventually realized they were getting ping on by thousands of devices 24&#x2F;7, so they decided they would drop some percentage of incoming requests silently, and of course the curl call was blocking without timeout. When the remote gateway&#x27;s was dropped, it blocked indefinitely.<p>I skipped a lot in between but it was definitely a fun firefighting session, it was particularly hampered by a couple engineers that were quite high up on the food chain getting lead in the wrong direction (as to the root cause) at the beginning and fighting particularly hard against any opposing theories. It was the one time I basically got to drop the &quot;I&#x27;m right and I bet my job on it.&quot; Fun times.
评论 #39823825 未加载
Wheaties466大约 1 年前
are we ruling out content filtering? any content filter that is going to filter HTTPS without SSL decryption is going to look at the esni, which is in the client hello.
dmarto大约 1 年前
Here is the author&#x27;s latest update and the revelation of the mystery:<p><a href="https:&#x2F;&#x2F;devnonsense.com&#x2F;posts&#x2F;asymmetric-routing-around-the-firewall" rel="nofollow">https:&#x2F;&#x2F;devnonsense.com&#x2F;posts&#x2F;asymmetric-routing-around-the-...</a>
mahirsaid大约 1 年前
A Firewall problem, from what i gathered in the article.