**** BEGIN LOGGING AT Fri Aug 07 02:59:57 2020
**** BEGIN LOGGING AT Fri Aug 07 03:51:12 2020
Aug 07 04:57:51 <mangix> this mt7621 thing seems to be back
Aug 07 04:57:54 <mangix> i wonder why
Aug 07 05:10:58 <owrt-snap-builds> build #421 of gemini/generic is complete: Failure [failed kmodconfig]  Build details are at http://buildbot.openwrt.org/master/images/builders/gemini%2Fgeneric/builds/421  blamelist: Davy Hollevoet <github@natox.be>, ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Daniel Golle <daniel@makrotopia.org>, Shibajee Roy <ador250@protonmail.com>, Adrian Schmutzler
Aug 07 05:10:58 <owrt-snap-builds> <freifunk@adrianschmutzler.de>, Jo-Philipp Wich <jo@mein.io>
Aug 07 05:11:08 <owrt-snap-builds> build #261 of bcm27xx/bcm2708 is complete: Failure [failed kmodconfig]  Build details are at http://buildbot.openwrt.org/master/images/builders/bcm27xx%2Fbcm2708/builds/261  blamelist: Davy Hollevoet <github@natox.be>, ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Daniel Golle <daniel@makrotopia.org>, Shibajee Roy <ador250@protonmail.com>, Adrian
Aug 07 05:11:08 <owrt-snap-builds> Schmutzler <freifunk@adrianschmutzler.de>, Jo-Philipp Wich <jo@mein.io>
Aug 07 05:12:25 <owrt-snap-builds> build #414 of lantiq/xway is complete: Failure [failed defconfig dltar]  Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fxway/builds/414  blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Jo-Philipp Wich <jo@mein.io>, Adrian Schmutzler <freifunk@adrianschmutzler.de>
Aug 07 05:12:39 <owrt-snap-builds> build #410 of armvirt/64 is complete: Failure [failed defconfig dltar]  Build details are at http://buildbot.openwrt.org/master/images/builders/armvirt%2F64/builds/410  blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Jo-Philipp Wich <jo@mein.io>, Adrian Schmutzler <freifunk@adrianschmutzler.de>
Aug 07 05:43:50 <Grommish> if I need to check CONFIG_ARCH_64BIT, should I use ifdef CONFIG_ARCH_64BIT or ifeq (CONFIG_ARCH_64BIT,y) in a Makefile?
Aug 07 06:20:20 <jow> Grommish: either should work
Aug 07 06:20:55 <Grommish> jow: thx sir.
Aug 07 06:22:59 <Grommish> jow: Who do I talk to about advancing the pr I put in for bringing up a device?
Aug 07 06:24:12 <jow> you have to be patient, a target maintainer needs to pick it up eventually
Aug 07 06:24:43 <jow> if there is no further controversy and no pending change requests and it is still not merged after a while you should consider a friendly ping
Aug 07 06:25:13 <Grommish> target maintainer as in, John?
Aug 07 06:26:22 <jow> Grommish: I forgot what your PR was, can you link it again?
Aug 07 06:26:23 <Grommish> Oh, there isn't even a maintainer listed in the Makefile anymore
Aug 07 06:26:56 <Grommish> https://github.com/openwrt/openwrt/pull/3241
Aug 07 06:27:27 <Grommish> jow: adrianschmutzler had a heck of a time getting me to follow a standardized naming scheme, or at least understanding it
Aug 07 06:27:39 <Grommish> so, mass props to him for putting up with my ignorance
Aug 07 06:31:47 <jow> Grommish: yeah it seems that the octeon target is a group maintenance effort since a while
Aug 07 06:32:14 <Grommish> I just used to remember the john@phozen.org tag in there at one point
Aug 07 06:32:21 <jow> Grommish: I'd say lets ask adrian again if anything is still open, if not I guess it is ready to merge
Aug 07 06:32:43 <Grommish> jow: Ok.. I will do that..  thank you
Aug 07 06:33:01 <jow> maybe blogic can take a look too, but not sure if he has an opinion at all
Aug 07 06:34:42 <jow> Grommish: I notice you still use the unpack-to-tmp, then copy approach for sysupgrade?
Aug 07 06:36:10 <Grommish> jow: I was having issues with it doing with a single line call, and since we have to wildcard the sysupgrade-* because of the difference between the name and the defined name
Aug 07 06:36:22 <Grommish> so the files would extract to sysupgrade-itus,shield-router hehe
Aug 07 06:36:50 <Grommish> So dropping them to tmp first let me run the code to grab that name
Aug 07 06:37:47 <Grommish> https://github.com/openwrt/openwrt/pull/3241/files#diff-a6a780f4082e88756e922a1f3ec5e2abR44
Aug 07 06:38:11 <jow> Grommish: https://pastebin.com/3TtBYUPy
Aug 07 06:38:19 <Grommish> But, I'm always willing to learn and I dont even know enough to ask the right questions many times
Aug 07 06:38:59 <jow> since you extract the dirname using tar -t first, you can directly use it later to unpack single files to stdout
Aug 07 06:39:11 <Grommish> Ok.. I can change and test that. Thanks!
Aug 07 06:39:34 <jow> upside is that you do not have to hold the kernel and rootfs files twie in ram
Aug 07 06:39:46 <jow> *twice, once compressed and once uncompressed
Aug 07 06:40:42 <Grommish> Right.. that makes sense.
Aug 07 06:42:44 <Grommish> jow: your thoughts on adding a rustc/cargo package?  Do you think it would be worth it? I'm just playing around right now, but would it be used you think?
Aug 07 06:43:07 <Grommish> I don't know enough about the "router" space to answer a lot of those questions
Aug 07 06:43:25 <jow> Grommish: hard to say, but I guess over time there will be popular software packages written in rust which people want to run on OpenWrt
Aug 07 06:43:32 <jow> so it likely makes sense
Aug 07 06:43:47 <Grommish> Ok.. it's pretty much the reason I'm messing with it.. i want to try suricata
Aug 07 06:44:32 <jow> so you're struggling with this atm?
Aug 07 06:45:23 <Grommish> I can get suricata to compile if I locally install rustc/cargo.  but I know in order to make it a real package, I gotta make it self-contained
Aug 07 06:45:38 <Grommish> So, I moved to getting rustc installed and working, and I'm close
Aug 07 06:46:02 <jow> right. I don't know much about the rust ecosystem... does it require toolchain support or is rustc some standalone thing? How is it usually bootstrapped?
Aug 07 06:46:59 <Grommish> Its wierd..  rustup installs the rustc and cargo bins, along with some other stuff.. but only on the host, nothing on device.  then you install the specific toolchain based on target and things like date or revision
Aug 07 06:47:37 <jow> so esentially fetching precompiled executables?
Aug 07 06:47:39 <Grommish> jow: https://hastebin.com/eliqaqewod.makefile is currently where I'm at
Aug 07 06:48:25 <Grommish> jow: Yes, but then it uses cargo and rustc, plus those toolchains, to compile when dealing with a rustc application.. like surcata will call, internally, cargo
Aug 07 06:49:43 <Grommish> Host/Configure will install  in build_dir/hostpkg/.cargo and .rustup, but Host/Install tells me there isn't anything to be done
Aug 07 06:50:12 <Grommish> and the arch stuff is still broken.. i'm trying to winnow down the various targets
Aug 07 06:52:07 <jow> trying it atm
Aug 07 06:53:19 <Grommish> I heard uClibc was broken, so i was going to only sort by gnu and musl targets and none of the windows stuff
Aug 07 06:57:10 <jow> right
Aug 07 06:57:23 <jow> I am trying x86-64/musl atm and there it fails too, applying some tweaks to the makefile
Aug 07 06:57:40 <jow> btw the  package/.../host/install  make target does not exist anymore
Aug 07 06:57:48 <jow> it is always  package/.../host/compile
Aug 07 07:05:31 <jow> Grommish: this one works for me: https://hastebin.com/ezexupetaf.makefile
Aug 07 07:07:34 <jow> Grommish: in order for a package like surricata to use it, it would require a PKG_BUILD_DEPENDS:=rustup/host and adjust its PATH accordingly
Aug 07 07:08:01 <jow> Grommish: this should be formalized by providing something like a "rust.mk" Makefile include which packages can use in order to request rust toolchain support
Aug 07 07:08:11 <jow> similar to how there's a python.mk for Python etc.
Aug 07 07:08:33 <aparcar> jow: how to deal with permissions of /var files?
Aug 07 07:08:42 <jow> aparcar: /var == /tmp
Aug 07 07:08:50 <aparcar> the while point to use fakeroot is to get rid of chown in init scripts
Aug 07 07:09:16 <jow> aparcar: ah you mean stuff generated by the init script?
Aug 07 07:10:18 <aparcar> yes
Aug 07 07:10:38 <jow> that requires procd support first
Aug 07 07:10:56 <jow> and procd then needs to execute the init scripts as the effective target user
Aug 07 07:11:13 <aparcar> how hard is it?
Aug 07 07:11:31 <jow> could be something like a   # Runas-User: 123  or  # Runas-Group: 456   comment in the init script which is parsed by procd prior to executing the script
Aug 07 07:12:03 <jow> roughly mimicking LSB tags: https://wiki.debian.org/LSBInitScripts
Aug 07 07:12:49 <jow> the more invasive solution would be to do away with classic init scripts at all and support a different, unit-file-like way to declare services, this way it is way easier to deal with
Aug 07 07:13:30 <jow> in many cases the init scripts are actually just various declarations with the only actual logic being the uci translation
Aug 07 07:13:58 <jow> that could be moved as executable into /usr/libexec and all the remaining init script stuff converted into declarations within a service unit file
Aug 07 07:14:18 <jow> the /usr/libexec/whatever.uci-converter could then be set as PreExec= or something
Aug 07 07:14:38 <jow> but that is just random ideas, the least invasive solution is having magic comments in init scripts which are parsed by procd
Aug 07 07:17:01 <Namidairo> nick[m]3: I don't know, perhaps take a look at how they're using syslog in wpa_debug.c in hostapd/wpa_supplicant? Not sure if that's a good example, but I'm thinking at least syslog would be better than spitting it all out into stderr
Aug 07 07:18:38 <jow> aparcar: of course this has further implications. Non-root users may not talk to ubus by defualt for example
Aug 07 07:19:00 <jow> aparcar: so once the init script is actually run as less-privileged user, it cannot register its service via ubus anymore
Aug 07 07:19:40 <jow> unless we introduce yet another api or namespacing magic to somehow give it a preopened socket
Aug 07 07:19:50 <jow> etc etc.
Aug 07 07:20:04 <jow> this is why systemd does not use init scripts :)
Aug 07 07:22:02 <aparcar> so we just port systemd to opewnrt ;)?
Aug 07 07:22:23 <jow> good luck
Aug 07 07:22:46 <aparcar> no worries
Aug 07 07:22:53 <Namidairo> I feel like there'd be pushback against that
Aug 07 07:22:56 <blogic> jow: i still have my old lsb-loader code for procd
Aug 07 07:23:03 <rsalvaterra> aparcar: hell, no!
Aug 07 07:23:10 <Namidairo> like so
Aug 07 07:23:15 <aparcar> just joking
Aug 07 07:23:20 <rsalvaterra> I know. :P
Aug 07 07:23:55 <jow> blogic: I think coming up with a simple unit-file-like format (maybe even compatible subset of systemd unit files) is the simplest way to tackle the issue
Aug 07 07:24:01 <aparcar> blogic: you think magic comments is the way?
Aug 07 07:24:21 <jow> the init script shell code approach simply does not work once you try to do things like privilege changing etc.
Aug 07 07:24:24 <blogic> jow: that is how lsb-loader works
Aug 07 07:24:34 <blogic> /etc/lsb.d/service
Aug 07 07:24:39 <aparcar> I think we need gitlab and it's 30 special issue features to keep track of those ideas
Aug 07 07:24:45 <blogic> when procd loads a service it parses the additional lsb tags
Aug 07 07:25:03 <blogic> additionally you can just spawn whole services from it without init.d if that is enough
Aug 07 07:25:17 <blogic> aparcar: i think that is hipster cloud tech
Aug 07 07:25:30 <aparcar> agree
Aug 07 07:25:40 <blogic> as you can see i keep track of code and ideas we discussed 8 years ago in this channel
Aug 07 07:25:59 <jow> conceptiually, what is needed is a spearation of the uci-to-native-config generation logic and the declarative service part (which process to execute, which uid to suid to, which files to track, which interfaces to track etc.)
Aug 07 07:26:28 <blogic> jow: whioch closes the loop to the uci template renderer we have been wanting for years
Aug 07 07:26:39 <jow> blogic: yes :)
Aug 07 07:26:49 <aparcar> uci templare renderer?
Aug 07 07:26:49 <russell--> swconfig --help
Aug 07 07:27:28 <jow> aparcar: something like Jinja templates to transform uci into various native config expressions
Aug 07 07:27:41 <jow> because that is what 90% of the init script logic is doing
Aug 07 07:27:49 <blogic> so we can basically have a template for dnsmasq.conf
Aug 07 07:27:54 <jow> read some uci vars, optionally validate them, loop over and print stuff
Aug 07 07:27:56 <blogic> jow: correct
Aug 07 07:28:14 <blogic> and the other 10% can be augmented away in declarative markup in most cases
Aug 07 07:28:37 <aparcar> is there a c implementation of jinja?
Aug 07 07:28:40 <jow> so what is needed is some kind of template expressiosn that allow reading uci values, simple filtering, looping, conditionals and text transformations
Aug 07 07:29:17 <aparcar> https://mustache.github.io/
Aug 07 07:29:27 <aparcar> this is a subset of jinja
Aug 07 07:31:48 <jow> is a step in the right direction, but lacks support for interacting with the environment
Aug 07 07:31:54 <aparcar> while we talk about changing things, is uci the best config format or would something like yaml(subset)/toml or whatever be better?
Aug 07 07:32:33 <blogic> aparcar: it would not as uci is integrated into most daemons
Aug 07 07:32:34 <jow> we would need facilities such as: ability to call external programs and evaluate their output or exit code (system(), call()), ability to read environment variables (getenv() or similar), ability to query ubus
Aug 07 07:32:38 <rsalvaterra> have we hit any limitation with the uci config format?
Aug 07 07:32:44 <jow> rsalvaterra: no
Aug 07 07:32:52 <blogic> rsalvaterra: no
Aug 07 07:32:59 <rsalvaterra> in that case, no need for changing, I guess.
Aug 07 07:33:00 <jow> aparcar just loves new tools
Aug 07 07:33:06 <blogic> aparcar: just likes python and yaml
Aug 07 07:33:08 <jow> and YAML is ho these days :)
Aug 07 07:33:24 <rsalvaterra> I love tools which don't increase the image size. :P
Aug 07 07:33:34 <Namidairo> I've seen wonderful vendor lua in regards to system()
Aug 07 07:33:38 <Namidairo> :)
Aug 07 07:34:00 <aparcar> yea I like fancy things sorry
Aug 07 07:34:12 <aparcar> maybe I should switch projects and start at node...
Aug 07 07:34:15 <jow> Namidairo: yeah,   if system("cat foo | grep "[123]" | tail -n1 | frobnicate") == 0 then system("cat /random/file") fi  :P
Aug 07 07:34:29 <jow> stuff like that
Aug 07 07:34:38 <rsalvaterra> aparcar: of course, npm on OpenWrt. :P
Aug 07 07:34:39 <Namidairo> then they start piping it all through a sanitisation function
Aug 07 07:34:41 <aparcar> jow: what does ho mean?
Aug 07 07:34:54 <jow> I especially like how they tend to invoke system() to invoke things like grep, sed or awk
Aug 07 07:34:58 <Namidairo> but then a junior dev just does it anyway
Aug 07 07:35:18 <jow> aparcar: *hot
Aug 07 07:35:23 <aparcar> ack
Aug 07 07:35:29 <rsalvaterra> jow: young devs don't know the UNIX way. :)
Aug 07 07:35:41 <owrt-snap-builds> build #501 of ramips/rt3883 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt3883/builds/501
Aug 07 07:36:30 <aparcar> what about init script just run things as a specific user via sudo?
Aug 07 07:36:45 <aparcar> we could just build a wrapper
Aug 07 07:37:05 <aparcar> even though the template stuff and procd lsb foo sounds better longterm
Aug 07 07:39:51 <aparcar> anyway I'm out. I'll build the fakeroot stuff first and ask dango about procd
Aug 07 07:39:56 <aparcar> night all
Aug 07 07:40:18 <rsalvaterra> good night!
Aug 07 07:41:08 <Borromini> night
Aug 07 07:54:23 <rsalvaterra> Oh, Linux 5.9 will finally have multicolour led support!
Aug 07 07:57:43 <Borromini> so you can go full RGB on your router? B-)
Aug 07 08:01:40 <Grommish> blogic: jow suggested I see if you might be interested in https://github.com/openwrt/openwrt/pull/3241 since there isn't a single maintainer for octeon. I've got one change he wanted to go in still
Aug 07 08:06:55 <rsalvaterra> Borromoni: My Omnia is going to be the gayest router ever. :P I just need to revive the service I've written for the original Turris OS (and maybe rewrite it in C, it's Lua at the moment).
Aug 07 08:22:56 <Borromini> lol
Aug 07 09:15:24 <karlp> what was wrong with the lua version?
Aug 07 09:18:00 <jow> nbd: do you have an estimation for the bridge/vlan hotplug ops support in netifd so that we can revise the default network configuration model?
Aug 07 09:27:06 <nbd> jow: i'll try to complete it next week
Aug 07 09:27:56 <nbd> maybe i'll have some time today as well
Aug 07 09:27:56 <nbd> not sure
Aug 07 09:46:21 <jow> nbd: great
Aug 07 10:06:26 <nick[m]3> jow: the tcpsocket gets readcallback with 0 bytes?
Aug 07 10:30:04 <jow> nick[m]3: if you get a readable callback on a socket and are only able to read zero bytes, you likely encountered an EOF (connection closure)
Aug 07 10:32:59 <nick[m]3> jow: we logged  looping - U-EOF = 0, U-error = 0...
Aug 07 10:33:14 <nick[m]3> jow: and the next read gives bytes againm
Aug 07 10:34:18 <nick[m]3> jow: https://github.com/berlin-open-wireless-lab/DAWN/pull/115#issuecomment-670451449
Aug 07 10:34:24 <nick[m]3> it reads 0 bytes
Aug 07 10:34:34 <nick[m]3> we leave reading loop
Aug 07 10:34:38 <nick[m]3> get back again and continue reading stream
Aug 07 10:34:50 <nick[m]3> I think it is a bug
Aug 07 10:47:28 <nick[m]3> jow: sry! the problem is that we have 0 length
Aug 07 10:47:29 <nick[m]3> xD
Aug 07 10:47:45 <nick[m]3> we fully drained the stream buffer
**** BEGIN LOGGING AT Fri Aug 07 11:21:14 2020
Aug 07 12:37:03 <nbd> jow: sent a very lightly tested implementation as rfc patches to openwrt-devel@
Aug 07 12:37:24 <jow> nbd: thank you, much appreciated. I'll play around with it for a while
Aug 07 12:38:06 <jow> I prepared LuCI support for device config & bridge vlan filtering in the meanwhile: https://github.com/openwrt/luci/pull/4307
Aug 07 12:43:44 <adrianschmutzler> since rt305x and rt3883 appear to be working, I wonder whether I should just bump the remaining rt288x to 5.4 as well. Does somebody have an opinion on that?
Aug 07 12:44:48 <jow> adrianschmutzler: do it
Aug 07 12:45:03 <jow> adrianschmutzler: if the sole device in there happens to break there's still a usable SDK and IB people can use
Aug 07 12:45:45 <jow> nbd: so these "hotplug ports" are kind of virtual placeholder ports in a bridge state that are filled by wifi devices?
Aug 07 12:46:40 <nbd> they're vlan port membership info for members added via hotplug
Aug 07 13:13:16 <nbd> jow: one thing still on my list for netifd after those patches is adding support for explicitly setting the vlan in wifi-iface/vlan sections
Aug 07 15:40:53 <Bumble-Bee> blogic: I'm getting the feeling that have some special source on the AX3600 PCIe or just something differs other than core clock speeds 8074 vs 8071_v2
Aug 07 15:41:11 <Bumble-Bee> xaiomi have some special source
Aug 07 15:45:27 <blogic> should be in their dts file
Aug 07 15:45:39 <blogic> is there a GPL drop from xiaomi ?
Aug 07 15:46:13 <Bumble-Bee> Nah no GPL for them at all. I extracted the DTS from the stock FIT image
Aug 07 15:46:30 <Bumble-Bee> Nothing different from QSDK AC04
Aug 07 15:46:45 <Bumble-Bee> But QSDK fails to bring up the PCIe lanes
Aug 07 15:54:14 <Bumble-Bee2> blogic fyi the DTS from the AX3600 latest stock images : https://pastebin.com/raw/MRQRCtDF
Aug 07 16:22:16 <owrt-snap-builds> build #422 of gemini/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/gemini%2Fgeneric/builds/422
Aug 07 16:23:20 <owrt-snap-builds> build #262 of bcm27xx/bcm2708 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/bcm27xx%2Fbcm2708/builds/262
Aug 07 16:53:56 <owrt-snap-builds> build #415 of lantiq/xway is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fxway/builds/415
Aug 07 17:31:48 <owrt-snap-builds> build #411 of armvirt/64 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/armvirt%2F64/builds/411
Aug 07 18:00:58 * rsalvaterra is looking at the hostapd/wpad/wpa_supplicant configuration mess...
Aug 07 18:01:31 <rsalvaterra> adrianschmutzler: ping
Aug 07 18:01:42 <adrianschmutzler> mom
Aug 07 18:02:09 <rsalvaterra> mom? :P
Aug 07 18:02:53 <rsalvaterra> Is there any technical reason to link the *basic variants with wolfSSL only, and not OpenSSL, if desired?
Aug 07 18:06:38 <adrianschmutzler> now ...
Aug 07 18:06:45 <rsalvaterra> (Asking before diving in the Makefile. :P)
Aug 07 18:06:55 <adrianschmutzler> rsalvaterra: not really
Aug 07 18:07:22 <adrianschmutzler> for the basic-wolfssl, I essentially just picked up the patch from ynezz
Aug 07 18:08:20 <adrianschmutzler> However, I haven't checked the sizes in comparison, maybe basic-openssl would be bigger, so it wouldn't make sense then to have a basic package.
Aug 07 18:08:33 <adrianschmutzler> i.e. reduce size at one end but add it at the other end
Aug 07 18:09:07 <rsalvaterra> The thing is, if one *really* wants to have, say, Tor (which only builds against OpenSSL) and is doesn't need the whole wpad/hostapd enchilada, having *basic-openssl variants would be nice.
Aug 07 18:10:16 <rsalvaterra> Of course you could argue that Tor should also build against wolfSSL, but I won't be the one opening that can of worms. :P
Aug 07 18:10:36 <adrianschmutzler> well, if you have a reason for it, propose it. won't make the existing mess much worse.
Aug 07 18:11:13 <adrianschmutzler> can't promise you that I will merge it though, just took this one up primarily because I want to get it into 19.07 before the bump
Aug 07 18:11:35 <adrianschmutzler> bump=point release
Aug 07 18:13:16 <rsalvaterra> I'm not proposing this for before the bump, for me it falls in the "nice to have" category.
Aug 07 18:14:18 <adrianschmutzler> yes, of course. just was expressing why I took initiative here, where wpad/hostapd typically is not my realm
Aug 07 18:14:44 <rsalvaterra> Nothing is my realm. I just scratch where it itches. :)
Aug 07 18:15:25 <adrianschmutzler> well, with the rearranged options, it should actually be fairly easy to add that other package.
Aug 07 18:16:25 <mangix> rsalvaterra: shoudln't be hard to add wolfssl support to tor
Aug 07 18:16:34 <adrianschmutzler> though I can't say whether openssl would have specific restrictions that prevent a wpad-basic variant
Aug 07 18:16:40 <mangix> APIs are mostly the same
Aug 07 18:16:57 <Grommish> rsalvaterra: So, I broke Suricata
Aug 07 18:17:19 <Grommish> rsalvaterra: https://forum.suricata.io/t/suricata-5-0-3-and-openwrt/461/9
Aug 07 18:17:56 <rsalvaterra> adrianschmutzler: Yeah, I believe so, that's why I asked about technical reasons. I'll cook something up, and post it if the diff isn't too scary.
Aug 07 18:18:55 <dangole> wpad-basic-openssl should build just fine and the resulting package should have about the same size as wpad-basic-wolfssl. if one already needs openssl anyway for something else i can see that this would be useful.
Aug 07 18:19:53 <rsalvaterra> dangole: That's the whole point, yes. :)
Aug 07 18:21:17 <rsalvaterra> Grommish: I don't think you broke it, you just exposed existing brokenness. ;)
Aug 07 18:21:53 <Grommish> Maybe.. the good news is, jow was feeling sympathetic and may have fixed my brokenness for rust
Aug 07 18:22:07 <Grommish> I'm testing another change and then I can switch back to the rustup/suricata stuff
Aug 07 18:27:40 <svanheule[m]> nick: ping
Aug 07 18:28:24 <nick[m]3> svanheule: ping
Aug 07 18:28:29 <nick[m]3> pong*
Aug 07 18:28:55 <svanheule[m]> nick: So I got myself some MX25L12835F flash chips
Aug 07 18:29:36 <nick[m]3> svanheule: aaand? :) do u have the jffs2 errro?
Aug 07 18:29:45 <svanheule[m]> nick: and put them in my EAP245-v1 with one of these nifty things: https://thelabeshop.com/products/dediprog-spi-flash-socket-8-pin
Aug 07 18:30:30 <adrianschmutzler> dangole: so the whole wolfssl vs. openssl is a taste-thing after all?
Aug 07 18:30:33 <svanheule[m]> nick: copied over flash contents from the original chip, and then ran a sysupgrade through LuCI, keeping the config (so like sysupgrade -n)
Aug 07 18:30:45 <svanheule[m]> nick: It runs just fine, no jffs2 errors :-/
Aug 07 18:30:45 <nick[m]3> svanheule: cool. did not know that something like this exists ;)
Aug 07 18:31:37 <nick[m]3> svanheule: which spi clock freq?
Aug 07 18:31:44 <svanheule[m]> nick: 25MHz
Aug 07 18:32:23 <dangole> adrianschmutzler: openssl is about 700kB, wolfssl about 250kB, mbedtls <200kB afaik
Aug 07 18:33:09 <svanheule[m]> nick: you tried running it at 10MHz, right?
Aug 07 18:33:19 <dangole> adrianschmutzer: OpenSSL License can also be a bit tricky
Aug 07 18:33:36 <Grommish> adrianschmutzle: jow gave me a change to make with the sysupgrade commands for Itus. I'm testing and then going to push it..  Where there any other issues you had format wise with the PR?
Aug 07 18:33:43 <adrianschmutzler> dangole: now I see the true meaning of your initial commit
Aug 07 18:34:18 <nick[m]3> svanheule: hmmm. :/ no did not try 10 MHz. This is my upstream to the internet right now and I had to do other stuff. I will try
Aug 07 18:35:04 <nick[m]3> svanheule: but some other person already confirmed
Aug 07 18:35:05 <nick[m]3> svanheule: https://forum.openwrt.org/t/nanobeam-ac-gen-2/70640/20?u=polynomialdivision
Aug 07 18:35:18 <adrianschmutzler> hmm, GitHub has changed the positioning of the commits conversation view
Aug 07 18:35:35 <adrianschmutzler> they aren't next to the last update, but just ... somewhere
Aug 07 18:35:58 <svanheule[m]> nick: my build is from 22/07, I wonder if that would make a difference
Aug 07 18:36:03 <Grommish> the biggest issue was my inability to understand the naming schema ;p
Aug 07 18:36:04 <jow> wait until they sneaking in rectangular tiles
Aug 07 18:36:24 <Grommish> and while i did update it, I pushed it to the wrong branch when I sent it, so it hadn't updated the PR :D
Aug 07 18:36:27 <Grommish> since corrected
Aug 07 18:36:37 <nick[m]3> I will pull latest master
Aug 07 18:36:53 <svanheule[m]> adrianschmutzler: I had to search a while for the commit history in the new layout :P
Aug 07 18:37:20 <adrianschmutzler> svanheule[m]: Indeed, the thing that hit me first, too
Aug 07 18:37:32 <adrianschmutzler> but that commit positioning is really crap for review
Aug 07 18:37:36 <jow> adrianschmutzler: I am going to take care of the jones commits
Aug 07 18:37:48 <adrianschmutzler> jow: thanks
Aug 07 18:38:51 <adrianschmutzler> svanheule[m]: was just recently looking at a PR where the commit was shown next to initial post, i.e. never changed based on previous behavior. was just about to close it when I saw that the submitter actually had pushed, but the commit was just stuck to the position
Aug 07 18:39:23 <adrianschmutzler> and for Grommish's PR it's now just somewhere in the middle, why ever
Aug 07 18:39:48 <svanheule[m]> adrianschmutzler: Yeah, I've had a force push mess up the order on my PR too :-/
Aug 07 18:40:11 <svanheule[m]> adrianschmutzler: changed into the correct order after a while...
Aug 07 18:40:54 <svanheule[m]> the commit order, to be precise, not just the message/commit timeline
Aug 07 18:41:11 <adrianschmutzler> commit order is an even older annoying problem
Aug 07 18:43:51 <adrianschmutzler> actually, I generally like GitHub, but some stuff is really annoying
Aug 07 18:46:24 <rsalvaterra> dangole: Do all the *basic variants support SAE/WPA3 Personal?
Aug 07 18:48:13 <adrianschmutzler> Grommish: That's what I was looking for. Only nitpicks now from my side; and I'd still like the changed title.
Aug 07 18:48:54 <Grommish> I'm fixing those changes.
Aug 07 18:49:28 <adrianschmutzler> jow: can I close the older one then instead? #3282 ?
Aug 07 18:49:36 <Grommish> adrianschmutzle: Although I'm not sure where the title you are talking about is? I've changed the commit msg, I've edited the PR title itself.. where did I miss?
Aug 07 18:50:00 <aparcar> morning
Aug 07 18:50:19 <adrianschmutzler> Grommish: "bring up" -> "add support for"
Aug 07 18:50:37 <Grommish> Ah, ok.. last time is the was itus,shield-router I included.. Gotcha
Aug 07 18:51:40 <aparcar> jow: Do you think the PKG_FILE_MODES is cleaner than having the steps directly within the Package/install definition? I think once there is selinux support another labeling variable would be required
Aug 07 18:52:09 <aparcar> I mean we could also use PKG_SELINUX_LABELS
Aug 07 18:52:16 <aparcar> and just extend ipkg-build
Aug 07 18:55:07 <jow> adrianschmutzler: and ... boom. That didn't take long :)
Aug 07 18:57:00 <aparcar> context?
Aug 07 19:00:31 <jow> aparcar: just the usual pr ranting
Aug 07 19:02:32 <aparcar> -.-
Aug 07 19:03:46 <Grommish> Is it detrimental to use a bs=4096 on a dd command when targeting a eMMC?  I had seen that eMMC uses 512byte sectors?
Aug 07 19:04:44 <Grommish> If I can combine these commands with the same one edgerouter uses, I can save some lines
Aug 07 19:10:20 <xdarklight> Hauke: great to hear that you found^Wfixed some bugs in the Lantiq Ethernet MAC driver :-) I'll be offline tomorrow but I'll try to review/test the patches once you sent them. Thanks for looking into it!
Aug 07 19:10:30 <adrianschmutzler> jow: so, he appears to be a known troll ...
Aug 07 19:13:57 <Borromini> adrianschmutzler: can i have a look at said pr? :)
Aug 07 19:14:29 <nick[m]3> svanheule: just flashed
Aug 07 19:14:36 <dangole> rsalvaterra: nope, they support 802.11w which is required for WPA3, but not SAE itself.
Aug 07 19:14:44 <nick[m]3> svanheule: and "daemon.err mount_root: failed to sync jffs2 overlay"
Aug 07 19:15:01 <nick[m]3> svanheule: just to be sure where can I check spi clock?
Aug 07 19:15:07 <aparcar> how do I run a Makefile definition in a subshell?
Aug 07 19:15:07 <dangole> rsalvaterra: so only when build against either openssl or wolfssl, the EC math for SAE is supported
Aug 07 19:15:09 <svanheule[m]> nick: let me try with a more recent master too
Aug 07 19:15:15 <blogic> nick[m]3: in the dts file
Aug 07 19:15:29 <rsalvaterra> dangole: Got it, thanks!
Aug 07 19:15:42 <nick[m]3> fsvanheule: not somewhere in the bootlog?
Aug 07 19:15:45 <svanheule[m]> nick: spi_max_frequency is defined in DTS, and can be found under /sys at runtime
Aug 07 19:16:49 <rsalvaterra> I'm actually more worried about my BusyBox patch. It's been a week and I only got crickets. I'm going to ask about it on #busybox.
Aug 07 19:16:52 <svanheule[m]> nick: `cat /sys/bus/spi/devices/spi0.0/of_node/spi-max-frequency  | hexdump`
Aug 07 19:17:47 <aparcar> rsalvaterra: a week and no upstream reaction? https://github.com/aperezdc/signify/pull/29
Aug 07 19:18:16 <adrianschmutzler> so, how's the mood here about that wpad-basic-wolfssl by default?
Aug 07 19:18:35 <nick[m]3> svanheule: 0000000 0098 9680
Aug 07 19:18:37 <adrianschmutzler> on the mailing list, there wasn't much discussion about it ...
Aug 07 19:19:08 <aparcar> adrianschmutzler: I like it but I already said so on the ML
Aug 07 19:19:10 <nick[m]3> svanheule: okay 10 MHz  ;)
Aug 07 19:19:32 <aparcar> can you compare the opkg update with and without https/
Aug 07 19:19:37 <aparcar> I felt like it's 5 times slower
Aug 07 19:19:48 <svanheule[m]> nick: they never taught me to read hex in primary school :P
Aug 07 19:20:04 <rsalvaterra> aparcar: Yeah, still no answer. :/ I asked in the channel, let's see.
Aug 07 19:20:38 <nick[m]3> svanheule: ^^
Aug 07 19:22:33 <nick[m]3> svanheule: a reboot completely destroys the router. xD logread -> "Failed to find log object: Not found"
Aug 07 19:22:51 <aparcar> dangole: -rwsr-xr-x root/root     81045 2020-08-07 07:14 ./usr/bin/sudo
Aug 07 19:22:55 <aparcar> oes thi look right to you?
Aug 07 19:23:40 <svanheule[m]> nick: that doesn't sound like it's improving
Aug 07 19:24:04 <aparcar> ipkg-build now uses fakeroot and the "modes" for files. I somewhat like that more than digging into package-ipkg.mk
Aug 07 19:24:46 <nick[m]3> svanheule: I could do a sysupgrade again without "-n" let me try it if improves the situation xD
Aug 07 19:26:31 <dangole> aparcar: would be great to also handle chown properly. many packages could potentially benefit from not having all files owned by root:root.
Aug 07 19:27:25 <jow> rsalvaterra: thats normal
Aug 07 19:27:40 <jow> rsalvaterra: wait times up to several months are possible for busybox patches
Aug 07 19:28:38 <jow> rsalvaterra: you need to send a friendly ping reminder every two weeks or so
Aug 07 19:28:39 <rsalvaterra> jow: Oh, my...! Do we want to wait that much? :P
Aug 07 19:28:53 <aparcar> dangole: but it does if you define PKG_FILE_MODES
Aug 07 19:29:38 <aparcar> rsalvaterra jow what if we add the patch to OpenWrt? Wouldn't that likely increase the speed
Aug 07 19:29:40 <aparcar> ?
Aug 07 19:29:49 <rsalvaterra> jow: Heh. #busybox also seems like a nickname parking lot.
Aug 07 19:30:05 <adrianschmutzler> so, just like with our PRs; only that pinging every two weeks doesn't help ;-)
Aug 07 19:30:37 <dangole> aparcar: nice, so PKG_FILE_MODES does the trick for all that and fakeroot only for SELinux then
Aug 07 19:30:52 <jow> well, isn't that the norm for most FOSS software? The more critical a component is, the less manpower is available to maintain it :)
Aug 07 19:30:59 <rsalvaterra> aparcar: I specifically mentioned that the patch is very useful to OpenWrt: http://lists.busybox.net/pipermail/busybox/2020-July/088164.html
Aug 07 19:31:30 <nick[m]3> svanheule: sysupgrade hepled. I have now logread again xD
Aug 07 19:31:44 <aparcar> dangole: fakeroot is used to set any modes you like inside the tar file
Aug 07 19:32:25 <aparcar> dangole: the squashfs part also uses fakeroot so modes are kept
Aug 07 19:33:38 <Slimey> what time do you guys stop drinking coffee during the day
Aug 07 19:34:32 <aparcar> jow dangole http://sprunge.us/fGjYBO that's the patch
Aug 07 19:34:46 <aparcar> once I understan how selinux work I could extend ipkg-build with that too
Aug 07 19:35:11 <dhewg> controversial but just fyi: the recent intel leak apparently contains some lantiq vrx fw source