Notes on ath79 RouterBoard 493G image
I have some feedback about the ATH79 RouterBoard 493G image built from master, as documented at: https://github.com/openwrt/openwrt/pull/3026 First, I was unable to update to the sysupgrade image at: https://downloads.openwrt.org/snapshots/targets/ath79/mikrotik/openwrt-ath79-mikrotik-mikrotik_routerboard-493g-squashfs-sysupgrade.bin while running 19.07.2, although the initial comments on the pull request above indicate this is possible. I fixed this by untarring the sysupgrade image, renaming its top-level directory from sysupgrade-mikrotik_routerboard-rb493g/ to sysupgrade-routerboard/, and retarring the sysupgrade image. I suspect something changed between the time of the intial pull request comment and the eventual merge. Is there a better way of doing this? DHCP/TFTP booting the ATH79 image directly fails; I suspect this is due to the size of the image (see the related comments throught the merge request referenced above). Second, the boot process fails as follows after performing the sysupgrade: [2.117395] UBI: auto-attach mtd2 [2.120802] ubi0: attaching mtd2 [3.260133] ubi0: scanning is finished [3.326963] ubi0 error: ubi_read_volume_table: not enough PEBs, required 970, available 958 [3.335627] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd2, error -28 [3.342742] UBI error: cannot attach mtd2 [3.347369] /dev/root: Can't open blockdev [3.351531] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6 [3.358996] Please append a correct "root=" boot option; here are the available partitions: [3.367344] 1f00 256 mtdblock0 [3.367347] (driver?) [3.373884] 1f018192 mtdblock1 [3.373886] (driver?) [3.380420] 1f02 122624 mtdblock2 [3.380422] (driver?) [3.386951] 1f03 64 mtdblock3 [3.386953] (driver?) [3.393486] 1f04 44 mtdblock4 [3.393488] (driver?) [3.400024] 1f05 4 mtdblock5 [3.400026] (driver?) [3.406554] 1f06 4 mtdblock6 [3.406557] (driver?) [3.413089] 1f07 8 mtdblock7 [3.413091] (driver?) [3.419620] 1f08 4 mtdblock8 [3.419623] (driver?) [3.426155] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [3.434403] Rebooting in 1 seconds.. I am not sure what causes this. -- Mike :wq ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 20.XX
On 31.07.20 21:49, Stefan Lippers-Hollmann wrote: I don't think this is going to happen for a 20.xy.0 release, basically there are only two platforms for this on the horizon at the moment: I am holding my patches back on purpose to not interfere with the release. AX will be a post 20.x thing John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 20.XX
Hi [Disclaimer: I'm not an OpenWrt developer] On 2020-07-31, bapti...@bitsofnetworks.org wrote: [...] > Possibly missing goals are: > > 1) major feature: 802.11ax and ath11k support? > >I don't know the current state of this. I don't think this is going to happen for a 20.xy.0 release, basically there are only two platforms for this on the horizon at the moment: - QCA ipq807x/ ath11k: so far ath11k is exclusively available for the ipq807x SOC family (dedicated PCIe/ m.2 cards have just appeared on the market, PCIe support for ath11k is not completely merged upstream yet), but while basic -incomplete- target support already exists in master, not a single device is supported at this point (missing parts, PCIe, ethernet, ath11k technically also isn't available in master so far). While there is quite some interest and activity around this target, predominantly around the Xiaomi AX3600, I don't think this will make it soon (enough) for a 20.xy.0 stable release - not ruling it out completely, but a lot would have to happen in short time. - Mediatek mt7915e 802.11ax wireless The first devices of this kind appear to favour the older mips based mt7621a SOC, so support for these could appear quite quickly - depending on the current state of mt7615e support in the mt76 driver (it's still very new/ under development, no idea how far that has been developed at this point), but so far none of these routers/ APs is support by OpenWrt yet (and I'm not aware of any pending pull requests adding support for these either). A more natural (faster) combination would be the mt7622 ARMv8 SOC, but this is also a rather new target with few supported devices whose practical support is also just shaping up (none of those come with mt7915e WLAN at this moment either). So far I haven't seen any mt7622a+mt7915e on the market (nor any announcements) yet. Both 802.11ax contenders will probably have to wait for a 21.xy.0, even though ipq807x might be close. [...] > 3) organisational: switch to gitlab? > >While there was a vote about it, I don't know if this is planned >for 20.XX. I think it makes sense: we could start using gitlab to >track 20.XX bug reports, and possibly drop 18.06 bug reports from >flyspray. But if it is not ready, it should probably not block the >20.XX release. This has imho no direct relation to the release, it's mostly invisible behind the curtain for the ordinary user - their interaction with the git repositories is close to zero, bugs are only filed at bugs.openwrt.org anyways, the binary repos pushed from downloads.openwrt.org and the canonical location of the git repos is git.openwrt.org (github is just a mirror and the package feeds are a different question alltogether). This migration to gitlab can happen at any point and doesn't need to be tied to a release. Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Simplified LuCI interface project: dashboard, quick setup, configuration
Hi On 2020-07-31, bapti...@bitsofnetworks.org wrote: > On 31-07-20, Henrique de Moraes Holschuh wrote: > > > As there has been no negative feedback about this, we will move to > > > configure the same SSID for 2.4 GHz and 5 GHz in the quick setup. > > > This will simplify the user experience. > > > > We have never tested it, but we did notice vendors nowadays, as well as the > > *large* ISPs witht their own CPEs and firmware, append _2G and _5G (or do > > something to that effect) to the default SSID. > > I noticed that too. Do you know why they do this? Personally my observation, especially with higher priced devices, is to the contrary. In my experience modern (highend 802.11ac/ 802.11ax) devices typically push[0] a single SSID/ network covering both bands, often with band-steering enabled; especially for devices touting the "mesh" mantra. Semi-modern mobile devices (e.g. android[1]) are also quite good at choosing the best band/ channel for their current needs, sticky clients should be less of a problem these days. The only potential reason to separate both networks for the common user would be broken-by-design IoT devices, which sometimes do fall over this (it's totally beyond imagination why these would care about the SSID of a 5 GHz network they don't even use/ see, but it happens). Obviously the option to configure this as needed must be available, but imho not necessarily for the simplified/ easy setup assistant (as long as full luci is easily available - and considering that the easy overview doesn't get confused by this). Regards Stefan Lippers-Hollmann [0] push := default and strongly suggested by the OEM firmware, but usually (not always) still offering both. [1] at least android 7 or newer ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Simplified LuCI interface project: dashboard, quick setup, configuration
On 31/07/2020 12:42, bapti...@bitsofnetworks.org wrote: On 31-07-20, Henrique de Moraes Holschuh wrote: As there has been no negative feedback about this, we will move to configure the same SSID for 2.4 GHz and 5 GHz in the quick setup. This will simplify the user experience. We have never tested it, but we did notice vendors nowadays, as well as the *large* ISPs witht their own CPEs and firmware, append _2G and _5G (or do something to that effect) to the default SSID. I noticed that too. Do you know why they do this? It causes less support calls, that would be my best bet. If you want a device to be able to connect to both networks (e.g. your phone), you have to type the same password twice. It seems cumbersome. Yes. But nowadays there is the QR code to configure the radios, so... As always, keep in mind that this should match the common needs of casual users: advanced users can always go to the current Wireless menu. It can also be argued that casual users are better off with two networks they can trivially use for separate things. Videogames and Smart TVs on 5G, cellphones and tablets on 2G. Ok, this is a good use-case. In general, having more control from the device side is good, but it brings more complexity. This is not a "special use case", you'll find lots of friends telling their friends to do it that way, etc. So these "casual users" know about the two radios and their difference with respect to range and throughput? I'm a bit surprised. Range and throughput are something they can "feel" from how the device behaves, and learn interactively. As long as they know there are two choices, that is. If I sum up, the three options so far are: [1] configure the same SSID on all radios [2] configure a different SSID on every radio [3] leave this choice to the user I would like to avoid option [3] for the reason above, but if half of the people need [1] and the other half need [2], then we need [3]. I can't give you strong reasons for which the default should be. What I do know is that vendors, when they can, use a "wizard" flow for first-setup and easy-setup, *as well as* a "basic" config view, and an "advanced" config view. On the wizard I'd not ask at all, and just do one of the two possible defaults consistently. On the basic config view, I'd let the user change it by having a separate area for each radio (with enable/disable, name/ssid and the PSK password) that is pre-filled with whichever default you prefer. -- Henrique de Moraes Holschuh ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Simplified LuCI interface project: dashboard, quick setup, configuration
On 31-07-20, Henrique de Moraes Holschuh wrote: > > As there has been no negative feedback about this, we will move to > > configure the same SSID for 2.4 GHz and 5 GHz in the quick setup. > > This will simplify the user experience. > > We have never tested it, but we did notice vendors nowadays, as well as the > *large* ISPs witht their own CPEs and firmware, append _2G and _5G (or do > something to that effect) to the default SSID. I noticed that too. Do you know why they do this? If you want a device to be able to connect to both networks (e.g. your phone), you have to type the same password twice. It seems cumbersome. > > > As always, keep in mind that this should match the common needs of casual > > > users: advanced users can always go to the current Wireless menu. > > It can also be argued that casual users are better off with two networks > they can trivially use for separate things. Videogames and Smart TVs on 5G, > cellphones and tablets on 2G. Ok, this is a good use-case. In general, having more control from the device side is good, but it brings more complexity. > This is not a "special use case", you'll find lots of friends telling their > friends to do it that way, etc. So these "casual users" know about the two radios and their difference with respect to range and throughput? I'm a bit surprised. > IMHO, you could do it this way and still keep it very simple: > > > Network Name (also knonw as SSID): > [ ] assign different names for each radio > > Then you'd get all radios with SSID "" > > > Network Name (also knonw as SSID): > [X] assign different names for each radio > > Then you'd get _2G, _5G, and on APs with many radios, _5G2, etc. > > Nice and simple. No need for a [x] that triggers an UCI form change that > asks for separate SSIDs (although *that* would work as well). It's close to the current UI (see https://openwrt.org/docs/guide-user/luci/quick_setup ), although it doesn't offer a choice: it merely informs the user that the second radio will have a slightly difference SSID. Some users are lost when they are faced with a choice they don't understand. If we go this way, it would need some UX efforts to convey that "it's really optional, no worries if you don't understand". If I sum up, the three options so far are: [1] configure the same SSID on all radios [2] configure a different SSID on every radio [3] leave this choice to the user I would like to avoid option [3] for the reason above, but if half of the people need [1] and the other half need [2], then we need [3]. Thanks, Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Simplified LuCI interface project: dashboard, quick setup, configuration
On 31/07/2020 07:30, Baptiste Jonglez wrote: On 18-07-20, Baptiste Jonglez wrote: - quick setup: https://github.com/openwrt/luci/pull/4141 - configuration: https://github.com/openwrt/luci/pull/4186 This needs more discussion and feedback. There is one interesting question (on the github pull request): should the quick setup configure the same SSID for 2.4 GHz and 5 GHz, or two different SSID? I remember that some clients had trouble switching between channels if the same SSID is used, which is why I pushed for two different SSID. Does anybody has current experience with this? As there has been no negative feedback about this, we will move to configure the same SSID for 2.4 GHz and 5 GHz in the quick setup. This will simplify the user experience. We have never tested it, but we did notice vendors nowadays, as well as the *large* ISPs witht their own CPEs and firmware, append _2G and _5G (or do something to that effect) to the default SSID. As always, keep in mind that this should match the common needs of casual users: advanced users can always go to the current Wireless menu. It can also be argued that casual users are better off with two networks they can trivially use for separate things. Videogames and Smart TVs on 5G, cellphones and tablets on 2G. This is not a "special use case", you'll find lots of friends telling their friends to do it that way, etc. IMHO, you could do it this way and still keep it very simple: Network Name (also knonw as SSID): [ ] assign different names for each radio Then you'd get all radios with SSID "" Network Name (also knonw as SSID): [X] assign different names for each radio Then you'd get _2G, _5G, and on APs with many radios, _5G2, etc. Nice and simple. No need for a [x] that triggers an UCI form change that asks for separate SSIDs (although *that* would work as well). -- Henrique de Moraes Holschuh ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 20.XX
On Fri, Jul 31, 2020 at 01:37:00PM +0200, bapti...@bitsofnetworks.org wrote: > 3) organisational: switch to gitlab? > >While there was a vote about it, Hi, do you happen to have a link to that discussion/vote? >I don't know if this is planned for 20.XX. I think it makes sense: >we could start using gitlab to track 20.XX bug reports, and >possibly drop 18.06 bug reports from flyspray. But if it is not >ready, it should probably not block the 20.XX release. I would encourage delaying such a move. My reason is that although Gitlab is free as in freedom (good!), it does rely on client-side JavaScript for much of the functionality of its web pages (bad!). (By "the functionality in its web pages", I mean as opposed to, say, the functionality exposed through its API.) This means that any visitor/developer who needs to interact with a Gitlab instance via its webpages is forced to increase their attack surface by enabling JavaScript in their browser. This in turn means that if the server running the Gitlab instance gets compromised by an attacker, then the attacker would be able to pivot to visitors/developers' workstations or laptops by serving JavaScript-based malware. This might in principle allow the attacker to e.g.: - steal the visitor's/developer's private keys if present in the cache or RAM of that person's PC;[1] or - gain privileged code execution on that person's PC,[2] allowing for installation of a remote access tool (RAT) and consequent ability to exfiltrate private keys or otherwise masquerade as the PC's owner. Clearly, such an attack if carried out would have serious implications for the future integrity of OpenWRT. Such malware, especially if it exploits unfixable hardware vulnerabilities in client CPUs (e.g. Spectre, Meltdown, etc) can be protected against by disabling JavaScript in one's web-browser. But although this protection works well when visiting the *current* OpenWRT websites (wiki, bug tracker, etc), it would *NOT* be viable if OpenWRT switches to Gitlab. (This is because of Gitlab's reliance on client-side JavaScript, as mentioned earlier.) Sadly, this is not only theoretical. Attacks along roughly these lines are known to have been conducted in the past, in order to insert vulnerabilities into networks and codebases.[3] OpenWRT is widely used, especially by people who value security and therefore choose it over proprietary alternatives. Consequently, it is a "target-rich environment". For this reason, I would urge the OpenWRT devs *not* to switch to any web-based software that requires visitors to browse with JavaScript enabled. All best, Sam [1] "Research showed that microarchitectural attacks like cache attacks can be performed through websites using JavaScript. ... However, the W3C and browser vendors responded to this significant threat by eliminating fine-grained timers from JavaScript. ... We demonstrate the inefficacy of this mitigation by finding and evaluating a wide range of new sources of timing information. We develop measurement methods that exceed the resolution of official timing sources by 3 to 4 orders of magnitude on all major browsers, and even more on Tor browser. Our timing measurements do not only re-enable previous attacks to their full extent but also allow implementing new attacks." https://gruss.cc/files/fantastictimers.pdf [2] "side-channel attacks allow to detect the exact location of kernel data structures or derandomize ASLR in JavaScript. A combination of a software bug and the knowledge of these addresses can lead to privileged code execution." https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-lipp.pdf "We demonstrate a fully automated attack that requires nothing but a website with JavaScript to trigger faults on remote hardware. Thereby we can gain unrestricted access to systems of website visitors. We show that the attack works on off-the-shelf systems. Existing countermeasures fail to protect against this new Rowhammer attack." https://link.springer.com/chapter/10.1007%2F978-3-319-40667-1_15 [3] https://theintercept.com/2014/03/20/inside-nsa-secret-efforts-hunt-hack-system-administrators/ https://theintercept.com/document/2014/03/20/hunt-sys-admins/ https://theintercept.com/2014/03/12/nsa-plans-infect-millions-computers-malware/ -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: add missing config symbol
Hi, > Signed-off-by: Stijn Tintel Acked-by: Jo-Philipp Wich signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH V2 uhttpd] ubus: add new RESTful API
On 7/31/20 1:49 AM, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> Initial uhttpd ubus API was fully based on JSON-RPC. That restricted it
> from supporting ubus notifications that don't fit its model.
>
> Notifications require protocol that allows server to send data without
> being polled. There are two candidates for that:
> 1. Server-sent events
I did a quick and dirty implementation of it some time ago, that works
with everything as it is.
You might want to check it out.
https://bugs.openwrt.org/index.php?do=details_id=2248
Still, eager to see this work done!
> 2. WebSocket
>
> The later one is overcomplex for this simple task so ideally uhttps ubus
> should support text-based server-sent events. It's not possible with
> JSON-RPC without violating it. Specification requires server to reply
> with Response object. Replying with text/event-stream is not allowed.
>
> All above led to designing new API that:
> 1. Uses GET and POST requests
> 2. Makes use of RESTful URLs
> 3. Uses JSON-RPC in cleaner form and only for calling ubus methods
>
> This new API allows:
> 1. Listing all ubus objects and their methods using GET /list
> 2. Listing object methods using GET /list/
> 3. Listening to object notifications with GET /subscribe/
> 4. Calling ubus methods using POST /call/
>
> JSON-RPC custom protocol was also simplified to:
> 1. Use "method" member for ubus object method name
>It was possible thanks to using RESTful URLs. Previously "method"
>had to be "list" or "call".
> 2. Reply with Error object on ubus method call error
>This simplified "result" member format as it doesn't need to contain
>ubus result code anymore.
>
> This patch doesn't break or change the old API. The biggest downside of
> the new API is no support for batch requests. It's cost of using RESTful
> URLs. It should not matter much as uhttpd supports keep alive.
>
> Example usages:
>
> 1. Getting all objects and their methods:
> $ curl http://192.168.1.1/ubus/list
> {
> "dhcp": {
> "ipv4leases": {
>
> },
> "ipv6leases": {
>
> }
> },
> "log": {
> "read": {
> "lines": "number",
> "stream": "boolean",
> "oneshot": "boolean"
> },
> "write": {
> "event": "string"
> }
> }
> }
>
> 2. Getting object methods:
> $ curl http://192.168.1.1/ubus/list/log
> {
> "read": {
> "lines": "number",
> "stream": "boolean",
> "oneshot": "boolean"
> },
> "write": {
> "event": "string"
> }
> }
>
> 3. Subscribing to notifications:
> $ curl http://192.168.1.1/ubus/subscribe/foo
> event: status
> data: {"count":5}
>
> 4. Calling ubus object method:
> $ curl -d '{
> "jsonrpc": "2.0",
> "id": 1,
> "method": "login",
> "params": {"username": "root", "password": "password" }
> }' http://192.168.1.1/ubus/call/session
> {
> "jsonrpc": "2.0",
> "id": 1,
> "result": {
> "ubus_rpc_session": "01234567890123456789012345678901",
> (...)
> }
> }
>
> $ curl -H 'Authorization: Bearer 01234567890123456789012345678901' -d '{
> "jsonrpc": "2.0",
> "id": 1,
> "method": "write",
> "params": {"event": "Hello world" }
> }' http://192.168.1.1/ubus/call/log
> {
> "jsonrpc": "2.0",
> "id": 1,
> "result": null
> }
>
> Signed-off-by: Rafał Miłecki
> ---
> V2: Use "Authorization" with Bearer for rpcd session id / token
> Treat missing session id as UH_UBUS_DEFAULT_SID
> Fix "result" format (was: "result":{{"foo":"bar"}})
> ---
> main.c | 8 +-
> ubus.c | 326 +++
> uhttpd.h | 5 +
> 3 files changed, 318 insertions(+), 21 deletions(-)
>
> diff --git a/main.c b/main.c
> index 26e74ec..73e3d42 100644
> --- a/main.c
> +++ b/main.c
> @@ -159,6 +159,7 @@ static int usage(const char *name)
> " -U file Override ubus socket path\n"
> " -a Do not authenticate JSON-RPC requests
> against UBUS session api\n"
> " -X Enable CORS HTTP headers on JSON-RPC
> api\n"
> + " -e Events subscription reconnection time
> (retry value)\n"
> #endif
> " -x string URL prefix for CGI handler, default is
> '/cgi-bin'\n"
> " -y alias[=path] URL alias handle\n"
> @@ -262,7 +263,7 @@ int main(int argc, char **argv)
> init_defaults_pre();
> signal(SIGPIPE, SIG_IGN);
>
> - while ((ch = getopt(argc, argv,
> "A:aC:c:Dd:E:fh:H:I:i:K:k:L:l:m:N:n:P:p:qRr:Ss:T:t:U:u:Xx:y:")) != -1) {
> + while ((ch = getopt(argc, argv,
> "A:aC:c:Dd:E:e:fh:H:I:i:K:k:L:l:m:N:n:P:p:qRr:Ss:T:t:U:u:Xx:y:")) != -1) {
> switch(ch) {
> #ifdef
RE: Release goals for 20.XX
> 3) organisational: switch to gitlab? > >While there was a vote about it, I don't know if this is planned >for 20.XX. I think it makes sense: we could start using gitlab to >track 20.XX bug reports, and possibly drop 18.06 bug reports from >flyspray. But if it is not ready, it should probably not block the >20.XX release. I personally don't think we should link this to the release. Best Adrian openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Release goals for 20.XX
Hi, Following the experiment with 19.07.4 release goals [1], here is a set of release goals for the next 20.XX major release: https://openwrt.org/docs/guide-developer/releases/goals/20.xx This is mostly based on the meeting notes of the last dev meeting posted by Hauke, as well as various discussions. According to my understanding, all the release goals above have reached consensus or a vote to be included in 20.XX. Please adjust / discuss if this is not the case. Some goals need references. Possibly missing goals are: 1) major feature: 802.11ax and ath11k support? I don't know the current state of this. 2) major feature: 802.11ad / 60 GHz support? Again, I haven't followed progress here. 3) organisational: switch to gitlab? While there was a vote about it, I don't know if this is planned for 20.XX. I think it makes sense: we could start using gitlab to track 20.XX bug reports, and possibly drop 18.06 bug reports from flyspray. But if it is not ready, it should probably not block the 20.XX release. Baptiste [1] https://openwrt.org/docs/guide-developer/releases/goals/19.07.4 signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
HW-Donation: Raidsonic IB-NAS-4220-B
Hi there! I want to donate a working Raidsonic IB-NAS-4220-B to an interested OpenWRT developer for free (included shipping). The first one who sends me an email to he...@nachtwindheim.de with an address will get it. Greets! Henne ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH V2 uhttpd] ubus: add new RESTful API
Hi Rafel,
this is really great stuff. It would help me to get forward with my wifi
controller.
Could it be possible to subsribe to multiple sources to limit the connections
to ubus?
2 SSIDs with 2.4 ad 5GHz would me 4 concurrent channels if I understand right.
Kind regards,
André
Am 31.07.20 um 06:49 schrieb Rafał Miłecki:
> From: Rafał Miłecki
>
> Initial uhttpd ubus API was fully based on JSON-RPC. That restricted it
> from supporting ubus notifications that don't fit its model.
>
> Notifications require protocol that allows server to send data without
> being polled. There are two candidates for that:
> 1. Server-sent events
> 2. WebSocket
>
> The later one is overcomplex for this simple task so ideally uhttps ubus
> should support text-based server-sent events. It's not possible with
> JSON-RPC without violating it. Specification requires server to reply
> with Response object. Replying with text/event-stream is not allowed.
>
> All above led to designing new API that:
> 1. Uses GET and POST requests
> 2. Makes use of RESTful URLs
> 3. Uses JSON-RPC in cleaner form and only for calling ubus methods
>
> This new API allows:
> 1. Listing all ubus objects and their methods using GET /list
> 2. Listing object methods using GET /list/
> 3. Listening to object notifications with GET /subscribe/
> 4. Calling ubus methods using POST /call/
>
> JSON-RPC custom protocol was also simplified to:
> 1. Use "method" member for ubus object method name
>It was possible thanks to using RESTful URLs. Previously "method"
>had to be "list" or "call".
> 2. Reply with Error object on ubus method call error
>This simplified "result" member format as it doesn't need to contain
>ubus result code anymore.
>
> This patch doesn't break or change the old API. The biggest downside of
> the new API is no support for batch requests. It's cost of using RESTful
> URLs. It should not matter much as uhttpd supports keep alive.
>
> Example usages:
>
> 1. Getting all objects and their methods:
> $ curl http://192.168.1.1/ubus/list
> {
> "dhcp": {
> "ipv4leases": {
>
> },
> "ipv6leases": {
>
> }
> },
> "log": {
> "read": {
> "lines": "number",
> "stream": "boolean",
> "oneshot": "boolean"
> },
> "write": {
> "event": "string"
> }
> }
> }
>
> 2. Getting object methods:
> $ curl http://192.168.1.1/ubus/list/log
> {
> "read": {
> "lines": "number",
> "stream": "boolean",
> "oneshot": "boolean"
> },
> "write": {
> "event": "string"
> }
> }
>
> 3. Subscribing to notifications:
> $ curl http://192.168.1.1/ubus/subscribe/foo
> event: status
> data: {"count":5}
>
> 4. Calling ubus object method:
> $ curl -d '{
> "jsonrpc": "2.0",
> "id": 1,
> "method": "login",
> "params": {"username": "root", "password": "password" }
> }' http://192.168.1.1/ubus/call/session
> {
> "jsonrpc": "2.0",
> "id": 1,
> "result": {
> "ubus_rpc_session": "01234567890123456789012345678901",
> (...)
> }
> }
>
> $ curl -H 'Authorization: Bearer 01234567890123456789012345678901' -d '{
> "jsonrpc": "2.0",
> "id": 1,
> "method": "write",
> "params": {"event": "Hello world" }
> }' http://192.168.1.1/ubus/call/log
> {
> "jsonrpc": "2.0",
> "id": 1,
> "result": null
> }
>
> Signed-off-by: Rafał Miłecki
> ---
> V2: Use "Authorization" with Bearer for rpcd session id / token
> Treat missing session id as UH_UBUS_DEFAULT_SID
> Fix "result" format (was: "result":{{"foo":"bar"}})
> ---
> main.c | 8 +-
> ubus.c | 326 +++
> uhttpd.h | 5 +
> 3 files changed, 318 insertions(+), 21 deletions(-)
>
> diff --git a/main.c b/main.c
> index 26e74ec..73e3d42 100644
> --- a/main.c
> +++ b/main.c
> @@ -159,6 +159,7 @@ static int usage(const char *name)
> " -U file Override ubus socket path\n"
> " -a Do not authenticate JSON-RPC requests
> against UBUS session api\n"
> " -X Enable CORS HTTP headers on JSON-RPC
> api\n"
> + " -e Events subscription reconnection time
> (retry value)\n"
> #endif
> " -x string URL prefix for CGI handler, default is
> '/cgi-bin'\n"
> " -y alias[=path] URL alias handle\n"
> @@ -262,7 +263,7 @@ int main(int argc, char **argv)
> init_defaults_pre();
> signal(SIGPIPE, SIG_IGN);
>
> - while ((ch = getopt(argc, argv,
> "A:aC:c:Dd:E:fh:H:I:i:K:k:L:l:m:N:n:P:p:qRr:Ss:T:t:U:u:Xx:y:")) != -1) {
> + while ((ch = getopt(argc, argv,
>
compat-version for mt7621
Hi, I just finally merged my compat-version patchset to master. This already takes care of bumping the compat-version for the kirkwood/mvebu devices affected by the DSA introduction. However, the biggest swap (based on number of devices) from swconfig to DSA has been done for ramips/mt7621. Since the entire subtarget is affected here, we essentially have two options how two address this, which I'd like to discuss. Generally, increasing the compat-version needs two changes: 1. adding the following to image/mt7621.mk for the affected devices (used for the image metadata): DEVICE_COMPAT_VERSION := 1.1 DEVICE_COMPAT_MESSAGE := Config cannot be migrated from swconfig to DSA 2. adding the following to a board.d file (used for the compat version "on the device") ucidef_set_compat_version "1.1" While this is straightforward for the devices actually affected by the migration, the question is how to deal with the devices that were added _after_ that, i.e. those that have been added with DSA in the first place, as well as new devices added in the future. This is where the two options become available: Option 1. Only bump actually migrated devices: Strictly, the version bump only is meant for _changed_ devices, so devices added with DSA in the first place would be 1.0, i.e. the first version added to OpenWrt. This would save us from specifying DEVICE_COMPAT_VERSION := 1.1 for these in image/mt7621.mk, but would require to list all 1.1 devices in the switch-case in a board.d file. Option 2. Set all mt7621 devices to 1.1 from the start The obvious alternative is to have _all_ mt7621 devices set to compat version 1.1, even those that have been added after DSA introduction and those that will be added in the future. While this is less strict in applying the compat version, it's actually easier to grasp for the user and easier to implement. Advantages: - No need to add a lot of devices to switch-case in board.d file (unless something else requires a 1.2 etc.) - "DSA = 1.1" without having to look at the specific device (for this subtarget) - DEVICE_COMPAT_VERSION can be moved to common/shared definitions (as that will also affect new devices), i.e. is stated less often - If somebody backports a device to 19.07 (locally) by switching to swconfig, the compat-version mechanism would also cover his/her case (as the 19.07 swconfig device would be 1.0) for a future upgrade Disadvantages: - DEVICE_COMPAT_VERSION = 1.1 in image/mt7621.mk would need to be added to every new device added to this subtarget in the future - There would be no official version 1.0 for the "newer" devices - DSA would be linked to 1.1 in the mind of people, while technically other reasons could lead to a compat-version bump to 1.1 as well (and DSA could then be 1.2 if that other things happens before) Personally, I prefer option 2, as I think the advantages outweigh the disadvantages and I think it is easier to maintain the DEVICE_COMPAT_VERSION in Makefile that a big switch-case in board.d. I'd be happy about your opinions on this one. Best Adrian openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Simplified LuCI interface project: dashboard, quick setup, configuration
On 18-07-20, Baptiste Jonglez wrote: > > - quick setup: https://github.com/openwrt/luci/pull/4141 > > - configuration: https://github.com/openwrt/luci/pull/4186 > > This needs more discussion and feedback. > > There is one interesting question (on the github pull request): should the > quick setup configure the same SSID for 2.4 GHz and 5 GHz, or two > different SSID? > > I remember that some clients had trouble switching between channels if the > same SSID is used, which is why I pushed for two different SSID. Does > anybody has current experience with this? As there has been no negative feedback about this, we will move to configure the same SSID for 2.4 GHz and 5 GHz in the quick setup. This will simplify the user experience. > As always, keep in mind that this should match the common needs of casual > users: advanced users can always go to the current Wireless menu. Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH v2 1/3] hostapd: add wpad-basic-wolfssl variant
Hi Petr, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Petr Štetiar > Sent: Montag, 27. Juli 2020 11:57 > To: openwrt-devel@lists.openwrt.org > Cc: Petr Štetiar > Subject: [PATCH v2 1/3] hostapd: add wpad-basic-wolfssl variant > > Add package which provides size optimized wpad with support for just WPA- > PSK, SAE (WPA3-Personal), 802.11r and 802.11w. a few comments below. > > Signed-off-by: Petr Štetiar > --- > > changed in v2: no changes > > include/target.mk | 2 +- > package/network/services/hostapd/Config.in | 2 ++ > package/network/services/hostapd/Makefile | 20 > > 3 files changed, 23 insertions(+), 1 deletion(-) > > diff --git a/include/target.mk b/include/target.mk index > aba477e83b8b..6ed6565bdaa2 100644 > --- a/include/target.mk > +++ b/include/target.mk > @@ -56,7 +56,7 @@ endif > DEFAULT_PACKAGES += $(DEFAULT_PACKAGES.$(DEVICE_TYPE)) > > filter_packages = $(filter-out -% $(patsubst -%,%,$(filter -%,$(1))),$(1)) - > extra_packages = $(if $(filter wpad-mini wpad-basic wpad nas,$(1)),iwinfo) > +extra_packages = $(if $(filter wpad-mini wpad-basic wpad-basic-wolfssl > +wpad nas,$(1)),iwinfo) > > define ProfileDefault >NAME:= > diff --git a/package/network/services/hostapd/Config.in > b/package/network/services/hostapd/Config.in > index 81a374c6525a..aa2a4bc41b5b 100644 > --- a/package/network/services/hostapd/Config.in > +++ b/package/network/services/hostapd/Config.in > @@ -13,6 +13,7 @@ config WPA_RFKILL_SUPPORT > PACKAGE_wpad-openssl || \ > PACKAGE_wpad-wolfssl || \ > PACKAGE_wpad-basic || \ > +PACKAGE_wpad-basic-wolfssl || \ > PACKAGE_wpad-mini || \ > PACKAGE_wpad-mesh-openssl || \ > PACKAGE_wpad-mesh-wolfssl > @@ -32,6 +33,7 @@ config WPA_MSG_MIN_PRIORITY > PACKAGE_wpad-openssl || \ > PACKAGE_wpad-wolfssl || \ > PACKAGE_wpad-basic || \ > +PACKAGE_wpad-basic-wolfssl || \ > PACKAGE_wpad-mini || \ > PACKAGE_wpad-mesh-openssl || \ > PACKAGE_wpad-mesh-wolfssl I think the package also needs to be added to "WPA_WOLFSSL" in the same file? > diff --git a/package/network/services/hostapd/Makefile > b/package/network/services/hostapd/Makefile > index d754f19857ea..df1a80d3dabb 100644 > --- a/package/network/services/hostapd/Makefile > +++ b/package/network/services/hostapd/Makefile > @@ -109,6 +109,13 @@ ifeq ($(LOCAL_VARIANT),full) >endif > endif > > +ifeq ($(LOCAL_VARIANT),basic) > + ifeq ($(SSL_VARIANT),wolfssl) > +DRIVER_MAKEOPTS += CONFIG_TLS=wolfssl CONFIG_SAE=y > +TARGET_LDFLAGS += -lwolfssl > + endif > +endif I've just pushed my patch to rearrange this setup. You can just drop this added "block" entirely now, as your case should be covered by the existing conditions. > + > ifneq ($(LOCAL_TYPE),hostapd) >ifeq ($(LOCAL_VARIANT),mesh) > ifeq ($(SSL_VARIANT),openssl) > @@ -248,6 +255,17 @@ define Package/wpad-basic/description > This package contains a basic IEEE 802.1x/WPA Authenticator and Supplicant > with WPA-PSK, 802.11r and 802.11w support. > endef > > +define Package/wpad-basic-wolfssl > +$(call Package/wpad/Default,$(1)) > + TITLE+= (WPA3-Personal, 11r and 11w) I'd use the shorter (wolfSSL, 11r, 11w) or similar now to stay in line with updated TITLE variables. Despite, we didn't refer to WPA3 as such anywhere else in the file. I'd also like the wpad-basic-wolfssl variant backported to 19.07 (optional, of course). Do you have an opinion about that? Best Adrian > + VARIANT:=wpad-basic-wolfssl > + DEPENDS+=+libwolfssl > +endef > + > +define Package/wpad-basic-wolfssl/description > + This package contains a basic IEEE 802.1x/WPA Authenticator and > Supplicant with WPA-PSK, SAE (WPA3-Personal), 802.11r and 802.11w > support. > +endef > + > define Package/wpad-mini > $(call Package/wpad/Default,$(1)) >TITLE+= (WPA-PSK only) > @@ -567,6 +585,7 @@ define Package/wpad/install > $(LN) wpad $(1)/usr/sbin/wpa_supplicant endef Package/wpad- > basic/install = $(Package/wpad/install) > +Package/wpad-basic-wolfssl/install = $(Package/wpad/install) > Package/wpad-mini/install = $(Package/wpad/install) Package/wpad- > openssl/install = $(Package/wpad/install) Package/wpad-wolfssl/install = > $(Package/wpad/install) @@ -622,6 +641,7 @@ $(eval $(call > BuildPackage,wpad)) $(eval $(call BuildPackage,wpad-mesh-openssl)) $(eval > $(call BuildPackage,wpad-mesh-wolfssl)) $(eval $(call BuildPackage,wpad- > basic)) > +$(eval $(call BuildPackage,wpad-basic-wolfssl)) > $(eval $(call BuildPackage,wpad-mini)) > $(eval $(call BuildPackage,wpad-openssl)) $(eval $(call BuildPackage,wpad- > wolfssl)) > > ___ > openwrt-devel mailing list >
