Force IPv4 for baidu connectivity probe#11
Open
DzmingLi wants to merge 1 commit into
Open
Conversation
minreq has no happy-eyeballs fallback — on a host with AAAA records returned first (typical default getaddrinfo order), every request loops on IPv6 SYN retries until timeout, even when IPv4 connectivity is fine. On networks where IPv6 isn't routed (e.g. captive-portal Wi-Fi before auth), the daemon never reaches baidu and never triggers login. Resolve www.baidu.com manually, pick the first IPv4 address, and request by IP with an explicit Host header. The captive portal intercepts based on egress destination so the redirect still fires.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
On dual-stack hosts, the daemon can sit forever in a retry loop without ever entering the login flow. Observed on HUST_WIRELESS captive-portal Wi-Fi:
tcpdumpshows every probe goes out as IPv6 SYN to baidu's AAAA address, never falling back to IPv4 even though IPv4 connectivity works fine.Root cause:
minreqhas no happy-eyeballs / address fallback — it pins to whichever addressgetaddrinfo()returns first. With default Linuxgai.confordering, AAAA wins. On the typical campus captive portal where the host has an IPv6 default route via RA but no upstream IPv6 reachability, every request stalls on SYN retransmits until the 10s timeout. The daemon never sees the portal redirect script and so never logs in.Fix
Resolve
www.baidu.commanually, pick the first IPv4 address, request by IP with an explicitHostheader.has been tested