I would certainly hope that "entering an endless boot loop" is considered a malfunction no matter what network traffic is occurring.
TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.
As originally mentioned here in RFC 761 but credit to Wikipedia for having the citation.
Once the switch is in airplane mode, the endlessly looping device seems fixed.
The fact that it reboots is probably a bug.
The fact that it reboots endlessly is caused by the nintendo switch endlessly broadcasting the same signal.
To add to this, even if it wouldn't be for legitimate purposes, a device shouldn't enter a boot loop because another device is malfunctioning.
2. Three-way handshake.
4. Please reboot.
The chain described there is "possible network traffic", and would be a valid type of network traffic, "while-meaning-to" if we so please, but there is no way to distinguish that and it is thus meaningless to code.
A device that would never reboot, no matter what network traffic is occurring, would never allow you to reboot it remotely... SSH is network traffic. Your SSH authentication also is.
The point wasn't about the Roku, it was a pointed reply to that particular point, I think. :)
Besides, words have multiple meanings, and there are many floating signifiers in the world. Correcting diction without an acknowledgment of intent might as well be pissing into the wind.
On a personal level, aimless pedantry is a terrible attribute in people you work with, and these people can be toxic to productivity.
> Pokémon sends a network discovery packet to each device on port 26037. Roku also listen on that port for LAN based updates so that multiple devices on the same network can update each other. It was an obvious decision. Saved Roku around a quarter million dollars in CDN traffic costs. Roku is popular in the commercial space where it’s often used as a media source to control sometimes 100s of TVs on the same network. It just so happens that Pokémon’s network discovery packet shares the exact same bytes as Roku’s signed bytecode to reboot.
> The odds are astronomically low. We could have wound up with an alien planet full of Justin Timberlake clones, but the universe decided this was our colossal fluke.
EDIT: Nope, nothing. They just stated it as fact and left it it at that. I'm calling shenanigans. Amusing theory, but it really is too incredulous to believe without any evidence.
I'd find a collision of such low probability very humorous if it actually happened.
Not if both teams, or lazy developers on both teams, picked some sample code from a book, blog or public GitHub repo and didn't bother to make obvious changes.
The only thing we're missing are some back-of-the-envelope estimates of whether Roku really saved $250k on CDN fees and whether Roku devices are, in fact, used in commercial settings.
It's one of the weirdassest things I've seen on HN (a forum, it is worth recalling, on which the intellectual rigour the discipline of programming instills in its practitioners is frequently extolled) and I've been here a while.
> The odds are astronomically low.
Interesting. Any chance anyone here would know exactly how many bytes we're talking about?
So either "signed" means something different in this context or GameFreak replicated Roku's reboot packet for some reason.
Indeed, and 16-bytes is SHA1 or MD5, both considered insecure at this point. 32-bytes (SHA256) seems more likely to me.
So I'm going to bet that they aren't "signing" the packet.
(SHA1 is 20 bytes, BTW.)
Cryptographic hashes are prone to the birthday attack instead. MD5 hashes (128-bits) are broken when a computer has enough power to calculate 2^64 keys (birthday attack: they found a hash collision).
I think it's funny.
Nintendo made an informed decision and their hardware is welcome on my networks.
If you assume basic _routing_ doesn't work, why do you assume a TCP connection from one to another would work? If an AP implements client isolation (as many home models do now for "guest" networks) broadcast would be the only thing that works.
Pretty much every printer you buy now uses Bonjour for printing, so your average SOHO router is going to make sure that works.
I can't fault them, at one point I thought this was the right way to do autodiscovery on a LAN too. Then I learned from my mistakes.
Bottom line is that nothing on an IP network should do something st00pid if it gets a random weird packet from a random IP, because the whole history of IP shows that you will, eventually, get one.
Edit to add: and Pokémon games have used peer to peer protocols before on different systems, so this use isn’t new to Pokémon or Nintendo systems.
I might be able to sniff the packets later today.
To me it looks like a Roku issue. A device shouldn’t go into a reboot loop if it encounters something unexpected. I also heard the switch uses its own version of Bluetooth to add 8 players but since its nonstandard they won’t let you connect any BT devices to it.
If I had to guess it's probably something silly like not actually checking the signature for validity, or (more likely, IMO) incorrectly checking the length of the packet and getting a buffer overflow/underflow that eventually crashes the Roku.
Also I get the huge unlikeliness of this happening but massively unlikely things do occasionally happen.
This is less likely then two people generating the same random GUID. For SHA256, it's the same as generating two GUIDs in the same message and having them both be identical.
> Connect to your fingerd daemon and type more than 528 (= 512 + 16) characters (any will do). If your daemon crashes or terminates the connection with no data sent back, you probably have the vulnerability.
Of course, it's funny that a specific game is involved here. Perhaps there are other Switch games that do it too?
The only thing I would find implausible about breaking Rokus by proximity would be why the Rokus are picking up the communication from a Switch, when presumably they didn't break whenever someone used a 3DS within ten yards (or we'd have heard these complaints years ago). But that could easily be down to changes in protocol by Nintendo between the two systems, such that one is ignored and the other is mistaken for relevant data.
I don't have a Roku or an easy way to inspect nearby wifi packets, so I can't easily test this theory.
> (1) This device may not cause harmful interference
> (2) this device must accept any interference received, including interference that may cause undesired operation.
You'll see it's actually a general, universal principle of good communication, and applies to many cases other than RF spectrum. Internet pioneer Jon Postel once said TCP implementations should follow a general principle of robustness:
> (1) Be conservative in what you send
> (2) Be liberal in what you accept.
It's almost identical to the principles of Part 15.
A few years ago, when the Mirai botnet launched its massive DDoS attack, a HN user used Part 15 as an analogy of the future directions of IoT's security model. And in this example of protocol conflict between Pokemon and Roku, it also applies.
It's like the person on your team that insists on shoehorning language features into the application from the dustiest corners of the language instead of sticking to the tried-and-true idioms.
Uh, considering that Nintendo became popular by breaking the arcade game mold with Donkey Kong, and continued that trend with Super Mario Bros, The Legend of Zelda, Pokemon, etc. then went on to create things like Wii Music, not to mention the Wiimotes, building a tablet into the WiiU, Amiibos, Labo...
Conservative isn't the word I'd associate Nintendo with.