[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