<div dir="ltr"><div>Uki, got some feedback from IRC (SOLVED - somewhat)<br><br>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.<br>
<br>"<span style="font-family:courier new,monospace">iwpriv wlan0 setMCBCFilter 1</span>"<br><br></div><div>In my case I've reached out to the LIFX developers to hear if the behaviour of their lightbulbs could possibly be changed.<br>
</div><div><br><br></div><div>Regards<br>Nc.<br></div><div><br></div><div>----Log from IRC (abbreviate) ----<br></div><div> <tigeli> # Flags to filter Mcast abd Bcast RX packets.<br> <tigeli> # Value 0: No filtering, 1: Filter all Multicast.<br>
<tigeli> # 2: Filter all Broadcast. 3: Filter all Mcast abd Bcast<br> <tigeli> McastBcastFilter=3<br> <tigeli> which explains lots of things ;)<br> <Stskeeps> okay, why would we do this..<br> <tigeli> Stskeeps: to save battery<br>
<tigeli> no other reasons<br> <Stskeeps> tigeli: aren't dhcp broadcast?<br> <tigeli> Stskeeps: yes, but you don't have to listen for those, only server needs to<br> <tigeli> Stskeeps: the reply will back straight to you<br>
<tigeli> Stskeeps: but ARP is brodcast, which is handled on the chip<br> <Stskeeps> hmm ok<br> <tigeli> Stskeeps: and if we set that to 0, it will consume a lot of power in busy wlan network<br> <Nc_> tigeli: so issue is that phone is filtering out bcast/mcast due to powersaving settings?<br>
<tigeli> Nc_: yes<br> <tigeli> Nc_: you could confirm this by changint that McastBcastFilter to 0 for a test<br> <tigeli> Nc_: mount -t ext4 -o remount,rw /dev/mmcblk0p25 /persist<br> <tigeli> Nc_: and then edit /persist/WCNSS_qcom_cfg.ini<br>
<tigeli> Nc_: and reboot<br> <Nc_> but from your description, sounds like this is not something that can be controlled at runtime :/<br> <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. :(<br>
<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.<br> <Stskeeps> iwpriv maybe?<br> <javispedro> these days MS is also filtering bcasts when on "connected standby", so it's pretty much the norm.<br>
<tigeli> Stskeeps: at least there is setMCBCFilter in iwpriv<br> <tigeli> Stskeeps: Nc_: iwpriv wlan0 setMCBCFilter 1 seems to be working also<br> <Nc_> weeeeeeee<br> <tigeli> works?<br> <Nc_> got a reply from the LIFX bulbs (setting 0)<br>
<Nc_> and I just turned on a lightbulb using the CLI on my phone :p<br> <Nc_> and yes, seems iwpriv turns it on/off depending on setting<br></div><div>---- end log ----<br></div><br><div><div><div class="gmail_extra">
<br><div class="gmail_quote">2014-05-13 13:44 GMT+02:00 Niels Christian Ørgaard <span dir="ltr"><<a href="mailto:ncothang@gmail.com" target="_blank">ncothang@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div><div><div><div><div><div><div><div><div>Hi,<br></div>(uh, first post to this mailing list - exciting!)<br><br></div>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.<br>
</div><div>The app is supposed to control LIFX lightbulbs via wifi.<br></div><div><br></div>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.<br><br>
</div>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.<br></div><div>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.<br>
</div><div>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.<br></div><div><br>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.<br>
</div><div>This was done by having a laptop on the same wifi as the phone and bulbs, and running tcpdump on both.<br><br><br></div><div>Dump from the Jolla phone:<br>----<br><span style="font-family:courier new,monospace">[root@Jolla nemo]# tcpdump -n "broadcast or multicast"<br>
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode<br>listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes<br>10:38:21.919881 IP 192.168.1.11.56700 > 255.255.255.255.56700: UDP, length 36<br>
10:38:21.920278 IP 192.168.1.11.56700 > 255.255.255.255.56700: UDP, length 36<br>10:38:21.920552 IP 192.168.1.11.56700 > 255.255.255.255.56700: UDP, length 36<br>10:38:21.920827 IP 192.168.1.11.56700 > 255.255.255.255.56700: UDP, length 36<br>
10:38:21.921102 IP 192.168.1.11.56700 > 255.255.255.255.56700: UDP, length 36<br>12:34:33.460396 ARP, Request who-has 192.168.1.11 tell 192.168.1.1, length 28<br>12:37:45.263353 IP 192.168.1.10.138 > 255.255.255.255.138: NBT UDP PACKET(138)<br>
12:37:47.310354 ARP, Request who-has 192.168.1.10 tell 192.168.1.1, length 28</span><br>----<br></div><div>(data broadcast from 192.168.1.11 = phone)<br></div><div><br></div><div>Dump from the laptop (concurrent to the above):<br>
----<br><span style="font-family:courier new,monospace">Nielss-MacBook-Pro:projects nc$ sudo tcpdump -n "broadcast or multicast"<br>tcpdump: data link type PKTAP<br>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode<br>
listening on pktap, link-type PKTAP (Packet Tap), capture size 65535 bytes<br>10:37:50.417809 ARP, Request who-has 192.168.1.10 tell 192.168.1.1, length 28<br>10:38:26.071691 IP 192.168.1.11.56700 > 255.255.255.255.56700: UDP, length 36<br>
10:38:26.073139 IP 192.168.1.11.56700 > 255.255.255.255.56700: UDP, length 36<br>10:38:26.074562 IP 192.168.1.11.56700 > 255.255.255.255.56700: UDP, length 36<br>10:38:26.075840 IP 192.168.1.11.56700 > 255.255.255.255.56700: UDP, length 36<br>
10:38:26.081271 IP 192.168.1.11.56700 > 255.255.255.255.56700: UDP, length 36<br>10:38:26.082544 IP 192.168.1.6.56700 > 192.168.1.255.56700: UDP, length 41<br>10:38:26.084234 IP 192.168.1.6.56700 > 192.168.1.255.56700: UDP, length 41<br>
10:38:26.085967 IP 192.168.1.6.56700 > 192.168.1.255.56700: UDP, length 41<br>10:38:26.087745 IP 192.168.1.6.56700 > 192.168.1.255.56700: UDP, length 41<br>10:38:26.089417 IP 192.168.1.6.56700 > 192.168.1.255.56700: UDP, length 41<br>
10:38:26.091339 IP 192.168.1.6.56700 > 192.168.1.255.56700: UDP, length 41<br>10:38:26.093355 IP 192.168.1.6.56700 > 192.168.1.255.56700: UDP, length 41<br>10:38:26.095297 IP 192.168.1.6.56700 > 192.168.1.255.56700: UDP, length 41<br>
10:38:26.097493 IP 192.168.1.6.56700 > 192.168.1.255.56700: UDP, length 41</span><br><span style="font-family:courier new,monospace">10:38:26.099300 IP 192.168.1.6.56700 > 192.168.1.255.56700: UDP, length 41</span><br>
</div><div>----<br></div><div>(data broadcast from 192.168.1.11 = phone, from 192.168.1.6 = lightbulbs)<br></div><div>We can see the 5 UDP packets from the phone in both dumps, but the reply-packets only in the dump from the laptop.<br>
Note: All devices are on the same wifi, connected to the same router.<br></div><div><br>I can provide more detailed dumps, if anyone wishes.<br></div><br><br>The relevant python-code, which is basically stalling in the udpsock.recvfrom(1024) call:<br>
-----<br><span style="font-family:courier new,monospace">IP = '0.0.0.0'<br>BCAST = '255.255.255.255'<br>PORT = 56700<br><br>connection = None<br>debug = False<br>site = b'\00\00\00\00\00\00'<br><br>
def connect():<br> global connection, site<br> udpsock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)<br> udpsock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)<br> udpsock.bind((IP, PORT))<br> p = packetcodec.Packet(packetcodec.GetPANGatewayPayload())<br>
for x in range(5):<br> udpsock.sendto(p.__bytes__(), (BCAST, PORT))<br> while True:<br> data, addr = udpsock.recvfrom(1024)<br> packet = packetcodec.decode_packet(data)<br> if packet is not None and \<br>
isinstance(packet.payload, packetcodec.PANGatewayPayload):<br> break<br> udpsock.close()<br> if debug:<br> print 'found light: %s' % (addr[0], )<br> tcpsock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)<br>
tcpsock.settimeout(2.0)<br> tcpsock.connect(addr)<br> connection = tcpsock<br> site = packet.site<br> if debug:<br> print 'connection established with %s' % (unicode(hexlify(site), encoding='utf-8'))</span><br>
----<br></div>(The python-code is a variant of <a href="https://github.com/sharph/lifx-python" target="_blank">https://github.com/sharph/lifx-python</a> and is an UNofficial Python lib for LIFX bulbs) <br><br><br></div><div>
Have looked at iptables, in case there were any rules defined there, but not seeing any:<br>
----<br><span style="font-family:courier new,monospace">[root@Jolla project]# iptables --list<br>Chain INPUT (policy ACCEPT)<br>target prot opt source destination <br><br>Chain FORWARD (policy ACCEPT)<br>
target prot opt source destination <br><br>Chain OUTPUT (policy ACCEPT)<br>target prot opt source destination <br>[root@Jolla project]# iptables --list-rules<br>-P INPUT ACCEPT<br>
-P FORWARD ACCEPT<br>-P OUTPUT ACCEPT</span><br>----<br></div><div><br><br></div>I hope someone can shed some light on what might be wrong, though my immediate thought is that it is OS-level ...<br><br><br></div>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.<br>
<br><br></div>Best Regards,<br>Niels Chr. Ørgaard<br>Belgium.<br></div>
</blockquote></div><br></div></div></div></div>