[SailfishDevel] Not receiving broadcasted UDP replies (Jolla, Python)

Niels Christian Ørgaard ncothang at gmail.com
Tue May 13 12:34:11 UTC 2014


Uki, got some feedback from IRC (SOLVED - somewhat)

Changing McastBcastFilter to either 0 (allow all) or 1 (filter MCAST)
allows the phone to receive BCAST messages, but this is by default set to 3
(Filter MCAST+BCAST), and will drain power is left at a lower level.

"iwpriv wlan0 setMCBCFilter 1"

In my case I've reached out to the LIFX developers to hear if the behaviour
of their lightbulbs could possibly be changed.


Regards
Nc.

----Log from IRC (abbreviate) ----
 <tigeli> # Flags to filter Mcast abd Bcast RX packets.
 <tigeli> # Value 0: No filtering, 1: Filter all Multicast.
 <tigeli> # 2: Filter all Broadcast. 3: Filter all Mcast abd Bcast
 <tigeli> McastBcastFilter=3
 <tigeli> which explains lots of things ;)
 <Stskeeps> okay, why would we do this..
 <tigeli> Stskeeps: to save battery
 <tigeli> no other reasons
 <Stskeeps> tigeli: aren't dhcp broadcast?
 <tigeli> Stskeeps: yes, but you don't have to listen for those, only
server needs to
 <tigeli> Stskeeps: the reply will back straight to you
 <tigeli> Stskeeps: but ARP is brodcast, which is handled on the chip
 <Stskeeps> hmm ok
 <tigeli> Stskeeps: and if we set that to 0, it will consume a lot of power
in busy wlan network
 <Nc_> tigeli: so issue is that phone is filtering out bcast/mcast due to
powersaving settings?
 <tigeli> Nc_: yes
 <tigeli> Nc_: you could confirm this by changint that McastBcastFilter to
0 for a test
 <tigeli> Nc_: mount -t ext4 -o remount,rw /dev/mmcblk0p25 /persist
 <tigeli> Nc_: and then edit /persist/WCNSS_qcom_cfg.ini
 <tigeli> Nc_: and reboot
 <Nc_> but from your description, sounds like this is not something that
can be controlled at runtime :/
 <tigeli> Nc_: I understand why you want to use broadcasting but with
mobile devices which want to conserve power it might not be good idea. :(
 <tigeli> Nc_: yeah. :( At least I'm not aware of how.. unless there some
nice API on the driver itself which could enable to change that filter
during the runtime.
 <Stskeeps> iwpriv maybe?
 <javispedro> these days MS is also filtering bcasts when on "connected
standby", so it's pretty much the norm.
 <tigeli> Stskeeps: at least there is setMCBCFilter in iwpriv
 <tigeli> Stskeeps: Nc_: iwpriv wlan0 setMCBCFilter 1 seems to be working
also
 <Nc_> weeeeeeee
 <tigeli> works?
 <Nc_> got a reply from the LIFX bulbs (setting 0)
 <Nc_> and I just turned on a lightbulb using the CLI on my phone :p
 <Nc_> and yes, seems iwpriv turns it on/off depending on setting
---- end log ----


2014-05-13 13:44 GMT+02:00 Niels Christian Ørgaard <ncothang at gmail.com>:

> Hi,
> (uh, first post to this mailing list - exciting!)
>
> I am trying to write a small app for my Jolla phone (and hopefully for
> others' too, later), using QML, PyOtherSide and some 3rd-party python-based
> network code.
> The app is supposed to control LIFX lightbulbs via wifi.
>
> The network code works fine on Desktop (I tested it on OSX in an app, and
> from the Python CLI), and was ported to Python3.
>
> On the Jolla phone, and in the Sailfish emulator on my laptop, the network
> code never gets a reply from the lightbulbs, despite the lightbulbs sending
> one.
> If run from the CLI, merely hangs, waiting for data; if run as a QML app,
> the app continues, but the python code still stalls, and eventually a
> message comes up about an unresponsive process.
> In the emulator I've mostly concluded that the network settings use aren't
> conducive to this setup, and that I'll mostly have to work directly on the
> phone.
>
> Using tcpdump, I have determined that the broadcasts from the Python code
> is sent out and reaches the bulbs, and a reply is also transmitted from the
> bulbs, but never received on the phone.
> This was done by having a laptop on the same wifi as the phone and bulbs,
> and running tcpdump on both.
>
>
> Dump from the Jolla phone:
> ----
> [root at Jolla nemo]# tcpdump -n "broadcast or multicast"
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
> 10:38:21.919881 IP 192.168.1.11.56700 > 255.255.255.255.56700: UDP, length
> 36
> 10:38:21.920278 IP 192.168.1.11.56700 > 255.255.255.255.56700: UDP, length
> 36
> 10:38:21.920552 IP 192.168.1.11.56700 > 255.255.255.255.56700: UDP, length
> 36
> 10:38:21.920827 IP 192.168.1.11.56700 > 255.255.255.255.56700: UDP, length
> 36
> 10:38:21.921102 IP 192.168.1.11.56700 > 255.255.255.255.56700: UDP, length
> 36
> 12:34:33.460396 ARP, Request who-has 192.168.1.11 tell 192.168.1.1, length
> 28
> 12:37:45.263353 IP 192.168.1.10.138 > 255.255.255.255.138: NBT UDP
> PACKET(138)
> 12:37:47.310354 ARP, Request who-has 192.168.1.10 tell 192.168.1.1, length
> 28
> ----
> (data broadcast from 192.168.1.11 = phone)
>
> Dump from the laptop (concurrent to the above):
> ----
> Nielss-MacBook-Pro:projects nc$ sudo tcpdump -n "broadcast or multicast"
> tcpdump: data link type PKTAP
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on pktap, link-type PKTAP (Packet Tap), capture size 65535 bytes
> 10:37:50.417809 ARP, Request who-has 192.168.1.10 tell 192.168.1.1, length
> 28
> 10:38:26.071691 IP 192.168.1.11.56700 > 255.255.255.255.56700: UDP, length
> 36
> 10:38:26.073139 IP 192.168.1.11.56700 > 255.255.255.255.56700: UDP, length
> 36
> 10:38:26.074562 IP 192.168.1.11.56700 > 255.255.255.255.56700: UDP, length
> 36
> 10:38:26.075840 IP 192.168.1.11.56700 > 255.255.255.255.56700: UDP, length
> 36
> 10:38:26.081271 IP 192.168.1.11.56700 > 255.255.255.255.56700: UDP, length
> 36
> 10:38:26.082544 IP 192.168.1.6.56700 > 192.168.1.255.56700: UDP, length 41
> 10:38:26.084234 IP 192.168.1.6.56700 > 192.168.1.255.56700: UDP, length 41
> 10:38:26.085967 IP 192.168.1.6.56700 > 192.168.1.255.56700: UDP, length 41
> 10:38:26.087745 IP 192.168.1.6.56700 > 192.168.1.255.56700: UDP, length 41
> 10:38:26.089417 IP 192.168.1.6.56700 > 192.168.1.255.56700: UDP, length 41
> 10:38:26.091339 IP 192.168.1.6.56700 > 192.168.1.255.56700: UDP, length 41
> 10:38:26.093355 IP 192.168.1.6.56700 > 192.168.1.255.56700: UDP, length 41
> 10:38:26.095297 IP 192.168.1.6.56700 > 192.168.1.255.56700: UDP, length 41
> 10:38:26.097493 IP 192.168.1.6.56700 > 192.168.1.255.56700: UDP, length 41
> 10:38:26.099300 IP 192.168.1.6.56700 > 192.168.1.255.56700: UDP, length 41
> ----
> (data broadcast from 192.168.1.11 = phone, from 192.168.1.6 = lightbulbs)
> We can see the 5 UDP packets from the phone in both dumps, but the
> reply-packets only in the dump from the laptop.
> Note: All devices are on the same wifi, connected to the same router.
>
> I can provide more detailed dumps, if anyone wishes.
>
>
> The relevant python-code, which is basically stalling in the
> udpsock.recvfrom(1024) call:
> -----
> IP = '0.0.0.0'
> BCAST = '255.255.255.255'
> PORT = 56700
>
> connection = None
> debug = False
> site = b'\00\00\00\00\00\00'
>
> def connect():
>     global connection, site
>     udpsock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
>     udpsock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
>     udpsock.bind((IP, PORT))
>     p = packetcodec.Packet(packetcodec.GetPANGatewayPayload())
>     for x in range(5):
>         udpsock.sendto(p.__bytes__(), (BCAST, PORT))
>     while True:
>         data, addr = udpsock.recvfrom(1024)
>         packet = packetcodec.decode_packet(data)
>         if packet is not None and \
>                 isinstance(packet.payload, packetcodec.PANGatewayPayload):
>             break
>     udpsock.close()
>     if debug:
>         print 'found light: %s' % (addr[0], )
>     tcpsock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>     tcpsock.settimeout(2.0)
>     tcpsock.connect(addr)
>     connection = tcpsock
>     site = packet.site
>     if debug:
>         print 'connection established with %s' % (unicode(hexlify(site),
> encoding='utf-8'))
> ----
> (The python-code is a variant of https://github.com/sharph/lifx-pythonand is an UNofficial Python lib for LIFX bulbs)
>
>
> Have looked at iptables, in case there were any rules defined there, but
> not seeing any:
> ----
> [root at Jolla project]# iptables --list
> Chain INPUT (policy ACCEPT)
> target     prot opt source               destination
>
> Chain FORWARD (policy ACCEPT)
> target     prot opt source               destination
>
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination
> [root at Jolla project]# iptables --list-rules
> -P INPUT ACCEPT
> -P FORWARD ACCEPT
> -P OUTPUT ACCEPT
> ----
>
>
> I hope someone can shed some light on what might be wrong, though my
> immediate thought is that it is OS-level ...
>
>
> Note: I am having some Android apps (incl official LIFX app) on my jolla,
> which also has issues with networking in relation to broadcasting. Am
> suspecting these are related, though I do not have any further information.
>
>
> Best Regards,
> Niels Chr. Ørgaard
> Belgium.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.sailfishos.org/pipermail/devel/attachments/20140513/2709a965/attachment.html>


More information about the Devel mailing list