netdev - Re: linux-lora.git and LoRaWAN (was: [RFC net-next 00/15] net: A socket API for LoRa)

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>] [day] [month] [year] [list]

Message-ID: <CAC=mGzgW2fmRAA9GxojcbiBWm_G=rWqFh2MZECu-VST20MePBg@mail.gmail.com>
Date:   Sun, 5 Aug 2018 22:08:10 +0800
From:   Jian-Hong Pan <starnight@...cu.edu.tw>
To:     Alan Cox <gnomes@...rguk.ukuu.org.uk>
Cc:     Andreas Färber <afaerber@...e.de>,
        Ben Whitten <Ben.Whitten@...rdtech.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "<linux-arm-kernel@...ts.infradead.org\\" 
        <linux-arm-kernel@...ts.infradead.org>,
        Jan Jongboom <jan.jongboom@....com>,
        Konstantin Böhm <konstantin.boehm@...ud.de>,
        Ken Yu <ken.yu@...wireless.com>,
        Dollar Chen <dollar.chen@...ec.com>,
        Michael Röder <michael.roeder@...et.eu>,
        Janus Piwek <jpiwek@...oweurope.com>,
        Matthias Brugger <mbrugger@...e.com>,
        "S. Miller" <davem@...emloft.net>,
        "linux-kernel@...r.kernel.org>," <contact@...otlab.com>,
        Brian Ray <brian.ray@...k-labs.com>
Subject: Re: linux-lora.git and LoRaWAN (was: [RFC net-next 00/15] net: A
 socket API for LoRa)

Hi Alan,

2018-08-03 22:02 GMT+08:00 Alan Cox <gnomes@...rguk.ukuu.org.uk>:
>> I'm not yet too deep into LoRaWAN, but from the AT command interfaces
>> I've seen there's confirmed and unconfirmed transmission modes that with
>> PF_LORAWAN might be mapped to SOCK_STREAM and SOCK_DGRAM. Or do you see
>> a way of doing both on a single PF_LORA SOCK_LORAWAN socket?
>
> SOCK_STREAM is not a confirmed message, but a reliable data stream where
> packet boundaries have no meaning.
>
> SOCK_SEQPACKET is a reliable ordered stream where message boundaries have
> meaning.
>
> SOCK_RDM is reliable messaging where there is no ordering.
>
> The standard socket API has no concept of a single connection doing both
> reliable and unreliable messages.

Thanks for the useful information.

LoRaWAN has 4 kinds of data messages: Unconfirmed data up/down,
Confirmed data up/down.

Unconfirmed data up/down can be mapped to SOCK_DGRAM.
Confirmed data up/down can be mapped to SOCK_SEQPACKET.  Because,
there is the FCnt (frame counter) field in frame header for the order.

Regards,
Jian-Hong Pan

>> Additionally I've been looking into socket options at PF_LORA dgram
>> layer for some radio options, but discarded that again for lack of
>> precedence. Basically I wondered whether we could allow to choose SF,
>
> I don't know if it'll stretch that far in the right directions but to the
> extent you can re-use bits of the wifi API and it makes sense it would be
> good to do so.
>
> For stuff bound to a specific socket you need to use the generic SOCK_
> stuff or you may indeed need some socket options at the PF_LORA level -
> which is fine, and the whole point of setsockopt passing layers around.
>
> Some of the existing general stuff like priority is probably quite
> useable.
>
>> bandwidth, etc. on socket level and then apply those settings before
>> sending one packet rather than expecting a global netlink operation that
>> affects all sockets for that interface.
>
> Alan