It's on Android. I have a chat tool that sends/receives packets. On the client side I parse the packets and display the message to users. A traditional chatting tool.
The problem is the tool works quite well on other devices on wifi, Edge and 3G, except the HTC One. On HSDPA (3G) we notice that the client cannot receive the packets as usual. It's stuck there until we reset the socket.
I debug and found that the DataInputStream.read() method (in the while loop to listen to the incoming data) is stuck there. I attached Android source to go deeper but not until the java.libcore package of Oracle.
I guess the issue is because of the Sleep mode of the HTC One. But on foreground, the app cannot receive the message too, until we open a new socket (with a long timeout, about 4 minutes, which is too long for a chatting tool).
As I researched, I try to install the SmartSync Disabler for HTC and the situation seems to be better. When I decompile the tool, it only sets 2 parameters: sleep_mode_mode to off and data_on_wifi to off, which means on the sleep mode, SmartSync does not disconnect wifi.
My question is has anyone encountered this situation before on HTC One in particular? What could be the reason?
Many thanks!
We have just got the same problem.
Try to play with this methods
void setReceiveBufferSize(int size)
void setSendBufferSize(int size)
I.e. make it much smaller.
Related
I am trying to reverse engineer the API of an IoT device using mitmproxy. My setup is an iphone, computer running on MacOS 10.14, and an IoT device (watering pump) that can only access the wireless network after being plugged into the computer via USB connection, i.e. a not genuinely WiFi device. My phone is configured to point to the computer, which is running mitmproxy on a standard configuration.
When I send instructions from the app controlling the device on my phone to the device itself, presumably these instructions are sent to the computer, to the device cloud server, and then to the device. With these assumptions, one would think that they would see the flow of POST requests in mitmproxy before observing the results of those instructions. That is, if you send an instruction to turn on the pump, you'd think you'd see POST request containing that instruction show up in the mitmproxy flows before you see the pump turn on.
However that is not the case here. What happens is that, when I send instructions from the app, I observe the expected behavior from the IoT device, and then the flow of requests appear on the mitmproxy console seemingly at random. There seems to be no determinate relationship between the instructions I send and the requests that appear; they show up 5 seconds later, 5 minutes later, or 30 minutes later. Is this an intentional security feature? To somehow jam MITMproxies so that hackers cannot easily isolate the knowledge of which packet is performing which instruction? Or is it just something that I am doing wrong? Does anyone have any ideas as to what could be happening hear and potential solutions for making the flow of requests appear in real time? Ty
I have loaded mod_portaudio in freeswich. But after that when pa rescan the device, i found no device in the device list. While the pi is connected to a bluetooth speaker and also a headset with a aux cable and those are working fine in the system.
Can anyone please help me to sort out this issue.
Thanks
I am also working on this and shortly believed to have solved it (see https://lists.freeswitch.org/pipermail/freeswitch-users/2020-August/133883.html and https://lists.freeswitch.org/pipermail/freeswitch-users/2020-August/133884.html), but it wasn't true:
I was testing with my headset and had successful "pa looptest" indicating both indev & outdev were working
Then, when I tested that in the context of my application for auto-answering incoming calls (I called with my mobile phone while putting it in front of a tv so that I can test if I would hear anything on my headset), I didn't notice that in that case the mic was not working because I had the headset on my ears and was hearing the tv (because of success of looptest, I was just assuming that the mic would also be working)
But when I finally got a Plantronics Calisto 620-M Bluetooth Speakerphone, even the looptest failed. At this moment, I tested more carefully my headset again, and there I found out that the mic was not working.
Because it seemed that something device-specific should be the reason for failure, I also tested with my bluetooth earphones; there the effect was equivalent to Calisto speakerphone.
I finally got a USB speakerphone and tried that one, but in that case "pa rescan" failed to find any devices.
With all four devices, always arecord and aplay were working perfectly, and the above issues appeared only with mod_portaudio.
I don't have any idea what the issue could be with the usb, but with the three bluetooth devices, I still believe that something device-specific should be causing the problems here, e.g. the sample rate. But, currently I am lacking time to further work on this...
Despite working earlier, my socket chat app now refuses to write to socket on the iPhone!
It works fine on the simulator and again, used to run fine on my phone. I don't really know where to start troubleshooting this issue --- just seems weird. My server doesn't detect anything trying to connect.
Any ideas on how to start troubleshooting this?
Thanks tons.
I did run into a problem where using sockets on the iPhone would not open up the cell phone network unless something else opened it first. I had to run an http call to a generic web site first, and then the sockets would communicate normally. Try putting a call, like sendSynchronousRequest, to a generic web site, like www.apple.com, before opening your socket, and see if it works in that case.
I need to stop wasting all you nice peoples' time.
Long story, my friend updated to iOS 5.1. Now the 3G network reads 4G on iOS 5.1. So I turned off my (5.0) wifi to see if mine cell network was "4G" (which, of course, it wasn't).
But yeah, having turned off wifi my app could no longer join my locally hosted server...
I grabbed Charles though, and it looks handy, so thanks for that anyways. Also Owen's comment about the cell network originally made me think about checking my wifi, as my app shouldn't even be using the cell network yet. But I'll keep in mind what you said for the future.
Thanks everybody!
I have a Game Center matchmaker working and implemented, and by using Game Kit's Bluetooth functionality I know that my multiplayer code works. When playing over the internet through the Game Center sandbox, it works when both devices are on WiFi, but if one is on 3G it quickly stops sending and receiving data, and so the game grinds to a halt. Does anyone have an idea why on earth this is happening?
EDIT:
After further debugging, the problem is that data is just not received on the 3G device after a certain point. Any ideas?
EDIT2:
I have created a simple test program that fails around 6,000 for me. http://dl.dropbox.com/u/2042276/Game%20Center%203G%20Test.zip (change the bundle ID)
Silly idea probably, but have you tried rebooting your iDevice and resetting your network settings.
I found the cause of the problem - although my packets were incredibly small, I was sending lots of them. I fixed it by lumping packets together and sending them as one big packet.
What steps will reproduce the problem?
Startup application with PJSIP at iPhone 3G with iOS 4.
Make outgoing call. Start conversation.
Wait 20 seconds.
What is the expected output? What do you see instead?
Actual result: Outgoing call cut off at 20 sec. The call breaks on the phone on which I have called. And the call ends normally according to the log-file.
What version of the product are you using? On what operating system?
I use iPhone 3g with iOS 4, iPhone 2g with iOS 3, iPhone 3gs with iOS 4, iPhone 4 with iOS 4
I tried to use PJSIP 1.0.3, PJSIP 1.6, PJSIP 1.7
I have tried another sip clients at this Wi-Fi network:
Fring - the problem reproduce
Nimbuzz - the problem NOT reproduce
Please help me to solve this problem.
Sounds like you need a keepalive mechanism on the SIP connection. PJSIP supports this. Maybe you will have to enable it.
Use a packet sniffer to see what is actually going on.
You'll probably have more luck at SuperUser. Having said that, if one SIP client doesn't have this problem, while the other does, your first step should be to look at what's different between working and non-working clients.
When you say the call cuts off do you mean that media just stops flowing? Does something send you a BYE? (If the media stops flowing, and you terminate your end of the call, does the BYE go out and do you get a 200 OK back?)
Is it possible to use something like Wireshark on the far side of your wireless access point? In other words, can you see media traffic on the first hop past the Wifi network? When the call's cut off, what do you see?