**** BEGIN LOGGING AT Fri Mar 20 02:59:57 2020 Mar 20 04:05:36 jg*yawn* Mar 20 04:05:48 oh he is offline Mar 20 04:05:58 so week 2 starts today, still nmo zombies Mar 20 04:06:13 jow: lets have a chat later on about utopologyd Mar 20 04:09:23 musl 1.2.0 will be a fun update Mar 20 04:09:39 64-bit time_t Mar 20 04:48:37 a must have! Mar 20 04:48:59 2039 is approaching faster then ever Mar 20 04:52:00 I updated musl locally. A lot of failure. Mainly with OpenWrt tools Mar 20 04:52:27 they call 32-bit syscalls, which are gone now. Mar 20 05:32:54 ideally there should be some unit tests added before the fixes in order to fight the possible regressions Mar 20 05:33:36 which tools are broken so far btw? Mar 20 05:37:03 from a quick look, netifd, odhcp6c, odhcpcd, umdns (actually a GCC9 issue), umbim, procd, and ugps. Mar 20 05:37:11 I'll handle the packages feed Mar 20 07:05:30 russell--: it's possible (though not super likely) that this bug surfaces due to backports. Have you tried running the kernel's driver? Mar 20 07:37:35 morning Mar 20 07:38:01 jow: i want to backport wwan fix ("wwan: fix hotplug event handling") to 19.07 and i'm reviewing other changes for that package Mar 20 07:38:26 jow: any idea if I should also backport c45c7606cc8017995609033a7fee80fa01b45434 ("wwan: check new uci bus option on proto setup event") ? Mar 20 07:39:33 according to the description it seems safe Mar 20 07:57:02 its always safe in the descriptions :) Mar 20 08:07:10 rmilecki: f00b4r0 wants to fix Mikrotik devices in ath79 properly, as Mikrotik seems to use dynamic mtd partitions (on some models?), probably due to variable size of the bootloader, apparently some partitions have tags and can be identified programatically, do you've any idea how to approach that in upstreamable fashion? Mar 20 08:07:25 rmilecki: he gave me this file as example target/linux/ath79/dts/qca9558_mikrotik_routerboard-922uags-5hpacd.dts Mar 20 08:07:37 PaulFertser: i have not. Mar 20 08:08:29 rmilecki: art: partition@c000 is probably wrong, as it has fixed offset, but it could be different on some devices Mar 20 08:09:34 ynezz: f00b4r0: then I believe you don't want "fixed-partitions" at all but a custom partitioner - give it its own "compatible" string and let it use those tags to find partitions and report them to mtd Mar 20 08:09:53 ynezz: f00b4r0: you can take a look at bcm47xxpart as example Mar 20 08:10:45 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mtd/parsers and e.g. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mtd/parsers/bcm47xxpart.c Mar 20 08:11:14 rmilecki: nice, thanks! Mar 20 08:11:22 bcm47xxpart doesn't use any partition table or tags but it simply scans block after block looking for magic numbers at beginning Mar 20 08:11:46 you can write a parser that will read partition table with flags (if there is one) and report partitions based on that Mar 20 08:12:14 another example I'm familiar with is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mtd/parsers/parser_trx.c Mar 20 08:12:24 this one actually does read TRX header and reports partitions based on that Mar 20 08:12:41 how does it look in the DTS then? Mar 20 08:12:47 there is no real difference between device partitioning and partition subpartitioning Mar 20 08:12:52 it doesn't Mar 20 08:12:57 ah Mar 20 08:13:11 but you can do that, you can mix getting info from DTS and from flash device Mar 20 08:13:34 check ofpart.c how it access DTS info Mar 20 08:13:38 the idea is to get mac address info and cal data via NVMEM Mar 20 08:13:54 and mix that with mtd_read as can be found in e.g. bcm47xxpart.c or trx.c Mar 20 08:14:19 ok, so maybe nvmem access function instead of mtd_read Mar 20 08:15:11 in .parse_fn callback you can do anything: check DTS node, read from mtd or access platform data / nvmem Mar 20 08:15:41 here is an example of the DTS which somehow uses NVMEM to get MAC addresses from mtd https://github.com/ynezz/openwrt/commit/00360cc2118beee5bb33b8c104ca08c798f04994 Mar 20 08:15:49 mangix: WARNING: Makefile 'package/feeds/telephony/freeswitch-stable/Makefile' has a dependency on 'opencv', which does not exist Mar 20 08:17:14 it may take some tinkering to support "nvmem-cells" subnode in your own parser but should be doable surly Mar 20 08:17:15 which sorta suggests opencv is used by 'freeswitch-stable' Mar 20 08:17:33 rmilecki: ok, thanks Mar 20 08:17:37 sure Mar 20 08:49:19 russell--: Oleksij was trying vanilla 5.5 but without giving it much traffic testing Mar 20 08:49:40 rmilecki: let me look at those commits Mar 20 08:50:37 jow: that hotplug.d is ok, i verified it Mar 20 08:50:48 jow: i'm not sure about that uci one you pushed Mar 20 08:50:55 rmilecki: yep, that commit makes a lot of sense Mar 20 08:51:03 jow: that uci / option one? Mar 20 08:52:27 rmilecki: that makes sense too Mar 20 08:53:03 thanks for checking that for me! Mar 20 08:53:51 yw Mar 20 08:58:17 PaulFertser: my test was creating a monitor mode interface and running tcpdump on it Mar 20 09:00:00 russell--: the warning is related to FCS, as if the driver reported an incorrect skb claiming it has fcs when it actually doesn't or something like that. Mar 20 09:00:49 russell--: did you run it with fcsfail otherbss ? Mar 20 09:02:26 PaulFertser: almost certainly Mar 20 09:02:51 noted Mar 20 09:03:10 russell--: what was the test duration and do you think it was much traffic around? Mar 20 09:03:10 fwiw, i don't see this on the debian kernel Mar 20 09:03:42 https://github.com/beagleboard/linux/releases/tag/4.19.94-ti-r34 Mar 20 09:04:23 russell--: that's an important data point Mar 20 09:05:34 oh i see a lot of incoming traffic in tcpdump, given i have ~1.5 dozen devices happily beaconing away in the house, not even counting the neighbors ;-) Mar 20 09:06:11 And how long did it take to the warning? Mar 20 09:07:15 a few seconds Mar 20 09:08:01 i probably saw a half dozen warning stack traces in 20 seconds or so Mar 20 09:08:07 (rough guess) Mar 20 09:09:01 If it's so easily reproducible you might try without fcsfail the next time. Mar 20 09:09:31 without fcsfail otherbss, i don't see the warnings Mar 20 09:10:15 OK, so my guess is confirmed Mar 20 09:11:52 russell--: he gets this every now and then on 5.5: Feb 01 14:53:19 AccessBox kernel: ath: phy0: Short RX data len, dropping (dlen: 3) Mar 20 09:12:14 So probably it got additional sanity check between 5.4 and 5.5 for that. Mar 20 09:14:12 if i turn it on with iw dev mon0 set monitor fcsfail otherbss, and then tcpdump -i mon0 again, i can get it, although not immediately ... in fact the warning arrived a few seconds after i killed tcpdump (after running it for 15 seconds or so) Mar 20 09:14:50 russell--: sorry, can't understand what exactly is the difference with the previous tests. Mar 20 09:32:49 the tests were similar, but not tightly controlled Mar 20 09:38:20 russell--: btw, is performance with PIO really disappointing? Or is it good enough of a workaround? It seems that musb is always problematic, in all kinds of ways. And in this case there's an impression DMA leads to memory corruption and musb maintainers are unlikely to care or help with that. Mar 20 09:41:38 not sure yet Mar 20 09:43:04 this is for the nano-satellite project i mentioned in #linux-wireless. this plan is to use debian, but i was exploring the possibility of using openwrt instead Mar 20 09:44:16 the likelihood is that i won't be able to convince them to use openwrt because they have a lot of debian infrastructure work already invested Mar 20 09:44:58 russell--: what would be the advantages of using openwrt for the project? Mar 20 09:45:46 the primary one for me is the ability to reset to squashfs if the filesystem becomes hosed Mar 20 09:46:03 also, size Mar 20 09:46:36 Reset to squashfs is a good selling point Mar 20 09:48:02 openwrt is small enough to make uploading a new image from the ground plausible Mar 20 09:48:05 But I guess you might want to have a backup boot partition regardless, as squashfs might get corrupted (especially in space) Mar 20 09:48:42 russell--: don't you want to talk directly to Oleksij to collaborate on this project? Mar 20 09:49:01 nanosat sounds fun enough Mar 20 09:49:56 russell--: he has many ath9k_htc devices for testing , some with serial console for debugging etc. Mar 20 09:49:57 i'll ping you if i get serious enough ... i want to look at the beagleboard patches to see if they are doing anything special Mar 20 09:50:43 yeah, i've got one with serial, though i haven't quite figured out where in the firmware to print debugging messages yet Mar 20 09:51:08 i see the firmware loading when it connects Mar 20 09:53:04 * russell-- needs to go to sleep so i can get up in time to go to the grocery store before it's picked clean by toilet paper hoarders Mar 20 09:53:17 he* Mar 20 09:53:43 russell--: certainly recommend you to contact him, your goals have intersection with Oleksij's hobby projects. Mar 20 09:53:48 nice Mar 20 09:54:03 russell--: sleep well Mar 20 09:54:05 please forward contact info Mar 20 09:54:12 russell--: git log has that Mar 20 09:54:16 oh, right Mar 20 09:54:22 i thought i recognized that name Mar 20 09:54:29 perfecto Mar 20 11:47:26 rmilecki: thanks, very helpful Mar 20 11:47:35 * f00b4r0 thanks ynezz for asking :) Mar 20 11:49:05 rmilecki: if I want to make a parser that works across all mikrotik platforms, I'm going to have to be able to handle "variants". Meaning some parts of the partition scheme are fixed, some are parsed, but the fixed parts may be different between variants. Is it acceptable to define several compatible strings for each variant? Mar 20 11:49:44 regarding nvmem I can start with writing the parser (low hanging fruit) and then add the nvmem code (considering you think it's doable) Mar 20 11:52:09 * f00b4r0 gets coding Mar 20 11:58:06 * ldir gets ready to sproing into action Mar 20 12:04:11 jow: ping Mar 20 12:04:29 let me finish my tea, will be back in ~5 minutes Mar 20 12:04:37 :-) Mar 20 12:42:28 f00b4r0: it sounds like you should store fixed partitions in dts and then handle dynamic partitions in parse_fn code using some flash / nvmem info Mar 20 12:43:55 rmilecki: I'm not sure how that would work considering that for the fixed partition, their "end" (size) is basically where the dynamic one begins? Mar 20 12:44:36 I'm also concerned that this would make the code a lot more complex if it has to ensure the DTS isn't shooting itself in the foot with conflicting/overlapping declarations? Mar 20 12:45:33 my idea is to define in DTS a "RouterBoot" segment (quite like we define the "firmware" one), and let the parser run its magic Mar 20 12:46:35 inside of that segment. Technically I could select the correct variant in the parser as the necessary metadata is on the flash as well (machine type), if I really wanted to be thorough Mar 20 12:49:49 f00b4r0: it's hard for me to help further without full understanding of possible layouts, if you provide some summary, I can try with more advises Mar 20 12:49:51 f00b4r0: there is no problem with dyanmic partitions starting after fixed ones, you can e.g. add something like dynamic-range = <0x0000f000 0x00010000>; Mar 20 12:49:56 rmilecki: if you look at this https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ramips/dts/mt7621_mikrotik_rbm11g.dts;h=60b6395c17948fa2cb058948e33503399cd71ae6;hb=HEAD line 94 and following Mar 20 12:50:18 yeah I understand why you are not seeing what I'm trying to express Mar 20 12:50:53 within RouterBoot segment, depending on platform, you can have: "fixed dynamic fixed dynamic fixed" or "fixed fixed dynamic dynamic dynamic fixed" for instance Mar 20 12:51:02 f00b4r0: if "RouterBoot" content is not always fixed, you need a custom parser for that partition Mar 20 12:51:29 some of its content is always fixed (start offsets) some isn't (end size and start offset of dynamic parts) Mar 20 12:52:10 and considering its typically interleaved, I'd rather handle both fixed and dynamic part in the parser, to avoid chaos Mar 20 12:52:18 so replace compatible = "fixed-partitions"; with custom parser and make that parser support e.g. reg = <0x2000>; (without end address) Mar 20 12:52:57 ah i see Mar 20 12:53:12 so the parser would get a partially populated partition map and would fill the blanks? Mar 20 12:54:43 * f00b4r0 has no idea (yet) how to code that but will investigate. Mar 20 12:55:29 (the interfacing with DTS/of is what I'm not familiar with) Mar 20 12:55:36 * f00b4r0 bbl Mar 20 12:55:48 rmilecki: thanks again for the input Mar 20 13:09:39 f00b4r0: you can see how ofpart.c reads from DTS Mar 20 14:50:46 rmilecki: thanks, now I get it. If it's ok to have partition nodes which have no unit-address (the DTS spec allows it if a node has no reg property, which will be the case for dynamic parts), then I can probably kill two birds with one stone: the dynamic partitions would be declared in dts without reg (this will enable to tell the parser which dynamic parts to find as needed) and nvmem should then be useable directly in dts refere Mar 20 14:50:46 ncing these partitions Mar 20 15:10:23 f00b4r0: sounds good Mar 20 15:10:50 cool. Baking something now. We'll see if that flies :) Mar 20 15:25:36 Baking and flies? Doesn't sound appetising at all ;-) Mar 20 15:27:29 ;) Mar 20 15:30:17 could be a lifesaver though, with all those empty shelves in supermarkets :P Mar 20 15:59:19 I'm sure you can bake something with toilet paper Mar 20 16:44:50 build #241 of sunxi/cortexa8 is complete: Failure [failed updatefeeds] Build details are at http://buildbot.openwrt.org/master/images/builders/sunxi%2Fcortexa8/builds/241 blamelist: Daniel Golle Mar 20 16:54:36 rmilecki: I'm trying to figure out from of driver code whether i'm guaranteed that for_each_child_of_node() will return nodes /in order/ (the specification doesn't seem to make node ordering mandatory): trying to figure out if I must sort the parts first before fixing up the size of the "unsized" ones Mar 20 18:20:55 did anyone have a chance to test the latest ath10k-ct driver/firmware that I wrote about a few days ago? Mar 20 18:21:27 I also have a fix for scanning + powersave bug on wave-1, still needs a bit of testing though... Mar 20 18:29:24 mangix: pong Mar 20 19:04:46 greearb__: I've been running it without any issues. Mar 20 19:06:27 thanks! Mar 20 19:54:17 Hauke: comment on this? https://github.com/openwrt/packages/pull/11587 Mar 20 19:54:52 *yawn* Mar 20 19:55:32 utopologyd is taking shape Mar 20 19:56:04 tomorrow i will add the dhcp/mdns/lldp/... hooks Mar 20 19:56:10 not that anyone cares Mar 20 19:59:59 PaulFertser: i sent Oleksij a message Mar 20 20:03:16 blogic: we already talked about it, I'm definitely interested :) Mar 20 20:03:25 zorun: ;) Mar 20 20:03:50 I am already gathering neigh table, brtable and arps Mar 20 20:04:08 and nl80211 info Mar 20 20:05:13 what does the output look like? list of device, with hostname / IP / MAC / interface / signal strength / etc? Mar 20 20:05:24 pkey is mac Mar 20 20:05:35 ok Mar 20 20:05:38 then linked to that is N ipv4/6 addr Mar 20 20:05:41 bridge port Mar 20 20:05:56 netdev it is seen behind Mar 20 20:06:03 wifi interface it is seen behind Mar 20 20:06:16 next i will add info from dhcp/mdns if available Mar 20 20:06:24 f00b4r0: for_each_child_of_node() doesn't sort, good practice is to have entries sorted, but I don't believe it's guaranteed Mar 20 20:06:35 and then start bcasting the lot via ieee1905.2 and lldp Mar 20 20:07:05 oh and i added some code to parse the oui Mar 20 20:07:06 oh, so it will advertise this information to neighbours? Mar 20 20:07:18 so that you can see its a samsung device or a sony device Mar 20 20:07:19 you could pick lldp from neighbouring devices Mar 20 20:07:33 yup, that is the plan Mar 20 20:07:35 ah, nice, my students wanted something like this :) Mar 20 20:07:40 send and receive lldp and ieee1905 Mar 20 20:07:57 os fingerprinting is another option Mar 20 20:08:00 they wanted to show a difference picture depending on whether the device is a phone, tablet, computer... Mar 20 20:08:21 so there are ways to tell if its a m$ craple or *nix device by looking at arp ttls and so on Mar 20 20:08:31 it looks feasible from OUI + hostname (android-XXX) Mar 20 20:08:39 yeah Mar 20 20:08:45 anyhow Mar 20 20:08:47 more tomorrow Mar 20 20:09:02 the zombie apocalypse will be around for a while so plenty of time Mar 20 20:09:17 rumours have it that schools wont open again in .de this scheel year Mar 20 20:09:44 and the uk .gov says that we will be busy with china aids for 18 months Mar 20 20:10:02 still hoping for zombies though Mar 20 20:22:06 * ldir-zombie arrrrrghhs - then gets distracted by fireworks Mar 20 20:49:28 rmilecki: ok, so I'll add a sort step then to be thorough. I have some code ready but I think testing will have to wait tomorrow :) Many thanks for your help! Mar 20 21:30:23 mangix: fine with me to remove iotivity Mar 20 21:32:50 blogic: please send me the testcases Mar 20 21:33:14 is it possible that base-files and openwrt-keyring both provide the snapshot usign key? I see some conflicts in my buildlogs Mar 20 21:49:43 why do people in the forum suddenly start to talk about "wifi 5" and "wifi 6" ? Did I miss some new marketing bs terms? Mar 20 21:52:28 yes (but you didn't miss much, don't worry) Mar 20 21:53:22 Apparently, 802.11ac and 802.11ax are too difficult… Mar 20 21:54:39 I don't know, I think the numbers are a pretty decent move. Mar 20 21:55:28 is 802.11ac a wifi 5 now?! Mar 20 21:55:45 unofficially AFAIK Mar 20 21:56:01 oh my Mar 20 21:56:11 another usb-like naming mess Mar 20 22:00:03 there is also wifi 6E Mar 20 22:02:42 Mister_X: rather very officially I'd say: https://www.wi-fi.org/discover-wi-fi :) Mar 20 22:03:20 rmilecki: I actually think they were trying to learn from usb to not make the same mistakes Mar 20 22:03:38 f00b4r0, thanks Mar 20 22:03:46 butr perhaps I'm optimistic and generous :) Mar 20 22:03:52 :P Mar 20 22:04:23 WiFi 6E Mar 20 22:04:36 WiFi 6 on 6GHz Mar 20 22:11:49 jow: any idea why this fails? make image PROFILE="jjplus_ja76pf2" PACKAGES="openwrt-keyring base-files" Mar 20 22:12:06 * check_data_file_clashes: Package base-files wants to install file /home/a/src/openwrt/asu/var/asu-instance/cache/snapshot/ath79/generic/build_dir/target-mips_24kc_musl/root-ath79/etc/opkg/keys/b5043e70f9a75cde Mar 20 22:17:08 I guess it is because the imagebuilders insert their own key but also openwrt-keyring contains that key? Mar 20 22:18:07 aparcar[m]: no immediate idea, sorry Mar 20 22:18:21 and the order PACKAGES="base-file openwrt-keyring" works again Mar 20 22:19:44 jow: please put this one on your backlog too https://patchwork.ozlabs.org/patch/1207614/ :) Mar 20 22:19:46 dangole: ping Mar 20 22:20:43 jow: pong Mar 20 22:21:30 dangole: I've been receiving various reports that sometimes the "ifname" property is not populated for networks in the "ubus call network.wireless status" output and I wonder if it is related to the recent hostapd / netifd integration rework Mar 20 22:21:38 good rtt Mar 20 22:22:42 dangole: most recent report here: https://github.com/openwrt/luci/issues/3758 Mar 20 22:22:50 I wonder if you seen something like this on your end Mar 20 22:22:57 or if you have an immediate idea what might cause it Mar 20 22:23:02 jow: that'd be weird because the ifname is fixed in the same unchanged shell-script as before, just instead of starting hostapd/wpa_supplicant, a ubus call to the running service is made Mar 20 22:23:25 jow: i'll look into it Mar 20 22:23:37 then somehow netifd seems to loose track of it Mar 20 22:24:15 jow: ah, could be that i've just merged the fix for it: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=23a885bf89a204f91e4f17ed96f1a9fc7f50ea34 Mar 20 22:24:57 hm Mar 20 22:25:25 jow: but interface state tracking in netifd seems dodgy in some other places since the dynamic reload changes as well... Mar 20 23:01:49 clearly my ISP is feeling the netflix burn at this time ;P **** ENDING LOGGING AT Sat Mar 21 02:59:57 2020