Reception of UDP packets in sleep mode
4,940 views
Skip to first unread message
jcucurull
Jun 20, 2011, 3:40:00 AM6/20/11
to android-platform
Hi all,
I am implementing an Android service which listens to the network for
the reception of UDP packets. When the phone is active, i.e. the
screen is switched on, the reception is correct. But, when the phone
enters in sleep mode no more packets are received until it wakes up.
The service I am implementing uses an independent thread that calls
the "receive(...)" method of a DatagramSocket in a loop:
public void run() {
while(Thread.currentThread() == runner){
try {
do {
pktIn.setLength(BUFF_SIZE);
socket.receive(pktIn);
} while(pktIn.getAddress().equals(localIp)); // packet if
comes from the node's own IP
...
} catch (InterruptedIOException ioe) {
// Captures the timeout exception produced to unblock the
receive.
Log.d(MSG_TAG, "receivingThread - Socket timeout " +
ioe.getMessage());
} catch (IOException ioe) {
}
}
}
When the phone enters the sleep mode this thread is not stopped (one
can regularly see the message issued by the InterruptedIOException).
It is the "receive()" method that does not receive anything.
A workaround to solve the problem has been to use the PowerManager
classes to create a lock to force the system to stay awake.
Nevertheless I have to force the system to the state
PowerManager.SCREEN_DIM_WAKE_LOCK at least, i.e. the screen must be
switched on. It does not work with the state
PowerManager.PARTIAL_WAKE_LOCK.
Does somebody knows why the network sockets are temporally disabled?
(the network in fact is active, because when the system wakes up it
receives all the messages that were not received before). Is there
some way to keep them enabled?
Thank you in advance!
Jordi.
I am implementing an Android service which listens to the network for
the reception of UDP packets. When the phone is active, i.e. the
screen is switched on, the reception is correct. But, when the phone
enters in sleep mode no more packets are received until it wakes up.
The service I am implementing uses an independent thread that calls
the "receive(...)" method of a DatagramSocket in a loop:
public void run() {
while(Thread.currentThread() == runner){
try {
do {
pktIn.setLength(BUFF_SIZE);
socket.receive(pktIn);
} while(pktIn.getAddress().equals(localIp)); // packet if
comes from the node's own IP
...
} catch (InterruptedIOException ioe) {
// Captures the timeout exception produced to unblock the
receive.
Log.d(MSG_TAG, "receivingThread - Socket timeout " +
ioe.getMessage());
} catch (IOException ioe) {
}
}
}
When the phone enters the sleep mode this thread is not stopped (one
can regularly see the message issued by the InterruptedIOException).
It is the "receive()" method that does not receive anything.
A workaround to solve the problem has been to use the PowerManager
classes to create a lock to force the system to stay awake.
Nevertheless I have to force the system to the state
PowerManager.SCREEN_DIM_WAKE_LOCK at least, i.e. the screen must be
switched on. It does not work with the state
PowerManager.PARTIAL_WAKE_LOCK.
Does somebody knows why the network sockets are temporally disabled?
(the network in fact is active, because when the system wakes up it
receives all the messages that were not received before). Is there
some way to keep them enabled?
Thank you in advance!
Jordi.
Paul Gardner-Stephen
Jun 21, 2011, 7:29:20 AM6/21/11
to android-platform
Hello,
Let me guess, the UDP packets are broadcast packets?
On Android phones with the broadcom chipsets the driver contains code
for a packet filter that filters out broadcast packets when the phone
goes to sleep, or more accurately, when the screen goes off.
This caused us much pain with the Serval BatPhone software, as the
mesh would stop working when the screen stopped.
There are two solutions:
1. Root the phone and control the wifi directly, loading the driver
with the option to disable all packet filters, which is what we do,
but probably an overkill for your needs. You can find our code at
http://github.com/servalproject if you need it.
2. Acquire a PARTIAL_WAKE_LOCK, and trap when the screen goes off.
Then disable and reenable the wifi. This works because the filter
only turns on when the screen goes off, so starting wifi with the
screen off will keep it working until the screen goes off again. This
is what we did before we figured out solution (1).
Paul.
Let me guess, the UDP packets are broadcast packets?
On Android phones with the broadcom chipsets the driver contains code
for a packet filter that filters out broadcast packets when the phone
goes to sleep, or more accurately, when the screen goes off.
This caused us much pain with the Serval BatPhone software, as the
mesh would stop working when the screen stopped.
There are two solutions:
1. Root the phone and control the wifi directly, loading the driver
with the option to disable all packet filters, which is what we do,
but probably an overkill for your needs. You can find our code at
http://github.com/servalproject if you need it.
2. Acquire a PARTIAL_WAKE_LOCK, and trap when the screen goes off.
Then disable and reenable the wifi. This works because the filter
only turns on when the screen goes off, so starting wifi with the
screen off will keep it working until the screen goes off again. This
is what we did before we figured out solution (1).
Paul.
Dianne Hackborn
Jun 21, 2011, 1:16:47 PM6/21/11
to android-...@googlegroups.com
On Tue, Jun 21, 2011 at 4:29 AM, Paul Gardner-Stephen <paul.gardn...@gmail.com> wrote:
2. Acquire a PARTIAL_WAKE_LOCK, and trap when the screen goes off.
Then disable and reenable the wifi. This works because the filter
only turns on when the screen goes off, so starting wifi with the
screen off will keep it working until the screen goes off again. This
is what we did before we figured out solution (1).
This sounds incredibly fragile. I really would not recommend it.
Dianne Hackborn
Android framework engineer
hac...@android.com
Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them.
jcucurull
Jun 22, 2011, 9:21:23 AM6/22/11
to android-platform
> Let me guess, the UDP packets are broadcast packets?
I will try to use your first option, since I am already using a root
phone to enable the ad-hoc mode.
Thank you for your answer!
Jordi.
Paul Gardner-Stephen
Jun 22, 2011, 6:21:54 PM6/22/11
to android-platform
Hello Dianne,
On Jun 22, 2:16 am, Dianne Hackborn <hack...@android.com> wrote:
> On Tue, Jun 21, 2011 at 4:29 AM, Paul Gardner-Stephen <
>
But until the Android APIs solve amazingly simple use-cases like this,
we have to resort to such ugly hacks.
Some documentation would also help. In the case of this WiFi fiddle
to receive broadcast UDP packets while sleeping, there was zero
documentation that we could find that indicated whether it was a bug
or a feature. Then we discover this crazy workaround that proves
there is a bug somewhere, since we can get the behaviour we want by
flapping the interface with the screen off.
You probably don't want to know how we discovered how to the filter
works, gets activated and how to completely disable the filtering of
broadcast packets, but our lead developer should probably get a magic
sword or pair of seven league boots or similar for the successful
return from his epic quest.
The same goes for getting the wifi into ad hoc mode. We really
SHOULDNT have to root the phone, figure out which driver to load,
which arcane options to load it with, and which of a zillion versions
of wifi management tools apply to this combination.
However, the situation is that, today, and for the foreseeable future,
we don't have a choice.
The Serval Project is about creating tactical software that lets
people use their phones to communicate when they would otherwise be
useless lumps of tantalum and plastic, such as post-earthquakes etc.
As such, we can't wait for these features to get proper APIs, let
alone for all the phones to get Android Peachmelba (which is very
delicous, I might add) or whatever release does finally get these
APIs, as it is not in phone vendors to offer updates on anything but
the most expensive phones, because as Microsoft realised many years
ago, ones prior products are ones greatest competitors. Indeed,
nearly half of deployed Android devices run 1.6 or older. If we are
going to save as many lives as possible, we need to target this
advanced software for Android 1.6, and if possible, 1.5.
We and others have poked and proded about ad hoc support for almost
three years now, and it still doesn't seem to be on the road map,
despite in some cases, the submission of patches which if they were
examined in a timely manner would have integrated with the source
tree, but when they were eventually looked, the patches were so old
that they no longer built cleanly with the head of the source.
I understand that there are limitations of resources, and I am not out
to ascribe blame, but PLEASE make proper ad hoc support a priority.
iPhone can do it (more or less). Windows Mobile 5/6 can do it. Even
Symbian S40 can do it! But Android requires the most ugly hacks,
rooting and voiding of warranty to do it.
The irony of course is that in some ways Androids robust security
model actually reduces security by requiring us to bypass it for the
most ridiculous things, like putting the WiFi into adhoc mode.
Perhaps some thought is warranted into allowing Google-signing of
scripts that are allowed to run with elevated privilege, as that at
least limits the resulting attack surface, instead of having an su
facility that any application can then access?
Meanwhile, we will continue to use shamefully fragile hacks like those
I have described, because we have no option.
I wouldn't recommend someone to drink dirty water, but if there is no
clean water to drink, what do you do?
We either sail in a boat made of glass, or we sink beneath the roiling
waves.
We have chosen the boat of glass, because at least that way there is
hope.
(Also, the view is kind of cool ;)
If Google would like to talk to us about how to get us out of the
glass boat and into something less fragile, we would love to talk.
As it happens, I will be state-side near Mountain View next week if
you would like to take the opportunity.
Paul.
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com
On Jun 22, 2:16 am, Dianne Hackborn <hack...@android.com> wrote:
> On Tue, Jun 21, 2011 at 4:29 AM, Paul Gardner-Stephen <
>
> paul.gardner.step...@gmail.com> wrote:
> > 2. Acquire a PARTIAL_WAKE_LOCK, and trap when the screen goes off.
> > Then disable and reenable the wifi. This works because the filter
> > only turns on when the screen goes off, so starting wifi with the
> > screen off will keep it working until the screen goes off again. This
> > is what we did before we figured out solution (1).
>
> This sounds incredibly fragile. I really would not recommend it.
You know, I agree 100%.
> > 2. Acquire a PARTIAL_WAKE_LOCK, and trap when the screen goes off.
> > Then disable and reenable the wifi. This works because the filter
> > only turns on when the screen goes off, so starting wifi with the
> > screen off will keep it working until the screen goes off again. This
> > is what we did before we figured out solution (1).
>
> This sounds incredibly fragile. I really would not recommend it.
But until the Android APIs solve amazingly simple use-cases like this,
we have to resort to such ugly hacks.
Some documentation would also help. In the case of this WiFi fiddle
to receive broadcast UDP packets while sleeping, there was zero
documentation that we could find that indicated whether it was a bug
or a feature. Then we discover this crazy workaround that proves
there is a bug somewhere, since we can get the behaviour we want by
flapping the interface with the screen off.
You probably don't want to know how we discovered how to the filter
works, gets activated and how to completely disable the filtering of
broadcast packets, but our lead developer should probably get a magic
sword or pair of seven league boots or similar for the successful
return from his epic quest.
The same goes for getting the wifi into ad hoc mode. We really
SHOULDNT have to root the phone, figure out which driver to load,
which arcane options to load it with, and which of a zillion versions
of wifi management tools apply to this combination.
However, the situation is that, today, and for the foreseeable future,
we don't have a choice.
The Serval Project is about creating tactical software that lets
people use their phones to communicate when they would otherwise be
useless lumps of tantalum and plastic, such as post-earthquakes etc.
As such, we can't wait for these features to get proper APIs, let
alone for all the phones to get Android Peachmelba (which is very
delicous, I might add) or whatever release does finally get these
APIs, as it is not in phone vendors to offer updates on anything but
the most expensive phones, because as Microsoft realised many years
ago, ones prior products are ones greatest competitors. Indeed,
nearly half of deployed Android devices run 1.6 or older. If we are
going to save as many lives as possible, we need to target this
advanced software for Android 1.6, and if possible, 1.5.
We and others have poked and proded about ad hoc support for almost
three years now, and it still doesn't seem to be on the road map,
despite in some cases, the submission of patches which if they were
examined in a timely manner would have integrated with the source
tree, but when they were eventually looked, the patches were so old
that they no longer built cleanly with the head of the source.
I understand that there are limitations of resources, and I am not out
to ascribe blame, but PLEASE make proper ad hoc support a priority.
iPhone can do it (more or less). Windows Mobile 5/6 can do it. Even
Symbian S40 can do it! But Android requires the most ugly hacks,
rooting and voiding of warranty to do it.
The irony of course is that in some ways Androids robust security
model actually reduces security by requiring us to bypass it for the
most ridiculous things, like putting the WiFi into adhoc mode.
Perhaps some thought is warranted into allowing Google-signing of
scripts that are allowed to run with elevated privilege, as that at
least limits the resulting attack surface, instead of having an su
facility that any application can then access?
Meanwhile, we will continue to use shamefully fragile hacks like those
I have described, because we have no option.
I wouldn't recommend someone to drink dirty water, but if there is no
clean water to drink, what do you do?
We either sail in a boat made of glass, or we sink beneath the roiling
waves.
We have chosen the boat of glass, because at least that way there is
hope.
(Also, the view is kind of cool ;)
If Google would like to talk to us about how to get us out of the
glass boat and into something less fragile, we would love to talk.
As it happens, I will be state-side near Mountain View next week if
you would like to take the opportunity.
Paul.
> --
> Dianne Hackborn
> Android framework engineer
Paul Gardner-Stephen
Jun 22, 2011, 6:23:40 PM6/22/11
to android-platform
Hello,
On Jun 22, 10:21 pm, jcucurull <jcucur...@gmail.com> wrote:
> > Let me guess, theUDPpackets are broadcast packets?
Or better yet, hop over to serval-project-developers Google group and
lets talk about how to use common code for doing it all, since you
have exactly the same requirements as we have already solved, and
there is no point having two sets of code that do the same thing.
Paul.
On Jun 22, 10:21 pm, jcucurull <jcucur...@gmail.com> wrote:
> > Let me guess, theUDPpackets are broadcast packets?
>
> Yes. :-D
>
> I will try to use your first option, since I am already using a root
> phone to enable the ad-hoc mode.
>
> Thank you for your answer!
You're welcome. Feel free to grab our code to get ad hoc mode.
> Yes. :-D
>
> I will try to use your first option, since I am already using a root
> phone to enable the ad-hoc mode.
>
> Thank you for your answer!
Or better yet, hop over to serval-project-developers Google group and
lets talk about how to use common code for doing it all, since you
have exactly the same requirements as we have already solved, and
there is no point having two sets of code that do the same thing.
Paul.
Jordi Cucurull
Jun 29, 2011, 5:35:12 AM6/29/11
to android-platform
As far as I have seen in a post in your serval-project-developers
Google group, the second solution only works with the Broadcom
chipset, right? I am using a LG P990 and I guess it uses another
chipset, since the module is not the "dhd" used for example in the
Samsung Galaxy S1 phones.
For enabling the ad-hoc mode, by now, I am using the thether-wifi
scripts modified by myself (but I do not discard to integrate your
variant of them in the future).
Thanks!
Jordi.
On Jun 23, 12:23 am, Paul Gardner-Stephen
Google group, the second solution only works with the Broadcom
chipset, right? I am using a LG P990 and I guess it uses another
chipset, since the module is not the "dhd" used for example in the
Samsung Galaxy S1 phones.
For enabling the ad-hoc mode, by now, I am using the thether-wifi
scripts modified by myself (but I do not discard to integrate your
variant of them in the future).
Thanks!
Jordi.
On Jun 23, 12:23 am, Paul Gardner-Stephen
Paul Gardner-Stephen
Jun 29, 2011, 9:41:37 AM6/29/11
to android-platform
Hi Jordi,
We support a number of chipsets, and are actively working to support
others.
Poke us an email over on serval-project-developers asking us to
support your phone, and we will start working to solve your problem.
Paul.
We support a number of chipsets, and are actively working to support
others.
Poke us an email over on serval-project-developers asking us to
support your phone, and we will start working to solve your problem.
Paul.
Jordi Cucurull
Jun 29, 2011, 10:04:27 AM6/29/11
to android-platform
Hi Paul,
I have managed to solve it. Despite the kernel module of the LG P990
is not the "dhd", it seems that the chipset is still a Broadcom.
Hence, the kernel module, called "wireless" for this phone, it also
accepts the parameter "dhd_pkt_filter_enable=0" that disables the
filter of broadcast packets.
Thanks!
Jordi.
On Jun 29, 3:41 pm, Paul Gardner-Stephen
I have managed to solve it. Despite the kernel module of the LG P990
is not the "dhd", it seems that the chipset is still a Broadcom.
Hence, the kernel module, called "wireless" for this phone, it also
accepts the parameter "dhd_pkt_filter_enable=0" that disables the
filter of broadcast packets.
Thanks!
Jordi.
On Jun 29, 3:41 pm, Paul Gardner-Stephen
Dianne Hackborn
Jun 29, 2011, 7:55:27 PM6/29/11
to android-...@googlegroups.com
Ultimately a lot of what you are wanting to do is not supported by the platform, for various reasons, and these kinds of hacks are relying on implementation details that make it very likely your code is going to break.
--
Dianne Hackborn
Android framework engineer
Yes Android does not do everything. These are probably some of the things. Sometimes that's just how things are.
--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.
--
Dianne Hackborn
Android framework engineer
Paul Gardner-Stephen
Jun 30, 2011, 11:24:43 AM6/30/11
to android-platform
Hi Dianne,
On Jun 29, 4:55 pm, Dianne Hackborn <hack...@android.com> wrote:
> Ultimately a lot of what you are wanting to do is not supported by the
> platform, for various reasons, and these kinds of hacks are relying on
> implementation details that make it very likely your code is going to break.
True, but that just makes the probability of success <1 instead of 0.
> Yes Android does not do everything. These are probably some of the things.
> Sometimes that's just how things are.
True, but this is one that has the potential to, literally, be the
difference between life and death for people in a disaster zone.
The thing is we have just about spent longer arguing back and forth
than it would actually take to write the three lines of code to enable
Android to talk to ad hoc wifi support. They guys at CyanogenMod
figured out how to do it in a simple clean way ages ago.
Anyway, I'll be at the Googleplex today, and would love to have a chat
about it over lunch if you are there today.
Paul.
On Jun 29, 4:55 pm, Dianne Hackborn <hack...@android.com> wrote:
> Ultimately a lot of what you are wanting to do is not supported by the
> platform, for various reasons, and these kinds of hacks are relying on
> implementation details that make it very likely your code is going to break.
> Yes Android does not do everything. These are probably some of the things.
> Sometimes that's just how things are.
difference between life and death for people in a disaster zone.
The thing is we have just about spent longer arguing back and forth
than it would actually take to write the three lines of code to enable
Android to talk to ad hoc wifi support. They guys at CyanogenMod
figured out how to do it in a simple clean way ages ago.
Anyway, I'll be at the Googleplex today, and would love to have a chat
about it over lunch if you are there today.
Paul.
Juliusz Chroboczek
Jul 12, 2011, 8:07:59 PM7/12/11
to android-...@googlegroups.com
> On Android phones with the broadcom chipsets the driver contains code
> for a packet filter that filters out broadcast packets when the phone
> goes to sleep, or more accurately, when the screen goes off.
> for a packet filter that filters out broadcast packets when the phone
> goes to sleep, or more accurately, when the screen goes off.
Do you know if the same is true of (link-local) multicast?
-- Juliusz
Sumit Chaturvedi
Apr 4, 2016, 7:29:46 PM4/4/16
to android-platform
Hi All,
So we are also having trouble sending UDP packets over wifi when phone is locked/sleep . We even tried to use out the solution (2) on two phone Micromax A315 (OS: Android 4.4.2 Chipset :Mediatek MT6592 ) and BQ S37 ( OS : Android 4.4, Chipset :MediaTek MT6572A). Now on micromax the solution works perfectly but on BQ phone there is significant drops in packets, though we receive some packets but not all of them. Here is what we are using for the locks as suggest in solution (2). Please let us know if we are doing anything wrong or if there is another way.
public class ScreenStateReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
if (intent.getAction().equals(Intent.ACTION_SCREEN_OFF)) {
Log.i("Check", "Screen went OFF");
PowerManager powerManager = (PowerManager) context.getSystemService(Context.POWER_SERVICE);
PowerManager.WakeLock wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK,
"MyWakelockTag");
wakeLock.acquire();
final WifiManager wifiManager = (WifiManager) context.getSystemService(Context.WIFI_SERVICE);
new Thread(
new Runnable() {
public void run() {
try {
if (wifiManager.isWifiEnabled()) {
wifiManager.setWifiEnabled(false);
Log.i("Check Wifi: ", "Disabled");
}
Thread.sleep(1000);
if (!wifiManager.isWifiEnabled()) {
wifiManager.setWifiEnabled(true);
WifiManager.MulticastLock multicastLock = wifiManager.createMulticastLock("lockWifiMulticast");
multicastLock.acquire();
WifiManager.WifiLock wifiLock = wifiManager.createWifiLock(WifiManager.WIFI_MODE_FULL_HIGH_PERF,"MyWifiLock");
wifiLock.acquire();
Log.i("Check Wifi: ", "Enabled");
}
}
catch(InterruptedException e) {
}
}
}).start();
} else if (intent.getAction().equals(Intent.ACTION_SCREEN_ON)) {
Log.i("Check","Screen went ON");
}
}
}
Karl Rowley
Jan 4, 2017, 8:48:55 PM1/4/17
to android-platform
when the screen turns off. It did not work for me.
What did work was closing sockets used for UDP and then re-opening them. I do this when
the screen turns off.
I'd be curious to know if this works for you.
Good luck,
Karl Rowley
sri krish
Oct 10, 2019, 1:21:38 PM10/10/19
to android-platform
.
Hi Hackborn,
Can u suggest me please what is the exact reason that udp packets are not received in android 7.0 while screen is off.
Reply all
Reply to author
Forward
0 new messages