While doing the test that @trendy is suggesting, make a note of your public IP with both a computer directly connected to the ISP router in bridge mode, as well as that on the OpenWrt router. If different, it is possible that there is a block on the public IP due to abuses (maybe by a previous holder of that IP).
1 Like
There is no difference in the IP, and I checked if my IP was blacklisted, it is not.
I also checked if my IP was shared (the ISP in France does this sometimes), and it is not the case, I am in full stack that means I am the only owner of my IP.
I bought a new hard drive on which I installed a new version of W11 with nothing but Chrome and Firefox, but the problem remains exactly the same.
My next step will be to call my ISP to see if anything has changed on their end.
2 Likes
- is the above actually needed?
Try running tcpdump on the router while whatever is broken is happening, maybe you'll see something timing out or not getting responses.
Also try enabling 'private dns' with 'dns.google' on your Android phone:
https://www.zdnet.com/article/what-is-private-dns-mode-on-android-and-how-do-you-enable-it/
(you can try cloudflare and/or quad9 too)
Does that fix the phone's update issues?
If it does, then presumably you'd know the problem is DNS.
If it doesn't, and private DNS works, then it's not DNS.
If private DNS outright doesn't work... maybe there's some weird firewall or something...
For no apparent reason, a problem that lasted 2 months or maybe 3, disappeared.
The only thing I did was to install TCPDUMP and start looking at, and understanding, the packets.
Did my ISP change anything on my line?
I don't know.
Did the TCPDUMP installation modify, install or overwrite any packages that made the problem go away?
I don't know (but my intuition tells me to explore this possibility)
The problem has gone away, however I would like to know why so that I can fix it if it happens again in the future.
I'm still puzzled, but I'm doubly grateful to the Openwrt community for their help, and because in the process of solving the problem I learned new things.
Tcpdump enables promiscuous mode on the interface. But this is not something that can affect your case. You can enable it on the interface as well.
Ok... So the problem is back, but I think I finally found the origin.
While analyzing the Pcap generated by TCPDUMP I found this line several times:
g-pni-mrs-2.routers.proxad.net > SAL9000.lan: ICMP time exceeded in-transit, length 76
I did an internet search with the name of this particular server node g-pni-mrs-2.routers.proxad.net and came across many people having exactly the same problem as me.
I will explore further and come back here, as it may require a special IPV6 configuration on Openwrt in conjunction with the ISP (Freebox) router.
What is its IP? This domain doesn't exist.
The ip is 212.27.40.50 and it's g-pni-mrs-2.routers.proxad.net
I checked it with a tracert and it appear both with TCPDUMP and Wireshark.
This server seems to be the cause of all the problems.
It seems to be a router in France belonging to AS12322 (Free SAS). It's had an issue with Google since at least September 2022.
2 Likes
this happens when there is a routing loop and TTL is exceeded (reached 0) at free's router hence it replies back to client (you). where the routing loop is, cannot be seen from this but probably worth to check with your ISP.
you may increase your outgoing TTL as a test.
1 Like
Increasing TTL won't make any difference. The default TTL is enough to go around the globe 2-3 times and from the traceroute in the french forum that @lleachii posted earlier is visible that the packets are being ping-ponged between their routers.
@KingofPunk better notify your ISP, they can exclude them from routing.
3 Likes
unless not the default is used for whatever reason.
Then OP would have a global issue and not only in Google 
if only the working default would be everywhere OP had not have any issue at all. but has.
my point is: there is an issue with google traffic specifically, other directions are working. according to OP without owrt everything is shiny, with openwrt google traffic is impacted. the only abnormal thing from the pcap is TTL related.
likely ISP routing is screwed google route as all other direction seems to work. but then why everything works without owrt router??? might OP doing TTL manipulation? as OP played with MSS too, s/he might played with TTL (am not saying s/he definitely did, s/he could. we don't know).
by the way what is default TTL value? nowdays in Linux/owrt is 64, in Windows it is 128 ... as i know recommendation is at least 64 due size of modern Internet (but in past it was 16 then 32)
in short: we don't know all details, foremost ISP side. so it might be a destination specific TTL manipulation in owrt custom config, or ISP routing problem or ...
even if OP did not do TTL manipulation a quick traceroute or ping -t does not hurt and may reveal additional info, which maybe interesting for ISP too.
but for sure should report to ISP first. there is no debate on that.
The TTL value doesn't matter, unless you suspect that OP has manipulated the TTL only for the Google sites. Again, you can reach any destination in under 20 hops, so the default of 64 (or 128) is more than enough.
Sure, a traceroute or mtr can be helpful to show to his ISP what stupidity they have done.
2 Likes
Sometimes routing depends on the 8-bit TOS field in the ipv4 header...
Perhaps the Openwrt is modifying that - perhaps applying wifi priority -> dscp marking...
or perhaps it's something to do with the ECN bits in that field (an ECN black hole).
You could try running ping -Q ... on the router itself with varying values of tos (between 0 and 255)
See https://linux.die.net/man/8/ping
Hello,
I am experementing the same issue with my open wrt router, with a freebox mini4K in bridge mode.
@KingofPunk do you still have the issue?
I was never able to solve the problem, I had to remove the WRT3200ACM and connect directly to the Freebox Delta.
If you have any clues, please let me know.
I have find this on the free bug tracking system :
One clue seems to be the conflict between the IPV4 and IPV6, but no result for now.
Edit : Free had deployed a fix just yesterday afternoon, and it's seems to be working!