**** BEGIN LOGGING AT Mon Jul 06 03:00:57 2020
Jul 06 03:03:39 <owrt-snap-builds> build #433 of apm821xx/nand is complete: Failure [failed defconfig dltar]  Build details are at http://buildbot.openwrt.org/master/images/builders/apm821xx%2Fnand/builds/433  blamelist: Hauke Mehrtens <hauke@hauke-m.de>
**** BEGIN LOGGING AT Mon Jul 06 03:06:48 2020
Jul 06 05:05:15 <owrt-snap-builds> build #436 of x86/generic is complete: Failure [failed kmodconfig]  Build details are at http://buildbot.openwrt.org/master/images/builders/x86%2Fgeneric/builds/436  blamelist: Hauke Mehrtens <hauke@hauke-m.de>
Jul 06 06:02:29 <russell--> ynezz: is there is reason "dropbear: make rsa-sha2-256 pubkeys usable again" isn't merged yet?
**** BEGIN LOGGING AT Mon Jul 06 06:28:57 2020
Jul 06 06:37:39 <jow> russell--: maybe missing tested-by acked-by
Jul 06 06:39:27 <owrt-1907-builds> build #137 of x86/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/x86%2Fgeneric/builds/137
Jul 06 06:40:10 <Grommish> jow: does the buildbot server use ccache?
**** BEGIN LOGGING AT Mon Jul 06 06:42:32 2020
Jul 06 06:42:58 <Grommish> jow: I'm building out CONFIG_ALL and if I use ccache, I get a fatal on luci, saying env too many arguments.. my ulimit -s and ulimit -n are both 65535.  Works fine if I have ccache off though
Jul 06 06:43:17 <jow> Grommish: iirc we removed ccache support a while back from the build servers
Jul 06 06:43:23 <jow> too many quirks for too little effect
Jul 06 06:43:35 <Grommish> jow: Thanks..
Jul 06 06:51:25 <Borromini> Grommish: ran into a few issues myself, which might boil down to using ccache...
Jul 06 06:52:41 <Grommish> Borromini: the luci issue is the only one I've personally seen, but could be.  it just is harsh to build out every package at -j1 V=sc for it haha
Jul 06 06:53:45 <Borromini> i'm not sure if everything gets recompiled if it's still in staging_dir or build_dir
Jul 06 06:53:50 <Borromini> even without ccache.
Jul 06 06:55:43 <Grommish> I wouldn't think so, but it still takes a while to bounce thru all the packages..  I just will leave ccache off and bo done with it
Jul 06 06:56:18 <Borromini> true enough. i sometimes still run -j16 V=s and then pry out the error messages
Jul 06 06:56:22 <Grommish> Though it would speed up single target builds
Jul 06 06:57:14 <Grommish> I usually run -j9, but I've found if I run a multiple of that it takes about the same time (slightly longer) but doesn't lag the system out
Jul 06 06:57:37 <Grommish> so I'll run it at -j27 and and wait
Jul 06 06:58:28 <Borromini> how many cores do you have? usually -j is the amount of cores to be optimal
Jul 06 06:58:34 <Grommish> I always heard it was n+1 for threads, but I ran across a thread about it and have started running tests
Jul 06 06:58:55 <Grommish> Threads+1
Jul 06 06:59:16 <Grommish> I've got a i7-4th gen Quad core, so 8 threads
Jul 06 06:59:22 <Borromini> Grommish: so did i. recently someone said just n though. don't remember why and who anymore but it made sense.
Jul 06 07:01:00 <Grommish> Yeah, I guess it's whatever gets the best results.. I lose some time, but experience wise, jamming the jobs so hard seems to provide less overall system lag
Jul 06 07:01:26 <Grommish> but the time loss is minimal vs what I get
Jul 06 07:02:38 <russell--> jow: i sent a Tested-by: three days ago, fwiw
Jul 06 07:02:45 <russell--> oh, but just to him
Jul 06 07:04:17 <Grommish> Does anyone know off hand if SUBTARGET directories that contain base-files is additive to the TARGET base-files, or replaces it completely?
Jul 06 07:08:11 <jow> Hauke: offloading is working :)
Jul 06 07:08:32 <jow> just did an iperf test desktop<>laptop from tagged to tagged port
Jul 06 07:08:40 <jow> now trying tagged to untagged
Jul 06 07:11:24 <jow> works too... great stuff
Jul 06 07:59:23 <jow> # ls -lh /sys/class/net/wan/of_node
Jul 06 07:59:24 <jow> lrwxrwxrwx    1 root     root           0 Jul  6 07:57 /sys/class/net/wan/of_node -> ../../../../../../../../../../firmware/devicetree/base/soc/internal-regs/mdio@72004/switch@0/ports/port@4
Jul 06 07:59:43 <jow> can I rely on "switch@" being present in the of_node property of a DSA switch port netdev?
Jul 06 08:00:20 <jow> I guess it refers to a label in DT but I wonder if using "switch" there is a just convetion or if it is mandated by the bindings
Jul 06 08:01:12 <rsalvaterra> jow: Welcome to the mvebu club! ;)
Jul 06 08:01:23 <rsalvaterra> (Been away for the weekend, just read the logs now.)
Jul 06 08:01:58 <jow> rsalvaterra: I don't plan using it. As soon as the DSA config is done I'll throw it on the test hardware pile
Jul 06 08:02:28 <rsalvaterra> Yeah, mwlwifi is crap.
Jul 06 08:03:39 <rsalvaterra> About the MTU issue… I don't remember the details, but one thing to look out for is that mvneta isn't capable of doing hardware CRC for frames > 1500 bytes, IIRC.
Jul 06 08:31:55 <rsalvaterra> Hauke: WPA3 on b43 really isn't that bad. Sure, management frames crypto and the butterfly handshake have to be done in software, but the AES-CCMP part will still be done in hardware. The CPU usage difference is within 2-3 % above that of WPA2 (measured on a 1.333 GHz iBook G4). Talk about teaching an old dog new tricks. ;)
Jul 06 08:32:59 <rsalvaterra> *dragonfly
Jul 06 08:58:29 <Namidairo> ah so that's why they don't advertise 160mhz in china
Jul 06 08:59:24 <Namidairo> every second channel looks disallowed lol
Jul 06 09:01:37 <Namidairo> looks a whole lot less worse on regdb though
Jul 06 09:02:12 <ador> Hi, I have a netgear device with Ralink MT7620N SoC and 4MB flash, 32MB ram..Is it possible to implement minimum support with luci web ?
Jul 06 09:02:49 <Namidairo> https://openwrt.org/supported_devices/432_warning
Jul 06 09:02:57 <ador> device info from telnet - https://gist.github.com/shibajee/8fb5bd3fd422a8957a3de3f7352eed45
Jul 06 09:03:19 <ador> I know the warning but there r still many devices supporting with 4MB flash
Jul 06 09:05:05 <Namidairo> "19.07 will be the last release with support for 4/32 MB devices."
Jul 06 09:06:06 <ador> So I should work with the 19.07 branch not with master
Jul 06 09:08:20 <PaulFertser> Namidairo: but it doesn't mean source code for those devices will be removed. It only means the autobuilders won't be cooking images for those devices.
Jul 06 09:09:19 <Namidairo> just don't expect too much help if something breaks horribly?
Jul 06 09:09:51 <PaulFertser> Namidairo: I do not think flash or RAM size plays that big of a role there.
Jul 06 09:10:34 <rsalvaterra> There's a brave guy running master on a WRT54G with 16 MiB of RAM.
Jul 06 09:11:15 <Namidairo> those are some interesting partition names though
Jul 06 09:13:14 <owrt-snap-builds> build #379 of ramips/rt305x is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt305x/builds/379  blamelist: Hauke Mehrtens <hauke@hauke-m.de>
Jul 06 09:14:38 <PaulFertser> rsalvaterra: it's very nice you continue looking into best ways to run on RAM-constrained targets!
Jul 06 09:15:25 <rsalvaterra> rsalvaterra: Not personally (yet, since I don't have the hardware), but yeah, it's kind of a fun hobby. :P
Jul 06 09:15:45 <rsalvaterra> Ooops! Brain fart.
Jul 06 09:16:04 <rsalvaterra> I meant PaulFertser, of course.
Jul 06 09:16:29 <Namidairo> worst case scenario, you have a router shaped frisbee to play with
Jul 06 09:16:51 <rsalvaterra> All my "constrained" targets are 8/128, at the moment. :D
Jul 06 09:17:36 <rsalvaterra> Namidairo: I have my reserves about router aerodynamics, but given enough thrust…
Jul 06 09:21:23 <Namidairo> at least the rt28xx drivers aren't as bad as they were a few years ago
Jul 06 09:22:02 <rsalvaterra> And it's quite ironic a lowly WRT54G with b43 Wi-Fi has WPA3 support, while all the WRT{1200,1900,3200}AC{,M,S} are stuck with WPA2.
Jul 06 09:24:08 <Namidairo> shall I begin asking about 2/8 support for one of the later WRT54G's I have on the shelf ;)
Jul 06 09:28:06 <rsalvaterra> Namidairo: 2/8… now there's a challenge I'm not sure I'm willing to accept. :P
Jul 06 09:30:06 <rsalvaterra> The worst possible router I've laid my hands on was actually from Linksys. Also a 2/8 device: WRK54G. I have no words to describe it.
Jul 06 09:38:06 <adrianschmutzler> but that's essentially why I think the current solution is a good one
Jul 06 09:38:39 <adrianschmutzler> whoever wants to invest some time still has the devices available, but we don't have to make them work with the everything-in selection of the buildbots
Jul 06 09:48:55 <PaulFertser> From the wiki warning ador (who plans to add support for a new 4/32 device) drew a conclusion that the support needs to be based on 19.07 branch, not on master.
Jul 06 09:50:24 <adrianschmutzler> New devices can only go through master.
Jul 06 09:50:55 <adrianschmutzler> So, if we stop to accept 4/32 devices for master, we will stop to accept them at all.
Jul 06 09:51:48 <adrianschmutzler> Whether it will be accepted to master depends on the reviewer, I'd say.
Jul 06 09:56:27 <Namidairo> although in theory you should come across less as time goes by and manufacturers decide that sticking tiny amounts of flash and ram might not be a great idea... nah.
Jul 06 10:01:26 <PaulFertser> That said, a 4 MiB flash device is usually almost easily convertible to a 16 MiB device.
Jul 06 10:01:54 <PaulFertser> (talking about SPI SOIC8 flash of course, not the CFI parallel flash)
Jul 06 10:08:13 <PaulFertser> It's reasonably easy to desolder even without hotair, just add enough leaded solder to cover the 4 legs at once, lift the side. With two soldering irons you can do both sides at once.
Jul 06 10:13:24 <PaulFertser> rsalvaterra: (linksys irony) indeed, but that's not too surprising given that b43 was written and maintained by cool independent free software developers so it's a whole different story compared to mwlwifi fiasco.
Jul 06 10:16:41 <Borromini> what even makes it more ironic is linksys marketed their wrt ac line as 'supported by openwrt'
Jul 06 10:17:11 <Borromini> their marketing basically said you could install openwrt on it right away
Jul 06 10:17:29 <Namidairo> quite a few use the word OpenWrt in their marketing materials for the CTRL+F users
Jul 06 10:18:04 <Namidairo> even if it just means their BSP is an OpenWrt fork of some sort with vendor stuff piled on
**** BEGIN LOGGING AT Mon Jul 06 10:24:07 2020
Jul 06 10:27:53 <Borromini> bsp?
Jul 06 10:28:27 <PaulFertser> Borromini: "binary support package", about the same as "SDK".
Jul 06 10:28:32 <PaulFertser> Board support package
Jul 06 10:28:41 <Borromini> oh. never heard that one. thanks :)
Jul 06 10:30:28 <hbug__> is there a good resource to understand how devices tree stuff works?
Jul 06 10:31:08 <PaulFertser> hbug__: the kernel documentation has an overview of the concepts, and then each driver might have its own specific properties.
Jul 06 10:31:09 <karlp> (if you're just desoldering it to replace with a new one, you can also just cut the legs and desolder the remainding scraps easily...
Jul 06 10:32:05 <PaulFertser> karlp: yep, a bit barbaric though, and I'd prefer to keep the part "just in case" :)
Jul 06 10:33:25 <karlp> I t hink if you're at the stage of even considering replacing the flash chip on an old 4meg router, you're way past the point of wanting to keep it :)
Jul 06 10:34:54 <PaulFertser> karlp: actually, short time after I replaced the chip in my old router, I used the old one to properly document a process of using (new back then) rpi1 spi with flashrom.
Jul 06 10:37:33 <hbug__> PaulFertser: the kernel doc was usefull, but i'm not able to find the driver specific parts. is it located somewhere centralized?
Jul 06 10:39:07 <PaulFertser> hbug__: yes, all upstream drivers must have their own documentation in Documentation/devicetree/bindings/
Jul 06 10:50:54 <owrt-snap-builds> build #369 of armvirt/64 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/armvirt%2F64/builds/369
Jul 06 11:02:09 <hbug__> thanks :)
Jul 06 11:02:20 <hbug__> don't know how i missed that.
Jul 06 11:44:08 <Hauke> rsalvaterra: the wrt53gs is much slower than an ibook, it is a 200 MHz in order MIPS CPU
Jul 06 11:46:41 <Hauke> jow: a DSA switch has the "dsa,member" attribute
Jul 06 11:46:43 <Hauke> in DTS
Jul 06 11:46:59 <Hauke> but not all switches support VLAN aware forwarding
Jul 06 11:47:35 <Hauke> but the marvell switches are well supported by DSA
**** BEGIN LOGGING AT Mon Jul 06 11:49:32 2020
Jul 06 11:52:53 <jow> Hauke: I just try to find a programmatic way to identify dsa port netdevs without harcoding switch specific topology info
Jul 06 11:53:15 <jow> Hauke: I already found a way to identify the CPU port (test -d /sys/class/net/$ifname/dsa/)
Jul 06 11:54:02 <blogic> jow: I just built an image for that realtek switch :-d
Jul 06 11:54:15 <blogic> lets see how the vlan support is on that unit
Jul 06 11:54:25 <blogic> kobi's latest tree has support for 8 switches already
Jul 06 11:54:48 <jow> Hauke: for ports I considered either `readlink -f /sys/class/net/$ifname/of_node | grep -q switch@` or attempting to add/delete a dummy vlan to see if a not supported error is thrown
Jul 06 11:54:50 <blogic> include/target.mk:DEVICE_TYPE?=router
Jul 06 11:55:03 <blogic> we need a switch variant i think ;)
Jul 06 11:55:50 <stintel> blogic: what switch are you talking about?
Jul 06 11:56:03 <blogic> guy ported owrt to realtek switch
Jul 06 11:56:04 <adrianschmutzler> that reminds me that I still wanted to clean this DEVICE_TYPE stuff up ...
Jul 06 11:56:06 <blogic> using v5.4
Jul 06 11:56:09 <blogic> kernel rewrite
Jul 06 11:56:15 <blogic> uses upstream eth and dsa drivers
Jul 06 11:56:17 <blogic> 1 sec
Jul 06 11:56:46 <blogic> stintel: https://github.com/rtk-owlab/openwrt/blob/tgtadd/rtl838x_bk/target/linux/rtl838x/image/Makefile
Jul 06 11:57:06 <blogic> i ordered 2 and will flash them today i hope
Jul 06 11:57:11 <stintel> cool
Jul 06 11:57:17 <stintel> very cool
Jul 06 11:57:18 <blogic> 24 port 1g + 4 sfp, 48v poe
Jul 06 11:57:28 <blogic> overall 190W poe output
Jul 06 11:57:31 <blogic> yes
Jul 06 11:57:46 <blogic> and they are working on a bigger switch silicon that even has 4x10g uplink
Jul 06 11:57:55 <stintel> oh sweet
Jul 06 11:58:14 <stintel> would be nice if a PoE-PD model with that comes out, with PD on the 10G uplinks :)
Jul 06 11:58:14 <blogic> i have a 24 + 4sfp switch here that cost me 120 euro
Jul 06 11:58:23 <blogic> hehe
Jul 06 11:58:34 <stintel> that's what I am missing in my office
Jul 06 11:58:41 <blogic> i ordered a sonicwall 10g poe injector for that new high power profile
Jul 06 11:58:54 <blogic> 280$ + shipping + 19% import ;)
Jul 06 11:59:00 <stintel> yikes
Jul 06 11:59:01 <stintel> wtf
Jul 06 11:59:14 <blogic> the cheapest one on the market right now
Jul 06 11:59:31 <owrt-1806-builds> build #76 of mpc85xx/p1020 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/mpc85xx%2Fp1020/builds/76
Jul 06 11:59:32 <blogic> its using the 3at profile or whatever it is called
Jul 06 11:59:45 <blogic> stintel:  those realtek switch do 56GB on the fabric backplane
Jul 06 12:02:17 <stintel> really cool development
Jul 06 12:02:23 <blogic> yes
Jul 06 12:02:29 <stintel> maybe one day I'll be able to replace my S6720-32C-PWH-SI with something that runs openwrt
Jul 06 12:02:35 <blogic> I will do basic testing and then get the mips support upstream asap
Jul 06 12:06:52 <stintel> I guess if you compare that price of that injector against that switch I bought... I have 24 PoE++ ports and 1440W PoE budget, set me back ~3k EUR
Jul 06 12:06:58 <stintel> ex VAT
Jul 06 12:07:08 <blogic> yup
Jul 06 12:07:11 <blogic> i know
Jul 06 12:07:16 <blogic> hence the sonic wall
Jul 06 12:07:37 <blogic> my previous injectors all allowed me to boot 11AX boards
Jul 06 12:07:49 <blogic> but once i started wifi, the budget expired ;)
Jul 06 12:07:53 <stintel> :D
Jul 06 12:08:13 <stintel> I should probably have another go at fixing OpenWrt on the AP7060DN I have
Jul 06 12:12:53 <stintel> the inside of that thing looked quite impressive
Jul 06 12:13:02 <PaulFertser> Looks like they use a MIPS core rather than Lexra. Isn't it a bit odd?
Jul 06 12:37:33 <blogic> lynxis: done
Jul 06 12:37:42 <lynxis> blogic: thanks!
Jul 06 12:38:22 <Bumble-Bee> So 16.04 still fails to build QSDK for me :/
Jul 06 12:45:30 <rsalvaterra> blogic: Realtek-based switches with OpenWrt support? Sign me up!
Jul 06 12:47:24 <rsalvaterra> I guess they're probably not much different from a "normal" router. (Perhaps too short of CPU and RAM to work like one, right?)
Jul 06 12:49:28 <blogic> the SoC is scaled to be a controller for the switch
Jul 06 12:49:41 <blogic> it wont be able to NAT gb traffic
Jul 06 12:51:16 <jow> rsalvaterra: right, too underspecced to work as gbit router
Jul 06 12:51:25 <jow> rsalvaterra: but perfect to act as smart switch with ssh capabilities
Jul 06 12:51:47 <jow> and to do various extra things (stat gathering, weird policy routing etc.)
Jul 06 12:53:28 <rsalvaterra> jow: I'm sold.
Jul 06 12:53:57 <rsalvaterra> Too bad my TL-SG2008 isn't supported, though… :P
Jul 06 12:55:20 <rsalvaterra> If it can do L3 (no NAT, just forwarding between VLAN, to limit the broadcast domains), it's perfect.
Jul 06 13:02:08 <stintel> I'm using the L3 feature of my huawei switch to have 10GbE between some VLANs, but non-stateful packet filtering is a major PITA :P
Jul 06 13:02:56 <stintel> so only really useful for routing between trusted VLANs. DMZ and IOT vlans are still handled by my apu2
Jul 06 13:03:06 <stintel> and guest
Jul 06 13:03:52 <rsalvaterra> stintel: Yeah, that's the idea.
Jul 06 13:04:43 <stintel> would be interesting to know how fast it will be able to do just simple routing
Jul 06 13:04:53 <stintel> heck I guess I should just order such a device
Jul 06 13:05:34 <rsalvaterra> stintel: maybe they support some sort of hardware flow offloading?
Jul 06 13:07:38 <rsalvaterra> If so, I believe static routing without NAT should be extremely fast.
Jul 06 13:10:23 <blogic>         case RTDRV_L3_ROUTE_ROUTEENTRY_GET:
Jul 06 13:10:56 <blogic>         case RTDRV_L3_ROUTE_SWITCHMACADDR_SET:
Jul 06 13:11:18 <blogic> and there is a ton of L2, QoS, mcast, ...offload stuff
Jul 06 13:11:23 <blogic> but no real L3 flow offload
Jul 06 13:11:48 <blogic> oh
Jul 06 13:11:49 <blogic>         case RTDRV_FILTER_FLOW_TBL_ADD:
Jul 06 13:11:57 <rsalvaterra> Flow table! YEAH!
Jul 06 13:12:01 <blogic> and there seems to be a properl multip port ACL
Jul 06 13:12:23 <blogic> dont get too excited yet ;)
Jul 06 13:12:30 <rsalvaterra> :P
Jul 06 13:13:17 <blogic> the sdk code is so insanely shitty
Jul 06 13:14:17 <rsalvaterra> Aren't all SDKs like that?
Jul 06 13:14:23 <nick[m]3> jow: could u help? I really do not understand the luci api. I set page.sysauth = false after this line https://github.com/openwrt/luci/blob/master/applications/luci-app-olsr/luasrc/controller/olsr.lua#L29
Jul 06 13:14:29 <nick[m]3> but I still have a 403 if I access /luci/admin/status/olsr
Jul 06 13:14:42 <rsalvaterra> I mean, has anyone got the Qualcomm NSS working stably?
Jul 06 13:17:28 <Bumble-Bee> I think someone has a build for the R7800 ? https://forum.openwrt.org/t/ipq806x-nss-drivers/12613/1454
Jul 06 13:17:42 <Bumble-Bee> rsalvaterra /\
Jul 06 13:18:23 <rsalvaterra> Yeah, I've been following that thread (even though I don't have a suitable device).
Jul 06 13:18:52 <rsalvaterra> Last time I've seen it, there were random reboots.
Jul 06 13:19:07 <Bumble-Bee> Yeah im getting an AX3600 IPQ8071 device and am trying to get QSDK building
Jul 06 13:19:30 <Bumble-Bee> but on par for QOM SDK / BSP's its really picky about the build environment
Jul 06 13:20:35 <rsalvaterra> Does it have binary blobs, or is the code completely open?
Jul 06 13:21:17 <Bumble-Bee> QCOM will have fw blobs with pretty light touch userspace
Jul 06 13:21:43 <blogic> rsalvaterra: there is now L3 offloading
Jul 06 13:21:56 <blogic> the flow table is just the switch fdb
Jul 06 13:22:28 <rsalvaterra> Bumble-Bee: Hm. Firmware is "fine", I guess.
Jul 06 13:22:31 <blogic> if we can igmp/3 L2 an bridge L2 offload that is me happy
Jul 06 13:22:40 <rsalvaterra> blogic: Sweeeeeet!
Jul 06 13:23:30 <adrianschmutzler> blogic: can you tell me the reason why tplink-archer devices have been disabled in bcm53xx when bumping the kernel? there is no comment about it ...
Jul 06 13:24:33 <jow> nick[m]3: tried purging the menu cache?
Jul 06 13:25:52 <blogic> adrianschmutzler: link ?
Jul 06 13:26:21 <nick[m]3> jow: u mean disabled caching like in the wiki?`yes. :)
Jul 06 13:26:31 <jow> nick[m]3: rm -rf /tmp/luci-indexcache*
Jul 06 13:26:37 <nick[m]3> jow: if I delete page.acl_depends = { "luci-app-olsr" }, I can access the status page again without login! :O
Jul 06 13:26:41 <blogic> adrianschmutzler: do you mind if i disable the freifunk feed by default ?
Jul 06 13:28:03 <jow> nick[m]3: yeah this is expected
Jul 06 13:28:17 <jow> nick[m]3: the unauthenticated session usually has no rights
Jul 06 13:28:38 <adrianschmutzler> blogic: https://github.com/openwrt/openwrt/commit/50c6938b95a0c915c5c8ffe1fe67a94b9402e98e
Jul 06 13:28:43 <jow> you would need to grant it read permissions to the luci-app-olsr acl
Jul 06 13:28:47 <rsalvaterra> Guys, is it already safe to build master for 74kc devices (regarding the MIPS hazard issues)? I'd hate to TFTP my way out of an Archer C6 brick. It's finicky as hell.
Jul 06 13:29:12 <karlp> jow: if I logout, and then login again from the form presented, I'm getting taken to a page that wasn't the page I waws on when I logged out, or any index page of any sort I can figure out.  doing it with the plain bootstrap theme too, (I thought it was problems in my sysauth.htm in my theme)
Jul 06 13:29:18 <Borromini> rsalvaterra: plenty of people who tested on the ML
Jul 06 13:29:18 <adrianschmutzler> blogic: I do not care about the freifunk feed in particular, I just made the decision after it was about 50:50
Jul 06 13:29:56 <adrianschmutzler> blogic: this line and the device below: https://github.com/openwrt/openwrt/blob/master/target/linux/bcm53xx/image/Makefile#L413
Jul 06 13:30:08 <rsalvaterra> Borromini: Thanks. I saw the commit, but just wanted to be sure. :)
Jul 06 13:30:20 <Borromini> rsalvaterra: you're not subscribed to the ml?
Jul 06 13:30:48 <nick[m]3> jow: you mean I add some acl.d json file with "unauthenticated" and add some parameter to access that acld.d file? so just "read" permission on that acl.d file under that rpcd/acl.d/ path?
Jul 06 13:30:57 <rsalvaterra> Borromini: Nope. I just read the browse the archives, from time to time.
Jul 06 13:31:04 <jow> karlp: cannot reproduce, I'm always bounced to /
Jul 06 13:31:05 <rsalvaterra> *I just browse the
Jul 06 13:31:21 <Borromini> https://lists.openwrt.org/pipermail/openwrt-devel/2020-July/029879.html < start here
Jul 06 13:31:42 <karlp> jow: yeah, makes no sense to me, I thought it was my local theme rework I'm doing, going to try a clean build again.
Jul 06 13:32:05 <karlp> I can see in the form that it's just pointing to cgi-bin/luci, but still ending up altogether elsewhere.
Jul 06 13:33:24 <jow> nick[m]3: I think what you want is not possible atm
Jul 06 13:33:43 <jow> nick[m]3: best is to map the smae view elsewhere without acl restrictions
Jul 06 13:34:36 <nick[m]3> jow: I need to find a way to get freiunk working again with olsr overview :/
Jul 06 13:34:39 <nick[m]3> jow: what do u mean with map somehwere else?
Jul 06 13:34:39 <jow> make a new entry  "/olsr-status" or similar, let it execute the same template() target but do not apply sysauth or acl_depends
Jul 06 13:36:00 <nick[m]3> ahhhh, I will try! :) freifunk is already mapping it somehwere else but does some call to it
Jul 06 13:36:17 <nick[m]3> I can't overwrite it, or? like giving that with call
Jul 06 13:36:51 <blogic> adrianschmutzler: i think rmilecki asked me to do so
Jul 06 13:37:02 <blogic> rmilecki: https://github.com/openwrt/openwrt/blob/master/target/linux/bcm53xx/image/Makefile#L413 do you remeber ?
Jul 06 13:37:13 <blogic> adrianschmutzler: i think it was boot looping
Jul 06 13:37:22 <blogic> and we could not figure out why
Jul 06 13:37:53 <jow> nick[m]3: node() is create-or-fetch. It either creates a new node or fetches an existing one. If your code runs later than the code registering that node, it will overwrite the existing one
Jul 06 13:40:36 <nick[m]3> jow: nice! I fixed it! Thank u!!! :D
Jul 06 13:41:10 <jow> that reminds me... that olsrd app should be ported to client side js as well
Jul 06 13:41:35 <jow> its just years that I had access to a working olsr mesh
Jul 06 13:43:51 <rsalvaterra> jow: How well do OLSR and/or BATMAN work in practice? I've never used them at all.
Jul 06 13:44:22 <jow> rsalvaterra: used to work reasonably well. Nowadays my go-to choice would be batman-adv since it solves all the layer 3 addressing headaches
Jul 06 13:44:33 <jow> and since it is layer2 transparent
Jul 06 13:45:26 <jow> the hardest part in olsr meshes was the globally unique ip address coordination
Jul 06 13:45:42 <nick[m]3> jow:  I did not fixed it compltetely... Now I get "Session expired" when I first visist the site xD
Jul 06 13:46:06 <nick[m]3> jow: we thought about switching to babel
Jul 06 13:46:13 <rsalvaterra> The idea was to give the connected clients access to the internet though the "nearest" WAN connection, right?
Jul 06 13:46:30 <jow> rsalvaterra: broadly speaking, yes
Jul 06 13:47:25 <jow> nick[m]3: that session expired happens when some javascript code calls an endpoint that requires authnetication while you're not logged in
Jul 06 13:47:43 <jow> nick[m]3: the template code likely has some polling JS which fetches raw status data
Jul 06 13:48:10 <jow> nick[m]3: you need to expose this raw data endpoint as well as a public page and change the template code in a way that it requests the data relative to its own location
Jul 06 13:48:55 <jow> so that admin/olsr fetches admin/olsr/data and public/olsr fetches public/olsr/data (simplified example)
Jul 06 13:49:38 <jow> nick[m]3: for us, babeld always was "that other thing". The few times I looked at it it was always complex
Jul 06 13:49:55 <jow> then the holy distance vector vs. link state wars...
Jul 06 13:59:12 <rsalvaterra> Hard to believe the led multicolour framework is already on the 29th iteration… https://marc.info/?l=linux-kernel&m=159403875909235&w=4
Jul 06 13:59:13 <nick[m]3> jow: but the app works without login? so the functuoinallity is just fine. I will look this
Jul 06 13:59:33 <rsalvaterra> … I really need that on my Omnia. :P
Jul 06 14:00:33 <nick[m]3> jow: I think I have it
Jul 06 14:00:40 <nick[m]3> GET https://frei.funk/ubus/?1594044012096=
Jul 06 14:04:18 <jow> nick[m]3: does not resolve here
Jul 06 14:04:47 <jow> nick[m]3: nevermind, I think I was not supposed to actually open this link
Jul 06 14:05:28 <jow> rsalvaterra: uhh... led stuff. I usually avoid touching it at all. Way too much bikeshed potential
Jul 06 14:05:32 <nick[m]3> jow: sry, yep. xD RPCError: RPC call to session/access failed with error -32002: Access denied  at handleCallReply
Jul 06 14:06:11 <nick[m]3> jow: I think I will try to give the freifunk app, maybe some permissions to access the stuff the olsr app has? maybe this works as a fix?
Jul 06 14:07:10 <jow> nick[m]3: sounds odd. according to /usr/share/rpcd/acl.d/unauthenticated.json session/access is allowed for unauthenticated users
Jul 06 14:07:54 <jow> nick[m]3: ubus call session list '{ "ubus_rpc_session": "00000000000000000000000000000000" }'  should confirm it
Jul 06 14:08:13 <nick[m]3> jow: whuuups, I destroyed my unauthenticated.json! :S
Jul 06 14:08:33 <nick[m]3> not it works without session expired
Jul 06 14:09:04 <nick[m]3> Still have some error saying "RPCError: RPC call to file/list failed with error -32002: Access denied   at h"
Jul 06 14:09:05 <nick[m]3> but this is failing silently, so it works xD
Jul 06 14:09:19 <jow> this is expected, file listing is not allowed for unauthenticated users
Jul 06 14:09:35 <jow> its probably done to discover available olsr plugins
Jul 06 14:10:38 <rsalvaterra> jow: Yeah, I couldn't care less about the interface, as long as the feature is sanely implemented. I just want the control my leds. :)
Jul 06 14:11:04 <jow> I usually just want to turn them off
Jul 06 14:11:17 <jow> they don't tell me anything ping/tcpdump cannot
Jul 06 14:14:48 <rsalvaterra> Heh… during the TurrisOS time, I implemented a Lua program to change the power led colour smoothly, according to the loadavg (0 green, 1 yellow, 2+ red).
Jul 06 14:22:21 <nick[m]3> jow: I want to have a look at facebook openR routing
Jul 06 14:22:52 <nick[m]3> but someone deleted all dependencies xD I have to re-add them again
Jul 06 14:23:02 <nick[m]3> but olsrv1 is not really maintained anymore, and some freifunk communities switched to babel
Jul 06 14:23:23 <nick[m]3> i like the idea of meshing on layer 3 more than making a big switch xD ^^
Jul 06 14:23:26 <jow> olsrv2 still not ready yet?
Jul 06 14:32:06 <nick[m]3> jow: not sure if maintained
Jul 06 14:45:37 <karlp> ok, so it's doing it again, but now it's going to a different page.  cgi-bin/luci is the one going "somedwhere" but I can't find anything that explicitly lists itself as the "root" entry?
Jul 06 14:45:57 <karlp> even in the menu.d/luci-base.json, there's still a "admin" path
Jul 06 14:47:28 <karlp> how does the view shown for just "/" get determined?
Jul 06 14:49:12 <jow> first resolvable node with lowest order index
Jul 06 15:18:14 <karlp> I have a local p = entry({'home'}, call("action_diags2"), "Home", 1) which should be first then though?
Jul 06 15:18:57 <karlp> the page that's coming up is at 10, entry({'home', 'wizard', 'gate_password'}, view("system/password"), _("Gate Password"), 10)
Jul 06 15:22:29 <Bumble-Bee> Woohoo my new USB -> Serial adaptor is here
Jul 06 15:25:06 <jow> karlp: https://github.com/openwrt/luci/blob/master/modules/luci-base/luasrc/dispatcher.lua#L615
Jul 06 15:25:41 <jow> karlp: your problem might be that "call" targets are not considered when guessing a firstchild node
Jul 06 15:26:09 <jow> since the dispatcher does not know if a "call" action is going to render a view or merely provide unformatted json or something else
Jul 06 15:26:55 <jow> I don't fully recall why I went this route... checking if a node has a name instead would likely work equally well
Jul 06 15:26:57 <karlp> ok, I can poke it fromthere then I think.
Jul 06 15:27:11 <karlp> thanks for the pointers.
Jul 06 15:27:16 <karlp> stable 1907 has been lots of fun so far... :)
Jul 06 15:27:24 <jow> so replace all the type compares with  root.title ~= nil
Jul 06 15:32:30 <rsalvaterra> blogic: I really want to believe there's hope for my TL-SG2008… https://www.smallnetbuilder.com/lanwan/lanwan-reviews/32471-tp-link-tl-sg108e-and-tl-sg2008-8-port-smart-switches-reviewed
Jul 06 15:33:12 <rsalvaterra> … it's based on the Realtek RTL8380M. ;)
Jul 06 15:33:38 <stintel> > • Requires Windows utility to configure
Jul 06 15:33:39 <stintel> wtf
Jul 06 15:34:37 <rsalvaterra> stintel: Yeah, the SG108E Doesn't Exist™.
Jul 06 15:34:54 <rsalvaterra> That was exactly the reason I didn't buy it at the time.
Jul 06 15:36:24 <rsalvaterra> In any case, it could probably be supported on OpenWrt too, I don't know. That would actually make it desirable.
Jul 06 15:38:35 <rsalvaterra> But the SG2008 is a 64/8 device, with a 500 MHz CPU. Surprisingly less horrible that I expected.
Jul 06 15:38:44 <rsalvaterra> *than
Jul 06 15:41:34 <rsalvaterra> And another peeve of mine (with the SG108E) is power and Ethernet connectors on opposite sides. It's a desktop switch, I want everything in the back.
Jul 06 15:44:11 <zorun> reviews on the new dashboard for LuCI have been good so far
Jul 06 15:44:12 <zorun> https://github.com/openwrt/luci/pull/4185
Jul 06 15:44:19 <zorun> any other review?
Jul 06 15:45:14 <zorun> to check that the WAN is connected, they seem to check whether it has an IP address with ifc.getIPAddr()
Jul 06 15:45:20 <zorun> I wonder if there is a better way
Jul 06 15:47:50 <olmari> I sure hope that will have some intelligence, I have alias IP in wan for modem, which then gets internet IP from modem or whatever... Otherwise that looks fun at a glance for me
Jul 06 15:48:16 <jow> the ui shouldn't try to cover "clever" configurations
Jul 06 15:48:23 <jow> at least not the simple one
Jul 06 15:52:20 <zorun> I was more thinking of an equivalent of "up": true that is shown by ifstatus
Jul 06 15:52:38 <jow> yeah, that makes more sense
Jul 06 15:53:16 <zorun> https://openwrt.github.io/luci/jsapi/LuCI.network.Device.html#isUp
Jul 06 15:53:39 <zorun> hmm, that's a device, not a network
Jul 06 15:54:04 <jow> https://openwrt.github.io/luci/jsapi/LuCI.network.Protocol.html#isUp
Jul 06 15:54:32 <zorun> ah, thanks :)
Jul 06 15:57:56 <zorun> jow: btw, do you think this should replace the current status page?
Jul 06 15:58:30 <zorun> that is, when installing the luci-mod-dashboard, it would overwrite the status page
**** BEGIN LOGGING AT Mon Jul 06 16:18:57 2020
Jul 06 16:27:15 <rsalvaterra> The APU2 leds were renamed…?
Jul 06 16:27:52 <rsalvaterra> I had power, led2 and led3 on the old module, now I have 1, 2 and 3.
Jul 06 16:29:44 <rsalvaterra> I'm guessing the mapping is…
Jul 06 16:29:44 <rsalvaterra> power -> 1
Jul 06 16:29:44 <rsalvaterra> led2 -> 2
Jul 06 16:29:44 <rsalvaterra> led3 -> 3
Jul 06 16:29:44 <rsalvaterra> … right?
Jul 06 16:35:14 <dwmw2_gone>  * satisfy_dependencies_for: Cannot satisfy the following dependencies for base-files:
Jul 06 16:35:15 <dwmw2_gone>  * 	libubox20170601
Jul 06 16:35:15 <dwmw2_gone>  * opkg_install_cmd: Cannot install package base-files.
Jul 06 16:35:15 * dwmw2_gone frowns
Jul 06 16:48:21 <jow> zorun: probably
Jul 06 16:48:39 <jow> dwmw2_gone: I remember that one... it is a quirk/bug in buildroot
Jul 06 16:52:53 <jow> dwmw2_gone: you could try  staging_dir/target-*/pkginfo/*.provides  followed by a make
Jul 06 16:53:06 <jow> *try  rm staging_dir/target-*/pkginfo/*.provides
Jul 06 16:53:55 <jow> under some specific circumstances, these provide files are not properly refreshed/cleared, causing opkg to pick up bad dependencies at build time
Jul 06 16:54:46 <karlp> it's like it's searching for the first _leaf_ not just the first node, even after looking for title instead of a certain type.  I can see it recursing past the node I expect to be first, and so on all the way down.
Jul 06 17:09:47 <karlp> good news, if you add infinite recursion to dispatcher.lua, and are writing to stderr, it self limits itself enough that it never crashes, just spams forever :)
Jul 06 17:27:36 <dwmw2_gone> jow: thanks
Jul 06 17:36:37 <karlp> jow: https://paste.centos.org/view/8c0572c6 "works for me" and I've tried looking at the (few) places that use this code, and it seems to be ok, but... hard to say further.
Jul 06 17:38:21 <jow> karlp: iirc the problem is a firstchild node pointing onto a firstchild node
Jul 06 18:12:07 <Grommish> Anyone seen this issue before? I thought it was a ccache error, but I turned ccache off, make clean, and still happening..  my ulimit is set to either 65535 or unlimited...
Jul 06 18:12:07 <Grommish> make[2]: Entering directory '/home/grommish/openwrt/feeds/luci/collections/luci'
Jul 06 18:12:07 <Grommish> make[2]: execvp: /usr/bin/env: Argument list too long
Jul 06 18:12:07 <Grommish> make[2]: *** [../../luci.mk:296: /home/grommish/openwrt/bin/packages/mips64_octeon3/luci/luci_git-20.184.73759-da42423_all.ipk] Error 127
Jul 06 18:24:18 <Grommish> Not an OpenWrt error, but..  Would an Invalud RMGII packet length mismatch from the L2 HDR field be a HARDWARE issue?
**** BEGIN LOGGING AT Mon Jul 06 19:24:35 2020
Jul 06 21:04:14 <owrt-snap-builds> build #434 of apm821xx/nand is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/apm821xx%2Fnand/builds/434
Jul 06 21:38:04 <owrt-1806-builds> build #75 of ar71xx/mikrotik is complete: Failure [failed images]  Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/ar71xx%2Fmikrotik/builds/75  blamelist: Stijn Segers <foss@volatilesystems.org>, Baptiste Jonglez <git@bitsofnetworks.org>, Hauke Mehrtens <hauke@hauke-m.de>
Jul 06 22:23:05 <zorun> Hauke: the build failure looks like a small typo in the kernel bump (it needs s/rbni/info/ in rb91x_nand_remove())
Jul 06 22:23:19 <zorun> Hauke: btw thanks for merging that libubox patch! :)
Jul 06 22:41:11 <owrt-snap-builds> build #437 of x86/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/x86%2Fgeneric/builds/437
**** BEGIN LOGGING AT Tue Jul 07 02:51:46 2020
Jul 07 02:59:01 <owrt-snap-builds> build #370 of armvirt/64 is complete: Failure [failed defconfig dltar]  Build details are at http://buildbot.openwrt.org/master/images/builders/armvirt%2F64/builds/370  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 02:59:02 <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>
**** ENDING LOGGING AT Tue Jul 07 02:59:58 2020