Ernst Lopes Cardozo
New Around Here
Ok, I’ll try to put this as short and simple as I can. Under certain conditions, I cannot access certain websites but I can access other sites without problem. “Access” here means open the sites in a browser, on Windows 10 or Android, using Chrome or Firefox or a site-specific application. But I can ping these sites and get a normal response. The browsers tell me that the site did not respond in time. I traced a connection with Wireshark and saw a health handshake, a normal GET request sent and then only keep-alives. Yet these are mainstream sites, like speedtest.net, the (French) IRS, a web shop that makes car plates, Netflix.com, … nothing exotice. This is strange, but the weird part is yet to come.
I have two internet access connections, a WISP for which I have a good old WRT54G with their firmware acting as a “modem”. It is wired to the WAN port of my RT-AC68U (running the latest Merlin firmware). Alternatively, I can use a 3G/4G mobile router (Huawei B593s-12), connected to a completely different operator. In that case I unplug the WRT54G and plug the same cable in the Huawei. And that, my friends, makes all the difference!
When I am on the mobile network, all these sites are accessible. When I am on the WISP network, they are not.
So I thought there was a problem in the big NAT that my WISP is using to connect its customers to the net. Except, that when I plug my PC directly into the WISP modem, they are accessible without problem. This proves that it is not their fault.
Yet, when that same WAN port is connected to the Huawei / mobile network, the problem disappears, so it is NOT in the RT-AC68U or any of the components between my PC or Android phone and the WAN cable.
What am I missing?
<grandfather story> Back in the 80’s, when Ethernet was moving from coaxial cable to twisted pair, I witnessed a problem where certain services on the LAN were inaccessible for no good reason. Until we found the non-twisted patch cables used in a wiring closet. Apparently, the reflections they caused would kill specific packets while passing other (especially: shorter) packets without problem </grandfather story>. So let me test with a new WAN-to-modem cable and report back here. In the meantime, any suggestions are welcome. No, I did not roll back the router software to earlier versions – I cannot for the life of me imagine how this could be a software bug. But I just might try that next.
I have two internet access connections, a WISP for which I have a good old WRT54G with their firmware acting as a “modem”. It is wired to the WAN port of my RT-AC68U (running the latest Merlin firmware). Alternatively, I can use a 3G/4G mobile router (Huawei B593s-12), connected to a completely different operator. In that case I unplug the WRT54G and plug the same cable in the Huawei. And that, my friends, makes all the difference!
When I am on the mobile network, all these sites are accessible. When I am on the WISP network, they are not.
So I thought there was a problem in the big NAT that my WISP is using to connect its customers to the net. Except, that when I plug my PC directly into the WISP modem, they are accessible without problem. This proves that it is not their fault.
Yet, when that same WAN port is connected to the Huawei / mobile network, the problem disappears, so it is NOT in the RT-AC68U or any of the components between my PC or Android phone and the WAN cable.
What am I missing?
<grandfather story> Back in the 80’s, when Ethernet was moving from coaxial cable to twisted pair, I witnessed a problem where certain services on the LAN were inaccessible for no good reason. Until we found the non-twisted patch cables used in a wiring closet. Apparently, the reflections they caused would kill specific packets while passing other (especially: shorter) packets without problem </grandfather story>. So let me test with a new WAN-to-modem cable and report back here. In the meantime, any suggestions are welcome. No, I did not roll back the router software to earlier versions – I cannot for the life of me imagine how this could be a software bug. But I just might try that next.