**** BEGIN LOGGING AT Tue Jul 07 02:59:58 2020
Jul 07 03:50:48 <owrt-snap-builds> build #368 of zynq/generic is complete: Failure [failed kmodconfig]  Build details are at http://buildbot.openwrt.org/master/images/builders/zynq%2Fgeneric/builds/368  blamelist: Martin Blumenstingl <martin.blumenstingl@googlemail.com>, Sunguk Lee <d3m3vilurr@gmail.com>, Matthew Gyurgyik <matthew@gyurgyik.io>, David Bauer <mail@david-bauer.net>, Sungbo
Jul 07 03:50:49 <owrt-snap-builds> Eo <mans0n@gorani.run>, Adrian Schmutzler <freifunk@adrianschmutzler.de>, Christoph Krapp <achterin@googlemail.com>, Jan Hoffmann <jan@3e8.eu>, Lars Wessels <software@bytebox.org>, Aleksander Jan Bajkowski <A.Bajkowski@stud.elka.pw.edu.pl>
Jul 07 03:52:14 <owrt-snap-builds> build #357 of ath79/tiny is complete: Failure [failed defconfig dltar]  Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Ftiny/builds/357  blamelist: Martin Blumenstingl <martin.blumenstingl@googlemail.com>, Sunguk Lee <d3m3vilurr@gmail.com>, Matthew Gyurgyik <matthew@gyurgyik.io>, David Bauer <mail@david-bauer.net>, Sungbo
Jul 07 03:52:14 <owrt-snap-builds> Eo <mans0n@gorani.run>, Adrian Schmutzler <freifunk@adrianschmutzler.de>, Christoph Krapp <achterin@googlemail.com>, Jan Hoffmann <jan@3e8.eu>, Lars Wessels <software@bytebox.org>, Aleksander Jan Bajkowski <A.Bajkowski@stud.elka.pw.edu.pl>
Jul 07 03:53:46 <owrt-snap-builds> build #345 of ipq40xx/generic is complete: Failure [failed defconfig dltar]  Build details are at http://buildbot.openwrt.org/master/images/builders/ipq40xx%2Fgeneric/builds/345  blamelist: Martin Blumenstingl <martin.blumenstingl@googlemail.com>, Sunguk Lee <d3m3vilurr@gmail.com>, Matthew Gyurgyik <matthew@gyurgyik.io>, David Bauer <mail@david-
Jul 07 03:53:46 <owrt-snap-builds> bauer.net>, Sungbo Eo <mans0n@gorani.run>, Adrian Schmutzler <freifunk@adrianschmutzler.de>, Christoph Krapp <achterin@googlemail.com>, Jan Hoffmann <jan@3e8.eu>, Lars Wessels <software@bytebox.org>, Aleksander Jan Bajkowski <A.Bajkowski@stud.elka.pw.edu.pl>
**** BEGIN LOGGING AT Tue Jul 07 04:29:41 2020
**** BEGIN LOGGING AT Tue Jul 07 05:22:32 2020
**** BEGIN LOGGING AT Tue Jul 07 05:56:26 2020
Jul 07 06:58:24 <jow> managed to finish a working proof of concept for dsa uci configuration: https://gist.github.com/jow-/ae0f51a27f20a14e4b9e8416956f60bb
Jul 07 06:58:38 <jow> still needs some cleanup. requires ip-bridge and ip-full to function
Jul 07 07:28:12 <nitroshift> jow, nice!
Jul 07 07:42:47 <Borromini> jow: cool :). Will LuCI still need adaptations or does it fully rely on what UCI does and reports?
Jul 07 07:50:16 <jow> Borromini: it needs some adaptations to cope with the different port notation /[0-9]+[ut]?/ vs. /\w+(?:\.[ut])?/
Jul 07 07:50:28 <jow> and it also queries swconfig yet
Jul 07 07:50:45 <jow> the above is just an rfc though, maybe it makes sense to name the sections differently
Jul 07 07:51:13 <jow> config_dsa + config_dsa_vlan + config_dsa_port instead of config_switch + config_switch_vlan + config_switch_port
Jul 07 07:56:33 <Grommish> Anyone familar with this error?
Jul 07 07:56:33 <Grommish> make[2]: Entering directory '/home/grommish/openwrt/feeds/luci/collections/luci'
Jul 07 07:56:33 <Grommish> make[2]: execvp: /usr/bin/env: Argument list too long
Jul 07 08:00:31 <jow> Grommish: https://patchwork.ozlabs.org/project/openwrt/cover/20200219215212.31263-1-cotequeiroz@gmail.com/
Jul 07 08:01:04 <jow> https://patchwork.ozlabs.org/series/159595/mbox/
Jul 07 08:01:35 <Grommish> jow: You are amazing, sir.. Thank you
Jul 07 08:45:51 <rsalvaterra> jow: getconf ARG_MAX gives me 2 MiB. That must be the argument list from hell. :P
Jul 07 08:47:24 <jow> the list of all absolute paths of all packages
Jul 07 08:47:41 <jow> depending on the nesting depth of the buildroot topdir I see how those 2MB can be easily reached
Jul 07 08:47:53 <rsalvaterra> Yeah, indeed.
Jul 07 08:49:08 <ynezz> 2MB ought to be enough for anyone.
Jul 07 08:50:15 <rsalvaterra> ynezz: On Linux 2.6.23 the limit was 128 kiB, so… I guess? :D
Jul 07 08:50:18 <dwmw2_gone> Almost enough. I'd like to have the extra 97152 bytes if it's all the same with you.
Jul 07 08:50:39 <Grommish> ynezz: i blame all the delicious packages in the repo
Jul 07 08:53:01 <Grommish> ynezz: but yes, the vast majority will never run into the issue
Jul 07 08:57:58 * rsalvaterra looks at 201-extra_optimization.patch
Jul 07 08:58:16 <rsalvaterra> Do we still need -fno-reorder-blocks -fno-tree-ch at -Os?
Jul 07 09:00:26 <rsalvaterra> I've been building 19.07 for my ath79 devices without these options, without any problems.
Jul 07 09:05:15 <rsalvaterra> I don't know if there's some obscure arch which needs them, of course.
Jul 07 09:20:19 <jow> is mwlwifi not supporting ap+sta operation?
Jul 07 09:23:40 <rsalvaterra> jow: Still having fun with mvebu, I see.
Jul 07 09:23:44 <jow> https://pastebin.com/jM4ES2Pu
Jul 07 09:23:49 <jow> seems its shitting all over itself
Jul 07 09:24:29 <jow> so far the experience with this model is underwhelming at best
Jul 07 09:24:52 <PaulFertser> Should have banned linksys from using the OpenWrt(tm) ;)
Jul 07 09:25:29 <Grommish> They were better before Cisco :)
Jul 07 09:25:57 <jow> apparently I managed to somwhow complete kill the radio
Jul 07 09:26:11 <jow> rmmod/insmod not working either
Jul 07 09:26:33 <rsalvaterra> Hey, the mvebu platform is great. The problem with Linksys mvebu devices is in the shitty Avastar chips.
Jul 07 09:26:34 <jow> reboot time
Jul 07 09:27:08 <jow> yeah, it is not working in a very fast manner
Jul 07 09:28:08 <rsalvaterra> The Omnia is mvebu done right.
Jul 07 09:29:52 <rsalvaterra> jow: About AP+STA, what are the valid interface combinations in iw list?
Jul 07 09:32:08 <rsalvaterra> For example, one of my QCA9880 cards shows this…
Jul 07 09:32:08 <rsalvaterra> 	valid interface combinations:
Jul 07 09:32:08 <rsalvaterra> 		 * #{ managed, P2P-client } <= 8, #{ P2P-GO } <= 3, #{ AP } <= 8, #{ IBSS } <= 1,
Jul 07 09:32:08 <rsalvaterra> 		   total <= 8, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz }
Jul 07 09:32:29 <rsalvaterra> … which means it doesn't support AP+STA (I think).
Jul 07 09:32:54 <jow> https://pastebin.com/zKfsDJye
Jul 07 09:32:57 <jow> garbage
Jul 07 09:33:10 <jow> seems only phy2 supports ap-sta
Jul 07 09:33:32 <jow> yet I wouldn't expect the driver to freeze
Jul 07 09:34:12 <rsalvaterra> Oh, right! "STA/AP BI must match", so the QCA9880 supports AP+STA.
Jul 07 09:35:23 <rsalvaterra> jow: Garbage, indeed. :(
Jul 07 09:35:51 <Grommish> rsalvaterra: shoudn't it read #{ managed, AP, P2P-client } if it supports AP+STA?
Jul 07 09:36:06 <Grommish> Or am I reading it wrong.. Trying to learn
Jul 07 09:36:08 <PaulFertser> rsalvaterra: managed is STA, so it tells you that you can have up to 8 managed interfaces and up to 8 APs (but not more than 8 overall).
Jul 07 09:36:30 <PaulFertser> rsalvaterra: "STA/AP BI must match" is an additional condition for beacon interval
Jul 07 09:37:08 <jow> didn't know that mwlwifi is that limited
Jul 07 09:37:21 <rsalvaterra> Grommish: I think so, I'm also not very good at interpreting that output. :)
Jul 07 09:37:47 <Grommish> Me either.. but luckily, my device doesn't have WiFi hehe
Jul 07 09:38:00 <rsalvaterra> PaulFertser: Right, but my reasoning was that condition implied support. :)
Jul 07 09:38:26 <PaulFertser> rsalvaterra: each * line is an allowed combination. It lists how many and what types are allowed in that combination and what additional restrictions are there. There can be more than one * lines.
Jul 07 09:40:23 <rsalvaterra> jow: In order of crappiness, I place Broadcom first. Marvell (Avastar, at least), is second.
Jul 07 09:41:26 <Borromini> rsalvaterra: and yet a lot of people in the openwrt community jumped on the WRT hype train
Jul 07 09:41:37 <Grommish> Woo.. Not the worst! cheer
Jul 07 09:42:47 <rsalvaterra> Grommish: Broadcom isn't just bad, it's actively harmful and evil.
Jul 07 09:43:05 <Grommish> I've got an R8000 :(
Jul 07 09:43:41 <rsalvaterra> Grommish: My condolences.
Jul 07 09:44:03 <Grommish> Yah.. it's just got stock because of the midding cto
Jul 07 09:44:12 <Grommish> err missing.. meh
Jul 07 09:45:02 <rsalvaterra> Borromini: I missed the WRT hype train only because distracted with the Turris Omina on Indiegogo. :P
Jul 07 09:45:16 <Grommish> the other box is an octeon3, which has been it's own bundle of joy
Jul 07 09:45:16 <rsalvaterra> *because I got
Jul 07 09:49:32 <rsalvaterra> Grommish: Octeon 3? Isn't that MIPS64 multicore?
Jul 07 09:49:45 <Grommish> rsalvaterra: yes..
Jul 07 09:50:07 <rsalvaterra> Grommish: Hmm… what box is that? :P
Jul 07 09:50:23 <Grommish> itus networks shield
Jul 07 09:50:53 <Tapper> People got on to the wrt bandwagon because Linksys  gave 50 wrt3200acms away oin the forums.
Jul 07 09:51:00 <Tapper> away*
Jul 07 09:51:06 <Grommish> https://deviwiki.com/wiki/Itus_Networks_Shield_Pro
Jul 07 09:51:18 <Grommish> you can find them from time to time online, but they were limited run before the company went under
Jul 07 09:51:38 <DonkeyHotei> iirc, octeon3 needed cavium's weird sdk to get openwrt running
Jul 07 09:51:53 <Grommish> I had to bring in the ethernet driver
Jul 07 09:52:12 <Grommish> but other than that.. I've not tried 5.4 yet, but 4.19 works
Jul 07 09:52:21 <Tapper> They would of had a hit on there hands if the wifi driver was not a crock of shit!
Jul 07 09:52:58 <DonkeyHotei> Grommish: did you fully port openwrt to that device?
Jul 07 09:53:28 <DonkeyHotei> might help support for other octeon3 devices, few as they may be
Jul 07 09:53:34 <Grommish> DonkeyHotei:  Yes..  I'm working on finalizing the target directory so it plays nice with subtargets and with the er/erlite because they  use octeon+
Jul 07 09:53:46 <DonkeyHotei> awesome
Jul 07 09:54:05 <rsalvaterra> Grommish: Nice!
Jul 07 09:54:18 <Grommish> My goal is to see if I can get it pulled.. because I'm really not up on building every package, every time to keep on my github for people to use opkg
Jul 07 09:54:36 <DonkeyHotei> what kind of performance have you been seeing on it?
Jul 07 09:54:39 * rsalvaterra goes to look for Itus Shield Pro on eBay…
Jul 07 09:54:47 <jow> Grommish: why do you need to build your own packages?
Jul 07 09:55:00 <Grommish> jow: because octeon3 is not a supported platform
Jul 07 09:55:26 <Grommish> jow: and the users who will use the firmware need access to the opkgs
Jul 07 09:56:27 <Grommish> DonkeyHotei: aside from some quirks with the fact its BigEndian, the builds have been pretty easy..  I get full speed on my Fiber conn (max at about 930/250)
Jul 07 09:56:30 <Borromini> Tapper: yeah well that doesn't open up a third party wireless driver of course =)
Jul 07 09:56:48 <Grommish> and it has 1gb ram and a dual core 1ghz cpu, so it isn't bad
Jul 07 09:57:11 <Grommish> Actually, apparently some of the very first Kickstarter versions had a Wireless chipset
Jul 07 09:57:15 <Grommish> But neither of mine do
Jul 07 09:57:20 <Grommish> So they are outta luck :D
Jul 07 09:57:25 <DonkeyHotei> i'd expect it to be on par with mt7621, since that is also mips
Jul 07 09:57:45 <rsalvaterra> Grommish: Big-endian is cool. I like it. :P
Jul 07 09:57:47 <Grommish> Though they could always install the kmods and libs for it if they have one, i suppose
Jul 07 09:57:54 * rsalvaterra has endianness issues
Jul 07 09:58:46 <SwedeMike> but mt7621 only does full gig with hw acceleration, does this octeon3 have that as well?
Jul 07 09:59:03 <Grommish> I'm still trying to figure out how to handle the sysupgrade..  I'm making the ext4 root, and the tar.gz ext4 images.. but I need a file that has both.. i need the sysupgrade kernel image combined with the rootfs.tgz
Jul 07 09:59:14 <Grommish> SwedeMike: Yes..
Jul 07 09:59:19 <Grommish> Both HW and SW
Jul 07 09:59:46 <SwedeMike> ok, I haven't kept up to date with what has hw acceleration nowadays. Last I looked, it was only mt7621
Jul 07 10:00:07 <Grommish> Or, at least, I have the option and I see a throughput increase
Jul 07 10:00:08 <DonkeyHotei> Grommish: take a look at how x86 does it
Jul 07 10:00:13 <SwedeMike> I'm on the WRT "hype train" because it's fast without hw acceleration, so I can run SQM
Jul 07 10:00:24 <Grommish> DonkeyHotei: So many thanks for the hint
Jul 07 10:01:05 <Grommish> I've got 850MB partitions for each image and I can only fit a few hundred mb root image into RAM before it dies from the watchdog
Jul 07 10:01:23 <rsalvaterra> DonkeyHotei: MT7621 is a dual-core SMT2 in-order MIPS32 arch at about 880 MHz. I'd say Octeon 3 is on another league.
Jul 07 10:01:45 <DonkeyHotei> and you might wanna look into f2fs instead of ext4
Jul 07 10:02:25 <Grommish> I looked into it because of the mmc, but it was so early on that I put it aside for compat issues with getting it to boot
Jul 07 10:02:39 <DonkeyHotei> x86 does f2fs
Jul 07 10:02:51 <Grommish> I will certainly check it out again
Jul 07 10:03:12 <Grommish> I'll just need to make sure my rescue image has it baked in
Jul 07 10:03:17 <SwedeMike> looking at octeon 3 https://www.marvell.com/products/infrastructure-processors/multi-core-processors/octeon-multi-core-mips64-processors/octeon-iii-cn7xxx.html this is... yes, magnitudes faster.
Jul 07 10:03:18 <Grommish> for when the bad things happen
Jul 07 10:03:33 <Grommish> Yeah, this is a CN7020AAP1.2
Jul 07 10:03:34 <DonkeyHotei> rsalvaterra: but not approaching mvebu
Jul 07 10:03:36 <rsalvaterra> For F2FS, you need the overlay to be larger than 128 MiB. I was actually bitten by that on my Omnia, a couple of weeks ago.
Jul 07 10:03:47 <SwedeMike> that looks more like a user-space networking server appliance.
Jul 07 10:03:53 <rsalvaterra> 128 MiB or less, you'll get ext4.
Jul 07 10:04:07 <Grommish> Was designed as a security device
Jul 07 10:04:24 <Grommish> has a GPIO switch on the front to allow triple boot
Jul 07 10:04:35 <rsalvaterra> DonkeyHotei: mvebu is fast. mvebu compiled by me is faster. :P
Jul 07 10:04:37 <Grommish> Though I'm dumping one
Jul 07 10:05:14 <DonkeyHotei> multi-stage boot, right?
Jul 07 10:05:30 <Grommish> Yes.. uboot, though I can't find a viable uboot for the board
Jul 07 10:05:42 <Grommish> So it has a 2013 version
Jul 07 10:06:07 <Grommish> and they don't seem to want to deal with the octeon3 version from the list archives I've seen
Jul 07 10:06:27 <Grommish> cavium/marvell suppositly has one, but again, not for the board
Jul 07 10:06:32 <Grommish> or at least, not that I can fidn
Jul 07 10:09:50 <DonkeyHotei> no source for the 2013 version?
Jul 07 10:09:53 <Grommish> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell.git is about as far as I've found
Jul 07 10:10:14 <Grommish> I've honestly not looked hard into it.. I have a hard enough time with OpenWrt heh
Jul 07 10:10:47 <DonkeyHotei> for most devices, openwrt does not touch u-boot
Jul 07 10:11:50 <Grommish> I'm not sure I should be touching it either.. not yet anyway
Jul 07 10:12:29 <Grommish> although I'd like to eventually try to build with the octeon toolchain
**** BEGIN LOGGING AT Tue Jul 07 10:14:46 2020
Jul 07 10:15:01 <Grommish> Would there be anything worth pulling from the 4.14 kernel they have posted you think?
Jul 07 10:15:30 <Grommish> most of the octeon stuff seems to be in the kernel already, some of the BGX stuff isn't though and I don't include it
Jul 07 10:15:38 <DonkeyHotei> anything in it that doesn't work in vanilla
Jul 07 10:15:54 <DonkeyHotei> GBX?
Jul 07 10:16:04 <DonkeyHotei> *BGX?
Jul 07 10:16:51 <Grommish> I'd have to check.. Maybe.. BGM?
Jul 07 10:17:46 <Grommish> cavium-bgx
Jul 07 10:18:31 <Grommish>  .../net/ethernet/cavium/octeon/octeon3-bgx-nexus.c
Jul 07 10:18:31 <Grommish>  .../net/ethernet/cavium/octeon/octeon3-bgx-port.c
Jul 07 10:18:31 <Grommish> and some octeon3 files
Jul 07 10:18:44 <DonkeyHotei> ethernet? that would help, i'm sure
Jul 07 10:18:52 <Grommish> but seems to be the octeon3 that isn't the 70xx series..
Jul 07 10:19:12 <Grommish> and I'm getting C++ errors which is beyond me :)
Jul 07 10:19:22 <DonkeyHotei> iirc, that chip series also had some sort of kernel-level hardware-based text processor
Jul 07 10:20:02 <DonkeyHotei> and the kernel isn't supposed to use c++
Jul 07 10:21:13 <Grommish> https://hastebin.com/aporagafey.coffeescript for the bgx explaination
Jul 07 10:22:31 <Grommish> Well.. When i get this working, I can then work on those patches.. I've got about 10 of them I put in the 700 range, but pulled the ones that weren't working that are designed for later SoC's I guess
Jul 07 10:25:34 <rsalvaterra> DonkeyHotei: you can't compile Linux with a C++ compiler because the kernel source has variable names which are C++ reserved keywords. It's a feature. ;)
Jul 07 10:30:37 <Grommish> I've set this device up with 3 subtargets (generic, Ubiq, and Itus).. I've got the three subtarget directories.. In the Itus defines, i've got 2 devices.. Is there a way to setup a base-files folder for each of them that is different?  Is there a Makefile flag for setting the base-file directory for the image?
Jul 07 10:41:08 <Grommish> or, if anyone knows of a build that does that or something similar i can look at
Jul 07 10:47:03 <DonkeyHotei> dangole: you worked on an octeon2 target at some point, no?
Jul 07 10:47:44 <dangole> DonkeyHotei: no, never touched that hardware.
Jul 07 10:48:02 <DonkeyHotei> nvm, sorry
Jul 07 10:48:33 <DonkeyHotei> i ask because Grommish is hoping to import an ethernet driver for octeon3
Jul 07 10:49:06 <Grommish> I've got the ethernet driver in for the 70xx, but it's the later Soc's that seem to be having issues being patched in
**** BEGIN LOGGING AT Tue Jul 07 11:21:02 2020
Jul 07 12:18:19 <johnf> I'm trying to build PACKAGE_kmod-xfrm-interface but I'm unable to select it
Jul 07 12:18:32 <johnf> I can't understand where things are going wrong with the dependancies
Jul 07 12:23:31 <PaulFertser> johnf: if you use ? it'll show you the dependencies.
Jul 07 12:24:57 <johnf> I've searched for the packages with / and find them, but they aren't in the menus
Jul 07 12:25:23 <Grommish> Check your arch
Jul 07 12:25:42 <johnf> https://gist.github.com/johnfzc/a1e840a3485a903ad9993707dfbf608b
Jul 07 12:25:48 <Grommish> if the package is limited by arch, it won't show either
Jul 07 12:26:05 <johnf> this is my current state, apologies for the awfulness of the gist
Jul 07 12:26:14 <Grommish> Your not using 4.14, right?
Jul 07 12:26:30 <dangole> johnf: you can toggle displaying unselectable package with the [Z] button in menuconfig. that should at least show the package and allow you to find out why you can't select it
Jul 07 12:26:58 <Grommish> The only thing I see is that package won't work under Kernel 4.14
Jul 07 12:27:07 <johnf> I'm using the default kernel version, wasn't really aware that this was configurable
Jul 07 12:27:18 <johnf> I've certainly adjusted kmods before, but not the actual version
Jul 07 12:27:37 <Grommish> It's in the target/linux/xxxxx/Makefile
Jul 07 12:28:03 <Grommish> 4.14, 4.19 and 5.4 are the current ones
Jul 07 12:29:43 <johnf> ah, I see
Jul 07 12:29:45 <nick[m]3> Someone ever had a problem like this? libboost_context.so.1.73.0 (64 bit, need 32)
Jul 07 12:30:09 <johnf> ok, so I'm on AR7xxx which is indeed using 4.14
Jul 07 12:30:28 <johnf> I'm guessing there's a reason this arch is on this older kernel version and that moving it up would be distinctly non-trivial
Jul 07 12:30:31 <johnf> lol
Jul 07 12:31:00 <Grommish> Not sure.. I don't know anything about that device series
Jul 07 12:31:55 <Grommish> If you are feeling frisky,  add KERNEL_TESTING_PATCHVER:=4.19 to your Makefile
Jul 07 12:32:24 <Grommish> make sure you touch it, then you'll see an option for building with the testing kernel
Jul 07 12:32:43 <Grommish> under.. global target options I think?  I'm building so I can't check
Jul 07 12:33:26 <johnf> field deployment with very large numbers of remote devices only accessible by VPN
Jul 07 12:33:30 <Grommish> You'll also want to copy the patches-4.14 to patches-4.19
Jul 07 12:33:33 <johnf> I'll never feel that frisky ;)
Jul 07 12:33:46 <Grommish> in target dir
Jul 07 12:33:59 <Grommish> and for giggles, the config-4.14 to config-4.19
Jul 07 12:34:02 <johnf> it's interesting to understand this, but I'm going to need to give up on xfrm interfaces
Jul 07 12:34:06 <Grommish> that'll get you setup for it
Jul 07 12:34:43 <johnf> unless there's a reason to believe that AR7xxx is almost ready for 4.19 or 5.4
Jul 07 12:35:13 <zorun> no, it will be phased out in favour of ath79
Jul 07 12:35:18 <zorun> which just got bumped to 5.4
Jul 07 12:36:05 <zorun> https://openwrt.org/docs/techref/targets/ath79
Jul 07 12:43:12 <johnf> oh, I see
Jul 07 12:43:19 <johnf> so I could try to build that target instead
Jul 07 12:43:20 <johnf> hmm
Jul 07 12:44:16 <karlp> meant to be "drop in " :)
Jul 07 12:44:51 <karlp> ar71xx is mach- file based, ath79 is dts based though, if you've got your own target
Jul 07 12:45:11 <johnf> I've got 2-3 target platforms
Jul 07 12:45:26 <johnf> a much older device, TL-WR842ND
Jul 07 12:45:31 <johnf> GL-iNet MiFi
Jul 07 12:45:43 <ador> hi, how do i know the reset gpio key from serial bootlog ? this is the bootlog of the new device I'm trying to port https://gist.github.com/shibajee/8fb5bd3fd422a8957a3de3f7352eed45
Jul 07 12:45:45 <johnf> and a non ath79 device, gl-inet mt-300n-v2
Jul 07 12:45:55 <karlp> I more meant if you had private ones in your own tree. ~most ar71xx intree are already available as ath79
Jul 07 12:46:01 <johnf> I see that I should be able to build the mifi on ath79 so this is pretty cool
Jul 07 12:46:44 <johnf> yeah, the tp-link appears to be selectable
Jul 07 12:50:59 <johnf> ah, nice, and I see that the mt300n-v2 which is MT76x8 / ramips is using a new enough kernel for the xfrm
Jul 07 12:51:02 <johnf> this is great
Jul 07 12:51:37 <johnf> thanks very much for your help karlp, Grommish , dangole and PaulFertser
Jul 07 12:51:38 <karlp> sometimes git pull does magic :)
Jul 07 12:51:51 <ador> there r gpio, gpio2, gpio3 in rampis...how do i know that which one is using current led function ?
Jul 07 12:52:08 <johnf> do you have led interfaces present on your device
Jul 07 12:52:11 <johnf> like, named?
Jul 07 12:52:21 <johnf> I guess not or they wouldn't be present as gpios
Jul 07 12:52:39 <ador> nope...they write as d4, d5 something like that
Jul 07 12:52:46 <johnf> I believe you'll need to try them and see what happens
Jul 07 12:53:02 <johnf> or ask the device manufacturer, which may or may not be an option
Jul 07 12:53:08 <ador> i got this from serial boot log
Jul 07 12:53:10 <ador> Disabling lock debugging due to kernel taint
Jul 07 12:53:24 <ador> does this tell anything ?
Jul 07 12:53:32 <johnf> this is ASIC
Jul 07 12:53:35 <johnf> I like that message
Jul 07 12:53:47 <Grommish> johnf: hah!
Jul 07 12:53:59 <johnf> it tells us you're running stock firmware with a tainted kernel, probably
Jul 07 12:54:03 <johnf> but that's nothing all that special
Jul 07 12:54:29 <ador> so, i have to play with all the option see which one working ?
Jul 07 13:10:53 <rsalvaterra> Eek! I just noticed we're compressing the BusyBox applet messages by default! This makes no sense, the squashfs rootfs is already highly compressed, compressing the messages will only add extra entropy.
Jul 07 13:11:12 * rsalvaterra will cook a patch…
Jul 07 13:17:22 <rsalvaterra> Patch sent.
Jul 07 13:30:01 <rsalvaterra> Question… is it possible to specify two SNAT rules for two different interfaces (one SNAT rule for each interface) on the same firewall zone, on /etc/config/firewall? For now, I'm doing it in /etc/firewall.user, since I haven't figured out how (if at all possible).
Jul 07 13:38:54 <jow> rsalvaterra: yes, there is "option device" for "config nat" rules
Jul 07 13:42:14 <rsalvaterra> jow: You mean "config redirect", right?
Jul 07 13:42:25 <jow> no, config nat is the new way
Jul 07 13:42:37 <jow> config redirect w/ target SNAT is deprecated
Jul 07 13:43:07 <rsalvaterra> Oh, nice… :P
Jul 07 13:43:57 <rsalvaterra> Is there an example somewhere? Nevermind the wiki…
Jul 07 13:45:50 <jow> config nat; option src wan; option snat_ip a.b.c.d; option device xyz
Jul 07 13:46:15 <jow> + option target SNAT
**** BEGIN LOGGING AT Tue Jul 07 13:52:36 2020
Jul 07 13:52:51 <rsalvaterra> jow: So, IIRC, if I have a static WAN IP a.b.c.d and want to use SNAT instead of MASQ, and my device is eth0 on the wan firewall zone, I should specify it like this…
Jul 07 13:52:51 <rsalvaterra> config nat
Jul 07 13:52:51 <rsalvaterra> 	option device 'eth0'
Jul 07 13:52:51 <rsalvaterra> 	option dst 'wan'
Jul 07 13:52:52 <rsalvaterra> 	option snat_ip 'a.b.c.d'
Jul 07 13:52:52 <rsalvaterra> 	option target 'SNAT'
Jul 07 13:55:58 <jow> option src wan
Jul 07 14:00:42 <rsalvaterra> Ah, src, makes sence. And the device is the interface specified in /etc/config/network, not the physical device itself, right?
Jul 07 14:00:46 <rsalvaterra> *sense
Jul 07 14:01:08 <jow> device is the physical one in this case
Jul 07 14:01:24 <jow> since it is just used for this disambiguation
Jul 07 14:01:38 <jow> in case you have multiple devices in your zone
Jul 07 14:02:47 <rsalvaterra> Yeah, this an APU2C4 managing two WAN ISP connections with mwan3. Both interfaces are in the same firewall zone.
Jul 07 14:03:20 <rsalvaterra> (And both have static IPs.)
Jul 07 14:17:22 <rsalvaterra> Well, that didn't work… :P
Jul 07 14:17:53 <rsalvaterra> Oh, wait! It did!
Jul 07 14:18:14 <rsalvaterra> I was looking at the wrong chain, sorry.
Jul 07 14:18:33 <rsalvaterra> Not it's in zone_wan_postrouting, not postrouting_wan_rule.
Jul 07 14:18:35 <rsalvaterra> *Now
Jul 07 14:18:56 <jow> if you omit option src it shoudl got directly into POSTROUTING
Jul 07 14:19:06 <jow> in case it is needed / not applicable to any zone
Jul 07 14:19:38 <rsalvaterra> jow: Hard to believe the wiki is so outdated. I just looked at the code, you started this change in 2014(!).
Jul 07 14:20:34 <jow> it is six years already? I always had it on the todo for $sometime
Jul 07 14:21:16 <rsalvaterra> It's over 6 years: https://git.openwrt.org/?p=project/firewall3.git;a=commit;h=31456301f514e3e04f61930bb00f6b2d99b4d067
Jul 07 14:22:25 <rsalvaterra> The problem with being a developer is that we reach a point we don't really care about documentation… we just go and read the code.
Jul 07 14:23:12 <jow> my problem with the wiki is that its structure became too complicated
Jul 07 14:23:26 <jow> I wrote most of the initial uci option reference
Jul 07 14:23:35 <jow> then it was split and distributed over dozen of pages
Jul 07 14:23:53 <jow> now I don't know where to put new section types
Jul 07 14:24:01 <jow> back in the day I just added a new table
Jul 07 14:24:22 <rsalvaterra> In this specific case, maybe here? https://openwrt.org/docs/guide-user/firewall/firewall_configuration#config_sections
Jul 07 14:25:05 <jow> yeah, lkely
Jul 07 14:31:23 <rsalvaterra> Oh, looks like I have to fix this, then… :P https://openwrt.org/docs/guide-user/network/wan/isp-configurations#altice_meopt_empresas
Jul 07 14:32:08 <jow> the config redirect approach is stil lfully working, but it is confusing due to the overloaded meaning of src_ip, src_dip, dest_ip
Jul 07 14:32:17 <jow> and src_port, src_dport and dest_port
Jul 07 15:08:18 <karlp> jow: yar, my patch yesterday fixed my home node/leaf tree issues, but hits infinite recursion when I get back into the admin tree.  Gonna keep trying to find something that works there :)
Jul 07 15:24:02 <jow> karlp: you could try keeping the existing logic but change all the type compares to just  type ~= "firstchild"
Jul 07 15:47:15 <karlp> yeah, I actually just added a "and also not first child"
Jul 07 15:47:25 <karlp> was just tidying up some other stuff, was going to send it to you.
Jul 07 16:01:23 <karlp> https://github.com/openwrt/luci/pull/4240
Jul 07 17:19:20 <owrt-snap-builds> build #457 of ath79/nand is complete: Failure [failed images]  Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Fnand/builds/457  blamelist: Adrian Schmutzler <freifunk@adrianschmutzler.de>, David Bauer <mail@david-bauer.net>
**** BEGIN LOGGING AT Tue Jul 07 17:48:59 2020
Jul 07 17:56:52 <Hauke> zorun: I have to push my fix for the rb91x_nand_remove()
Jul 07 18:32:54 <xdarklight> thank you for working on the DSA "integration" jow!
Jul 07 18:36:09 <olmari> Not asking for best device for openwrt, but developers perspective from current best chipset MFG or model etc which device I should be looking to have said chippie in, for most awesome wifi experience with owrt :P
Jul 07 18:36:40 <olmari> routing etc is not in focal point
Jul 07 18:43:44 <nickname_> ath9k and mt76 devices
Jul 07 18:59:28 <ador> porting a new device, how do I config this in dts file ?
Jul 07 18:59:35 <ador> MX25L3205D(c2 2016c220) (4096 Kbytes)
Jul 07 18:59:37 <ador> 0x0000003e0000-0x0000003f0000 : "SC Nvram"
Jul 07 19:01:00 <ador> should I configure the kernel+rootfs+chinese ui = firmware (denx) or just kernel+rootfs ?
Jul 07 19:12:19 <olmari> so mt76 it would be then, at least has 11ac :)
Jul 07 19:18:23 <xdarklight> olmari: newer mt76 chips also implement 802.11ax: https://github.com/nbd168/wireless/blob/2025b7abd79d7dff38f23124afdba037af9862e1/drivers/net/wireless/mediatek/mt76/mt7915/Kconfig - but I don't know if there's any board out in the wild which uses that chip
Jul 07 19:19:49 <olmari> Mm.. one shall dig
Jul 07 19:20:21 <olmari> Thank you all for pointers
Jul 07 19:20:45 <PaulFertser> ador: btw, if you ever plan to offer your code to upstream you need to base it on master, not 19.07 branch.
Jul 07 19:21:16 <PaulFertser> ador: the general rule about partitions is that you can use anything that won't harm the possibility of downgrading to vendor firmware.
Jul 07 19:21:43 <PaulFertser> ador: firmware,denx is suitable for when the bootloader is uboot and expects a kernel uimage at that location.
Jul 07 19:22:25 <nickname_> no ax devices supported yet afaik. but theres some 7915 stuff already. Mercury X18G, XDR1860
Jul 07 19:25:09 <PaulFertser> ador: so if one can somehow reasonably restore that "chinese ui" contents, it's ok to take over it.
Jul 07 19:25:52 <ador> PaulFertser: tnx for the info..another thing is any quick way to figure out all gpio keys ? there r gpio0, gpio1, gpio2..how can I figure out which one is actually using
Jul 07 19:26:36 <PaulFertser> ador: is vendor firmware based on openwrt by any chance?
Jul 07 19:27:04 <PaulFertser> ador: then take a look into /sys/kernel/debug/gpio
Jul 07 19:27:20 <ador> nope..it's a netgear router..I have GPL source code but couldn't find anything (linux 2.6.30)
Jul 07 19:28:16 <ador> there is ralink_gpio.c but it's a mess
Jul 07 19:28:54 <PaulFertser> ador: https://openwrt.org/docs/techref/hardware/port.gpio#finding_gpio_pins_input_on_the_pcb
Jul 07 19:29:45 <ador> I found this on serial bootlog-
Jul 07 19:29:47 <ador> led_pb_api: module license 'Sercomm' taints kernel.
Jul 07 19:29:54 <ador> does this tell anything ?
Jul 07 19:31:15 <PaulFertser> ador: it means there's some shitty kernel module, probably proprietary.
Jul 07 19:31:32 <PaulFertser> Most likely proprietary since the license is "Sercomm".
**** BEGIN LOGGING AT Tue Jul 07 19:57:41 2020
Jul 07 20:12:22 <dwmw2_gone> ynezz: yes please :)
Jul 07 20:12:25 <dwmw2_gone> (#3101)
Jul 07 20:14:27 <dwmw2_gone> I wanted to test the other supported mt7623 board first, but it arrived now and it's totally hosed.
Jul 07 20:15:13 <dwmw2_gone> master doesn't boot as described in https://bugs.openwrt.org/index.php?do=details&task_id=3217
Jul 07 20:15:37 <dwmw2_gone> and although updating it to 19.07 *does* work, it required the process I describe in https://forum.openwrt.org/t/cant-start-openwrt-19-07-2-on-unielec-u7623-02/61872/4 to rewrite the MBR from u-boot.
Jul 07 20:15:54 <dwmw2_gone> I hereby absolve myself of *all* responsibility for that board; sysupgrade or otherwise :)
Jul 07 20:16:01 <dwmw2_gone> but will poke at it anyway, separately.
Jul 07 20:32:49 <aparcar[m]> zorun: did you read the GSoD mail?
Jul 07 20:43:30 <owrt-snap-builds> build #381 of ramips/rt305x is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt305x/builds/381
Jul 07 21:28:47 <owrt-snap-builds> build #371 of armvirt/64 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/armvirt%2F64/builds/371
Jul 07 21:43:21 <owrt-snap-builds> build #369 of zynq/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/zynq%2Fgeneric/builds/369
Jul 07 22:19:22 <rsalvaterra> dwmw2_gone: That U7623-06 system looks *really* nice.
Jul 07 22:20:57 <owrt-snap-builds> build #358 of ath79/tiny is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Ftiny/builds/358
Jul 07 22:21:13 <owrt-snap-builds> build #346 of ipq40xx/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ipq40xx%2Fgeneric/builds/346
Jul 07 22:26:21 <rsalvaterra> Still, 512 MiB of RAM is a bit of a disappointment, even though it should be more than enough for a router.
Jul 07 22:44:50 <karlp> 1GB is an option if you speak to them
Jul 07 23:20:14 <nickname_> 512MB is a lot but yeah, more wont hurt ;)
Jul 07 23:20:25 <nickname_> that board is interesting
Jul 07 23:22:53 <Ivan_83> hi everyone again :)
Jul 07 23:23:35 <Ivan_83> I foud a way to make 32mb ram + 8mb flash to be mush more responsive in web ui
Jul 07 23:28:46 <Ivan_83> CONFIG_KERNEL_SQUASHFS_FRAGMENT_CACHE_SIZE=8 + CONFIG_TARGET_SQUASHFS_BLOCK_SIZE=64 = 512 kb ram, on cache miss - only 64kb required to read and unpack
Jul 07 23:29:42 <Ivan_83> default 1mb for frag size and 2 frags to cache consume 2mb ram, requires a lot time to unpack on cache miss
Jul 07 23:45:23 <owrt-1907-builds> build #187 of ar71xx/mikrotik is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ar71xx%2Fmikrotik/builds/187