From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C5EEFC46470 for ; Wed, 8 Aug 2018 20:38:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7F58E21A13 for ; Wed, 8 Aug 2018 20:38:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7F58E21A13 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lxorguk.ukuu.org.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731219AbeHHW7k convert rfc822-to-8bit (ORCPT ); Wed, 8 Aug 2018 18:59:40 -0400 Received: from www.llwyncelyn.cymru ([82.70.14.225]:50034 "EHLO fuzix.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727530AbeHHW7k (ORCPT ); Wed, 8 Aug 2018 18:59:40 -0400 Received: from alans-desktop (82-70-14-226.dsl.in-addr.zen.co.uk [82.70.14.226]) by fuzix.org (8.15.2/8.15.2) with ESMTP id w78KafpD011609; Wed, 8 Aug 2018 21:36:41 +0100 Date: Wed, 8 Aug 2018 21:36:40 +0100 From: Alan Cox To: Andreas =?UTF-8?B?RsOkcmJlcg==?= Cc: Jian-Hong Pan , netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Jiri Pirko , Marcel Holtmann , "David S. Miller" , Matthias Brugger , Janus Piwek , Michael =?UTF-8?B?UsO2ZGVy?= , Dollar Chen , Ken Yu , Konstantin =?UTF-8?B?QsO2aG0=?= , Jan Jongboom , Jon Ortego , contact@snootlab.com, Ben Whitten , Brian Ray , lora@globalsat.com.tw, Alexander Graf , Michal =?UTF-8?B?S3ViZcSNZWs=?= , Rob Herring , devicetree@vger.kernel.org, Steve deRosier , Mark Brown , linux-spi@vger.kernel.org, Pieter Robyns , Hasnain Virk , linux-wpan , Stefan Schmidt , Daniele Comel Subject: Re: [RFC net-next 00/15] net: A socket API for LoRa Message-ID: <20180808213640.10a1d76f@alans-desktop> In-Reply-To: <92ee4016-1da9-826b-3674-b2d604a64848@suse.de> References: <20180701110804.32415-1-afaerber@suse.de> <92ee4016-1da9-826b-3674-b2d604a64848@suse.de> Organization: Intel Corporation X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 5 Aug 2018 02:11:25 +0200 Andreas Färber wrote: > Hi Jian-Hong, > > Am 03.07.2018 um 17:11 schrieb Jian-Hong Pan: > > 2018-07-01 19:07 GMT+08:00 Andreas Färber : > >> 2) PF_LORA is used with SOCK_DGRAM here. The assumption is that RAW mode > >> would be DGRAM plus preamble plus optional checksum. > > > > Is the preamble added by the hardware itself here or software here? > > That depends on the driver. For SX127x and any SX127x based modules it > is added by hardware and a SOCK_RAW seems impossible. If you were to use > some SDR hardware, it would need to be done by software and might either > be done in the device driver for SOCK_DGRAM or by user with a SOCK_RAW. > Right now I don't see a practical use case for the latter. (CC Pieter) For TCP/IP a SOCK_RAW is a socket with raw IP level access. It doesn't deal in IP headers and unless you ask it also does chunks of IP header stuff for you. SOCK_PACKET is the truely raw interface and even then it's rawness is bounded. You can't for example talk truely raw wifi bit streams, and for ethernet you get to generate MAC headers but not preambles etc. > LoRa radio channels being half-duplex, we'd need to stop receiving in > ndo_start_xmit and re-start receiving in the TX interrupt handler AFAIU. > Yes, it's ugly - one reason I haven't implemented RX in sx1276 yet. Why - the signal is still floating around in the air, you can't unhear it at the antenna. If a given piece of hardware needs to flip between RX and TX mode then it should be handled by that driver. (Some ancient ethernet cards do this btw.. they can't listen and transmit at the same time) > > - We can have a pre-defined table according to LoRaWAN Regional Parameters. > > - Device driver declares the hardware's capability, for example > > frequency, TX power. And then registers as a LoRaWAN compatible > > device. > > That sounds like a layering violation. We rather need to expose all > these tunable parameters individually at the LoRa layer, allowing the > LoRaWAN layer to configure them as it pleases. Not the other direction. > That still leaves my above question 4) open of how to implement each. Wifi already has the general policy database for the various existing protocols. Please take a look at the CRDA agent and how it hooks into wireless.It might need to some tweaking but it would be odd to have different configuration schemes for different wifi protocols. > The use case I have in mind is this: User A opens a LoRaWAN socket and > using maclorawan sends a packet P1. Here the LoRaWAN Regional Parameters > and LoRaWAN Sync Word need to be applied. > User B then opens a pure LoRa socket and transmits a packet P1' with > different Sync Word, SF, BW, CR, etc. > Afterwards user A wants to send another packet P2 via LoRaWAN - this > needs to use the same LoRaWAN settings as before, not those used for > LoRa in between. Therefore I was thinking about socket-level options, as > netlink operations would be device-wide, with undesired side-effects. Agreed > Obviously in that scenario not both users can receive at the same time. That's a hardware question. Imagine a software defined radio. If your limitation wouldn't exist in a pure software defined radio then it's almost certainly a device level detal. > interface but cleanly distinguished as ETH_P_GFSK or something. > For example, the Chistera Pi HAT has both an RFM95W and an RFM22 module. Agreed if you can flip per packet. > The next question arising is how the user would create such an skb. Just > like I was hesitant about PF_LORAWAN originally, I'd like to avoid > polluting the PF_ number space for each of these. Maybe have one PF_FSK > as equivalent to PF_LORA and then have either a socket option or > sockaddr field to select the modulation variants? Not sure how exactly > those others differ from each other, that's why I tried to postpone the > FSK topic and to focus on LoRa first - b) below. > > At this point we could also argue whether we need a PF_LORA at all or > rather just some generic PF_RADIO with lots of options stored in its > sockaddr. What matters most is mux/demux. If you've got something listening to data but without the structure needed to identify multiple listeners and split out the data meaningfully to those listeners according to parts of the packet then you've got no reason to make it a protocol just use SOCK_PACKET and if need be BPF. The reason we have a socket layer not /dev/ethernet0 is that it's meaningful to divide messages up into flows, and to partition those flows securely amongst multiple consumers/generators. Alan From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Cox Subject: Re: [RFC net-next 00/15] net: A socket API for LoRa Date: Wed, 8 Aug 2018 21:36:40 +0100 Message-ID: <20180808213640.10a1d76f@alans-desktop> References: <20180701110804.32415-1-afaerber@suse.de> <92ee4016-1da9-826b-3674-b2d604a64848@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: Michal =?UTF-8?B?S3ViZcSNZWs=?= , Konstantin =?UTF-8?B?QsO2aG0=?= , Pieter Robyns , contact@snootlab.com, Ken Yu , Michael =?UTF-8?B?UsO2ZGVy?= , Stefan Schmidt , Rob Herring , lora@globalsat.com.tw, Alexander Graf , Jan Jongboom , Janus Piwek , Jon Ortego , Jian-Hong Pan , devicetree@vger.kernel.org, Jiri Pirko , Hasnain Virk , Daniele Comel , Marcel Holtmann , Mark Brown , Dollar Chen , Brian Ray , linux-arm-kernel@lists.infradead.org, Matthias Brugger Return-path: In-Reply-To: <92ee4016-1da9-826b-3674-b2d604a64848@suse.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org List-Id: netdev.vger.kernel.org T24gU3VuLCA1IEF1ZyAyMDE4IDAyOjExOjI1ICswMjAwCkFuZHJlYXMgRsOkcmJlciA8YWZhZXJi ZXJAc3VzZS5kZT4gd3JvdGU6Cgo+IEhpIEppYW4tSG9uZywKPiAKPiBBbSAwMy4wNy4yMDE4IHVt IDE3OjExIHNjaHJpZWIgSmlhbi1Ib25nIFBhbjoKPiA+IDIwMTgtMDctMDEgMTk6MDcgR01UKzA4 OjAwIEFuZHJlYXMgRsOkcmJlciA8YWZhZXJiZXJAc3VzZS5kZT46ICAKPiA+PiAyKSBQRl9MT1JB IGlzIHVzZWQgd2l0aCBTT0NLX0RHUkFNIGhlcmUuIFRoZSBhc3N1bXB0aW9uIGlzIHRoYXQgUkFX IG1vZGUKPiA+PiAgICB3b3VsZCBiZSBER1JBTSBwbHVzIHByZWFtYmxlIHBsdXMgb3B0aW9uYWwg Y2hlY2tzdW0uICAKPiA+IAo+ID4gSXMgdGhlIHByZWFtYmxlIGFkZGVkIGJ5IHRoZSBoYXJkd2Fy ZSBpdHNlbGYgaGVyZSBvciBzb2Z0d2FyZSBoZXJlPyAgCj4gCj4gVGhhdCBkZXBlbmRzIG9uIHRo ZSBkcml2ZXIuIEZvciBTWDEyN3ggYW5kIGFueSBTWDEyN3ggYmFzZWQgbW9kdWxlcyBpdAo+IGlz IGFkZGVkIGJ5IGhhcmR3YXJlIGFuZCBhIFNPQ0tfUkFXIHNlZW1zIGltcG9zc2libGUuIElmIHlv dSB3ZXJlIHRvIHVzZQo+IHNvbWUgU0RSIGhhcmR3YXJlLCBpdCB3b3VsZCBuZWVkIHRvIGJlIGRv bmUgYnkgc29mdHdhcmUgYW5kIG1pZ2h0IGVpdGhlcgo+IGJlIGRvbmUgaW4gdGhlIGRldmljZSBk cml2ZXIgZm9yIFNPQ0tfREdSQU0gb3IgYnkgdXNlciB3aXRoIGEgU09DS19SQVcuCj4gUmlnaHQg bm93IEkgZG9uJ3Qgc2VlIGEgcHJhY3RpY2FsIHVzZSBjYXNlIGZvciB0aGUgbGF0dGVyLiAoQ0Mg UGlldGVyKQoKRm9yIFRDUC9JUCBhIFNPQ0tfUkFXIGlzIGEgc29ja2V0IHdpdGggcmF3IElQIGxl dmVsIGFjY2Vzcy4gSXQgZG9lc24ndApkZWFsIGluIElQIGhlYWRlcnMgYW5kIHVubGVzcyB5b3Ug YXNrIGl0IGFsc28gZG9lcyBjaHVua3Mgb2YgSVAgaGVhZGVyCnN0dWZmIGZvciB5b3UuCgpTT0NL X1BBQ0tFVCBpcyB0aGUgdHJ1ZWx5IHJhdyBpbnRlcmZhY2UgYW5kIGV2ZW4gdGhlbiBpdCdzIHJh d25lc3MgaXMKYm91bmRlZC4gWW91IGNhbid0IGZvciBleGFtcGxlIHRhbGsgdHJ1ZWx5IHJhdyB3 aWZpIGJpdCBzdHJlYW1zLCBhbmQgZm9yCmV0aGVybmV0IHlvdSBnZXQgdG8gZ2VuZXJhdGUgTUFD IGhlYWRlcnMgYnV0IG5vdCBwcmVhbWJsZXMgZXRjLgoKPiBMb1JhIHJhZGlvIGNoYW5uZWxzIGJl aW5nIGhhbGYtZHVwbGV4LCB3ZSdkIG5lZWQgdG8gc3RvcCByZWNlaXZpbmcgaW4KPiBuZG9fc3Rh cnRfeG1pdCBhbmQgcmUtc3RhcnQgcmVjZWl2aW5nIGluIHRoZSBUWCBpbnRlcnJ1cHQgaGFuZGxl ciBBRkFJVS4KPiBZZXMsIGl0J3MgdWdseSAtIG9uZSByZWFzb24gSSBoYXZlbid0IGltcGxlbWVu dGVkIFJYIGluIHN4MTI3NiB5ZXQuCgpXaHkgLSB0aGUgc2lnbmFsIGlzIHN0aWxsIGZsb2F0aW5n IGFyb3VuZCBpbiB0aGUgYWlyLCB5b3UgY2FuJ3QgdW5oZWFyIGl0CmF0IHRoZSBhbnRlbm5hLiBJ ZiBhIGdpdmVuIHBpZWNlIG9mIGhhcmR3YXJlIG5lZWRzIHRvIGZsaXAgYmV0d2VlbiBSWAphbmQg VFggbW9kZSB0aGVuIGl0IHNob3VsZCBiZSBoYW5kbGVkIGJ5IHRoYXQgZHJpdmVyLgoKKFNvbWUg YW5jaWVudCBldGhlcm5ldCBjYXJkcyBkbyB0aGlzIGJ0dy4uIHRoZXkgY2FuJ3QgbGlzdGVuIGFu ZCB0cmFuc21pdAphdCB0aGUgc2FtZSB0aW1lKQoKPiA+IC0gV2UgY2FuIGhhdmUgYSBwcmUtZGVm aW5lZCB0YWJsZSBhY2NvcmRpbmcgdG8gTG9SYVdBTiBSZWdpb25hbCBQYXJhbWV0ZXJzLgo+ID4g LSBEZXZpY2UgZHJpdmVyIGRlY2xhcmVzIHRoZSBoYXJkd2FyZSdzIGNhcGFiaWxpdHksIGZvciBl eGFtcGxlCj4gPiBmcmVxdWVuY3ksIFRYIHBvd2VyLiAgQW5kIHRoZW4gcmVnaXN0ZXJzIGFzIGEg TG9SYVdBTiBjb21wYXRpYmxlCj4gPiBkZXZpY2UuICAKPiAKPiBUaGF0IHNvdW5kcyBsaWtlIGEg bGF5ZXJpbmcgdmlvbGF0aW9uLiBXZSByYXRoZXIgbmVlZCB0byBleHBvc2UgYWxsCj4gdGhlc2Ug dHVuYWJsZSBwYXJhbWV0ZXJzIGluZGl2aWR1YWxseSBhdCB0aGUgTG9SYSBsYXllciwgYWxsb3dp bmcgdGhlCj4gTG9SYVdBTiBsYXllciB0byBjb25maWd1cmUgdGhlbSBhcyBpdCBwbGVhc2VzLiBO b3QgdGhlIG90aGVyIGRpcmVjdGlvbi4KPiBUaGF0IHN0aWxsIGxlYXZlcyBteSBhYm92ZSBxdWVz dGlvbiA0KSBvcGVuIG9mIGhvdyB0byBpbXBsZW1lbnQgZWFjaC4KCldpZmkgYWxyZWFkeSBoYXMg dGhlIGdlbmVyYWwgcG9saWN5IGRhdGFiYXNlIGZvciB0aGUgdmFyaW91cyBleGlzdGluZwpwcm90 b2NvbHMuIFBsZWFzZSB0YWtlIGEgbG9vayBhdCB0aGUgQ1JEQSBhZ2VudCBhbmQgaG93IGl0IGhv b2tzIGludG8Kd2lyZWxlc3MuSXQgbWlnaHQgbmVlZCB0byBzb21lIHR3ZWFraW5nIGJ1dCBpdCB3 b3VsZCBiZSBvZGQgdG8gaGF2ZQpkaWZmZXJlbnQgY29uZmlndXJhdGlvbiBzY2hlbWVzIGZvciBk aWZmZXJlbnQgd2lmaSBwcm90b2NvbHMuCgo+IFRoZSB1c2UgY2FzZSBJIGhhdmUgaW4gbWluZCBp cyB0aGlzOiBVc2VyIEEgb3BlbnMgYSBMb1JhV0FOIHNvY2tldCBhbmQKPiB1c2luZyBtYWNsb3Jh d2FuIHNlbmRzIGEgcGFja2V0IFAxLiBIZXJlIHRoZSBMb1JhV0FOIFJlZ2lvbmFsIFBhcmFtZXRl cnMKPiBhbmQgTG9SYVdBTiBTeW5jIFdvcmQgbmVlZCB0byBiZSBhcHBsaWVkLgo+IFVzZXIgQiB0 aGVuIG9wZW5zIGEgcHVyZSBMb1JhIHNvY2tldCBhbmQgdHJhbnNtaXRzIGEgcGFja2V0IFAxJyB3 aXRoCj4gZGlmZmVyZW50IFN5bmMgV29yZCwgU0YsIEJXLCBDUiwgZXRjLgo+IEFmdGVyd2FyZHMg dXNlciBBIHdhbnRzIHRvIHNlbmQgYW5vdGhlciBwYWNrZXQgUDIgdmlhIExvUmFXQU4gLSB0aGlz Cj4gbmVlZHMgdG8gdXNlIHRoZSBzYW1lIExvUmFXQU4gc2V0dGluZ3MgYXMgYmVmb3JlLCBub3Qg dGhvc2UgdXNlZCBmb3IKPiBMb1JhIGluIGJldHdlZW4uIFRoZXJlZm9yZSBJIHdhcyB0aGlua2lu ZyBhYm91dCBzb2NrZXQtbGV2ZWwgb3B0aW9ucywgYXMKPiBuZXRsaW5rIG9wZXJhdGlvbnMgd291 bGQgYmUgZGV2aWNlLXdpZGUsIHdpdGggdW5kZXNpcmVkIHNpZGUtZWZmZWN0cy4KCkFncmVlZAoK PiBPYnZpb3VzbHkgaW4gdGhhdCBzY2VuYXJpbyBub3QgYm90aCB1c2VycyBjYW4gcmVjZWl2ZSBh dCB0aGUgc2FtZSB0aW1lLgoKVGhhdCdzIGEgaGFyZHdhcmUgcXVlc3Rpb24uIEltYWdpbmUgYSBz b2Z0d2FyZSBkZWZpbmVkIHJhZGlvLiBJZiB5b3VyCmxpbWl0YXRpb24gd291bGRuJ3QgZXhpc3Qg aW4gYSBwdXJlIHNvZnR3YXJlIGRlZmluZWQgcmFkaW8gdGhlbiBpdCdzCmFsbW9zdCBjZXJ0YWlu bHkgYSBkZXZpY2UgbGV2ZWwgZGV0YWwuCgo+IGludGVyZmFjZSBidXQgY2xlYW5seSBkaXN0aW5n dWlzaGVkIGFzIEVUSF9QX0dGU0sgb3Igc29tZXRoaW5nLgo+IEZvciBleGFtcGxlLCB0aGUgQ2hp c3RlcmEgUGkgSEFUIGhhcyBib3RoIGFuIFJGTTk1VyBhbmQgYW4gUkZNMjIgbW9kdWxlLgoKQWdy ZWVkIGlmIHlvdSBjYW4gZmxpcCBwZXIgcGFja2V0LgoKPiBUaGUgbmV4dCBxdWVzdGlvbiBhcmlz aW5nIGlzIGhvdyB0aGUgdXNlciB3b3VsZCBjcmVhdGUgc3VjaCBhbiBza2IuIEp1c3QKPiBsaWtl IEkgd2FzIGhlc2l0YW50IGFib3V0IFBGX0xPUkFXQU4gb3JpZ2luYWxseSwgSSdkIGxpa2UgdG8g YXZvaWQKPiBwb2xsdXRpbmcgdGhlIFBGXyBudW1iZXIgc3BhY2UgZm9yIGVhY2ggb2YgdGhlc2Uu IE1heWJlIGhhdmUgb25lIFBGX0ZTSwo+IGFzIGVxdWl2YWxlbnQgdG8gUEZfTE9SQSBhbmQgdGhl biBoYXZlIGVpdGhlciBhIHNvY2tldCBvcHRpb24gb3IKPiBzb2NrYWRkciBmaWVsZCB0byBzZWxl Y3QgdGhlIG1vZHVsYXRpb24gdmFyaWFudHM/IE5vdCBzdXJlIGhvdyBleGFjdGx5Cj4gdGhvc2Ug b3RoZXJzIGRpZmZlciBmcm9tIGVhY2ggb3RoZXIsIHRoYXQncyB3aHkgSSB0cmllZCB0byBwb3N0 cG9uZSB0aGUKPiBGU0sgdG9waWMgYW5kIHRvIGZvY3VzIG9uIExvUmEgZmlyc3QgLSBiKSBiZWxv dy4KPiAKPiBBdCB0aGlzIHBvaW50IHdlIGNvdWxkIGFsc28gYXJndWUgd2hldGhlciB3ZSBuZWVk IGEgUEZfTE9SQSBhdCBhbGwgb3IKPiByYXRoZXIganVzdCBzb21lIGdlbmVyaWMgUEZfUkFESU8g d2l0aCBsb3RzIG9mIG9wdGlvbnMgc3RvcmVkIGluIGl0cwo+IHNvY2thZGRyLgoKV2hhdCBtYXR0 ZXJzIG1vc3QgaXMgbXV4L2RlbXV4LgoKSWYgeW91J3ZlIGdvdCBzb21ldGhpbmcgbGlzdGVuaW5n IHRvIGRhdGEgYnV0IHdpdGhvdXQgdGhlIHN0cnVjdHVyZQpuZWVkZWQgdG8gaWRlbnRpZnkgbXVs dGlwbGUgbGlzdGVuZXJzIGFuZCBzcGxpdCBvdXQgdGhlIGRhdGEgbWVhbmluZ2Z1bGx5CnRvIHRo b3NlIGxpc3RlbmVycyBhY2NvcmRpbmcgdG8gcGFydHMgb2YgdGhlIHBhY2tldCB0aGVuIHlvdSd2 ZSBnb3Qgbm8KcmVhc29uIHRvIG1ha2UgaXQgYSBwcm90b2NvbCBqdXN0IHVzZSBTT0NLX1BBQ0tF VCBhbmQgaWYgbmVlZCBiZSBCUEYuCgpUaGUgcmVhc29uIHdlIGhhdmUgYSBzb2NrZXQgbGF5ZXIg bm90IC9kZXYvZXRoZXJuZXQwIGlzIHRoYXQgaXQncwptZWFuaW5nZnVsIHRvIGRpdmlkZSBtZXNz YWdlcyB1cCBpbnRvIGZsb3dzLCBhbmQgdG8gcGFydGl0aW9uIHRob3NlIGZsb3dzCnNlY3VyZWx5 IGFtb25nc3QgbXVsdGlwbGUgY29uc3VtZXJzL2dlbmVyYXRvcnMuCgpBbGFuCgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1h aWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xp c3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: gnomes@lxorguk.ukuu.org.uk (Alan Cox) Date: Wed, 8 Aug 2018 21:36:40 +0100 Subject: [RFC net-next 00/15] net: A socket API for LoRa In-Reply-To: <92ee4016-1da9-826b-3674-b2d604a64848@suse.de> References: <20180701110804.32415-1-afaerber@suse.de> <92ee4016-1da9-826b-3674-b2d604a64848@suse.de> Message-ID: <20180808213640.10a1d76f@alans-desktop> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Sun, 5 Aug 2018 02:11:25 +0200 Andreas F?rber wrote: > Hi Jian-Hong, > > Am 03.07.2018 um 17:11 schrieb Jian-Hong Pan: > > 2018-07-01 19:07 GMT+08:00 Andreas F?rber : > >> 2) PF_LORA is used with SOCK_DGRAM here. The assumption is that RAW mode > >> would be DGRAM plus preamble plus optional checksum. > > > > Is the preamble added by the hardware itself here or software here? > > That depends on the driver. For SX127x and any SX127x based modules it > is added by hardware and a SOCK_RAW seems impossible. If you were to use > some SDR hardware, it would need to be done by software and might either > be done in the device driver for SOCK_DGRAM or by user with a SOCK_RAW. > Right now I don't see a practical use case for the latter. (CC Pieter) For TCP/IP a SOCK_RAW is a socket with raw IP level access. It doesn't deal in IP headers and unless you ask it also does chunks of IP header stuff for you. SOCK_PACKET is the truely raw interface and even then it's rawness is bounded. You can't for example talk truely raw wifi bit streams, and for ethernet you get to generate MAC headers but not preambles etc. > LoRa radio channels being half-duplex, we'd need to stop receiving in > ndo_start_xmit and re-start receiving in the TX interrupt handler AFAIU. > Yes, it's ugly - one reason I haven't implemented RX in sx1276 yet. Why - the signal is still floating around in the air, you can't unhear it at the antenna. If a given piece of hardware needs to flip between RX and TX mode then it should be handled by that driver. (Some ancient ethernet cards do this btw.. they can't listen and transmit at the same time) > > - We can have a pre-defined table according to LoRaWAN Regional Parameters. > > - Device driver declares the hardware's capability, for example > > frequency, TX power. And then registers as a LoRaWAN compatible > > device. > > That sounds like a layering violation. We rather need to expose all > these tunable parameters individually at the LoRa layer, allowing the > LoRaWAN layer to configure them as it pleases. Not the other direction. > That still leaves my above question 4) open of how to implement each. Wifi already has the general policy database for the various existing protocols. Please take a look at the CRDA agent and how it hooks into wireless.It might need to some tweaking but it would be odd to have different configuration schemes for different wifi protocols. > The use case I have in mind is this: User A opens a LoRaWAN socket and > using maclorawan sends a packet P1. Here the LoRaWAN Regional Parameters > and LoRaWAN Sync Word need to be applied. > User B then opens a pure LoRa socket and transmits a packet P1' with > different Sync Word, SF, BW, CR, etc. > Afterwards user A wants to send another packet P2 via LoRaWAN - this > needs to use the same LoRaWAN settings as before, not those used for > LoRa in between. Therefore I was thinking about socket-level options, as > netlink operations would be device-wide, with undesired side-effects. Agreed > Obviously in that scenario not both users can receive at the same time. That's a hardware question. Imagine a software defined radio. If your limitation wouldn't exist in a pure software defined radio then it's almost certainly a device level detal. > interface but cleanly distinguished as ETH_P_GFSK or something. > For example, the Chistera Pi HAT has both an RFM95W and an RFM22 module. Agreed if you can flip per packet. > The next question arising is how the user would create such an skb. Just > like I was hesitant about PF_LORAWAN originally, I'd like to avoid > polluting the PF_ number space for each of these. Maybe have one PF_FSK > as equivalent to PF_LORA and then have either a socket option or > sockaddr field to select the modulation variants? Not sure how exactly > those others differ from each other, that's why I tried to postpone the > FSK topic and to focus on LoRa first - b) below. > > At this point we could also argue whether we need a PF_LORA at all or > rather just some generic PF_RADIO with lots of options stored in its > sockaddr. What matters most is mux/demux. If you've got something listening to data but without the structure needed to identify multiple listeners and split out the data meaningfully to those listeners according to parts of the packet then you've got no reason to make it a protocol just use SOCK_PACKET and if need be BPF. The reason we have a socket layer not /dev/ethernet0 is that it's meaningful to divide messages up into flows, and to partition those flows securely amongst multiple consumers/generators. Alan