4 ms·
Reminds me of trying to do IoT stuff in hospitals before IoT was a thing. Send exactly one 205 byte packet. How do you really know? I can see it go out on a sc
by Gibbon1 10mo ago
Reminds me of trying to do IoT stuff in hospitals before IoT was a thing.
Send exactly one 205 byte packet. How do you really know? I can see it go out on a scope. And the other end receives a packet with bytes 0-56. Then another packet with bytes 142-204. Finally a packet a 200ms later with bytes 57-141.
FfffFFFFffff You!
- taherm789 10mo agoThings like these make me cry
- readmodifywrite 10mo agoIf you were using TCP, then this is absolutely normal and expected behavior. It is a stream protocol, not packet/message based.
- josefx 10mo agoAt the application layer you would not see the reordered bytes. However on the network you have IP beneath both UDP and TCP and network hardware is normally free to slice and reorder those IP packages however it wants.
- immibis 10mo agoIt's not. Routers are expected to be allowed to slice IPv4 packets above 576 bytes. They can't slice IPv6 and they can't slice TCP. However, malicious middleboxes insert themselves into your TCP connections, terminating a separate TCP connection on each side of the spyware and therefore completely rewriting TCP segment boundaries. In less common scenarios, the same may be done by non malicious middleboxes - but it's almost always malicious ones. The party that attacked xmpp.is/jabber.ru terminated not only TCP but also TLS and issued itself a Let's Encrypt certificate.
- sundbry 10mo agoIf only there was some sort of User Datagram Protocol where you could send specifically tuned packets like this.
- CamperBob2 10mo agoThose who do not understand TCP are doomed to reimplement it with UDP. The same is true of those who do understand it.
- nomel 10mo agoThat first time you do sure is fun though.