Apparently, the "Nintendo WiFi Network Adapter" was once a thing in Japan, and it did have a router mode.
https://www.wired.com/2008/09/nintendo-announ-2/
https://www.famitsu.com/game/news/1217892_1124.html
https://kotaku.com/nintendo-announces-wii-ds-wifi-router-bwa...
This obviously doesn’t help DS users though.
I went through this when setting up the switch to talk to someone behind heavy NAT over the holidays. 45000+ worked for me.
....which makes this even more ridiculous if it never uses them.
And let's not ever talk about two people in the same home playing the same game together. I loved splinter cell blacklist's multiplayer but damn did it take long to get anything connected.
I'm not even sure why I mean this was with internet gaming already being the norm, I assume it's because they made games for console and then ported, and on console port issue are handled for them or whatever ? Anyway this was stupid
The wide port range I think is Nintendo throwing their hands in the air and not actually knowing what ports third party switch software uses
Among the 4 first links, 3 explicitly tell me that UPnP is dangerous.
The most common problem I have seen over and over is double NAT or CGNAT. For the home networks I manage (my parents, in-laws, and my own), I put the ISP modems in bridge mode or passthrough mode.
Other problems will go to other vendors - and if their advice stops your switch from working, that's on them.
Perfect business sense.
I feel like it would be a fun excercise to intentionally subvert the assumptions they made and see how they handle it.
Something like putting your Switch on a /30 or Configuring DHCP to assign IPs in decreasing order.
> I feel like it would be a fun excercise to intentionally subvert the assumptions they made and see how they handle it.
[1] https://en-americas-support.nintendo.com/app/answers/detail/...
> 4. Enter the IP address you found on the network device, but add 20 to the last section of digits, and then select OK.
> As an example, if your computer's IP address displays as 192.168.2.5, enter 192.168.2.25 on the Nintendo Switch.
Hope you don't have more than 20 devices on your network (after your PC), and that they're not configured to be close to 255 there...
The main dhcp server used in most routers, dnsmasq, also assigns IPs using a MAC algorithm by default for consistent IP addressing of devices in a LAN. You would need to explicitly configure it for sequential first come first serve.
Forwarding all these ports was the recommended solution in Nintendo’s docs. However, it did nothing to resolve this problem. What helped was to ensure not to modify source ports in the NAT setup (“static-port” in pf).
It does make me wonder if all ISP provided routers are pretty insecure in some way?
Hell it took years for them to implement Bluetooth audio on the Switch, and that's output-only, no microphone. What stuff is their software division smoking?
https://en.wikipedia.org/wiki/Family_Computer_Network_System (1988)
https://en.wikipedia.org/wiki/Satellaview (1995)
https://en.wikipedia.org/wiki/64DD (1999)
They don't understand a lot of things, even some of which they've lucked into, like the competitive Smash scene. Or fan remakes and tributes (of which Sega notoriously doesn't send their lawyers after).
But they still make some incredibly compelling games.
Maybe the DNA of the company is just too focused on games specifically
It's not just that the UX is a bit clunky, it's that it's a veritable morass of junk, a lot of which is regurgitated ports of PC titles...
They didn't understand how online shops work, to be fair all titles still at least play, but there is not as high quality control as I would have expected.
I say this as, Nintendo has a reputation and clout as a games developer (honestly none of their consoles have ever been great - they have mishaps in the software world but it is rarer), looking at their store you see a suspicious similarity to steam with sales - in fact as far as software goes a humble bundle subscription is probably a better value proposition. It's just not the rich and high quality, unique catalog people have come to associate with them. Maybe it was always like that regarding 3rd party games, but it just underlines how much they don't understand the internet...
The buggy firmware that allowed control from outside had nothing to do with UPnP, it was... just buggy firmware implementing it wrong. And it can be easily detected with online testers.
I always leave UPnP on, and I've never seen it disabled by default, nor would I ever want them to do that.
When the router does it right, it's just a small extra convenience for malware that can only be used when they already compromised your system. If they are in your network already, they can already do whatever they want.
You just can't play networked games with Switch, or what?
The Router will keep track of network package going through to the Internet and store it in a table. in case there is an answer from outside of your network the router will look up whether a client started this conversation (there is a corresponding entry in his table) and will forward the incoming packet to the client that started the conversation.
What nintendo is asking you to allow here is to allow any outside packet coming in over UDP to get to the switch whether it first asked for it or not.
This means in practice you won't be able to run any other service which needs an UDP port fowarded in your network. It also means anyone can talk directly to your switch on any port they like whether you want to or not.
And it means, that should something ever take/get the same IP as the switch it will be exposed to the Internet directly
I'm not sure if most routers prioritize port forwarding rules or NAT tables. That's really up to implementation.
Is the Switch able to do other stuff which is not reported or mentioned anywhere?
When i use a router from my ISP it always just works.
I will not elaborate
Solid advice, redirect all incoming UDP traffic to your Switch, and your Switch alone...
Next, just about all real-time communications uses UDP, so your Skype, Zoom, &c. are all broken. And it just goes on. Some, like HTTP/3, will happily fall back to TCP when they observe it’s broken (HTTP/3 will fall back to HTTP/1 or HTTP/2), but various things will just be broken.
Take a look at everything in https://www.iana.org/assignments/service-names-port-numbers/... that uses UDP. This will break just about all of it.
And even if you didn’t need any of those things: what if you want to have two Switches on your network?
This is just mind-bogglingly stupid advice.
Switch is requesting ALL of the ports, which is going to make the above a bit difficult, to say the least.
https://www.reddit.com/r/NintendoSwitch/comments/agv6hw/fixi...
https://docs.netgate.com/pfsense/en/latest/services/upnp.htm...
https://www.sciencedirect.com/topics/computer-science/regist...
Problem one: Nintendo wants you to take your IP and add 20. So if you live in blahstreet 1 box 7, they tell you to send all Switch post to blahstreet 1 box 27. If someone else happens to own that box, bad luck for him. Worse, the IPs are dynamic via DHCP, so a box unused today may be used tomorrow. But that's the minor part.
Problem 2: Nintendo wants you to tape a big paper above the pidgeon holes, saying: Postmaster, please drop all mail in box 27, no matter what box it specifies. Technically only for UDP, so the TCP traffic will be delivered. Even so, a lot of post will be wrongly delivered to the Switch and thrown away. Other tenants will wonder why they don't get their mail.
Problem 3: You become very vulnerable. The router will send every hacking attempt to the Switch. The tiniest bug in its networking is now critical, as outsiders can just assume your Switch will receive anything they send.
To recap, Nintendo is making sure their device receives traffic by throwing every other device you own under the bus. Even a second Switch will suffer. The advice is Dilbert PHB level idiotic but will seem to work for a while.
But these days most users don't connect to remote servers directly. Instead, they're on a local network that connects through a router that only has a single world-routable IPv4 address. That means that while the combination of local and remote IPs and ports is still nominally a unique identifier, the local IP could now refer to multiple different devices. NAT handles this by keeping track of which machine behind the NAT triggered a local connection, mapping its local port to a local port on the publicly routable IP, and then rewriting traffic and forwarding it appropriately so this is mostly invisible (eg, you send traffic to 142.250.189.174 on port 80, and your local port is 31337. Someone else on your network may also be using port 31337 to talk to port 80 on 142.250.189.174, so your NAT router rewrites your local port to 31338. When it sees incoming traffic on port 31338 from 142.250.189.174, it rewrites the packet to be sent to you and as far as you're concerned you're directly communicating with 142.250.189.174)
This basically works fine for TCP, because TCP requires you to explicitly make a connection. That means the NAT router can tie the combination of a remote host and a local port to a unique mapping to an internal machine. But UDP is, at the transport layer, stateless - when you send traffic to a remote machine over UDP, the expectation is that that remote machine can just send traffic back to the same UDP port at some arbitrary point in the future and, if the local client is still listening, that'll got through.
If you port-forward literally every UDP port to a specific device, when another local device tries to connect to an external service over UDP, your router will probably be confused - it can't just say "Ok, you connected to something over UDP, I rewrote your local port to 31337, traffic to 31337 will be sent to you", because 31337 is already configured to be forwarded to the Switch. You can potentially send traffic to a remote service, but the responses may be forwarded to the wrong device.
In theory you could say that because a machine with a specific internal IP sent traffic to a specific remote IP and you rewrote that to a specific port, any traffic from that remote IP to that port should be forwarded to that internal IP even if there's a general port forwarding rule that would instead forward it to the Switch. I have no idea whether that's how routers behave, and it's far too late for me to dig into the kernel source to check that (I've spent the evening fighting Linux's in-kernel ASN1 parser, I'm not inclined to do more)