* Re: [RFC net-next 00/15] net: A socket API for LoRa [not found] ` <CAC=mGzgUCopz2xTOA0R-WD8a1DOaOOUn=YpfdMiJ33y3hnh6kg@mail.gmail.com> @ 2018-08-05 0:11 ` Andreas Färber 2018-08-08 20:36 ` Alan Cox 2018-08-09 0:50 ` Andreas Färber 0 siblings, 2 replies; 15+ messages in thread From: Andreas Färber @ 2018-08-05 0:11 UTC (permalink / raw) To: Jian-Hong Pan Cc: netdev, linux-arm-kernel, linux-kernel, Jiri Pirko, Marcel Holtmann, David S. Miller, Matthias Brugger, Janus Piwek, Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm, Jan Jongboom, Jon Ortego, contact, Ben Whitten, Brian Ray, lora, Alexander Graf, Michal Kubeček, Rob Herring, devicetree, Steve deRosier, Mark Brown, linux-spi, Pieter Robyns, Hasnain Virk, Alan Cox, linux-wpan, Stefan Schmidt, Daniele Comel 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 <afaerber@suse.de>: >> 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) >> 3) Only the transmit path is partially implemented already. The assumption >> is that the devices should go into receive mode by default and only >> interrupt that when asked to transmit. > > If it goes with LoRaWAN spec., end devices should be in idle (or > called standby mode) by default. Unless the device is asked to be in > transmitting or receiving timing slot. Whatever the LoRaWAN spec says, in practice struct net_device_ops has an ndo_start_xmit hook but no ndo_start_recv. All drivers that I've checked start receiving via interrupts after ndo_open has set things up. 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. Are you suggesting to have dgram's recvmsg trigger the RX state somehow? It gets access to the net_device and could access dev.h struct lora_priv that we might extend to contain a LoRa-specific start_recv callback. And probably rename it more uniquely to lora_dev_priv while at it. The only other alternative I can think of would be to require the user to perform some netlink operation, possibly wrapped in some lora_ API, to actively put the device into receive mode. Doesn't sound desirable. >> 4) Some hardware settings need to be supplied externally, such as the radio >> frequency for some modules, but many others can be runtime-configured, >> such as Spreading Factor, Bandwidth, Sync Word, or which antenna to use. >> What settings should be implemented as socket option vs. netlink layer >> vs. ioctl vs. sysfs? What are the criteria to apply? > > - 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. 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. Obviously in that scenario not both users can receive at the same time. If there was a way to start receiving only when a user performs such a socket operations, even this could be implemented - if incompatible reception can get detected and if the packet gets delivered to both, LoRa being broadcast. > - LoRaWAN module handle the requests from upper layer or MAC commands > from a gateway (netlink layer), than uses the pre-defined interface > functions to set the parameters. > > LoRaWAN module will export the operation functions interface. > >> 5) Many of the modules support multiple modes, such as LoRa, LoRaWAN and FSK. >> Lacking a LoRaWAN implementation, I am currently switching them into LoRa >> mode at probe time wherever possible. How do we deal with that properly? > > - There are data rate tables defined in LoRaWAN Regional Parameters. > Those contain which data rate uses LoRa mode or FSK mode. That's missing my point, I fear. Independently of what LoRaWAN does, the user needs to be able to send on the physical layer from a selection of LoRa, GFSK, FSK, OOK, GMSK and MSK. Supposedly Wireless M-Bus and IEEE 802.15.4 can be implemented via those according to the SX1276 datasheet. This opens a can of worms... SX127x has a single channel, so I don't think there should be six network interfaces lora0, gfsk0, fsk0, ook0, gmsk0 and msk0 exposed to the user. Having a lora0 interface speak non-LoRa modulations may be confusing, but since the chip is sold as LoRa transceiver it might be acceptable. SX130x has 8+2 channels, with IF9 dedicated to GFSK/FSK. It appears to use one FIFO for receiving (up to 16 packets) and can only transmit one packet at a time. So I think this should be one lora0 interface, too. With a view to supporting non-LoRa RF chipsets such as Si4xxx (GFSK, FSK, OOK) or nRF905 and nRF24L01+ (both GFSK) at a later date, I don't think those modulations should be some netlink option on a PF_LORA interface but cleanly distinguished as ETH_P_GFSK or something. For example, the Chistera Pi HAT has both an RFM95W and an RFM22 module. 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. One criteria will be whether we need multiple protocol options per modulation type or just one. For LoRa that was the dgram vs. raw discussion; for FSK/OOK I read packet mode vs. continuous mode in SX127x but not obvious if that affects the protocol or just the device driver. Getting back to your point, the data rate selection at LoRaWAN layer needs to determine how an skb gets passed between device driver and MAC. Another aspect FSK touches on is interactions with other subsystems. For example, how an sx1276 802.15.4 implementation for FSK/OOK (or LoRa, as you mentioned in your slides) would best interact with ieee802154 and mac802154 code when not done as standalone implementation. Or how to deal with SigFox on the same module as LoRaWAN - not aware of any kernel subsystem for SigFox. By comparison, on-module BLE sounds slightly easier, since it uses a separate antenna. (Haven't seen LoRa plus NB-IoT yet, to name the other LPWAN technology.) > - LoRaWAN should handle the data rate changing requests and then calls > the corresponding operation functions. Of course, the hardware's > capability registered before should also be under consideration at the > same time. > >> a) Is there any precedence from the Wifi world for dynamically selecting >> between our own trusted Open Source implementation vs. hardware/firmware >> accelerated and/or certified implementations? >> >> b) Would a proof of concept for FSK (non-LoRa) modes be required for >> merging any LoRa driver for chipsets that support both? Or is there any >> facility or design guidelines that would allow us to focus on LoRa and >> LoRaWAN and leave non-LoRa radio modes to later contributors? Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC net-next 00/15] net: A socket API for LoRa 2018-08-05 0:11 ` [RFC net-next 00/15] net: A socket API for LoRa Andreas Färber @ 2018-08-08 20:36 ` Alan Cox 2018-08-08 22:42 ` Andreas Färber 2018-08-09 0:50 ` Andreas Färber 1 sibling, 1 reply; 15+ messages in thread From: Alan Cox @ 2018-08-08 20:36 UTC (permalink / raw) To: Andreas Färber Cc: Jian-Hong Pan, netdev, linux-arm-kernel, linux-kernel, Jiri Pirko, Marcel Holtmann, David S. Miller, Matthias Brugger, Janus Piwek, Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm, Jan Jongboom, Jon Ortego, contact, Ben Whitten, Brian Ray, lora, Alexander Graf, Michal Kubeček, Rob Herring, devicetree, Steve deRosier, Mark Brown, linux-spi, Pieter Robyns, Hasnain Virk, linux-wpan, Stefan Schmidt, Daniele Comel On Sun, 5 Aug 2018 02:11:25 +0200 Andreas Färber <afaerber@suse.de> 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 <afaerber@suse.de>: > >> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC net-next 00/15] net: A socket API for LoRa 2018-08-08 20:36 ` Alan Cox @ 2018-08-08 22:42 ` Andreas Färber 2018-08-09 11:59 ` Alan Cox 0 siblings, 1 reply; 15+ messages in thread From: Andreas Färber @ 2018-08-08 22:42 UTC (permalink / raw) To: Alan Cox Cc: Jian-Hong Pan, netdev, linux-arm-kernel, linux-kernel, Jiri Pirko, Marcel Holtmann, David S. Miller, Matthias Brugger, Janus Piwek, Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm, Jan Jongboom, Jon Ortego, contact, Ben Whitten, Brian Ray, lora, Alexander Graf, Michal Kubeček, Rob Herring, devicetree, Steve deRosier, Mark Brown, linux-spi, Pieter Robyns, Hasnain Virk, linux-wpan, Stefan Schmidt, Daniele Comel, Sebastian Heß, Xue Liu Am 08.08.2018 um 22:36 schrieb Alan Cox: > On Sun, 5 Aug 2018 02:11:25 +0200 > Andreas Färber <afaerber@suse.de> wrote: >> Am 03.07.2018 um 17:11 schrieb Jian-Hong Pan: >>> 2018-07-01 19:07 GMT+08:00 Andreas Färber <afaerber@suse.de>: >> 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. Why what? :) > If a given piece of hardware needs to flip between RX > and TX mode then it should be handled by that driver. Yes, and we are talking about that concrete sx1276 driver here, whose chipset has a state machine that only allows either rx or tx and also has standby and sleep modes with differing levels of data retention. The sx1301 is a different beast (and driver) and may allow both. In any case, the ndo_start_xmit hook is in each device driver. But the recvmsg hook I mentioned is at protocol layer, which exactly is the layering problem I see. > (Some ancient ethernet cards do this btw.. they can't listen and transmit > at the same time) So when do they start receiving? The issue here was that my original description, which you appear to have cut, suggested a continuous listen mode, interrupted by transmit. Jian-Hong didn't like that, with reference to the LoRaWAN spec that supposedly asks for only being in receive mode when expecting a message, likely to save on battery. So the question is, could we cleanly implement receiving only when the user asks us to, or is that a no-go? >>> - 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. CRDA/wireless-regdb had been brought up and I've been pointed to nl80211 and nl802154, which I've tried to make sense of for my initial nllora. Admittedly with limited success, as that code is slightly complex. We also seemed to have consensus here that we _should_ be reusing wireless-regdb but would need to extend it 1.) with sub-GHz frequency bands and 2.) duty-cycle limits for some of those bands. No maintainer commented on that so far. Thus I am working in tiny steps on providing netlink-layer commands in nllora that can dispatch the individual radio settings to drivers, which then upper layers can instrument as needed. And making my very first steps with netlink here, it appeared as if each technology has its own enums of commands and attributes, so I don't see how to reuse anything from Wifi here apart from some design inspiration. >> 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. An SDR would not be using this sx1276 device driver, I imagine. In fact I would expect an SDR device not to be in drivers/net/lora/ at all but to live in drivers/net/sdr/ and to consume ETH_P_LORA etc. skbs and just do the right thing for them depending on their type... >> 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 SX127x can - it might involve delays of course. The SX130x doesn't even need to flip for sending AFAICT, it's just metadata after the payload in the FIFO. >> 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. Sorry, that doesn't parse for me. SOCK_PACKET must be a protocol on some PF_ protocol family, no? Are you suggesting I use SOCK_PACKET instead of SOCK_DGRAM in what is now net/lora/dgram.c? Or are you saying there's some generic implementation that we can reuse and scratch mine? > 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. For me the distinction is that a /dev/whatever0 would seem more suited for a stream of data to read/write, whereas sockets give us a bounded skb for packets at device driver level. These PHYs all broadcast something over the antenna when sending, with any addressing of listeners or senders being optional and MAC-specific, apart from the LoRa/FSK SyncWord as well as the various frequency etc. settings that determine what the receiver listens for. None of these PHYs define any mechanism like EtherType through which to identify upper-layer protocols. So in a way, listening is always in a promiscuous mode, and I guess we would need to try to parse each incoming packet as e.g. a LoRaWAN packet and just give up if it's too short or checksums don't match. Only at the layer of LoRaWAN and competing proprietary or custom protocols can we split received packets out to individual listeners. Does that give us any further clues for the design discussion here? Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC net-next 00/15] net: A socket API for LoRa 2018-08-08 22:42 ` Andreas Färber @ 2018-08-09 11:59 ` Alan Cox 2018-08-09 15:02 ` Jian-Hong Pan 2018-08-09 15:12 ` Alexander Aring 0 siblings, 2 replies; 15+ messages in thread From: Alan Cox @ 2018-08-09 11:59 UTC (permalink / raw) To: Andreas Färber Cc: Jian-Hong Pan, netdev, linux-arm-kernel, linux-kernel, Jiri Pirko, Marcel Holtmann, David S. Miller, Matthias Brugger, Janus Piwek, Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm, Jan Jongboom, Jon Ortego, contact, Ben Whitten, Brian Ray, lora, Alexander Graf, Michal Kubeček, Rob Herring, devicetree, Steve deRosier, Mark Brown, linux-spi, Pieter Robyns, Hasnain Virk, linux-wpan, Stefan Schmidt, Daniele Comel, Sebastian Heß, Xue Liu > Yes, and we are talking about that concrete sx1276 driver here, whose > chipset has a state machine that only allows either rx or tx and also > has standby and sleep modes with differing levels of data retention. It's a hardware limit, it should never influence the protocol stack itself just the driver. Linux always tries to design to optimize the non-crappy case. In the long term that works out best because hardware improves and you don't want to be tied to an old limit. > > (Some ancient ethernet cards do this btw.. they can't listen and transmit > > at the same time) > > So when do they start receiving? When they are not transmitting. The transmit path switches modes and when the frame send is done it goes back to receiving. As old ethernet was also half duplex that worked. > The issue here was that my original description, which you appear to > have cut, suggested a continuous listen mode, interrupted by transmit. I don't think I cut it but if so I didn't mean to and your approach is the one I agree with. > Jian-Hong didn't like that, with reference to the LoRaWAN spec that > supposedly asks for only being in receive mode when expecting a message, > likely to save on battery. So the question is, could we cleanly > implement receiving only when the user asks us to, or is that a no-go? Why would you do so ? You can't run Linux on a tiny little micro-controller where that would matter. Sure it makes sense for some tiny spec of embedded silicon buried in a sensor - but not a Linux box. Now you might power it down when the interface is down, or when there is nobody using that interface but that's really more about long term idle power. > bands and 2.) duty-cycle limits for some of those bands. No maintainer > commented on that so far. Thus I am working in tiny steps on providing > netlink-layer commands in nllora that can dispatch the individual radio > settings to drivers, which then upper layers can instrument as needed. Sounds right to me. > > And making my very first steps with netlink here, it appeared as if each > technology has its own enums of commands and attributes, so I don't see > how to reuse anything from Wifi here apart from some design inspiration. That seems reasonable - you aren't likely to want to manage them with the same tool. > > 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. > > An SDR would not be using this sx1276 device driver, I imagine. > > In fact I would expect an SDR device not to be in drivers/net/lora/ at > all but to live in drivers/net/sdr/ and to consume ETH_P_LORA etc. skbs > and just do the right thing for them depending on their type... The point I was trying to make was that if you want to decide whether something is driver level or protocol level ask 'is this something you can't do even with an SDR'. Some things are protocol properties that no fancy hardware will change. Others are hardware limits, in which case you want them driver level - because at some point the hardware will get better. > > 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. > > Sorry, that doesn't parse for me. SOCK_PACKET must be a protocol on some > PF_ protocol family, no? Are you suggesting I use SOCK_PACKET instead of > SOCK_DGRAM in what is now net/lora/dgram.c? Or are you saying there's > some generic implementation that we can reuse and scratch mine? There is a heirarchy. Let me us IP for an example (historically it was SOCK_PACKET nowdays PF_PACKET - the layering got sorted better) PF_PACKET SOCK_RAW ETH_P_ALL Everything on that device minus some things like hardware pre-ambles PF_PACKET SOCK_RAW ETH_P_SOMETHING Everything on that device that has the underlying protocol (and the protocol might not be in the packet but a property of the interface because it only does that format - simple example SLIP is IP packets over a serial link a SLIP interface is IP, not because there is anything saying it is but because that is *all* it can be) You get the two above for free. PF_PACKET is built into the stack so providing you label packets with the ETH_P_xxx you have for Lora, you can use PF_PACKET interfaces to dump them and write raw packets at the kernel layer. PF_INET SOCK_RAW Split the messages by protocol number in IP between multiple listeners/writers PF_INET SOCK_UDP / TCP etc Split the messages by port numbers in the higher level protocol For PF_LORA these would map to whatever goes on at the LORA protocol level and divide LORA messages up between multiple processes on the Linux system that are interested in some of the messages. > > 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. > > For me the distinction is that a /dev/whatever0 would seem more suited > for a stream of data to read/write, whereas sockets give us a bounded > skb for packets at device driver level. You could equally do that in a simple character device *if* you didn't need to split messages up and share between users. Some protocol stacks actually do that and then sort it out in user space, either because they are really obscure or they are incredibly complicated and broken so want to be out of kernel 8) > These PHYs all broadcast something over the antenna when sending, with > any addressing of listeners or senders being optional and MAC-specific, > apart from the LoRa/FSK SyncWord as well as the various frequency etc. > settings that determine what the receiver listens for. > > None of these PHYs define any mechanism like EtherType through which to > identify upper-layer protocols. > > So in a way, listening is always in a promiscuous mode, and I guess we > would need to try to parse each incoming packet as e.g. a LoRaWAN packet > and just give up if it's too short or checksums don't match. Only at the > layer of LoRaWAN and competing proprietary or custom protocols can we > split received packets out to individual listeners. My vote would be in that case that you either 1. Set the protocol type on the interface assuming you don't mix and match (and if it's relying on random bits not looking like other packets then it sounds a complete mess at the moment - but yeah its new tech) 2. You pass everything up to some magical agent which somehow splits them up and labels them ETH_P_LORA / ETH_P_FOO etc 3. You do what ethernet does (which admittedly is *way* simpler for ethernet) and you have a library routine you can pass an skbuff in the driver itself which figures out wtf to label the packet. Look how eth_type_trans() is used. Drivers then just do skb->protocol = xxx_type_trans(skb, dev); and the basic labelling gets done and any header pulls (you probably won't have any given you don't have anything wrapping LORA), and multicast/broadcast labelling - again meaningless I suspect. #3 Is probably the nicest because you update it all in one place as standards change and the market hopefully conslidates and develops some kind of sane packet formats. It's also effectively covering #1 and it's easy to start with because an initial implementation can just do 'return htons(ETH_P_LORA)'. > > Does that give us any further clues for the design discussion here? > I think so yes How do you plan to deal with routing if you've got multiple devices ? Alan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC net-next 00/15] net: A socket API for LoRa 2018-08-09 11:59 ` Alan Cox @ 2018-08-09 15:02 ` Jian-Hong Pan 2018-08-09 15:21 ` Alexander Aring 2018-08-10 15:57 ` Alan Cox 2018-08-09 15:12 ` Alexander Aring 1 sibling, 2 replies; 15+ messages in thread From: Jian-Hong Pan @ 2018-08-09 15:02 UTC (permalink / raw) To: Alan Cox Cc: Andreas Färber, netdev, <linux-arm-kernel@lists.infradead.org\, linux-kernel@vger.kernel.org>,, Jiri Pirko, Marcel Holtmann, David S. Miller, Matthias Brugger, Janus Piwek, Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm, Jan Jongboom, Jon Ortego, linux-kernel@vger.kernel.org>,, Ben Whitten, Brian Ray, lora, Alexander Graf, Michal Kubeček, Rob Herring, devicetree, Steve deRosier, Mark Brown, linux-spi, pieter.robyns, Hasnain Virk, linux-wpan - ML, Stefan Schmidt, Daniele Comel, shess, Xue Liu Alan Cox <gnomes@lxorguk.ukuu.org.uk> 於 2018年8月9日 週四 下午7:59寫道: > > > Yes, and we are talking about that concrete sx1276 driver here, whose > > chipset has a state machine that only allows either rx or tx and also > > has standby and sleep modes with differing levels of data retention. > > It's a hardware limit, it should never influence the protocol stack > itself just the driver. Linux always tries to design to optimize the > non-crappy case. In the long term that works out best because hardware > improves and you don't want to be tied to an old limit. > > > > (Some ancient ethernet cards do this btw.. they can't listen and transmit > > > at the same time) > > > > So when do they start receiving? > > When they are not transmitting. The transmit path switches modes and when > the frame send is done it goes back to receiving. As old ethernet was > also half duplex that worked. > > > The issue here was that my original description, which you appear to > > have cut, suggested a continuous listen mode, interrupted by transmit. > > I don't think I cut it but if so I didn't mean to and your approach is > the one I agree with. > > > Jian-Hong didn't like that, with reference to the LoRaWAN spec that > > supposedly asks for only being in receive mode when expecting a message, > > likely to save on battery. So the question is, could we cleanly > > implement receiving only when the user asks us to, or is that a no-go? > > Why would you do so ? You can't run Linux on a tiny little > micro-controller where that would matter. Sure it makes sense for some > tiny spec of embedded silicon buried in a sensor - but not a Linux box. > > Now you might power it down when the interface is down, or when there is > nobody using that interface but that's really more about long term idle > power. Except saving power, mitigating the wireless signal conflict on the air is one of the reasons. According to the LoRaWAN spec. defined by LoRa Alliance, all LoRaWAN end devices must implement class A features, which is also the most general and simplest. 1. The transmission slot scheduled by the end-device is based on its own communication needs with a small variation based on a random time basis (ALOHA-type of protocol). 2. Only require downlink communication from the server shortly after the end-device has sent an uplink transmission. Downlink communications from the server at any other time will have to wait until the next scheduled uplink. 3. Each end-device‘s uplink transmission is followed by two short downlink receive windows. End device transmits an uplink message finished -> End device goes to sleep/idle/stop -> End device opens RX1 window. This is the time for the downlink message. -> End device goes to sleep/idle/stop -> End device opens RX2 window. This is another time for the downlink message. -> End device goes to sleep/idle/stop The time between end device transmit an uplink message finished and end device opens RX1 window is RX delay #1. The time between end device transmit an uplink message finished and end device opens RX2 window is RX delay #2. If end device gets the meaningful downlink message in RX1 window, it will not open RX2 window. The time of RX delay #1 and 2 are defined in LoRaWAN Regional Parameters. The sleep/idle/stop mitigate the unconcerned RF signals or messages. > > bands and 2.) duty-cycle limits for some of those bands. No maintainer > > commented on that so far. Thus I am working in tiny steps on providing > > netlink-layer commands in nllora that can dispatch the individual radio > > settings to drivers, which then upper layers can instrument as needed. > > Sounds right to me. > > > > And making my very first steps with netlink here, it appeared as if each > > technology has its own enums of commands and attributes, so I don't see > > how to reuse anything from Wifi here apart from some design inspiration. > > That seems reasonable - you aren't likely to want to manage them with the > same tool. > > > > 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. > > > > An SDR would not be using this sx1276 device driver, I imagine. > > > > In fact I would expect an SDR device not to be in drivers/net/lora/ at > > all but to live in drivers/net/sdr/ and to consume ETH_P_LORA etc. skbs > > and just do the right thing for them depending on their type... > > The point I was trying to make was that if you want to decide whether > something is driver level or protocol level ask 'is this something you > can't do even with an SDR'. Some things are protocol properties that no > fancy hardware will change. Others are hardware limits, in which case you > want them driver level - because at some point the hardware will get > better. > > > > 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. > > > > Sorry, that doesn't parse for me. SOCK_PACKET must be a protocol on some > > PF_ protocol family, no? Are you suggesting I use SOCK_PACKET instead of > > SOCK_DGRAM in what is now net/lora/dgram.c? Or are you saying there's > > some generic implementation that we can reuse and scratch mine? > > There is a heirarchy. Let me us IP for an example > > (historically it was SOCK_PACKET nowdays PF_PACKET - the layering got > sorted better) > > PF_PACKET SOCK_RAW ETH_P_ALL > > Everything on that device minus some things like hardware pre-ambles > > PF_PACKET SOCK_RAW ETH_P_SOMETHING > > Everything on that device that has the underlying protocol (and the > protocol might not be in the packet but a property of the interface > because it only does that format - simple example SLIP is IP packets over > a serial link a SLIP interface is IP, not because there is anything > saying it is but because that is *all* it can be) > > You get the two above for free. PF_PACKET is built into the stack so > providing you label packets with the ETH_P_xxx you have for Lora, you can > use PF_PACKET interfaces to dump them and write raw packets at the kernel > layer. > > PF_INET SOCK_RAW > > Split the messages by protocol number in IP between multiple > listeners/writers > > PF_INET SOCK_UDP / TCP etc > > Split the messages by port numbers in the higher level protocol > > > For PF_LORA these would map to whatever goes on at the LORA protocol > level and divide LORA messages up between multiple processes on the > Linux system that are interested in some of the messages. > > > > > 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. > > > > For me the distinction is that a /dev/whatever0 would seem more suited > > for a stream of data to read/write, whereas sockets give us a bounded > > skb for packets at device driver level. > > You could equally do that in a simple character device *if* you didn't > need to split messages up and share between users. Some protocol stacks > actually do that and then sort it out in user space, either because they > are really obscure or they are incredibly complicated and broken so want > to be out of kernel 8) > > > These PHYs all broadcast something over the antenna when sending, with > > any addressing of listeners or senders being optional and MAC-specific, > > apart from the LoRa/FSK SyncWord as well as the various frequency etc. > > settings that determine what the receiver listens for. > > > > None of these PHYs define any mechanism like EtherType through which to > > identify upper-layer protocols. > > > > So in a way, listening is always in a promiscuous mode, and I guess we > > would need to try to parse each incoming packet as e.g. a LoRaWAN packet > > and just give up if it's too short or checksums don't match. Only at the > > layer of LoRaWAN and competing proprietary or custom protocols can we > > split received packets out to individual listeners. > > My vote would be in that case that you either > > 1. Set the protocol type on the interface assuming you don't mix and > match (and if it's relying on random bits not looking like other packets > then it sounds a complete mess at the moment - but yeah its new tech) > > 2. You pass everything up to some magical agent which somehow splits them > up and labels them ETH_P_LORA / ETH_P_FOO etc > > 3. You do what ethernet does (which admittedly is *way* simpler for > ethernet) and you have a library routine you can pass an skbuff in the > driver itself which figures out wtf to label the packet. Look how > eth_type_trans() is used. Drivers then just do > > skb->protocol = xxx_type_trans(skb, dev); > > and the basic labelling gets done and any header pulls (you probably won't > have any given you don't have anything wrapping LORA), and > multicast/broadcast labelling - again meaningless I suspect. > > #3 Is probably the nicest because you update it all in one place as > standards change and the market hopefully conslidates and develops some > kind of sane packet formats. It's also effectively covering #1 and it's > easy to start with because an initial implementation can just do 'return > htons(ETH_P_LORA)'. > > > > > Does that give us any further clues for the design discussion here? > > > I think so yes > > How do you plan to deal with routing if you've got multiple devices ? For LoRaWAN, it is a star topology. One end device and one LoRaWAN gateway: An end device sends a uplink message to the LoRaWAN gateway directly. A LoRaWAN gateway receives the uplink message, then transfers to the LoRaWAN network server. The network server sends a downlink message to the end device via the transfer of the LoRaWAN gateway. Multiple end devices and multiple LoRaWAN gateway: Multiple end devices can send uplink messages to multiple LoRaWAN gateways directly. Gateways receive the the uplink messages, then transfer to the LoRaWAN network server. The LoRaWAN network server compares the uplink messages' content to filter out the duplicated messages. The LoRaWAN network server sends a downlink message to the end device via the transfer of only one chosen LoRaWAN gateway. So, an end device does not talk to other end devices directly. And, of course, the links between LoRaWAN gateway and the network server could be any network technology, only if they can communicate with each other fast enough. Regards, Jian-Hong Pan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC net-next 00/15] net: A socket API for LoRa 2018-08-09 15:02 ` Jian-Hong Pan @ 2018-08-09 15:21 ` Alexander Aring 2018-08-10 15:57 ` Alan Cox 1 sibling, 0 replies; 15+ messages in thread From: Alexander Aring @ 2018-08-09 15:21 UTC (permalink / raw) To: Jian-Hong Pan Cc: Alan Cox, Andreas Färber, netdev, <linux-arm-kernel@lists.infradead.org\, linux-kernel@vger.kernel.org>,, Jiri Pirko, Marcel Holtmann, David S. Miller, Matthias Brugger, Janus Piwek, Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm, Jan Jongboom, Jon Ortego, linux-kernel@vger.kernel.org>,, Ben Whitten, Brian Ray, lora, Alexander Graf, Michal Kubeček, Rob Herring, devicetree, Steve deRosier, Mark Brown, linux-spi, pieter.robyns, Hasnain Virk, linux-wpan - ML, Stefan Schmidt, Daniele Comel, shess, Xue Liu Hi, On Thu, Aug 09, 2018 at 11:02:45PM +0800, Jian-Hong Pan wrote: ... > > For LoRaWAN, it is a star topology. > In sense of 6LoWPAN that means "border router" in the middle which runs radvd on it and sending RA messages. Then doing a route (or even allow nd proxy) between capable $IPv6 (ethernet?) and LoRa 6LoWPAN interface. All others listen for RA messages with PIO and doing autoconfiguration. (In 6LoWPAN you would also pass a 6CO option to compress the PIO prefix, which would make sense to fully elide all IP addresses in the header). - Alex ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC net-next 00/15] net: A socket API for LoRa 2018-08-09 15:02 ` Jian-Hong Pan 2018-08-09 15:21 ` Alexander Aring @ 2018-08-10 15:57 ` Alan Cox 2018-08-11 18:30 ` Stefan Schmidt 2018-08-12 16:37 ` Jian-Hong Pan 1 sibling, 2 replies; 15+ messages in thread From: Alan Cox @ 2018-08-10 15:57 UTC (permalink / raw) To: Jian-Hong Pan Cc: Andreas Färber, netdev, <linux-arm-kernel@lists.infradead.org\, linux-kernel@vger.kernel.org>,, Jiri Pirko, Marcel Holtmann, David S. Miller, Matthias Brugger, Janus Piwek, Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm, Jan Jongboom, Jon Ortego, linux-kernel@vger.kernel.org>,, Ben Whitten, Brian Ray, lora, Alexander Graf, Michal Kubeček, Rob Herring, devicetree, Steve deRosier, Mark Brown, linux-spi, pieter.robyns, Hasnain Virk, linux-wpan - ML, Stefan Schmidt, Daniele Comel, shess, Xue Liu > Except saving power, mitigating the wireless signal conflict on the > air is one of the reasons. If the device level is always receiving when not transmitting it has no effect on this. The act of listening does not harm other traffic. > The sleep/idle/stop mitigate the unconcerned RF signals or messages. At the physical level it's irrelevant. If we are receiving then we might hear more things we later discard. It's not running on a tiny microcontroller so the extra CPU cycles are not going to kill us. > > How do you plan to deal with routing if you've got multiple devices ? > > For LoRaWAN, it is a star topology. No the question was much more how you plan to deal with it in the OS. If for example I want to open a LORA connection to something, then there needs to be a proper process to figure out where the target is and how to get traffic to them. I guess it's best phrased as - What does a struct sockaddr_lora look like - How does the kernel decide which interface it goes out of (if any), and if it loops back remembering we might only be talking to a hub, or we might even be a virtualized LORA interface where we are pretending to be some kind of sensor and feeding it back. Long term yes I think Alexander is right the inevitable fate of all networks is to become a link layer in order to transmit IP frames 8) Alan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC net-next 00/15] net: A socket API for LoRa 2018-08-10 15:57 ` Alan Cox @ 2018-08-11 18:30 ` Stefan Schmidt 2018-08-12 16:49 ` Andreas Färber 2018-08-12 16:37 ` Jian-Hong Pan 1 sibling, 1 reply; 15+ messages in thread From: Stefan Schmidt @ 2018-08-11 18:30 UTC (permalink / raw) To: Alan Cox, Jian-Hong Pan Cc: Andreas Faerber, netdev, linux-arm-kernel, linux-kernel, Jiri Pirko, Marcel Holtmann, David S. Miller, Matthias Brugger, Janus Piwek, Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm, Jan Jongboom, Jon Ortego, contact, Ben Whitten, Brian Ray, lora, Alexander Graf, mkubecek, Rob Herring, devicetree, Steve deRosier, Mark Brown, linux-spi, pieter.robyns, Hasnain Virk, linux-wpan - ML, Daniele Comel, shess, Xue Liu Hello. On 08/10/2018 05:57 PM, Alan Cox wrote: > > Long term yes I think Alexander is right the inevitable fate of all > networks is to become a link layer in order to transmit IP frames 8) There should be a niche for both at the same time. LoRaWAN is relevant right now and we should aim for making it possible to run a native Linux gateway for it. As for IP for long range low power there is the static context header compression draft to adapt IPv6 to the characteristics for some use cases of such networks. Implementing it within the existing 6lwopan subsystem should be possible. https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-16 regards Stefan Schmidt ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC net-next 00/15] net: A socket API for LoRa 2018-08-11 18:30 ` Stefan Schmidt @ 2018-08-12 16:49 ` Andreas Färber 0 siblings, 0 replies; 15+ messages in thread From: Andreas Färber @ 2018-08-12 16:49 UTC (permalink / raw) To: Stefan Schmidt, Alan Cox Cc: Jian-Hong Pan, netdev, linux-arm-kernel, linux-kernel, Jiri Pirko, Marcel Holtmann, David S. Miller, Matthias Brugger, Janus Piwek, Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm, Jan Jongboom, Jon Ortego, contact, Ben Whitten, Brian Ray, lora, Alexander Graf, mkubecek, Rob Herring, devicetree, Steve deRosier, Mark Brown, linux-spi, pieter.robyns, Hasnain Virk, linux-wpan - ML, Daniele Comel, shess, Xue Liu Hi, Am 11.08.2018 um 20:30 schrieb Stefan Schmidt: > On 08/10/2018 05:57 PM, Alan Cox wrote: >> >> Long term yes I think Alexander is right the inevitable fate of all >> networks is to become a link layer in order to transmit IP frames 8) > > There should be a niche for both at the same time. LoRaWAN is relevant > right now and we should aim for making it possible to run a native Linux > gateway for it. +1 > As for IP for long range low power there is the static context header > compression draft to adapt IPv6 to the characteristics for some use > cases of such networks. Implementing it within the existing 6lwopan > subsystem should be possible. > > https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-16 I'm open to supporting by appropriate design all kinds of upper layers people want to experiment with. Review feedback for that is welcome. However I don't intend to implement each of those myself, and hardcoding them is not really an option so they must be in appropriate modules. Do keep in mind that depending on vendor implementation we have between 26 and 2048 bytes MTU available, less based on regulatory requirements, often below 256 bytes. The more space we take away for frame headers just because they're somehow standardized will make it less useful. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC net-next 00/15] net: A socket API for LoRa 2018-08-10 15:57 ` Alan Cox 2018-08-11 18:30 ` Stefan Schmidt @ 2018-08-12 16:37 ` Jian-Hong Pan 2018-08-12 17:59 ` Andreas Färber 1 sibling, 1 reply; 15+ messages in thread From: Jian-Hong Pan @ 2018-08-12 16:37 UTC (permalink / raw) To: Alan Cox Cc: Andreas Färber, netdev, <linux-arm-kernel@lists.infradead.org\, linux-kernel@vger.kernel.org>,, Jiri Pirko, Marcel Holtmann, David S. Miller, Matthias Brugger, Janus Piwek, Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm, Jan Jongboom, Jon Ortego, linux-kernel@vger.kernel.org>,, Ben Whitten, Brian Ray, lora, Alexander Graf, Michal Kubeček, Rob Herring, devicetree, Steve deRosier, Mark Brown, linux-spi, Pieter ROBYNS, Hasnain Virk, linux-wpan - ML, Stefan Schmidt, Daniele Comel, shess, Xue Liu Alan Cox <gnomes@lxorguk.ukuu.org.uk> 於 2018年8月10日 週五 下午11:57寫道: > > > Except saving power, mitigating the wireless signal conflict on the > > air is one of the reasons. > > If the device level is always receiving when not transmitting it has no > effect on this. The act of listening does not harm other traffic. My friend had tested practically: If he changes the LoRa interface to RX mode after TX completes immediately, he will receive the signals like reflection echo some times. That is interesting! There is a paper "Exploring LoRa and LoRaWAN A suitable protocol for IoT weather stations?" by Kristoffer Olsson & Sveinn Finnsson http://publications.lib.chalmers.se/records/fulltext/252610/252610.pdf In chapter 3.2 Chirp Spread Spectrum, it describes the reflection echo phenomenon. I think that is why LoRaWAN places the RX delay time which avoids receiving the reflection noise. > > The sleep/idle/stop mitigate the unconcerned RF signals or messages. > > At the physical level it's irrelevant. If we are receiving then we might > hear more things we later discard. It's not running on a tiny > microcontroller so the extra CPU cycles are not going to kill us. According different power resource, LoRaWAN defines Class A, B and C. Class A is the basic and both Class B and C devices must also implement the feature of Class A. If the end device has sufficient power available, it can also implement the Class C: Continuously listening end-device. Here are the descriptions in LoRaWAN spec. for Class C: - The Class C end-device will listen with RX2 windows parameters as often as possible. - The end-device listens on RX2 when it is not either (a) sending or (b) receiving on RX1, according to Class A definition. - 1. It will open a short window on RX2 parameters between the end of the uplink transmission and the beginning of the RX1 reception window. (*) 2. It will switch to RX2 reception parameters as soon as the RX1 reception window is closed; the RX2 reception window will remain open until the end-device has to send another message. According to the LoRaWAN Regional Parameters, the DataRate (including spreading factor and bandwidth) and frequency channel of RX1 and RX2 windows may be different.(*) So, yes! Class C opens the RX windows almost all the time, except the TX time. And uses different channel to avoid the reflection noise (*). However, Class C must also implements Class A and C is more complex than A. I think starting from the simpler one and adding more features and complexity in the future will be a better practice. > > > How do you plan to deal with routing if you've got multiple devices ? > > > > For LoRaWAN, it is a star topology. > > No the question was much more how you plan to deal with it in the OS. If > for example I want to open a LORA connection to something, then there > needs to be a proper process to figure out where the target is and how to > get traffic to them. > > I guess it's best phrased as > > - What does a struct sockaddr_lora look like According to LoRaWAN spec, the Data Message only has the device's DevAddr (the device's address in 4 bytes) field related to "address". The device just sends the uplink Data Message through the interface and does not know the destination. Then, a LoRaWAN gateway receives the uplink Data Message and forwards to the designated network server. So, end device does not care about the destination. It only knows there is a gateway will forward its message to some where. Therefore, only the DevAddr as the source address will be meaningful for uplink Data Message. > - How does the kernel decide which interface it goes out of (if any), and > if it loops back There is the MAC Header in the Data Message which is one byte. Bits 5 to 7 indicate which kind of type the message is. 000: Join Request 001: Join Accept 010: Unconfirmed Data Up 011: Unconfirmed Data Down 100: Confirmed Data Up 101: Confirmed Data Down 110: RFU 111: Proprietary So, end device only accepts the types of downlink and the matched DevAddr (the device's address) in downlink Data Message for RX. > remembering we might only be talking to a hub, or we might even be a > virtualized LORA interface where we are pretending to be some kind of > sensor and feeding it back. > > Long term yes I think Alexander is right the inevitable fate of all > networks is to become a link layer in order to transmit IP frames 8) Yeah, maybe. It will be easier for life. But I have not seen the formal standard for that yet or I missed it. If the standard appears, we can try to implement it. Jian-Hong Pan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC net-next 00/15] net: A socket API for LoRa 2018-08-12 16:37 ` Jian-Hong Pan @ 2018-08-12 17:59 ` Andreas Färber 2018-08-13 12:36 ` Alan Cox 0 siblings, 1 reply; 15+ messages in thread From: Andreas Färber @ 2018-08-12 17:59 UTC (permalink / raw) To: Jian-Hong Pan, Alan Cox Cc: netdev, linux-arm-kernel, linux-kernel, Jiri Pirko, Marcel Holtmann, David S. Miller, Matthias Brugger, Janus Piwek, Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm, Jan Jongboom, Jon Ortego, contact, Ben Whitten, Brian Ray, lora, Alexander Graf, Michal Kubeček, Rob Herring, devicetree, Steve deRosier, Mark Brown, linux-spi, Pieter ROBYNS, Hasnain Virk, linux-wpan - ML, Stefan Schmidt, Daniele Comel, shess, Xue Liu Am 12.08.2018 um 18:37 schrieb Jian-Hong Pan: > Alan Cox <gnomes@lxorguk.ukuu.org.uk> 於 2018年8月10日 週五 下午11:57寫道: >> >>> The sleep/idle/stop mitigate the unconcerned RF signals or messages. >> >> At the physical level it's irrelevant. If we are receiving then we might >> hear more things we later discard. It's not running on a tiny >> microcontroller so the extra CPU cycles are not going to kill us. > > According different power resource, LoRaWAN defines Class A, B and C. > Class A is the basic and both Class B and C devices must also > implement the feature of Class A. [...] > So, yes! Class C opens the RX windows almost all the time, except the TX time. > And uses different channel to avoid the reflection noise (*). > > However, Class C must also implements Class A and C is more complex than A. > I think starting from the simpler one and adding more features and > complexity in the future will be a better practice. Jian-Hong, you've failed to come up with any practical proposal or patch how to implement what you are saying LoRaWAN requires. Doing the impossible is never simpler! Implementing a simple back-off timer sounds doable by comparison. May I remind you, LoRa is the simpler step before LoRaWAN - if our layering is done right, someone else might choose to implement LoRaWAN in userspace based on PF_LORA. There is absolutely no reason to hardcode any LoRaWAN settings at device driver level for e.g. SX1276. >>>> How do you plan to deal with routing if you've got multiple devices ? >>> >>> For LoRaWAN, it is a star topology. >> >> No the question was much more how you plan to deal with it in the OS. If >> for example I want to open a LORA connection to something, then there >> needs to be a proper process to figure out where the target is and how to >> get traffic to them. >> >> I guess it's best phrased as >> >> - What does a struct sockaddr_lora look like > > According to LoRaWAN spec, the Data Message only has the device's > DevAddr (the device's address in 4 bytes) field related to "address". > The device just sends the uplink Data Message through the interface > and does not know the destination. Then, a LoRaWAN gateway receives > the uplink Data Message and forwards to the designated network server. > So, end device does not care about the destination. It only knows > there is a gateway will forward its message to some where. > Therefore, only the DevAddr as the source address will be meaningful > for uplink Data Message. Note that he was asking about sockaddr_lora, not LoRaWAN. The simple answer is that, inspired by CAN, it uses an ifindex to select the interface the user asked to use. That then also answers Alan's next question: This ifindex determines which interface it goes out to. sockaddr_lora was in patch 02/15, latest code here: https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/include/uapi/linux/lora.h?h=lora-next >> - How does the kernel decide which interface it goes out of (if any), and >> if it loops back > > There is the MAC Header in the Data Message which is one byte. > Bits 5 to 7 indicate which kind of type the message is. > 000: Join Request > 001: Join Accept > 010: Unconfirmed Data Up > 011: Unconfirmed Data Down > 100: Confirmed Data Up > 101: Confirmed Data Down > 110: RFU > 111: Proprietary > > So, end device only accepts the types of downlink and the matched > DevAddr (the device's address) in downlink Data Message for RX. LoRaWAN is an entirely different story, therefore my agreement that we need a separate PF_LORAWAN and sockaddr_lorawan for EUI addressing. I still think the user will need to explicitly say which interface they want to bind their socket to. AFAIU the device EUI is more comparable to an Ethernet MAC address than to an IP address that the user would configure routes for. If you have e.g. four SX1301 devices then they may be configured for different frequencies, bandwidths, etc. but unlikely for certain destination/source addresses. So either all that data comes via sockaddr (which I was discussing in the FSK/OOK part of this thread) or the user needs to make the interface choice for us. Loopback mode would require a separate virtual device driver such as fakelr or vlora. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC net-next 00/15] net: A socket API for LoRa 2018-08-12 17:59 ` Andreas Färber @ 2018-08-13 12:36 ` Alan Cox 0 siblings, 0 replies; 15+ messages in thread From: Alan Cox @ 2018-08-13 12:36 UTC (permalink / raw) To: Andreas Färber Cc: Jian-Hong Pan, netdev, linux-arm-kernel, linux-kernel, Jiri Pirko, Marcel Holtmann, David S. Miller, Matthias Brugger, Janus Piwek, Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm, Jan Jongboom, Jon Ortego, contact, Ben Whitten, Brian Ray, lora, Alexander Graf, Michal Kubeček, Rob Herring, devicetree, Steve deRosier, Mark Brown, linux-spi, Pieter ROBYNS, Hasnain Virk, linux-wpan - ML, Stefan Schmidt, Daniele Comel, shess, Xue Liu > The simple answer is that, inspired by CAN, it uses an ifindex to select > the interface the user asked to use. That then also answers Alan's next > question: This ifindex determines which interface it goes out to. > > sockaddr_lora was in patch 02/15, latest code here: > https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/include/uapi/linux/lora.h?h=lora-next And any loopback just becomes an ifindex, likewise any virtual lorawan device (eg when testing in a cloud or simulating radio properties). > I still think the user will need to explicitly say which interface they > want to bind their socket to. AFAIU the device EUI is more comparable to It does make it very hard for any vaguely complex environment because if for example you have two interfaces enumerated via USB they will appear in random order each boot. CANbus is a bit of a mess in this sense but it's so statically configured and embedded into industrial devices it's less of a problem. I just wonder if the name would be a better binding (so you can sort the order out), or a local physical identifier of some kind so that your enumeration is consistent. > Loopback mode would require a separate virtual device driver such as > fakelr or vlora. And a tunnel device, which is easy enough if you've got tap support or similar. Alan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC net-next 00/15] net: A socket API for LoRa 2018-08-09 11:59 ` Alan Cox 2018-08-09 15:02 ` Jian-Hong Pan @ 2018-08-09 15:12 ` Alexander Aring 1 sibling, 0 replies; 15+ messages in thread From: Alexander Aring @ 2018-08-09 15:12 UTC (permalink / raw) To: Alan Cox Cc: Andreas Färber, Jian-Hong Pan, netdev, linux-arm-kernel, linux-kernel, Jiri Pirko, Marcel Holtmann, David S. Miller, Matthias Brugger, Janus Piwek, Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm, Jan Jongboom, Jon Ortego, contact, Ben Whitten, Brian Ray, lora, Alexander Graf, Michal Kubeček, Rob Herring, devicetree, Steve deRosier, Mark Brown, linux-spi, Pieter Robyns, Hasnain Virk, linux-wpan, Stefan Schmidt, Daniele Comel, Sebastian Heß, Xue Liu Hi, On Thu, Aug 09, 2018 at 12:59:39PM +0100, Alan Cox wrote: > > Yes, and we are talking about that concrete sx1276 driver here, whose > > chipset has a state machine that only allows either rx or tx and also > > has standby and sleep modes with differing levels of data retention. > > It's a hardware limit, it should never influence the protocol stack > itself just the driver. Linux always tries to design to optimize the > non-crappy case. In the long term that works out best because hardware > improves and you don't want to be tied to an old limit. > > > > (Some ancient ethernet cards do this btw.. they can't listen and transmit > > > at the same time) > > > > So when do they start receiving? > > When they are not transmitting. The transmit path switches modes and when > the frame send is done it goes back to receiving. As old ethernet was > also half duplex that worked. > We do the same at some IEEE 802.15.4 transceivers. A transceiver has _one_ framebuffer only for tx and rx. Another one has two framebuffer separated tx and rx, but is half duplex. There is a little performance tweak in separated framebuffers that you can fill up the tx framebuffer while the transceiver receives the frame (completely independet from any bus communicaten/linux handling). > > The issue here was that my original description, which you appear to > > have cut, suggested a continuous listen mode, interrupted by transmit. > > I don't think I cut it but if so I didn't mean to and your approach is > the one I agree with. > ... > > There is a heirarchy. Let me us IP for an example > > (historically it was SOCK_PACKET nowdays PF_PACKET - the layering got > sorted better) > > PF_PACKET SOCK_RAW ETH_P_ALL > > Everything on that device minus some things like hardware pre-ambles > > PF_PACKET SOCK_RAW ETH_P_SOMETHING > > Everything on that device that has the underlying protocol (and the > protocol might not be in the packet but a property of the interface > because it only does that format - simple example SLIP is IP packets over > a serial link a SLIP interface is IP, not because there is anything > saying it is but because that is *all* it can be) > > You get the two above for free. PF_PACKET is built into the stack so > providing you label packets with the ETH_P_xxx you have for Lora, you can > use PF_PACKET interfaces to dump them and write raw packets at the kernel > layer. > In 802.15.4: We recommend nowadays to use PF_PACKET raw sockets for construct L2 frames in userspace. We use that mostly to connect some user space stacks to make some interop testing without hardware being involved. For DGRAM sockets, due lack of UAPI limitations of sockaddr_t we have our own implementation. DGRAM in PF_PACKET use some limitated feature to "just send something" to an unique address scheme... but some users need more access because 802.15.4 address scheme is complex. > PF_INET SOCK_RAW I think LoRa should look into the 6lowpan subsystem of the Linux kernel for that. 6lowpan is known as some "IPv6-over-foo" adaptations. Mostly you just need to implement some mapping from L2 address to SLAAC IPv6 address pattern only. I see there is a draft at 6lo wg [0] for that which is expired 2016 (But I would not care about that). At the end you have a master IP capable interface and your slave is your L2 interface. The 6lowpan interface is a RAW IP interface and do a protocol translation in the background. On L2 interface you will see L2 + 6LoWPAN + $IP_UPPER_LAYER. Current benefits are more compression, but there exists also some ndisc optimizations for low power networks which we don't support right now. - Alex [0] https://www.ietf.org/archive/id/draft-vilajosana-6lpwa-lora-hc-01.txt ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC net-next 00/15] net: A socket API for LoRa 2018-08-05 0:11 ` [RFC net-next 00/15] net: A socket API for LoRa Andreas Färber 2018-08-08 20:36 ` Alan Cox @ 2018-08-09 0:50 ` Andreas Färber 1 sibling, 0 replies; 15+ messages in thread From: Andreas Färber @ 2018-08-09 0:50 UTC (permalink / raw) To: Jian-Hong Pan Cc: netdev, linux-arm-kernel, linux-kernel, Jiri Pirko, Marcel Holtmann, David S. Miller, Matthias Brugger, Janus Piwek, Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm, Jan Jongboom, Jon Ortego, contact, Ben Whitten, Brian Ray, lora, Alexander Graf, Michal Kubeček, Rob Herring, devicetree, Steve deRosier, Mark Brown, linux-spi, Pieter Robyns, Hasnain Virk, Alan Cox, linux-wpan, Stefan Schmidt, Daniele Comel, Xue Liu, Sebastian Heß Am 05.08.2018 um 02:11 schrieb Andreas Färber: > Am 03.07.2018 um 17:11 schrieb Jian-Hong Pan: >> 2018-07-01 19:07 GMT+08:00 Andreas Färber <afaerber@suse.de>: >>> 5) Many of the modules support multiple modes, such as LoRa, LoRaWAN and FSK. >>> Lacking a LoRaWAN implementation, I am currently switching them into LoRa >>> mode at probe time wherever possible. How do we deal with that properly? [...] > Independently of what LoRaWAN does, the > user needs to be able to send on the physical layer from a selection of > LoRa, GFSK, FSK, OOK, GMSK and MSK. > Supposedly Wireless M-Bus and IEEE 802.15.4 can be implemented via those > according to the SX1276 datasheet. > > This opens a can of worms... > > SX127x has a single channel, so I don't think there should be six > network interfaces lora0, gfsk0, fsk0, ook0, gmsk0 and msk0 exposed to > the user. > Having a lora0 interface speak non-LoRa modulations may be confusing, > but since the chip is sold as LoRa transceiver it might be acceptable. > > SX130x has 8+2 channels, with IF9 dedicated to GFSK/FSK. It appears to > use one FIFO for receiving (up to 16 packets) and can only transmit one > packet at a time. So I think this should be one lora0 interface, too. > > With a view to supporting non-LoRa RF chipsets such as Si4xxx (GFSK, > FSK, OOK) or nRF905 and nRF24L01+ (both GFSK) at a later date, I don't > think those modulations should be some netlink option on a PF_LORA > interface but cleanly distinguished as ETH_P_GFSK or something. > For example, the Chistera Pi HAT has both an RFM95W and an RFM22 module. Answering myself here: MSK is a special case of FSK, and GMSK a special case of GFSK. SX1276 allows to switch between LoRa and FSK/OOK modes, and in FSK/OOK mode between FSK and OOK modulation types and for FSK modulation allows to set Gaussian filter values. I assume (G)MSK is selected indirectly through BitRate and Fdev settings or something. So we would just need ETH_P_FSK and ETH_P_OOK plus some skb fields for ETH_P_FSK. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <BY1PR02MB11147C7443AB9623D6B65798E75A0@BY1PR02MB1114.namprd02.prod.outlook.com>]
[parent not found: <e08cdcfb-207f-bd73-2afd-f775810b72b7@suse.de>]
[parent not found: <BY1PR02MB11143134B9ABAC9C9929A9C4E7530@BY1PR02MB1114.namprd02.prod.outlook.com>]
* Re: [RFC net-next 00/15] net: A socket API for LoRa [not found] ` <BY1PR02MB11143134B9ABAC9C9929A9C4E7530@BY1PR02MB1114.namprd02.prod.outlook.com> @ 2018-08-05 13:49 ` Andreas Färber 0 siblings, 0 replies; 15+ messages in thread From: Andreas Färber @ 2018-08-05 13:49 UTC (permalink / raw) To: Ben Whitten, Jian-Hong Pan Cc: netdev, linux-arm-kernel, linux-kernel, Jiri Pirko, Marcel Holtmann, David S. Miller, Matthias Brugger, Janus Piwek, Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm, Jan Jongboom, Jon Ortego, contact, Brian Ray, lora, Alexander Graf, Michal Kubeček, Hasnain Virk, Stefan Schmidt, linux-wireless, seth.forshee, Daniele Comel, linux-wpan Hi Ben and Jian-Hong, [- SPI - devicetree] Am 18.07.2018 um 13:28 schrieb Ben Whitten: >> Meanwhile my attempt to play with netlink during SUSE >> Hackweek has been >> going slow and I could use some guidance or a volunteer to >> contribute: I >> have a bare skeleton of registration, commands, attributes >> and multicast >> groups, but no plan yet how to connect that to the actual >> drivers to >> query or apply the settings... > > Happy to help, I will be starting from zero on netlink but I can contribute my existing work incorporating Marks comments for sx1301 etal. I've figured out a way to retrieve a frequency value via netlink: By passing the lora0 ifindex in as attribute, nllora can look up the net_device by index, and then via struct lora_dev_priv call into hooks that the device drivers can optionally implement. :) https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/net/lora/netlink.c?h=lora-next Tested with HIMO-01M module. The command might need an additional channel attribute for SX130x. The corresponding nltest program (using libnl-genl) is here: https://github.com/afaerber/lora-modules/blob/master/nltest.c Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2018-08-13 15:19 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20180701110804.32415-1-afaerber@suse.de> [not found] ` <CAC=mGzgUCopz2xTOA0R-WD8a1DOaOOUn=YpfdMiJ33y3hnh6kg@mail.gmail.com> 2018-08-05 0:11 ` [RFC net-next 00/15] net: A socket API for LoRa Andreas Färber 2018-08-08 20:36 ` Alan Cox 2018-08-08 22:42 ` Andreas Färber 2018-08-09 11:59 ` Alan Cox 2018-08-09 15:02 ` Jian-Hong Pan 2018-08-09 15:21 ` Alexander Aring 2018-08-10 15:57 ` Alan Cox 2018-08-11 18:30 ` Stefan Schmidt 2018-08-12 16:49 ` Andreas Färber 2018-08-12 16:37 ` Jian-Hong Pan 2018-08-12 17:59 ` Andreas Färber 2018-08-13 12:36 ` Alan Cox 2018-08-09 15:12 ` Alexander Aring 2018-08-09 0:50 ` Andreas Färber [not found] ` <BY1PR02MB11147C7443AB9623D6B65798E75A0@BY1PR02MB1114.namprd02.prod.outlook.com> [not found] ` <e08cdcfb-207f-bd73-2afd-f775810b72b7@suse.de> [not found] ` <BY1PR02MB11143134B9ABAC9C9929A9C4E7530@BY1PR02MB1114.namprd02.prod.outlook.com> 2018-08-05 13:49 ` Andreas Färber
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).