Why doesnt TCP reject the flip bits when the checksum fails?
AT&T Fiber in the SF Bay Area is flipping bits
81–90 of 374 posts
Re: AT&T Fiber in the SF Bay Area is flipping bits
#82Why doesnt TCP reject the flip bits when the checksum fails?
Apparently MacOS doesn't check the checksums.
Re: AT&T Fiber in the SF Bay Area is flipping bits
#83Earlier quoted context omitted.
The parts of SV that haven't buried their power lines (not too pretty to begin with) have gotten significantly uglier since all of the new cable/fiber/DSL infrastructure has gone in. There are in many cases multiple of these things on loads of poles: https://www.dslreports.com/forum/r31593060-Equip-What-is-thi...
Here in Germany we bury everything . I don't even want to imagine how long it takes to rebuild all of that when some drunkard crashes his car into one of these poles or a lightning strike hits.
you'd be surprised but it takes quite an impact to disrupt a telephone pole. most crashes leave the pole standing (see examples online), and even when it does topple the wires seem to hold, and the utility company comes in with a fresh pole. the lightning strike factor does suck if you live very very close to the strike and nothing is surge protected. That happened to my house once and fried my xbox and router.
Re: AT&T Fiber in the SF Bay Area is flipping bits
#84Earlier quoted context omitted.
”I would use traceroute to find a common bad point for everyone“ How do you mean? I use traceroute from time to time but I’m not sure how it would apply in a case like this. Feel free to elaborate :)
Take a traceroute from everyone experiencing the problem, look for the common hops among them all. Then compare that list against people not experiancing the problem to find the differences. The finsl set there are good places to start looking. Sweitches and routers along that way could be the cause
If you ping the hops with a large icmp payload, you might be able to observe the flipped bit in the echo reply. That could help isolate which hop it is.
Re: AT&T Fiber in the SF Bay Area is flipping bits
#85Earlier quoted context omitted.
The ISPs have tried, but they get pushback from local residents whenever they try to install the necessary network boxes at intervals down the street. They had to go out of their way to hide cellular towers as streetlamps to get the 5G rollout to happen; I remember getting two or three notices for this (each from different telcos, so the one street corner has three streetlamps and two traffic lights on one corner). I…
Solution: Paint the boxes grey.
Or even some cheap creeping hedges like bouganvillea
Re: AT&T Fiber in the SF Bay Area is flipping bits
#86Doesnt tcp have a checksum field? Would this mean they are doing mitm business with non-encrypted traffic?
I am thinking the same problem. TCP checksum includes data field. Is it means AT&T flip bits and re-calculate checksum?
Re: AT&T Fiber in the SF Bay Area is flipping bits
#87Earlier quoted context omitted.
The parts of SV that haven't buried their power lines (not too pretty to begin with) have gotten significantly uglier since all of the new cable/fiber/DSL infrastructure has gone in. There are in many cases multiple of these things on loads of poles: https://www.dslreports.com/forum/r31593060-Equip-What-is-thi...
The parts of SV that have buried their power lines, probably haven't gotten a whole lot of new cable/fiber/DSL than whatever was there when they buried it. SV is the perfect place to not bury infrastructure. There's no weather to worry about, and mostly people aren't going to shoot down the fiber to try to claim scrap metals.
I live in one of the few cities in the Bay Area where everything is buried, and it's refreshing not to have stuff hanging all over the place and blocking the view. Now, granted, AT&T fiber is slow to come here, but it's hard to know if the fact that the infrastructure is buried is the main reason. They are in some areas of town but not others.
You can bury conduits, by the way, and not cables or fiber directly. This allows you to avoid digging again just to install fiber, for example. There are ways to do it right. And having the infrastructure on poles is not a panacea either. New providers are not necessarily allowed to use the poles. The weather might not be crazy, but the poles are already overloaded and a little windstorm will disrupt electricity, coax cable, or fiber. And of course, those overloaded poles are crazy ugly.
Re: AT&T Fiber in the SF Bay Area is flipping bits
#88I believe I felt that one in Croatia. Started on 6-7th November.
My ISP Tele2, Croatia. But, I am on a 4G LTE router.
Haven't had it for 2 years since I've been with that ISP nothing the same as described.
Or at least we had some strange stuff for a few days, I thought it was my dedicated server SSH and MTU, bu not. When connected through the VPN, the speed is normal, fine. Also, FTP was working fine.
But, without a VPN, the network seems to be "throttled" somehow, do not know why.
Persists today. I have to use VPN for SSH connection to my server and to download on my "full speed" over FTP.
And my router is D-LINK, since firmware upgrade cannot access HTTPS configuration. Bad certificate :/
Re: AT&T Fiber in the SF Bay Area is flipping bits
#89From my professional experience of programming and debugging networking equipment, this could be a switch/router with a buffer with bad memory (stuck bit maybe). The better chips have CRC/Parity/ECC to cover such issues but there are always those magical choke points where the past CRC is tossed and the new one is generated that can leave a gaping hole. The tricky part is how often is this bad memory buffer used... I…
You can use ping to more easily hunt these types of issues, for example `ping -A -c 100 -s 1000 -p deadbeef` will show the difference if there is a flipped bit in the payload. You can generate patterns with xxd.
Re: AT&T Fiber in the SF Bay Area is flipping bits
#90Earlier quoted context omitted.
Take a traceroute from everyone experiencing the problem, look for the common hops among them all. Then compare that list against people not experiancing the problem to find the differences. The finsl set there are good places to start looking. Sweitches and routers along that way could be the cause
If you ping the hops with a large icmp payload, you might be able to observe the flipped bit in the echo reply. That could help isolate which hop it is.
You get some amount of your traceroute packet back too, could have flipped bits in there.