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 0B6B7C46464 for ; Sun, 12 Aug 2018 18:00:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8A2462199D for ; Sun, 12 Aug 2018 18:00:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8A2462199D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de 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 S1727979AbeHLUik (ORCPT ); Sun, 12 Aug 2018 16:38:40 -0400 Received: from mx2.suse.de ([195.135.220.15]:55558 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727758AbeHLUij (ORCPT ); Sun, 12 Aug 2018 16:38:39 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 4A8C8AD1E; Sun, 12 Aug 2018 17:59:47 +0000 (UTC) Subject: Re: [RFC net-next 00/15] net: A socket API for LoRa To: Jian-Hong Pan , Alan Cox Cc: 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 , =?UTF-8?Q?Michael_R=c3=b6der?= , Dollar Chen , Ken Yu , =?UTF-8?Q?Konstantin_B=c3=b6hm?= , Jan Jongboom , Jon Ortego , "contact@snootlab.com" , Ben Whitten , Brian Ray , lora@globalsat.com.tw, Alexander Graf , =?UTF-8?Q?Michal_Kube=c4=8dek?= , Rob Herring , devicetree@vger.kernel.org, Steve deRosier , Mark Brown , linux-spi@vger.kernel.org, Pieter ROBYNS , Hasnain Virk , linux-wpan - ML , Stefan Schmidt , Daniele Comel , shess@hessware.de, Xue Liu References: <20180701110804.32415-1-afaerber@suse.de> <92ee4016-1da9-826b-3674-b2d604a64848@suse.de> <20180808213640.10a1d76f@alans-desktop> <20180809125939.39ac2cc9@alans-desktop> <20180810165711.59bf26f7@alans-desktop> From: =?UTF-8?Q?Andreas_F=c3=a4rber?= Openpgp: preference=signencrypt Autocrypt: addr=afaerber@suse.de; prefer-encrypt=mutual; keydata= xsFNBE6W6ZQBEAC/BIukDnkVenIkK9O14UucicBIVvRB5WSMHC23msS+R2h915mW7/vXfn+V 0nrr5ECmEg/5OjujKf0x/uhJYrsxcp45nDyYCk+RYoOJmGzzUFya1GvT/c04coZ8VmgFUWGE vCfhHJro85dZUL99IoLP21VXEVlCPyIngSstikeuf14SY17LPTN1aIpGQDI2Qt8HHY1zOVWv iz53aiFLFeIVhQlBmOABH2Ifr2M9loRC9yOyGcE2GhlzgyHGlQxEVGFn/QptX6iYbtaTBTU0 c72rpmbe1Nec6hWuzSwu2uE8lF+HYcYi+22ml1XBHNMBeAdSEbSfDbwc///8QKtckUzbDvME S8j4KuqQhwvYkSg7dV9rs53WmjO2Wd4eygkC3tBhPM5s38/6CVGl3ABiWJs3kB08asUNy8Wk juusU/nRJbXDzxu1d+hv0d+s5NOBy/5+7Pa6HeyBnh1tUmCs5/f1D/cJnuzzYwAmZTHFUsfQ ygGBRRKpAVu0VxCFNPSYKW0ULi5eZV6bcj+NAhtafGsWcv8WPFXgVE8s2YU38D1VtlBvCo5/ 0MPtQORqAQ/Itag1EHHtnfuK3MBtA0fNxQbb2jha+/oMAi5hKpmB/zAlFoRtYHwjFPFldHfv Iljpe1S0rDASaF9NsQPfUBEm7dA5UUkyvvi00HZ3e7/uyBGb0QARAQABzSJBbmRyZWFzIEbD pHJiZXIgPGFmYWVyYmVyQHN1c2UuZGU+wsF7BBMBAgAlAhsDBgsJCAcDAgYVCAIJCgsEFgID AQIeAQIXgAUCTqGJnQIZAQAKCRD6LtEtPn4BPzetD/4rF6k/HF+9U9KqykfJaWdUHJvXpI85 Roab12rQbiIrL4hVEYKrYwPEKpCf+FthXpgOq+JdTGJ831DMlTx7Ed5/QJ9KAAQuhZlSNjSc +FNobJm7EbFv9jWFjQC0JcOl17Ji1ikgRcIRDCul1nQh9jCdfh1b848GerZmzteNdT9afRJm 7rrvMqXs1Y52/dTlfIW0ygMA2n5Vv3EwykXJOPF6fRimkErKO84sFMNg0eJV9mXs+Zyionfi g2sZJfVeKjkDqjxy7sDDBZZR68I9HWq5VJQrXqQkCZUvtr6TBLI+uiDLbGRUDNxA3wgjVdS2 v9bhjYceSOHpKU+h3H2S8ju9rjhOADT2F5lUQMTSpjlzglh8IatV5rXLGkXEyum4MzMo2sCE Cr+GD6i2M3pHCtaIVV3xV0nRGALa6DdF7jBWqM54KHaKsE883kFH2+6ARcPCPrnPm7LX98h2 4VpG984ysoq6fpzHHG/KCaYCEOe1bpr3Plmmp3sqj0utA6lwzJy0hj5dqug+lqmg7QKAnxl+ porgluoY56U0X0PIVBc0yO0dWqRxtylJa9kDX/TKwFYNVddMn2NQNjOJXzx2H9hf0We7rG7+ F/vgwALVVYbiTzvp2L0XATTv/oX4BHagAa/Qc3dIsBYJH+KVhBp+ZX4uguxk4xlc2hm75b1s cqeAD87BTQROlumUARAAzd7eu+tw/52FB7xQZWDv5aF+6CAkoz7AuY4s1fo0AQQDqjLOdpQF bifdH7B8SnsA4eo0syfs+1tZW6nn9hdy1GHEMbeuvdhNwkhEfYGDYpSue7oVxB4jajKvRHAP VcewKZIxvIiZ5aSp5n1Bd7B0c0C443DHiWE/0XWSpvbU7fTzTNvdz+2OZmGtqCn610gBqScv 1BOiP3OfLly8ghxcJsos23c0mkB/1iWlzh3UMFIGrzsK3sZJ/3uRaLYFimmqqPlSwFqx3b0M 1gFdHWKfOpvQ4wwP5P10xwvqNXLWC30wB1QmJGD/X8aAoVNnGsmEL7GcWF4cLoOSRidSoccz znShE+Ap+FVDD6MRyesNT4D67l792//B38CGJRdELtNacdwazaFgxH9O85Vnd70ZC7fIcwzG yg/4ZEf96DlAvrSOnu/kgklofEYdzpZmW+Fqas6cnk6ZaHa35uHuBPesdE13MVz5TeiHGQTW xP1jbgWQJGPvJZ+htERT8SZGBQRb1paoRd1KWQ1mlr3CQvXtfA/daq8p/wL48sXrKNwedrLV iZOeJOFwfpJgsFU4xLoO/8N0RNFsnelBgWgZE3ZEctEd4BsWFUw+czYCPYfqOcJ556QUGA9y DeDcxSitpYrNIvpk4C5CHbvskVLKPIUVXxTNl8hAGo1Ahm1VbNkYlocAEQEAAcLBXwQYAQIA CQUCTpbplAIbDAAKCRD6LtEtPn4BPzA6D/9TbSBOPM99SHPX9JiEQAw4ITCBF2oTWeZQ6RJg RKpB15lzyPfyFbNSceJp9dCiwDWe+pzKaX6KYOFZ5+YTS0Ph2eCR+uT2l6Mt6esAun8dvER/ xlPDW7p88dwGUcV8mHEukWdurSEDTj8V3K29vpgvIgRq2lHCn2wqRQBGpiJAt72Vg0HxUlwN GAJNvhpeW8Yb43Ek7lWExkUgOfNsDCTvDInF8JTFtEXMnUcPxC0d/GdAuvBilL9SlmzvoDIZ 5k2k456bkY3+3/ydDvKU5WIgThydyCEQUHlmE6RdA3C1ccIrIvKjVEwSH27Pzy5jKQ78qnhv dtLLAavOXyBJnOGlNDOpOyBXfv02x91RoRiyrSIM7dKmMEINKQlAMgB/UU/6B+mvzosbs5d3 4FPzBLuuRz9WYzXmnC460m2gaEVk1GjpidBWw0yY6kgnAM3KhwCFSecqUQCvwKFDGSXDDbCr w08b3GDk40UoCoUq9xrGfhlf05TUSFTg2NlSrK7+wAEsTUgs2ZYLpHyEeftoDDnKpM4ghs/O ceCeyZUP1zSgRSjgITQp691Uli5Nd1mIzaaM8RjOE/Rw67FwgblKR6HAhSy/LYw1HVOu+Ees RAEdbtRt37A8brlb/ENxbLd9SGC8/j20FQjit7oPNMkTJDs7Uo2eb7WxOt5pSTVVqZkv7Q== Organization: SUSE Linux GmbH Message-ID: <11276f7d-0175-05e9-a9bd-c72868067081@suse.de> Date: Sun, 12 Aug 2018 19:59:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 12.08.2018 um 18:37 schrieb Jian-Hong Pan: > Alan Cox 於 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)