**** BEGIN LOGGING AT Tue Jan 12 02:59:57 2021
Jan 12 07:32:31 <aparcar[m]> jow: I'd like to merge this patch http://patchwork.ozlabs.org/project/openwrt/patch/20200415004956.1130494-1-mail@aparcar.org/ because it fixes a user issue (https://github.com/openwrt/openwrt/pull/3777) but the code is taken from a apache licensed fragment. can you come up with a perl function implementing "unique"?
Jan 12 08:23:57 <xback> blogic: ping
Jan 12 08:24:43 <xback> blogic: Quick question.   Im porting rb912 from ar71xx to ath79
Jan 12 08:24:58 <xback> blogic: within ar71xx, GPIO's are shows as here:  https://pastebin.com/raw/y16FfKrR
Jan 12 08:25:35 <xback> blogic: The first 23 GPIO's are native from the SOC.  I was able to add the 8 pin SPI gpio expander also.
Jan 12 08:25:59 <xback> blogic: But I do not understand where those "gpio-latch" originate from
Jan 12 08:26:30 <xback> I notice there is a custom driver that exposes these somehow .. but I dont get how to see this physically :s
Jan 12 08:26:40 <xback> asking you as I notice some commits from you regarding this in the past :-)
Jan 12 09:06:30 <blogic> ermmm
Jan 12 09:10:30 <blogic> xback: that driver is not OF yet
Jan 12 09:12:09 <blogic> ahhh
Jan 12 09:12:20 <blogic> ok, they multi purposed some gpios
Jan 12 09:12:49 <blogic> google for d-type transparent 16 bit latch
Jan 12 09:12:59 <blogic> I am guessing they put opne of those onto the PCB
Jan 12 09:13:07 <blogic> similar to that EBU thing on lantiq
Jan 12 09:13:37 <blogic> like 74t543
Jan 12 09:38:47 <xback> blogic: thanks
Jan 12 09:38:55 <xback> this one is present on the board:  https://pdf1.alldatasheet.com/datasheet-pdf/view/15802/PHILIPS/LVC573A.html
Jan 12 09:41:08 <xback> wondering how the hell I should define this in a dts .. :-o
Jan 12 10:05:45 <blogic> i would go for a linear mapping
Jan 12 10:05:54 <blogic> as in define max-gpio = 16;
Jan 12 10:06:34 <blogic> and then gpio-linear = < list of real gpios ordered in the the way they are connected to the 573 in lsb->msb order
Jan 12 10:06:51 <blogic> no idea if that is what upstream wants
Jan 12 10:16:33 <xback> phew .. it will take some time to suck this up :-)
Jan 12 10:16:58 <xback> so basically, it's just passing throug GPIO's as long as LE is enabled
Jan 12 10:18:22 <svanheule[m]> xback: is the latching used to maintain output while the GPIOs do something else?
Jan 12 10:18:54 <xback> svanheule[m]: still tryign to understand the relation between the boardfile and that custom driver
Jan 12 10:19:12 <svanheule[m]> ok :-)
Jan 12 10:20:17 <xback> Also looking if there is another compatible driver already upstream ..
Jan 12 10:20:39 <xback> The board file shows that GPIO 11 on the soc is used to control the Latch Enable
Jan 12 10:20:53 <xback> but Im not seeing other purposes for the same GPIO's connected to it :s
Jan 12 10:22:28 <blogic> xback: they are the cs line of spi, nand, ....
Jan 12 10:22:29 <xback> blogic: I think that driver just ensures that GPIO 11 (LE) gets enabled when one of those latch GPIO's gets used.  correct?
Jan 12 10:22:38 <blogic> yes
Jan 12 10:23:07 <blogic> so when you pull LE the in bits get copied to out
Jan 12 10:23:18 <blogic> then disabling LE again makes the out state persistent
Jan 12 10:25:53 <xback> blogic: https://github.com/yandex/smart/blob/master/Documentation/devicetree/bindings/gpio/gpio-mm-lantiq.txt
Jan 12 10:26:00 <xback> is this how it should be defined in DT ?
Jan 12 10:31:18 <blogic> different
Jan 12 10:31:24 <blogic> EBU is an intel/hitachi bus
Jan 12 10:32:05 <blogic> so there is a memory location that you write that gets pushed onto a bus and there is a latch to switch between addr and data
Jan 12 10:33:22 <xback> blogic: thanks for your time :-) I think I know how to proceed from here .. hopefully
Jan 12 10:33:39 <blogic> good luck on your journey
Jan 12 11:06:23 <nlowe> jow: I have made the discussed changes to: https://github.com/openwrt/luci/pull/4713
Jan 12 11:06:44 <nlowe> jow: Are you happy with the changes in principle?
Jan 12 11:31:03 <dorf_> I'm not the one doing the approval, nlowe, but those changes look pretty sane to me.
Jan 12 11:32:07 <dorf_> I'm all for terse, descriptive labeling and you've hit the right note.
Jan 12 11:35:08 <dorf_> there are a couple of places where you're not consistent, however.. if you're going to remove "the" then you probably should do that globally.
Jan 12 11:35:21 <dorf_> e.g. Validate the server certificate against the built-in system CA bundle
Jan 12 11:35:28 <dorf_> is "the" necessary?
Jan 12 11:36:35 <dorf_> and: Certificate constraint against the Subject CN .. you've got "the" there but not in related labeling.
Jan 12 11:37:04 <dorf_> e.g. Certificate constraints against Subject Alternate Name values
Jan 12 11:38:15 <dorf_> I also personally prefer "(if available)" to ", if available,"
Jan 12 11:38:50 <dorf_> the leading comma in any event is spurious.
Jan 12 11:39:56 <grift> i agree with those observations (fwiw)
Jan 12 11:40:57 <dorf_> also, I think "Validate server certificate against the" is less clear than "Validate server certificate using"
Jan 12 11:47:16 <dorf_> yeah, not a fan of "against" in any context tbh.
Jan 12 11:48:08 <dorf_> wherever I'm seeing "against", "using" seems like a better fit.
Jan 12 11:54:14 <nlowe> dorf_: Thanks for the feedback. The idea was to not start descriptions with "This or the" but this word could be used in a description. Will cycle through and see what I can do.
Jan 12 11:54:24 <pavlix> Hi folks. I'm using Linux 5.10 with OpenWRT. Can the its configuration to the treee? Cc nbd
Jan 12 11:54:52 <dorf_> nlowe: no problem
Jan 12 11:55:10 <pavlix> I'm building externally and for some unknown reason kconfig.pl complains about a Parse error.
Jan 12 11:55:19 <dorf_> nlowe: these things invariably evolve, anyways, once someone decides they merit attention :)
Jan 12 11:56:01 <pavlix> I mean… I'm now building externally and would like to build a part of OpenWRT and when I'm trying to do that, I'm getting the error.
Jan 12 12:22:37 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_ath79.html has been updated. (99.2% images and 98.4% packages reproducible in our current test framework.)
Jan 12 12:26:26 <ldir> Sorry, my makefile foo is absent.  Often when I do 'make' to build openwrt or indeed ./scripts/feeds update -a, the build system goes through the build pre-reqs checks (working make, gcc, working-gcc etc blah blah blah) and I don't understand why.  Can someone educated me?
Jan 12 13:33:44 <PaulFertser> pavlix: your question is unclear
Jan 12 13:34:01 <PaulFertser> pavlix: what are you building externally, why, who complains where etc
Jan 12 13:35:16 <pavlix> PaulFertser: Thanks a lot. I solved that in the meantime by adding 5.10 config and a few other changes from nbd 's staging. I'm looking forward to getting native support for Linux 5.10, though.
Jan 12 13:36:19 <nbd> 5.10 will be pushed to openwrt master after we've created the next release branch
Jan 12 13:40:17 <johnf> I'm building a new image and I'm over the rather pathetic flash size of my device
Jan 12 13:40:36 <johnf> [mktplinkfw] *** error: images are too big by 455463 bytes
Jan 12 13:40:52 <johnf> is there an easy way to analyze the size of the different selected components?
Jan 12 13:43:59 <johnf> oh, I've got some v6 stuff I don't need
Jan 12 13:47:47 <johnf> it didn't help much
Jan 12 14:02:02 <dorf_> johnf: you can do that with luci, but I guess that won't help you much.
Jan 12 14:02:24 <johnf> no, I don't have luci built in these systems
Jan 12 14:02:30 <johnf> but that could still be helpful, maybe
Jan 12 14:02:36 <johnf> where in luci?
Jan 12 14:02:48 <dorf_> system -> software
Jan 12 14:02:57 <dorf_> it indicates the size of the .ipk
Jan 12 14:03:16 <johnf> yeah, I see what you're saying
Jan 12 14:03:23 <johnf> though all my sizes are 0 on this other device
Jan 12 14:03:27 <johnf> as I've got nothing from ipkg
Jan 12 14:03:47 <johnf> and the way these firmwares are built, in the current form, nothing is installed from ipkg, all built in using imagebuilder
Jan 12 14:04:37 <dorf_> yeah, but the .ipk will give you _some_ indication of the required space of the packages.
Jan 12 14:05:08 <johnf> what I'm doing now actualy, is the build outputs a list of ipkgs being installed
Jan 12 14:05:24 <johnf> so I can parse that and get the sizes, and see what packages are largest
Jan 12 14:05:40 <johnf> I suspect my problem is probably principally frr
Jan 12 14:05:47 <johnf> thanks for the suggestions, appreciate it
Jan 12 14:16:30 <pavlix> nbd: Does that mean that the next release will be based on 5.4?
Jan 12 14:17:37 <adrianschmutzler> pavlix: yes
Jan 12 14:18:56 <pavlix> adrianschmutzler: That is a pity due to some DSA driver changes in the kernel. On the other hand, not having a proper DSA based release out is even worse, I guess.
Jan 12 14:19:25 <johnf> I'm excluding a package from imagebuilder using PACKAGES="-hostapd-common", it's still getting built, I'm assuming something else depends on it, how can I understand the cause of that dependancy
Jan 12 14:19:42 <johnf> I should say, integrated, not built
Jan 12 16:07:19 <bkallus> the actiontec mi424wr rev i is based on the marvell 88f6560 SoC, which is not supported by the mainline linux kernel. Despite that, bodhi at doozan.com managed to get it booting a 5.2 kernel for his kirkwood debian distribution. I have the new dts/dtsi files, but I'm not sure which config file to modify to allow me to build an openwrt image for this new target from `make menuconfig`
Jan 12 16:42:42 <plntyk> bkallus, afaik the doozan stuff uses the normal upstream dts file - iirc from the posted bootlog in the thread he uses kirkwood-sheevaplug.dts
Jan 12 16:45:36 <plntyk> bkallus, look in target/linux/kirkwood/image/Makefile and the git history for that file
Jan 12 17:20:45 <bkallus> bodhi ported over the device tree files from pandorabox, so they are different dts files. the sheevaplug stuff doesn't fully boot, but the new ported one does
Jan 12 17:23:42 <bkallus> I have the new set of dts/dtsi files, i just want to know which files to edit so that I can compile them in with make menuconfig
Jan 12 17:26:09 <rsalvaterra> nbd: ping
Jan 12 17:27:14 <rsalvaterra> I'm seeing some mt76 oddness. I can't ping/ssh into wi-fi connected clients.
Jan 12 17:30:57 <shibboleth> so, driver issue then?
Jan 12 17:31:51 <rsalvaterra> I have no idea. Note that from inside the router, I can ping the wi-fi clients (I don't have ssh to test, though). From another client, I can't ping the wi-fi clients.
Jan 12 17:32:16 <shibboleth> ap isolate on?
Jan 12 17:32:29 <rsalvaterra> No.
Jan 12 17:33:19 <rsalvaterra> I have multiple vifs. Some of them are isolated, the LAN isn't, of course.
Jan 12 17:33:42 <shibboleth> so you're sure it isn't an issue of firewalling?
Jan 12 17:34:02 <rsalvaterra> I'm absolutely sure. My Omnia, with the exact same configuration and two ath10k cards works fine.
Jan 12 17:35:16 <shibboleth> and you're not using wds?
Jan 12 17:36:04 <shibboleth> tcpdump on the brige interfaces, is traffic received and forwarded?
Jan 12 17:36:28 <rsalvaterra> No relevant traffic caught on tcpdump.
Jan 12 17:36:46 <rsalvaterra> And WDS is something I avoid like the plague.
Jan 12 17:37:08 <shibboleth> STA1 <-> AP <-> STA2
Jan 12 17:37:14 <shibboleth> ping sta2 from sta1
Jan 12 17:37:19 <shibboleth> and tcpdump on the ap
Jan 12 17:37:27 <shibboleth> not even picking up the pings?
Jan 12 17:37:45 <rsalvaterra> I told you, the AP doesn't see the ICMP arriving at the bridge.
Jan 12 17:38:33 <rsalvaterra> Which is weird as hell.
Jan 12 17:39:10 <shibboleth> hmm...
Jan 12 17:40:28 <rsalvaterra> So, yeah, I'm a bit stumped.
Jan 12 17:40:48 <rsalvaterra> I wouldn't be asking nbd otherwise. :P
Jan 12 17:43:51 <nick[m]> With the introduction of abi in iwinfo, can we add back the channel quality stuff?
Jan 12 17:48:49 <plntyk> bkallus, see the commit history + the dts files should be put in target/linux/kirkwood/files-<kernelver> where they will be used if you edit the makefile correctly
Jan 12 18:05:23 <nbd> rsalvaterra: what device are you using?
Jan 12 18:06:09 <rsalvaterra> nbd: It's a Xiaomi Redmi RM2100. MT7603 + MT7615.
Jan 12 18:06:54 <rsalvaterra> (It's offline at the moment, I'm using the Omnia.)
Jan 12 18:07:19 <nbd> and do you have the odd behavior on 2.4 ghz or 5 ghz?
Jan 12 18:08:00 <rsalvaterra> Good question. Definitely on 5 GHz, not sure on 2.4 GHz. I have the same SSID on both bands.
Jan 12 18:08:31 <shibboleth> shutdown the 5ghz radio
Jan 12 18:09:33 * rsalvaterra goes to replace the router…
Jan 12 18:19:01 <rsalvaterra> Hm… 2.4 GHz seems to be working now…
Jan 12 18:22:10 <rsalvaterra> That's another thing I noticed… I usually can connect to the clients for a while, after they boot. But after a couple of hours I stop being able to access them. It's… weird.
Jan 12 18:29:15 <nbd> rsalvaterra: what version of openwrt are you using?
Jan 12 18:29:50 <rsalvaterra> nbd: master, built from scratch, with my pending patches.
Jan 12 18:30:07 <johnf> I'm creating a firmware image using the imagebuilder
Jan 12 18:30:10 <rsalvaterra> (Nothing mt76 related, though.)
Jan 12 18:30:24 <johnf> something is creating a dependancy on libustream-wolfssl
Jan 12 18:30:35 <johnf> is there a way to tell what's creating the dependancy?
Jan 12 18:31:07 <johnf> also, output from the make image process is overlapping, making it a bit harder to understand what's
Jan 12 18:31:10 <johnf> going on
Jan 12 18:31:33 <johnf> specifically, Collected errors is ending up on top of a Configuring line
Jan 12 18:34:18 <rsalvaterra> nbd: this is my rm2100 tree: https://gitlab.com/rsalvaterra/openwrt/-/commits/st1004kc/
Jan 12 18:34:27 <rsalvaterra> Nothing too controversial there, I believe.
Jan 12 19:06:10 <nbd> rsalvaterra: no idea at the moment. i'll let you know if i find something
Jan 12 19:19:03 <rsalvaterra> nbd: thanks, no worries. This was just to share my weirdness with the rest of the world. Hopefully someone will be able to reproduce it. :)
Jan 12 20:28:51 <aparcar[m]> anyone here with decent perl skill able to write me a "unique in list" function?
Jan 12 20:35:32 <karlp> system(@list | uniq) ;)
Jan 12 20:45:33 <aparcar[m]> karlp: found something without the lib:) my @unique = do { my %seen; grep { !$seen{$_}++ } @data };
Jan 12 21:45:54 <Tapper1> and we are up and running. Will kick the weeles a bit and see what breaks.
Jan 12 21:59:50 <Borromini> breaking things again Tapper ?
Jan 12 22:01:38 <Tapper> O yeah SELinux is propper broken.
Jan 12 22:02:11 <Tapper> sqm addblock banip and dns over https proxy plus a lot of luci will not work.
Jan 12 22:05:23 <stintel> that's to be expected, as the author of the SELinux policy for OpenWrt thinks all of that are corner cases that nobody will ever use
Jan 12 22:05:41 <stintel> so he doesn't care about, and thinks you should fix it instead, if you want to use it
Jan 12 22:06:48 <Tapper> hahaha O hell no!
Jan 12 22:07:04 <Borromini> :P
Jan 12 22:07:57 <stintel> Tapper: so make a choice: no selinux for you or no internet for you :P
Jan 12 22:09:02 <Tapper> O such a hard choice! It is not like my wife would not put a blade to my nec if she has no netflix lol
Jan 12 22:09:13 * Tapper shudders!
Jan 12 22:09:21 <Slimey> heh
Jan 12 22:09:40 <stintel> Tapper: you can't see that anyway, it would be an ineffective threat?
Jan 12 22:10:15 <Tapper> I could feel the cold hard steel!
Jan 12 22:10:30 <stintel> that's what she said 😂
Jan 12 22:10:52 <Tapper> Can you get prreemptive PTSD?
Jan 12 22:11:32 <Borromini> pre-traumatic stress disorder?
Jan 12 22:11:35 <Borromini> of course ;)
Jan 12 22:12:27 <Tapper> You are fucking shitting me I cant sysupgrade!
Jan 12 22:12:45 <Tapper> Putty here we come
Jan 12 22:13:06 <stintel> yeah I wouldn't recommend SELinux
Jan 12 22:13:18 <stintel> on redhat, sure
Jan 12 22:13:32 <stintel> but on OpenWrt? too much untested "corner cases" that will never work
Jan 12 22:13:40 <stintel>  /105
Jan 12 22:13:54 <Borromini> Tapper: lol
Jan 12 22:14:07 <Borromini> you know what you were up for :P
Jan 12 22:17:47 <Tapper> O I can breath again!
Jan 12 22:18:13 * ldir is glad selinux fails to build under macos 
Jan 12 22:18:25 * stintel refrains from making a comment
Jan 12 22:18:33 <Tapper> breathe*
Jan 12 22:19:20 <Borromini> and they say it's just catholics that like to torture themselves =)
Jan 12 22:19:40 <Tapper> After all that excitement I am going to make a cup of tea brb
Jan 12 22:19:48 <Tapper> hahaha
Jan 12 22:37:06 <ynezz> johnf: libustream-wolfssl is default package, check include/target.mk
Jan 12 22:38:03 <johnf> ynezz: i tried to remove it with -libustream-wolfssl, but I managed to get my kernel size down and my build is relatively ok now
Jan 12 22:43:15 <Borromini> johnf: if you use per device rootfs & packages you can strip it form your final image
Jan 12 22:48:56 <johnf> hmm, actually, it's interesting you say that
Jan 12 22:49:01 <johnf> but I've got to go right now
Jan 12 22:49:06 <johnf> I might have a few more questions tomorrow
Jan 12 22:49:19 <johnf> but per device rootfs did come up while I was working on this
Jan 12 22:49:36 <johnf> and, while usually I work on a clean tree, I did built another ath79 image on this config before
Jan 12 22:49:41 <johnf> for a different device
Jan 12 22:52:45 <Borromini> if you are building more than one device on ath79, even more reason to use it
Jan 12 22:53:08 <Borromini> i build e.g. ath79 and ramips/mt7621 for multiple devices, each in one run (one per target)
Jan 13 00:05:46 <mangix> rmilecki: do these new broadcom devices have any wifi support?
Jan 13 00:06:12 <mangix> rmilecki: by new I mean anything past the MIPS stuff
Jan 13 00:21:10 <hurricos> mangix: high-end broadcom chips usually support brcmfmac. But the driver has ... quirks
Jan 13 00:21:39 <hurricos> I'm not sure about 11ax, but bcm43465 (4x4 wave2 11ac) works fine under x86 OpenWrt.
Jan 13 00:26:48 <hurricos> But you were asking about fully embedded stuff.
Jan 13 00:27:34 <mangix> hurricos: of course
Jan 13 00:44:27 <pkgadd> hurricos: do you happen to know about bcm43684 in regards to this (softmac vs fullmac)? (I could get my hands to a device with BCM4906+BCM43684+BCM43684 for rather cheap, but... OpenWrt would be a hard requirement ;)
Jan 13 00:46:39 <hurricos> the problem with Broadcom is they make a zillion chips and freely document almost none of them. A lot like Realtek in this respect.
Jan 13 00:46:49 <pkgadd> yep :(
Jan 13 00:47:28 <pkgadd> well, realtek at least provides driver source (crap drivers, but at least something)
Jan 13 00:48:11 <hurricos> pkgadd: one thing I can say: if Broadcom hasn't put the firmware in one of the Linux git trees you're not getting it working under OpenWrt
Jan 13 00:48:38 <hurricos> If you can hunt down the pci ids -- even in u-boot, though I doubt they still use that, do they? -- then you can look them up and see where they fall in brcmfmac's firmware loading process
Jan 13 00:48:41 <hurricos> if they don't? not supported
Jan 13 00:50:00 <pkgadd> thanks
Jan 13 00:50:29 <hurricos> I also had some luck finding info based on what is being uh -- brought into OpenWrt by oh -- there's one person's tree on git.openwrt.org for this ...
Jan 13 00:51:48 <hurricos> I have no idea who it was :egg on face:
Jan 13 00:52:00 <hurricos> someone in 2020 brought in brcmfmac-firmware-4366c0
Jan 13 00:52:38 <hurricos> the other problem for you is that your chip being named something does not mean that's the firmware file it needs :^( e.g. that^ firmware file supports brcm43465
Jan 13 00:53:29 <hurricos> bcm43465*
Jan 13 00:55:37 <pkgadd> well, I've never considered this device seriously, but it could be a nice one (if bcm43684 were supportable by brcmfmac)
Jan 13 00:57:01 <hurricos> It would be interesting to see the content of the flash. That would help us find the firmware -- even if it is not distributable it gives a good target so we can know as soon as it *is*
Jan 13 00:57:22 <hurricos> they're all arm MCUs. https://blog.quarkslab.com/reverse-engineering-broadcom-wireless-chipsets.html
Jan 13 00:58:25 <hurricos> actually in the context of thie article all bcm chips should be considered wildly insecure :^)
Jan 13 00:58:38 <hurricos> sorry, wlan soc's
Jan 13 01:01:02 <pkgadd> don't have the device at my disposal, but checking the binary firmware finds /etc/wlan/dhd/43684b0/rtecdc.bin
Jan 13 01:01:18 <hurricos> can you binwalk it?
Jan 13 01:01:30 <hurricos> or actually -- yeah, do just check that article out for the methodology.
Jan 13 01:01:48 <pkgadd> dhd rings a bell in this regard, with some hoep for fullmac
Jan 13 01:02:09 <pkgadd> http://paste.debian.net/1180873/
Jan 13 01:03:46 <pkgadd> http://paste.debian.net/1180874/
Jan 13 01:04:24 <hurricos> I recognize none of this :^)
Jan 13 01:05:01 <hurricos> oh - the dhd I see from the quarkslab link I posted.
Jan 13 01:05:32 <hurricos> well, but that's not brcmfmac - and I don't believe openwrt packages bcmdhd, and probably with good reason
Jan 13 01:05:46 <pkgadd> yeah, kind of promising (in the potential for support sense, not really in a security sense)
Jan 13 01:10:01 <hurricos> yeah. bcmdhd is for the Android kernel, not Linux.
Jan 13 01:10:21 <hurricos> I think with the bcm43465 the reason it works with brcmfmac is because it is manufactured as well as an independent module
Jan 13 02:28:42 <aparcar[m]> mangix: msort.c:201: Error: opcode 'dmb' not supported for target arc700
Jan 13 02:28:54 <aparcar[m]> mangix: ideas?
**** ENDING LOGGING AT Wed Jan 13 02:59:57 2021