Dscard UDP packet because Sender IP doesn't match TCP session address

[willan]

Hi

I'm currently developing my multiplayer game using smartfox server.
It's a fast pace game, so I make use of the UDP protocol for better performance.
It works well almost all the time.

Though there are some times, I got the error of

Discard UDP packet from <IP>:<P1>, reason: Sender UDP Port doesn't match current session port

or some sort.
I searched and was able to fix it permanently with the allowClientUdpPortChanges config

But recently, I tested my game from a coffee shop and get a similar error of

Discard UDP packet from <IP1>:<P>, reason: Sender IP doesn't match TCP session address: <IP1> != <IP2>

I tried to find the root of error and found out that it's because of the coffee shop internet. They seems to have their internet provided by 2 ISPs, and I'm not sure how they configure their network, but when connecting to their network, my public IP changed randomly between 2 IPs (IP1 and IP2 on the error message) on each time of connecting. I guess this is the reason the IP also changed on TCP and UDP connection to my game, and cause the above error

But because this error is a client error with a coffee shop network, it's not something like my server is behind a proxy server or something similar like in other posts. So I believe that if my game is published, the error will happen somewhere else, with similar network. And I suppose the game will lose some users because of it.

I did try to search for a solution of this error, or even just workaround, but couldn't found any.
So I post this here with the hope that you could help me with some clues, to fix or workaround.
Something I could easily modify is good. But if it's not possible, even if the fix is in the library itself, I will try it too.
But please help me with some clues.

Thank you in advance

[Lapo]

Hi,
you're describing two different issues.

The first, where the server recognizes that the client has changed UDP port during the game session can be "silenced" by using the setting you have mentioned (allowClientUdpPortChanges). It can pose a security risk, but it's minor one. In simple terms an attacker from the same network could impersonate the player. Not very likely under most scenarios.

The second case however cannot be solved easily because the server notices that the client connected using IP1 and it's trying to communicate via UDP on IP2. This cannot be accepted, otherwise it would be very easy for another player to impersonate any other player since there are no controls over the origin of the session IP address.

So I believe that if my game is published, the error will happen somewhere else, with similar network. And I suppose the game will lose some users because of it.

I think this is a very unlikely case where a client can have two different source IPs for TCP and UDP. In fact in 15 years of activity in this field this is probably the first case I've encountered on this forums.

Cheers

[willan]

Firstly, thank you for your fast response.

you're describing two different issues.

Secondly, yes they are 2 different issues, and the first one was easily solved thanks to the UDP config as you showed in another post. So thank you.

I think this is a very unlikely case where a client can have two different source IPs for TCP and UDP. In fact in 15 years of activity in this field this is probably the first case I've encountered on this forums.

Lastly, yes, at first I thought so. I developed this game for almost a year, and never spot such issue. Who have their network from multiple ISPs, right?
Until I played my game from that coffee shop. To be honest I think it's a rare case to 2 different IPs (2 IPs of 2 ISPs, just to clarity). But it happened once, it probably will happen again else where. And the more users, the more likely it will happen, right?
So I thought better I would fix it. If there is no direct fix, maybe I will try to use TCP instead UDP, and find another way for the performance impact of this change

Again. Thank you.

[Lapo]

Hi,
yes, switching to TCP instead of UDP could be a solution in those rare instances. Performance may not be optimal but the game should be playable anyways.

Cheers