Android Question Samsung Galaxy S4 rejects UDP packets [solved]

[robotop]

Hi all. I have an application working with UDP packets. It's working on all the phones I tested, but recently, on Samsung Galaxy S4 with Android 4.4.2 , the incoming UDP packets are ignored (or rejected, I don't know). The same phone and application were working some time ago, so I suppose a new system update has introduced some security lock (I hate automatic updates). Note that the connection to the devices that is done via wifi on the same IP class (i.e. connecting devices behind the router 192.168.0.x) works fine, but if the connection is done via 3G, the output UDP packets are sent, while the answer coming from remote devices are lost. The whole system (routing ports etc) is well defined and the same application runs without problems (using the same SIM card) on Samsung Galaxy Nexus with Android 4.3 and also on very old A5000 with Android 2.2.1 and on NGM Dynamic Maxxi with Android 4.2.1 . Has someone experienced the same problem ? Is there some trick or tip to solve this big problem ? Any help will be highly appreciated, thanks.

 

[R0BERT0]

I just found the same problem with LG G2, android 4.3

 

[robotop]

Something strange happens, but must depend upon the mobile network. The same device (Samsung Galaxy S4) with the same application and SIM card, works perfectly when the phone is under covering of another cell. In my specific case (I'm in Italy) the applications doesn't receive UDP packets when the phone connects to a cell near Macerata (Marche), but works fine (receiving and sending all packets) if the phone connects to a cell near L'Aquila (Abruzzo). That means there is some TIM (my operator) server that blocks UDP traffic on some ports and some other that doesn't block them. This is a real chaotic behaviour and may take a "normal developer" to some form of insanity... Note that I checked the "well known ports" list for avoiding to use some that's reserved for other services. Anyone has suggestions on how to solve this problem ? My last chance will be to develop the application using TCP packets on port 80, but I think that, using this solution, I can add many security risks in my peripheral devices.

 

[lemonisdead]

My last chance will be to develop the application using TCP packets on port 80, but I think that, using this solution, I can add many security risks in my peripheral devices.

And this won't be a 100% working solution too. In fact, if you're in 3G/4G, you use the provider's proxy in most cases. The proxy blocks the p2p traffic. The only 100% working solution is to use a fixed server as a gateway in between and let your apps communicate using your gateway

 

[robotop]

Thank you for your answer, but I think that if my peripheral device acts as a webserver, and then gives back to my phone simply answers to "HTTP GET" requests, it will work even if passing.through proxies, as any other web page. Obviously, my device's application must act like a webserver , but just limited to handling some specific HTTP requests (I have a "self made" DynDns to know the device's IP at any time). I'm just starting to modify the application this way, hoping to have success. In other cases, I will purchase some land, chickens, seeds and start to be a farmer

 

[robotop]

Hello, problem solved. The user has changed the APN on his phone, activating WAP profile. In such way, all the communications are "bridged" to the real internet by the WAP access point. Changing back the APN to the "normal internet" solved the problem. All the packets are sent and received without any problem, regardless the cell that the phone connects to. Note that if you change the APN to the "normal internet" option (in my specific case, the internet APN is "ibox.tim.it", while the wap APN is "wap.tim.it") the phone will revert automatically to the WAP one, probabaly 'cause if you purchase a SIM card for "smartphone use" it defaults to WAP connections. Using WAP gives you more security in web navigation, but less power to send or receive packets not specific to web navigation. To overcome this fallback to WAP problem, simply create a new APN entry ; call it, for example, "MyApn" and put in it the "internet apn" data (as mentioned before, in my specific case, "ibox.tim.it"). With this new entry, the phone will NOT switch back to WAP APN and a program running with UDP packets will work again.