naia-lib / naia

a cross-platform (including Wasm!) networking library built in Rust. Intended to make multiplayer game development dead-simple & lightning-fast
Apache License 2.0
878 stars 58 forks source link

Firefox issues: won't connect to Public IP (but OK on LAN) #84

Open gak opened 2 years ago

gak commented 2 years ago

Hi,

I've been able to get a connection from Firefox to naia based server via WebRTC perfectly fine on LAN addresses. As soon as it connects via a public IP address, I get the error below. I can only guess it is using some other protocol when it should just be sending a HTTP POST?

I've tried many combinations of things with no luck. CORS is enabled for all hosts, if that makes a difference.

When changing the IP address I always update the public_webrtc_url in ServerAddrs to match the public IP address of the server.

I thought it was a firewall issue (at home), so I just ran it on a DigitalOcean host (which is what the logs are below) and exactly the same thing happened.

(Very limited knowledge about this:) I tried removing the STUN entries as I don't need any sort of NAT, as the server is not behind a NAT, but that caused a panic elsewhere in the code.

2022-08-24T21:24:27.803226Z  INFO server::init: Server running! http://198.199.92.237
2022-08-24T21:24:28.262014Z  INFO webrtc_unreliable::server: new WebRTC data channel server listening on 0.0.0.0:24192, public addr 198.199.92.237:24192
2022-08-24T21:24:28.262310Z  INFO naia_server_socket::backends::webrtc::session: Session initiator available at POST http://0.0.0.0:24191/rtc_session    
thread 'smol-1' panicked at 'called `Result::unwrap()` on an `Err` value: FromUtf8Error { bytes: [22, 3, 1, 2, 0, 1, 0, 1, 252, 3, 3, 178, 173, 225, 104, 22, 115, 221, 23, 221, 233, 244, 68, 156, 1, 103, 246, 93, 182, 97, 41, 46, 201, 60, 15, 209, 134, 47, 79, 52, 43, 22, 161, 32, 12, 185, 154, 2, 24, 139, 104, 127, 92, 69, 57, 125, 25, 26, 129, 119, 212, 138, 235, 20, 66, 11, 71, 86, 39, 173, 220, 43, 95, 138, 160, 65, 0, 34, 19, 1, 19, 3, 19, 2, 192, 43, 192, 47, 204, 169, 204, 168, 192, 44, 192, 48, 192], error: Utf8Error { valid_up_to: 8, error_len: Some(1) } }', /root/naia/socket/server/src/backends/webrtc/session.rs:101:63

Sorry for asking in here, this is probably me doing something stupid (I don't know much about WebRTC), and thought this would be the best place to get a good answer. Thanks for any hints/help.

connorcarpenter commented 2 years ago

I don't think you've done anything stupid .. Personally I have been very stumped by how to get this working on Firefox. I've spent several hours myself messing with Firefox feature flags regarding WebRTC .. no luck.

Related: https://github.com/naia-lib/naia/issues/46 https://github.com/triplehex/webrtc-unreliable/issues/3 (kyren seems to think the issue is with the loopback address in the demo .. not true)

connorcarpenter commented 2 years ago

Wait, I saw a little while back on Discord that Firefox requires you use port 3478 for WebRTC? Try that. Also search for "Firefox" in the Naia Discord for further hints possibly?

gak commented 2 years ago

Thanks for the response! I'll try your suggestions and check out the Discord, report here if I discover a solution.

FF-AntiK commented 1 year ago

I didn't know about the port 3478 requirement for Firefox. I've tried to just change the port for webrtc_listen_addr and public_webrtc_url. (But not session_listen_addr) Unfortunately Firefox still refuses to connect.

I still guess it has something to do with webrtc-unreliable and connecting to IPv6 only...

FF-AntiK commented 1 year ago

Also it kind of makes sense to firefox to not allow the connection. Have a look at the response I'm getting from the naia server: Screenshot_20221107_110528

Of course this is the correct IPv4 address of my server. But the DNS entry only resolves to the IPv6 address. So firefox assumes the IPv6 address to be the one to cummunicate with. I think security wise it's a good idea to reject connections to other addresses. Think of it like the CORS restrictions modern browsers have these days.

FF-AntiK commented 1 year ago

Oh and just for completeness. This is what I get in chromium, where everything works fine: Screenshot_20221107_131853

As you can see, here the server offers both IPv6 und IPv4. Chromium decides to use IPv4 but fortunately doesn't care about the "foreign" address.

FF-AntiK commented 1 year ago

Okay, nevermind. I've disabled IPv6 on my server completely. Won't work either...