<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">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>