LoRaWAN downlinks only work in port 1 and 2

[jmarcelino]

Board: LoPy running firmware 1.7.8.b1

Problem:
The LoRaWAN stack on the LoPy only accepts downlinks sent to port 1 and 2. Downlinks sent to other valid ports (3 - 223) don't trigger an RX_PACKET_EVENT and return empty on socket.recv()

This behaviour is confirmed by the source code - there are only case statements for port 1, 2 and 224 (the latter being the LoRaWAN certification port)

Expected result:
Since there isn't currently a way to filter downlinks by port number - socket.bind() on LoRa only changes the uplink ports - I think the LoPy should accept downlinks to all valid application ports 1 to 223 as per the LoRaWAN specification. Silently dropping them is not a good option.

Proposed solution:
I'd be happy to submit a pull request to fix this by simply allowing any valid port, but perhaps a more complex solution including downlink port filtering should be implemented. Such a mechanism has been requested in the forums, but I'm not sure what is the best place to do it.

Acknowledgments:
Thanks to bmarkus for raising the issue of missing downlinks.

[ha5di]

No need for filtering on this level, it is up to the application to manage. Just transfer port 1...223 downlink messages to user as it is now for port 1...2

(bmarkus)

[dbrgn]

Thanks @jmarcelino for the find, this cost me at least one full day of debugging.

No need for filtering on this level, it is up to the application to manage.

According to my tests, when sending a downlink to port 2 it can also be received by a socket bound to port 1. Is this correct?

If yes, and if you say "it is up to the application to manage filtering", how can I find out what FPort the downlink was sent to?

[danicampora]

If yes, and if you say "it is up to the application to manage filtering", how can I find out what FPort the downlink was sent to?

This is being implemented now. We'll add the recvfrom method which will return a tuple: (port, data)

[danicampora]

Fixed. Thanks!