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

When networking doesn't work

os2museum.com

Post reply on HN
Print view View original

11–17 of 17 posts

Re: When networking doesn't work

#11

Post by codemog »

userbinator wrote: post #7

Without disassembling and tracing the Intel Windows drivers (something I don’t feel like doing) As someone who generally doesn't use AI in software development nor RE, this is one thing that I'd recommend trying one on to see what it can do: the problem is clearly defined and a solution is easily validated, and it's a problem you're not intersted in digging deeper yourself. The other comment here about 0000 and FFFF…

Exactly. Why would people willingly do this kind of tedious grunt work by hand instead of having a machine do it? I guess some people enjoy it, but it was always one of my least favorite parts.

Re: When networking doesn't work

#12

Post by ErroneousBosh »

bombcar wrote: post #2

It'd be interesting to see what the wrong checksum it calculates is ...

Someone else mentioned further up that it's all zeroes or all ones. A checksum of all zeroes means "this packet has no checksum and that's okay". Because of the way it's calculated 0xffff works out the same as 0x0000, so if the checksum happens to sum to 0x0000 it's replaced with 0xffff.

Both values are totally valid checksums but some people don't believe that :-)

Re: When networking doesn't work

#13

Post by ongy »

deathanatos wrote: post #4

But what was the checksum? Like the actual, specific value? The Factorio devs found[1] that some devices do fail to compute checksums, in that they compute the checksum just fine, but they're doing something stupid with some values and so checksums of 0x0000 or 0xFFFF (the two values from the FFF) cause packet loss. In any protocol that, when the packet repeats, repeats it with even the slightest permutation (differe…

In my university times I wrote a library (to help with some homework we gave students) that calculated the CRC32 for ethernet.

Which worked well unless compiled with `strict-aliasing` gcc optimizations enabled...

Just writing UDP RFC compliant code doesn't protect you from running into annoying behavior with your programming language of choice...

Re: When networking doesn't work

#14

Post by RiverCrochet »

nubinetwork wrote: post #3

Interesting... I've heard enabling tx/rx offloading is actually beneficial, turns out that's not always the case...

Many NICs have embedded ARM or other CPU cores (sometimes multiple) to do offloading, and the OS NIC driver contains code to be run on them.

Re: When networking doesn't work

#15

Post by dijit »

RiverCrochet wrote: post #14
nubinetwork wrote: post #3

Interesting... I've heard enabling tx/rx offloading is actually beneficial, turns out that's not always the case...

Many NICs have embedded ARM or other CPU cores (sometimes multiple) to do offloading, and the OS NIC driver contains code to be run on them.

yeah, but sometimes the calculations they do are wrong.

Very annoying when it happens, used to be common on the chipsets in the TB16 Thunderbolt docks from Dell... if you knew to turn off the offloading the ethernet worked otherwise it was slower than wifi..

Realtek RTL8153 iirc.

Re: When networking doesn't work

#16

Post by adzm »

ongy wrote: post #13
deathanatos wrote: post #4

But what was the checksum? Like the actual, specific value? The Factorio devs found[1] that some devices do fail to compute checksums, in that they compute the checksum just fine, but they're doing something stupid with some values and so checksums of 0x0000 or 0xFFFF (the two values from the FFF) cause packet loss. In any protocol that, when the packet repeats, repeats it with even the slightest permutation (differe…

In my university times I wrote a library (to help with some homework we gave students) that calculated the CRC32 for ethernet. Which worked well unless compiled with `strict-aliasing` gcc optimizations enabled... Just writing UDP RFC compliant code doesn't protect you from running into annoying behavior with your programming language of choice...

> Which worked well unless compiled with `strict-aliasing` gcc optimizations enabled

I can't imagine enabling this by default instead of opting in with __restrict or equivalent. Just so many things that could go wrong if every little piece of code was not written with aliasing in mind.

Re: When networking doesn't work

#17

Post by deathanatos »

adzm wrote: post #16
ongy wrote: post #13

Earlier quoted context omitted.

In my university times I wrote a library (to help with some homework we gave students) that calculated the CRC32 for ethernet. Which worked well unless compiled with `strict-aliasing` gcc optimizations enabled... Just writing UDP RFC compliant code doesn't protect you from running into annoying behavior with your programming language of choice...

> Which worked well unless compiled with `strict-aliasing` gcc optimizations enabled I can't imagine enabling this by default instead of opting in with __restrict or equivalent. Just so many things that could go wrong if every little piece of code was not written with aliasing in mind.

The GCC flag is `-fno-strict-aliasing`, unless there is one I'm unaware of, which tells the compiler to essentially assume code might make aliasing mistakes.

> Just so many things that could go wrong if every little piece of code was not written with aliasing in mind.

You should always be writing "with aliasing in mind". It is a rule of the language, which specifies the "strict aliasing" that flag refers to, and it's UB to alias in ways which are not allowed. (Some aliasing is permitted by C. It's mostly type-punning that isn't.)

For computing the packet checksum, I'm not sure how you'd manage to run afoul of the strict-aliasing rule (you're just iterating over an array of octets … right?), but C is one of those "assume nothing" languages…

Post reply on HN