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 <ncoth...@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@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@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@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. >
_______________________________________________ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
