Re: [PATCH v5 5/6] net: maclorawan: Implement maclorawan class module

Am 20.12.18 um 11:19 schrieb Ben Whitten:

quoted

quoted

quoted

The hard-MAC implementations will be on my plate mostly, as both SX1276
and SX1301 need the soft-MAC.

On the SX1301 side of things, the ability to send messages as a LoRaWAN
node device is a niche use case, the majority if not all people will use the
concentrator card as the pass through gateway to the node.

In this mode of operation the parameters for transmission such as;

frequency,

quoted

spreading factor / data rate, power, are given by a remote server and passed
in from the userspace application which received it.
Eventually in the kernel these need to be checked locally to ensure

regulatory

quoted

compliance.
To that end I have experimented with framing, as CAN does, so that this
metadata can be provided on a write from userspace to the SX1301 driver.

Sounds like we need different protocols for framing within the protocol

family.

quoted

Raw in the case of nodes and framed with metadata in the case of

concentrator

quoted

cards, thoughts?

Yes, I have thought the roles of node and gateway.  They may have
different skb passing paths.
As you mentioned, many things of the gateway is controlled by the
remote server.  So, I only implement the path for nodes right now.
Maybe, we can have a role flag: node, gateway which can be assigned by
some way.  Then, the skb can be decode, checked and passed according
to the role flag.  And module also checks the integrity (MIC, length
...) and filter out the bad skb before sends to next stop.

As IP have IPPROTO_TCP, IPPROTO_UDP, etc maybe we can have
LORA_PROTO_MODULE, LORA_PROTO_GATEWAY which dictates the
pathway and skb format.

No, please don't. You were on track with your earlier comment: The user
decides what he wants to do by selecting PF_LORAWAN with
SOCK_DGRAM/_SEQPACKET vs. SOCK_RAW (or PF_PACKET with ETH_P_LORA[WAN]).

The terminology "gateway" has little to do with it. I've heard of packet
forwarders using JSON format for communication with their backend, so it
appears to highly depend on what exactly the gateway wants to do and how
the user wants to access the needed data.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel