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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <cd61fd58-02c0-8d1e-e194-cec3f0dea65c@suse.de>
Date:   Thu, 20 Dec 2018 16:31:34 +0100
From:   Andreas Färber <afaerber@...e.de>
To:     Ben Whitten <Ben.Whitten@...rdtech.com>
Cc:     Jian-Hong Pan <starnight@...cu.edu.tw>,
        Jiri Pirko <jiri@...nulli.us>,
        "David S. Miller" <davem@...emloft.net>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        "linux-lpwan@...ts.infradead.org" <linux-lpwan@...ts.infradead.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Marcel Holtmann <marcel@...tmann.org>,
        Dollar Chen <dollar.chen@...ec.com>,
        Ken Yu <ken.yu@...wireless.com>,
        linux-wpan - ML <linux-wpan@...r.kernel.org>
Subject: Re: [PATCH v5 5/6] net: maclorawan: Implement maclorawan class module

Am 20.12.18 um 11:19 schrieb Ben Whitten:
>>>> 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,
>>> 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
>>> 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.
>>> Raw in the case of nodes and framed with metadata in the case of
>> concentrator
>>> 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)