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-python and
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
