**** BEGIN LOGGING AT Thu Apr 22 02:59:57 2021
Apr 22 03:09:20 <owrt-snap-builds> Build [#61](https://buildbot.openwrt.org/master/images/#builders/64/builds/61) of `realtek/generic` failed.
Apr 22 05:20:27 <lipnitsk> nbd: I went ahead and submitted to netdev to get the ball rolling, hope that's okay with you... https://lore.kernel.org/lkml/20210422040914.47788-1-ilya.lipnitskiy@gmail.com/
Apr 22 06:11:21 <rmilecki> stintel: check https://github.com/Broadcom/stblinux/commit/9f01f5cdb548352418b34ce77db02a560fe2913b
Apr 22 06:12:18 <rmilecki> stintel: "mac-address" at nvmem-cell-names index 0 tells kernel that phandle at nvmem-cells index 0 (&base_mac_addr) should be used for reading MAC address
Apr 22 06:13:00 <rmilecki> stintel: kernel checks for that in the of_get_mac_address()
Apr 22 06:13:49 <rmilecki> stintel: then base_mac_addr is a phandle for NVMEM cell (6 bytes in MTD partition)
Apr 22 07:52:06 <mangix> lipnitsk: upstream's currently having fun undoing a bunch of damage
Apr 22 07:52:18 <mangix> even stuff that made it stable
Apr 22 07:54:37 <lipnitsk> Yeah I saw that. Of they don't get to my stuff np
Apr 22 07:54:55 <lipnitsk> Just wanted to get it out there but not a high priority
Apr 22 07:57:40 <lipnitsk> mangix: Figured why not try to upstream it before the merge window closes.. if there is pushback we can punt it to 5.14 np
Apr 22 08:30:57 <zorun> Hauke: I have improved https://openwrt.org/releases/21.02/notes-21.02.0-rc1
Apr 22 08:31:15 <zorun> thanks for taking care of getting the rc1 out
Apr 22 08:31:30 <zorun> I have left some FIXME because I haven't been following things closely lately
Apr 22 08:45:09 <rmilecki> zorun: "The LuCI web interface has no support for DSA yet" goes a bit too far I think?
Apr 22 08:45:19 <rmilecki> zorun: afaiu there is some basic support for DSA, right?
Apr 22 08:54:24 <Namidairo> yeah but it's not merged into the 21.02 branch yet
Apr 22 08:54:46 <Namidairo> see https://github.com/openwrt/luci/pull/4307
Apr 22 08:57:58 <Pepe> lucenera: reForis/Foris should be working in HBD
Apr 22 08:58:03 <Pepe> sorry wrong channel!
Apr 22 09:03:29 <rsalvaterra> Guys, ping on this one… https://patchwork.ozlabs.org/project/openwrt/patch/20210408225748.1596909-1-rsalvaterra@gmail.com/
Apr 22 09:03:46 <rsalvaterra> Can it be merged to master and backported to 21.x, please? :P
Apr 22 09:04:28 <rsalvaterra> It's acked by stintel and nbd.
Apr 22 09:12:19 * ldir notes his reckless mood continues
Apr 22 09:15:41 <rsalvaterra> ldir: One of these days you'll get us both in trouble… :P
Apr 22 09:16:54 <ldir> I hope so :-)
Apr 22 09:17:22 * ldir does man git-revert just in case
Apr 22 09:29:12 <rsalvaterra> lipnitsk: I'm not subscribed to the mailing list, but feel free to add my Tested-by to your "kernel: backport mtk_ppe busy-wait loop fix" patch.
Apr 22 09:30:31 <Borromini> rsalvaterra: why not?
Apr 22 09:30:34 <Borromini> just curious
Apr 22 09:31:42 <rsalvaterra> Borromini: I have this thing with email… :P
Apr 22 09:31:49 <Borromini> :P
Apr 22 09:32:50 <rsalvaterra> I'll probably bite the bullet and subscribe one of these days… I'll just have to create some rules to keep my inbox clean.
Apr 22 09:33:02 <rsalvaterra> Laziness prevails.
Apr 22 09:33:02 <Borromini> ok
Apr 22 09:33:12 <Borromini> natural state of man!
Apr 22 09:33:22 <Borromini> nature is all about conservation of energy ;)
Apr 22 09:33:47 <rsalvaterra> Indeed! XD
Apr 22 09:34:31 <Borromini> congrats on the commit access btw
Apr 22 09:34:49 <Borromini> even more reason to be subscribed :P
Apr 22 09:35:03 <Borromini> did i miss that vote on openwrt-adm btw?
Apr 22 09:35:21 <Borromini> (not that i have any voting rights the ML has just been quiet)
Apr 22 09:43:46 <rsalvaterra> Borromini: Oh, I don't have commit access! I also noticed that I appear as the committer, but I'm not, honest! :O
Apr 22 09:45:59 <Borromini> oh
Apr 22 09:46:01 <Borromini> weird!
Apr 22 09:46:23 <rsalvaterra> I'd be scared of having commit access. With great power comes great responsibility, etc.…
Apr 22 09:47:34 <rsalvaterra> Borromini: It's probably due to the way ldir merged, I don't know the details… :/
Apr 22 09:47:52 <Borromini> ok
Apr 22 09:49:06 <ldir> I used the github-apply & patchwork-apply maintainer scripts.
Apr 22 09:50:14 <ldir> it looks like the github-apply doesn't put in a committer
Apr 22 09:51:41 <stintel> rmilecki: I tried this https://gitlab.com/stintel/openwrt/-/issues/2#note_557371298 but didn't work
Apr 22 09:51:52 <stintel> rmilecki: if you can spot what I'm doing wrong, please do tell :)
Apr 22 09:53:47 <ldir> the maintainer tools don't come with obvious instructions so I may well have done something wrong
Apr 22 09:54:02 <mangix> lipnitsk: lol do you know what i'm referring to?
Apr 22 09:55:07 <mangix> https://lwn.net/ml/linux-kernel/20210407001658.2208535-1-pakki001@umn.edu/ <--- intentionally bad/malicious patches that even hit stable
Apr 22 09:55:28 <mangix> greg's working on nuking them
Apr 22 10:10:11 <ldir> yet the uni involved in their faq say that no intentionally bad patches were committed - which is absolute twaddle
Apr 22 10:11:02 <ldir> Still we know which uni to go to to hire blackhats
Apr 22 10:13:56 <Habbie> ldir, you sure? they did get caught ;)
Apr 22 10:15:30 <rsalvaterra> https://cse.umn.edu/cs/statement-cse-linux-kernel-research-april-21-2021
Apr 22 10:15:50 <mangix> ldir: speaking of blackhats, the signal blog post was hilarious
Apr 22 10:16:10 <Habbie> mangix, especially the last bit in it, i loved that
Apr 22 10:16:59 <mangix> i was reading comments on whether or not they'll actually weaponize their files. i think moxie's crazy enough to do that
Apr 22 10:22:00 <rsalvaterra> And the video is just brilliant! :D
Apr 22 13:21:53 <russell--> hmm. wzr600dhp recent-master build is kernel panic'ing on boot
Apr 22 13:21:55 <russell--> [    2.604079] /dev/root: Can't open blockdev
Apr 22 13:21:55 <russell--> [    2.608189] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
Apr 22 13:21:58 <russell--> [    2.615705] Please append a correct "root=" boot option; here are the available partitions:
Apr 22 13:40:00 <russell--> doing a make dirclean world
Apr 22 14:10:55 <barhom> Hey, most routers does not have a HW clock. Im testing on a IPQ4019 based device with ntp-busybox disabled. I tried setting the date to 2018-01-01, then I power cycled the router and it still set it to todays date. How is this possible?
Apr 22 14:12:13 <barhom> Im testing this because I've encountered a specific ISP that seems to block busybox-ntp client (I do not get any replies back from the ntp server).
Apr 22 14:12:50 <stintel> barhom: something with timestamps
Apr 22 14:12:53 <stintel> of files
Apr 22 14:13:15 <barhom> The weird thing is that ntpd works (busybox-ntp does not). In wireshark they differ in the ntp4 packet a bit. My best bet now is that the ISP is blocking outgoing packets coming from busybox-ntp, but not ntpd
Apr 22 14:13:35 <barhom> stintel, that must be an openwrt thing then? if it reads the timestamps of files
Apr 22 14:13:44 <stintel> yeah, I can't find it though
Apr 22 14:14:33 <stintel> and I believe I also had some issues with busybox-ntp several years ago, something with it selecting the wrong interface to send the query or something
Apr 22 14:14:50 <stintel> but that could have also been DNS or ... dunno, it's too long ago
Apr 22 14:14:53 <stintel> .94
Apr 22 14:14:58 <barhom> yeh, I checked that with tcpdump, packet is going out
Apr 22 14:15:29 <barhom> I saved both pcap files for the ntp client from busybox and ntpd. Both have same source and dest, but the contents of the ntp4 packet is slightly different
Apr 22 14:16:21 <stintel> maybe violates something
Apr 22 14:16:28 <stintel> but I'd report that to busybox upstream maybe
Apr 22 14:24:18 <malwar3hun73r> I'm seeing an issue on 19.07.7 where something dies and I lose all routing for a VLAN i have setup on my wrt1900acs. Any thoughts?
Apr 22 14:25:12 <malwar3hun73r> It's an untagged VLAN assigned to a specific port. All works as expected until a large amount of traffic passes the VLAN and then the interface dies. The only way to bring it back is to reboot the router.
Apr 22 14:33:32 <ynezz> barhom: package/base-files/files/etc/init.d/sysfixtime
Apr 22 14:50:49 <malwar3hun73r> Traffic can flow outbound, but not in
Apr 22 15:03:46 <PaulFertser> stintel: please if you see bahrom again, tell /etc/init.d/sysfixtime is what sets the time to the newest modification time of a file in /etc.
Apr 22 15:06:31 <Pepe> Guys, I noticed that a few days ago there was added basic WiFi6 support in iwinfo. But I noticed that it is not in OpenWrt master either OpenWrt 21.02. Would it be possible to update it there to have at least some basic support of WiFi6?
Apr 22 15:09:39 <malwar3hun73r> Any ideas what would cause the interface to drop with high levels of traffic?
Apr 22 15:24:38 <barhom> ynezz, thanks
Apr 22 15:39:42 <barhom> PaulFertser, thanks for the info about sysfixtime. I understand how it works now.
Apr 22 15:43:03 <PaulFertser> barhom: welcome, I thought you parted :)
Apr 22 15:44:31 <barhom> PaulFertser, am I leaving the channel everytime I'm changing wifi's? I should always be here since Im running it via znc
Apr 22 15:51:50 <PaulFertser> barhom: I just looked somewhere else and thought your nick can't be completed or something like that, sorry for the noise. FYI I found the file in question by doing this: git grep "date -s"
Apr 22 16:27:22 <rmilecki> stintel: please patch your kernel with this: https://pastebin.com/raw/PyCGGhqs
Apr 22 16:27:27 <rmilecki> and provide output
Apr 22 16:27:50 <rmilecki> stintel: oh, wait, I just noticed something
Apr 22 16:28:10 <rmilecki> &tlv_eeprom { compatible = "nvmem-cells"; } <-- this basically overwrites compatible = "atmel,24c256";
Apr 22 16:28:33 <rmilecki> i'd expect this to stop drivers/misc/eeprom/at24.c from picking your DT node at all
Apr 22 16:29:03 <rmilecki> stintel: at43.c calls devm_nvmem_register() without checking for the "nvmem-cells"
Apr 22 16:29:19 <rmilecki> stintel: so you should not need compatible = "nvmem-cells"; at all
Apr 22 16:44:52 <barhom> PaulFertser, nice use of git grep
Apr 22 16:49:53 <stintel> rmilecki: thanks, trying something
Apr 22 16:51:35 <Habbie> what do i use on my host system to inspect .ipk files?
Apr 22 16:55:26 <Habbie> (other than two levels of untar ;) )
Apr 22 17:00:24 <Habbie> related, why is the outside of an .ipk tar.gz instead of ar, like it apparently was?
Apr 22 17:00:29 <Habbie> (which would make it compatible with dpkg-deb)
Apr 22 17:00:37 <Habbie> -rw-r--r-- 1 peter peter 1704241 Apr 22 17:58 dnsdist_1.6.0-rc1-5_x86_64.ipk
Apr 22 17:00:39 <Habbie> -rw-r--r-- 1 peter peter 1709528 Apr 22 17:58 dnsdist.ar
Apr 22 17:00:42 <Habbie> the savings do not immediately appear to be worth it
Apr 22 17:00:46 <Habbie> but of course i could be missing something
Apr 22 17:02:25 <stintel> rmilecki: still doesn't work. thanks for checking anyway. I might ping you on the subject tomorrow
Apr 22 17:02:48 <stintel> but now it's time to start my weekend
Apr 22 17:02:55 <rmilecki> stintel: ok, please compile with that diff and provide output
Apr 22 17:03:07 <rmilecki> stintel: so early?
Apr 22 17:03:09 <rmilecki> have fun :)
Apr 22 17:03:20 <rmilecki> i may be out on Monday and Tuestday
Apr 22 17:28:28 <galak> anyone know how one might determine the flash layout on a tplink WA801ND.  I've got the v6 version of the board which seems to be MT7628NN + 4M flash
Apr 22 17:29:04 <stintel> 4M flash -> throw it out
Apr 22 17:38:25 <rsalvaterra> stintel: Don't be that way… :P
Apr 22 17:38:52 <stintel> it's the only realistic answer
Apr 22 17:39:19 <rsalvaterra> For general purposes, yes…
Apr 22 17:39:25 <stintel> unless you want to be running stuff that is broken af
Apr 22 17:39:31 <stintel> you might as well stick to OEM firmware then
Apr 22 17:39:44 <Habbie> or learn some bare metal programming! it's all the rage in Pi circles
Apr 22 17:40:51 <stintel> well I stand my ground. 4MB -> throw it out. 8MB? consider replacing
Apr 22 17:42:06 <stintel> those SNIC10E without NAND have only 8MiB. it's impossible
Apr 22 17:42:36 <owrt-snap-builds> Build [#62](https://buildbot.openwrt.org/master/images/#builders/64/builds/62) of `realtek/generic` completed successfully.
**** BEGIN LOGGING AT Thu Apr 22 18:39:31 2021
Apr 22 18:40:29 <hurricos> stintel: at the very least the snic10e has pre-populated solder balls for a TSOP48 NAND
Apr 22 18:41:23 <hurricos> at that point all you do is add a dab of epoxy between the pads, stick on the chip with good alignment, add a little bit of flux and blow at it with a heat gun
Apr 22 18:41:25 <hurricos> and boom, done
Apr 22 19:03:42 <Habbie> aha, ipkg-build actually uses tar
Apr 22 19:22:26 <owrt-snap-builds> Build [#68](https://buildbot.openwrt.org/master/images/#builders/4/builds/68) of `x86/generic` failed.
Apr 22 20:29:18 <stintel> hurricos: yeah I've seen that irl :)
Apr 22 20:29:24 <stintel> I'm actually considering it
Apr 22 21:33:55 <Habbie> stintel, ah, the shared lib checker finally caught me :D
Apr 22 21:34:23 <stintel> честито!
Apr 22 21:35:09 <Habbie> gracis
Apr 22 21:35:11 <Habbie> gracias
Apr 22 21:35:15 <Habbie> i removed a dnsdist dependency (libre2)
Apr 22 21:35:18 <Habbie> and suddenly dnsdist did not build at all
Apr 22 21:35:37 <Habbie> turns out through a sequence of terrible events, libre2 was the only reason i was compiling with -std=c++17
Apr 22 21:35:49 <Habbie> and also the only reason libstdcpp was pulled in
Apr 22 21:35:53 <Habbie> dnsdist needs both of those :)
Apr 22 21:51:07 <mangix> Habbie: yes it does
Apr 22 21:55:08 <Habbie> mangix, hmm? oh dnsdist?
Apr 22 21:59:11 <Habbie>  * opkg_install_pkg: Failed to download dnsdist. Perhaps you need to run 'opkg update'?
Apr 22 21:59:27 <Habbie> to me this always actually means 'perhaps you need to run make package/index' :)
Apr 22 22:00:00 <Habbie> mangix, oh you're neheb :)
Apr 22 22:03:11 <Habbie> that reminded me of a comment i wanted to post - https://github.com/openwrt/packages/issues/14200#issuecomment-825183602
Apr 22 22:16:48 <mangix> Habbie: what's wrong with c++17?
Apr 22 22:22:57 <Habbie> mangix, nothing, but the openwrt package build system doing 'CXX=....-g++' dropped our -std=c++17
Apr 22 22:23:09 <Habbie> this might be a problem with our Makefiles, I did not investigate
**** ENDING LOGGING AT Fri Apr 23 02:59:56 2021