Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AT&T Fiber in the SF Bay Area is flipping bits

twitter.com

Post reply on HN
Print view View original

361–370 of 374 posts

Re: AT&T Fiber in the SF Bay Area is flipping bits

#361

Post by ncmncm »

cranekam wrote: post #269
toast0 wrote: post #224

Earlier quoted context omitted.

Or their computer isn't checking the checksum. As is apparently the case on mac os (as reported elsewhere in the thread). Another quality product by Apple ;P

There’s no proof of this. And what possible reason would macOS have for not checking the checksum? Although the checksum is weak it presumably catches at least some corrupt traffic. Do you really think Apple would just skip the TCP checksum and make its network performance less reliable when they have already implemented (or maintained if it came from BSD) the rest of a TCP/IP stack, which is vastly more complex, jus…

It is extremely common for hardware to be configured to ignore checksums. ("A packet with a bad checksum would have been dropped before it got here. Our cabling is too short to drop bits.")

Re: AT&T Fiber in the SF Bay Area is flipping bits

#362

Post by ummonk »

FullyFunctional wrote: post #302
ummonk wrote: post #291

Earlier quoted context omitted.

No, it hasn't made anything uglier - you don't really notice the infrastructure unless you're specifically trying to look for something to get annoyed by.

Maybe you have gotten blind to it? When I first landed in Palo Alto (coming from Europe), I couldn't believe my eyes: 3rd world infrastructure with wires flying everywhere! I most definitely noticed and notice. It's symptomatic of some of the ill that plague Sillicon Valley.

Overhead power / telecom lines (and cable car power lines) have always been a thing in America. Adding fiber and additional infrastructure hasn't really made it uglier. It would be different if we had buried power lines to start with.

Re: AT&T Fiber in the SF Bay Area is flipping bits

#363

Post by warent »

sneak wrote: post #180
warent wrote: post #107

Earlier quoted context omitted.

The obnoxious thing to me is the hubris that must be behind this. Either they considered it and decided they would never encounter a system error like this and refused to implement an escalation route, or they never even considered it. Or perhaps even worse than that, maybe they considered it, decided it was possible, but just don't care because of their insane borderline monopoly. I don't understand how internet com…

Either that or every single CSR takes 50 calls per day, every day, that start with "There's a problem with the AT&T network!!!"

Do you find it difficult to believe many of those calls actually are issues with the AT&T network?

Re: AT&T Fiber in the SF Bay Area is flipping bits

#365

Post by tialaramex »

superjan wrote: post #324
tialaramex wrote: post #209

Earlier quoted context omitted.

> presumably because a corrupted packet in a TLS handshake is an error and the connection dies Not just in the handshake, TLS moves these things called TLSPlaintext records (about 16kbytes each), not only in the handshake, but also for all the actual data - and they'll always have integrity protection to ensure bad guys can't change anything. TLS can't know the difference between a bad guy tampering with data and you…

Thanks for sharing this! I have long suspected that TLS does this. It is great: for many applications preventing bitflips in transit is arguably more important than privacy. Is there an authorative source where this is documented?

You mean besides the RFCs (the most recent RFC 8446 describes TLS 1.3) ?

https://tools.ietf.org/html/rfc8446

If you aren't interested in why this works just the Introduction to the RFC explains the intent, specifically what we care about here is that TLS delivers:

"Integrity: Data sent over the channel after establishment cannot be modified by attackers without detection."

And further notes "These properties should be true even in the face of an attacker who has complete control of the network".

Re: AT&T Fiber in the SF Bay Area is flipping bits

#366

Post by Avery3R »

noncoml wrote: post #355
ericbarrett wrote: post #276

Earlier quoted context omitted.

Checksums are also often recomputed on transit if the packet is intercepted, e.g. to limit TTL, unflag odd/unused TCP features, that kind of ISP-ish preening. So if it was a software error or even a hardware problem in the right (wrong) spot it’s possible to get this kind of corruption without retransmits.

I think you are confusing the IP header with TCP header. Routers don’t touch the TCP header at all

if your router does NAT it touches the tcp header

Re: AT&T Fiber in the SF Bay Area is flipping bits

#367

Post by lights0123 »

Rychard wrote: post #347
stevencorona wrote: post #274

Earlier quoted context omitted.

Huge bummer but the next generation of ATT routers with onboard ONT don’t work this bypass :(

Do you know the model numbers and/or have any other information about these new routers? I'm currently using eap_proxy with my BGW210, and it's been a huge improvement, but I fear the day the device needs to be replaced with a newer model.

BGW320 is the new model, which I had installed about a month ago. It isn't a simple swap, as it uses a SFP module combined with the modem's internal ONT instead of a separate ONT, so I've heard it's only used in new installations. More about it: https://www.dslreports.com/forum/r32605799-BGW320-505-new-ga... (although theirs says 1550nm while mine says 1310nm)

However, it has 5Gbit Ethernet, hasn't re-enabled WiFi on automatic firmware updates, and has only screwed with my IP Passthrough configs once which was resolved with a router reboot. (that was possibly my router's fault, it seemed like it was unable to fetch a new DHCP lease)

Re: AT&T Fiber in the SF Bay Area is flipping bits

#368

Post by noncoml »

Avery3R wrote: post #366
noncoml wrote: post #355

Earlier quoted context omitted.

I think you are confusing the IP header with TCP header. Routers don’t touch the TCP header at all

if your router does NAT it touches the tcp header

You are right, although NAT could be classified as a firewall feature, that runs on routers.

But in any case it's irrelevant in this context as ATT shouldn't be doing any NAT

Re: AT&T Fiber in the SF Bay Area is flipping bits

#369

Post by osamagirl69 »

osamagirl69 wrote: post #111

I see this on my end too (redwood city) using the check against example.com diff example-http example-tls 4c4 > Example Domain Been wondering why my tls connections kept failing...

Update - they seem to have fixed it! The same script successfully ran for 5 minutes for me without problems today

Re: AT&T Fiber in the SF Bay Area is flipping bits

#370

Post by ericbarrett »

noncoml wrote: post #355
ericbarrett wrote: post #276

Earlier quoted context omitted.

Checksums are also often recomputed on transit if the packet is intercepted, e.g. to limit TTL, unflag odd/unused TCP features, that kind of ISP-ish preening. So if it was a software error or even a hardware problem in the right (wrong) spot it’s possible to get this kind of corruption without retransmits.

I think you are confusing the IP header with TCP header. Routers don’t touch the TCP header at all

No. URG, “Christmas tree” packets, etc. all can be mangled by the ISP. Or more commonly dropped
Post reply on HN