**** BEGIN LOGGING AT Wed Jan 09 02:59:57 2019 **** BEGIN LOGGING AT Wed Jan 09 04:53:10 2019 Jan 09 06:06:57 hmmm Jan 09 06:06:57 [jwh@aurbuilder erpoe]$ ./scripts/kconfig.pl Jan 09 06:06:58 Parse error at ./scripts/kconfig.pl line 137. Jan 09 06:07:05 I hate perl :( Jan 09 06:07:45 what args does it need? Jan 09 06:13:34 that's kinda not really a way kconfig is done Jan 09 06:14:10 I'm trying to generate a .config Jan 09 06:14:36 but without doing a build and copying the .config from build_dir Jan 09 06:14:58 there are defconfig files Jan 09 06:15:05 kernel .config, not openwrt Jan 09 06:15:33 obviously the nicer solution would be for the build system to generate one for external trees, but alas Jan 09 06:15:35 there are still defconfig files Jan 09 06:15:50 yeah, but that doesn't cover any kmods etc selected Jan 09 06:16:35 although I guess if they're modules maybe it'll work Jan 09 06:16:39 s/if/s/ Jan 09 06:16:41 as* Jan 09 06:18:42 on a related note, if I was applying the openwrt patches, which order should they be in? for hack/backports/pending Jan 09 06:20:05 other alternative is to just diff stock vs vendor, but I'd still need to go back a few patch levels so patches may not apply anyway Jan 09 06:24:49 not that its going to work anyway, there are nonsense redefinitions using this kernel for no apparent reason Jan 09 06:24:53 musl is great :D Jan 09 06:25:22 it's backports -> pending -> hack afaik Jan 09 06:25:35 hm Jan 09 06:25:36 ok Jan 09 06:32:20 wait so it *does* generate a .config? Jan 09 06:32:28 I'm really confused now Jan 09 06:37:48 "it" ? Jan 09 06:38:05 build Jan 09 06:38:10 if using an external tree Jan 09 06:38:18 I couldn't convince it to generate one the other day Jan 09 06:42:50 hm, ok nevermind then back to netifd not building Jan 09 06:46:14 http://ix.io/1xRT Jan 09 06:46:18 :( Jan 09 06:48:48 but external tree or not should make no difference Jan 09 08:23:08 jwh: that error is indeed caused by external tree Jan 09 08:24:09 jwh: your kernel headers are too old for musl (https://wiki.musl-libc.org/faq.html#Q:-Why-am-I-getting-) Jan 09 08:26:51 jwh: apply the 270 and 272 uapi patches from https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=target/linux/generic/backport-4.14;hb=4336efe14b61e47177a2d0863f8391c48cf4a9f5 Jan 09 08:37:13 ah hm Jan 09 08:37:23 thought I'd be safe with a 4.9 tree Jan 09 08:37:40 thanks! Jan 09 08:38:03 jwh: at the same revision there's also backport patches for 4.9 Jan 09 08:38:12 https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=target/linux/generic/backport-4.9;hb=4336efe14b61e47177a2d0863f8391c48cf4a9f5 Jan 09 08:38:32 so would this break on any tree, even latest 4.14 or 4.19? Jan 09 08:39:10 upstream supposedly carries these catches since 4.15 Jan 09 08:40:20 ahhhh Jan 09 08:49:51 question. If I want a given uci option to always have the value of another option (say, hostname), how would I do that? Jan 09 08:53:12 there is no such facility in uci Jan 09 09:01:16 rats. well, one could hope :) Jan 09 09:06:49 hm Jan 09 09:07:04 are there any little poe switches supported by openwrt? (toughswitch type things?) Jan 09 09:07:23 dumb passive that is Jan 09 09:07:50 I don't follow that line of questioning Jan 09 09:08:43 which bit? Jan 09 09:08:55 I mean, wouldn't you ideally want something capable of running an OS in that case? I'd love to get openwrt or the like on my cisco catalyst switches but that'll never happen D: Jan 09 09:09:17 the toughswitch is an ar71xx as an example Jan 09 09:09:47 no console and probably no uart, so that will be why Jan 09 09:09:53 huh. but is that a dumb/passive switch? seems like it would be more 'advanced' Jan 09 09:09:54 pipe dream maybe Jan 09 09:09:57 ah... Jan 09 09:10:11 pretty much, 24V (iirc) in, configurable output per port Jan 09 09:10:15 probably gpio controlled Jan 09 09:10:45 just a switch with the pins for poe wired up to a voltage regulator and stuff Jan 09 09:11:16 https://wikidevi.com/wiki/Ubiquiti_Networks_TOUGHSwitch_PoE_Pro Jan 09 09:11:27 24/48, not 24 Jan 09 09:12:26 jwh: do you mean passive PoE when you say "dumb"? Jan 09 09:12:31 yes Jan 09 09:12:49 jwh: I think hanetzer interpreted it as "dumb switch" as in "not configurable" Jan 09 09:12:54 ahhh Jan 09 09:13:04 well thats why I said dumb passive (meaning poe, not the switch) Jan 09 09:13:07 rather than af Jan 09 09:13:31 reason being: I was going to step it down to power LEDs also Jan 09 09:13:36 jwh: right, so that's the confusion. I think it's easier for people to udnerstand if you call it "passive PoE" only. Jan 09 09:14:07 radio is going on the roof, so need 24V up there anyway Jan 09 09:14:44 may as well put other devices up there too Jan 09 09:14:58 SwedeMike: noted Jan 09 09:16:06 jwh: what's the use-case to run OpenWrt on something like this instead of edgeos or similar? Jan 09 09:16:16 none really, just nic to have Jan 09 09:16:18 nice* Jan 09 09:16:37 but actually thinking about it, I wonder if an edgerouter poe would be better albeit with limited ports Jan 09 09:18:52 that depends if I get this vendor kernel working, then I can have openwrt *and* the switch ports and poe Jan 09 09:19:25 I think I figured out the magic for switch config now, poe is a simple toggle Jan 09 09:20:32 config is horrible, it uses bitmasks to denote which ports are "switched" and which are "routed" (looks like it just tags the port like swconfig) Jan 09 09:20:55 but it calls the interfaces ethX instead of ethX.Y Jan 09 09:23:24 ubnt are just assholes for doing it like this when they could have done it sensibly Jan 09 09:24:30 although lack of DSA makes it a pain in the ass for them I guess Jan 09 09:33:38 hm, I'm doing something wrong Jan 09 09:44:59 my biggest gripe with openwrt at this point in time is remote software management and using the openwrt provided images. It's a pain to try to get into the same state after sysupgrade after you've initially taken the openwrt image and then done some opkg install , especially if these packages are needed for connectivity Jan 09 09:45:12 yes Jan 09 09:45:16 I am facing that problem as well Jan 09 09:45:27 so for remote management one really has to roll ones own image, it's the only sensible thing. And even then, config management is so-so Jan 09 09:45:36 less so the packages though as I just build everything in, images don't even have opkg on them Jan 09 09:46:17 config/firmware management is a bit of a nightmare though, the openwisp stuff is half there Jan 09 09:46:21 but I'm just rolling my own now Jan 09 09:46:34 shell scripts and curl Jan 09 09:47:46 I should really write it as a daemon in that maintains a persistent connection, rather than using cron to poll Jan 09 09:48:44 but I expect libevent and all that jazz will make it too big for some obscure devices Jan 09 09:49:32 the other alternative is to make sure they're always reachable (in some vrf probably) and use ssh from central management, but bleh Jan 09 09:59:38 openwisp2 is nifty for mass remote mgmt Jan 09 10:01:22 hm Jan 09 10:01:48 I think I looked at the original Jan 09 10:07:12 granted this is just me watching vids and such, I've not used it (yet) Jan 09 10:20:20 heh Jan 09 11:06:03 SwedeMike: you want to roll your own firmware images anyway, package management/deps is PITA even on desktop Linux distributions so I wouldn't even expect to be working on embedded devices Jan 09 11:06:43 I think its more post sysupgrade packages Jan 09 11:06:53 but iirc someone in #openwrt was trying to implement that sort of thing Jan 09 11:07:18 but those packages can have dependencies, which usually is causing the most problems Jan 09 11:07:36 or that they're not reinstalled after sysupgrade... Jan 09 11:08:00 so if you need one of those non-default packages for connectivity, they can't even be added Jan 09 11:08:27 and it's easier to track problems down while knowing that there's only one possible state (one firmware image version Y) Jan 09 11:08:49 yeah but that doesn't happen in real world deployments Jan 09 11:11:12 sure, just take a Turris fuckups Jan 09 11:11:21 s/take a/take a look at/ Jan 09 11:11:47 you often get multiple generations of products for example Jan 09 11:12:00 or services that just aren't compatible with your latest firmware Jan 09 11:12:46 you can build custom images for that cases as well Jan 09 11:13:09 I have like 3 generations of firmware active at present as an example, one isn't even openwrt based so theres no upgrade path and honestly even the openwrt based ones that are old I wouldn't attempt Jan 09 11:13:44 I'm talking about only openwrt, following best practices, running latest stable release Jan 09 11:13:58 again, doesn't happen in the real world Jan 09 11:13:58 heh Jan 09 11:14:15 especially if you also rely on vendor cde Jan 09 11:14:19 code* Jan 09 11:15:50 but upstream don't need to care about this use cases, it's your fight :) Jan 09 11:16:02 runtime-installable packages on openwrt are more a byproduct Jan 09 11:16:22 the normal use case should be pregenerated firmware images Jan 09 11:16:43 yup Jan 09 11:16:54 given the ever increasing space constraints etc. I was even thinking about making opkg on-target completely optional Jan 09 11:16:56 packages are actually just an extra level of hassle Jan 09 11:17:07 jow: hm isn't it already? Jan 09 11:17:17 if you deselect it, that is Jan 09 11:17:51 well in the sense that binary images come without opkg already and hat we propvide some sort of install script or standalone opkg executable to bootstrap opkg on-target if needed Jan 09 11:18:17 oh right Jan 09 11:18:58 you could pretty much just have 'opkg' as a shell script I guess, download and extract an archive if its not installed, or exec opkg.bin or something if it is Jan 09 11:19:16 for runtime config management on openwrt I had good success with ansible raw mode Jan 09 11:19:19 well, nice solution (and probably good GSoC project) might be an online image generator Jan 09 11:19:57 that blurs the line between user fuckups and project though, extra support load when people could just use imagebuilder Jan 09 11:19:58 the only "hassle" I see compared to other distros is that there is few to none prbuilt macros Jan 09 11:20:36 but other than that I'm unsure why rewriting /etc/config/wireless is more painful than generating /etc/hostapd.conf for debian or similar Jan 09 11:21:00 I don't think its particularly painful Jan 09 11:21:01 who said that? Jan 09 11:21:15 jwh: it's not easy to use imagebuilder for BFUs, it doesn't run on Windows Jan 09 11:21:23 was referring to SwedeMike's statement "And even then, config management is so-so" Jan 09 11:21:35 if you can't manage to install ubuntu in a VM then you should probably stick with stock firmware Jan 09 11:21:38 :D Jan 09 11:21:48 jow: oh Jan 09 11:21:57 theoretically you can replace the entire /etc/config/ and call /sbin/reload_config Jan 09 11:21:59 jow: I think he meant more mass management (CPE etc) Jan 09 11:22:03 it does not get much simpelr than that Jan 09 11:22:18 ansible doesn't scale that well if you have 1000s and 1000s of devices Jan 09 11:22:22 well for mass management do exactly that using ansible Jan 09 11:22:22 mass management with uci is much easier, try to do that with debian Jan 09 11:22:43 also ansible only covers config, not version management or upgrading Jan 09 11:22:50 openwisp does do some of that Jan 09 11:23:02 right, but that would be way out of scope of openwrt either way Jan 09 11:23:12 ansible also requires that the devices be reachable via ssh Jan 09 11:23:18 debian, gentoo, ubuntu, centos do not attmempt to do that either Jan 09 11:23:21 yes Jan 09 11:23:28 such logic is usually externalized into a deployment controller Jan 09 11:23:55 yeah Jan 09 11:24:08 sigh Jan 09 11:24:09 arch/mips/vdso/genvdso: 'arch/mips/vdso/vdso.so.dbg' contains relocation sections Jan 09 11:24:12 what a useful error Jan 09 11:46:50 ynezz: if I upgrade a debian system then I don't have the problem I am describing. Jan 09 11:47:10 ynezz: because sysupgrade means I will miss packages after it's run in its current form. Jan 09 11:47:59 I think some bits towards that got merged Jan 09 11:48:13 and also there was a guy in #openwrt trying to implement package installation post upgrade Jan 09 11:48:22 I mean really you should just make your own image but whatevr Jan 09 11:48:25 whatever* Jan 09 11:48:52 there are shell oneliners to try to grab a list of opkg install packages I need to perform after the upgrade to get back to my existing package list, there isn't even a built in function to do that Jan 09 11:49:35 jwh: yes, it's pretty obvious that it's very common to make ones own build environment and compile ones own image. Jan 09 11:51:12 imagebuilder makes it asier Jan 09 11:51:15 easier Jan 09 11:51:21 pretty much what its designed for I guess Jan 09 11:52:21 right. Jan 09 11:53:13 I mean, I rarely even upgrade my openwrt devices Jan 09 11:53:26 obviousy I don't bother building images for my own stuff like APs Jan 09 11:53:39 obviously* Jan 09 11:53:58 SwedeMike: but with debian you're upgrading complete system with packages, so this is not exactly proper comparison Jan 09 11:54:50 and you don't have read-only rootfs there etc. Jan 09 11:56:21 I believe, that nobody has added such built-in functionality yet, because once added it has to be supported, and while it works for most use cases, it would be maintenance and support nightmare for the rest use cases Jan 09 11:57:00 opkg would need to handle a lot of corner cases, becoming essentialy apt Jan 09 11:59:30 ynezz: I agree, it's a complicated problem. Jan 09 12:00:22 and I understand why it's the way it is because it makes sense for the very constrained devices that openwrt wants to support Jan 09 12:14:53 jow: I'm wondering if there is going to be 18.06.2-rc ? Seems like 18.06.1 is broken on kirkwood/audi but snapshots work https://bugs.openwrt.org/index.php?do=details&task_id=1810#comment5893 Jan 09 12:23:52 ynezz: usually we do no rc's for .2 Jan 09 12:24:00 or for service versions that is Jan 09 12:27:18 ok, noted Jan 09 12:28:30 it's going to be fun without that device to find the commit for cherry-pick into 18.06.2 if it's not already included in your branch Jan 09 12:32:06 is it broken in .1 as well? then we could simply disable it Jan 09 12:34:31 it seems so https://forum.openwrt.org/t/failed-firmware-flash-from-18-06-0-to-18-06-1-ea3500-extroot/20196/11 Jan 09 12:36:06 what's the current ETA for 18.06.2 ? Still 15th? Jan 09 12:40:46 thats still the plan, yes Jan 09 12:49:50 noice Jan 09 14:16:53 hm, cmdline hack, theres only the one patch in hack right? Jan 09 14:18:02 oh nm, target one too Jan 09 14:23:23 well, it builds.. lets see if it boots (probably not) Jan 09 14:37:17 Linux OpenWrt 4.9.79 #0 SMP Sat Jan 5 10:24:52 2019 mips64 GNU/Linux Jan 09 14:37:17 Linux OpenWrt 4.9.79 #0 SMP Sat Jan 5 10:24:52 2019 mips64 GNU/Linux Jan 09 14:37:23 far too easy, whats broken Jan 09 14:41:03 ah, network, good start Jan 09 14:41:49 :P Jan 09 14:41:53 not important Jan 09 14:42:39 morning Jan 09 14:42:41 IANAL, but if someone puts Apache 2.0 license text into `Impinj-Standard Binary License and Distribution Agreement` can I assume, that I can probably freely redistribute binary firmware images as well ? Jan 09 14:42:50 the offloading probably needs some setup, or the generic one doesn't quite work with this ubnt board Jan 09 14:42:56 and requires their module Jan 09 14:43:13 the source code contains Apache 2.0 license, but obviously no such thing exists for firmware images for MCUs Jan 09 14:43:33 they made a total mess, broke netfilter in their kernel too Jan 09 14:43:52 tries to goto a non existent label if IMQ isn't enabled Jan 09 14:45:38 oh nm, just windows sharing being uselss Jan 09 15:47:37 981213: Christmas! Thanks, and enjoy your holidays! :) Jan 09 15:59:57 * gch981213 doesn't know what to reply due to his poor English :D Jan 09 16:01:13 :) Jan 09 16:08:07 gch981213: BTW I've noticed your esp8266/mt7530 project and I'm wondering which switch are you using for that, since the information is missing in the README Jan 09 16:13:43 ynezz: I'm using Tenda SG105. Jan 09 16:56:12 gch981213: Ok, thanks Jan 09 17:49:15 anyone got an mt7620 device? Jan 09 20:46:17 I've got a https://openwrt.org/toh/xiaomi/mir3 in tthe cupboard I guess, what do you really asking? Jan 09 22:11:03 karlp: some guy is asking if packet injection works Jan 09 22:11:19 i don't have such a device Jan 10 01:47:52 nbd: hi, just found out that mediatek has a 4x4 mu-mimo card, mt7615. Are there plans for a upstream driver like mt76? **** ENDING LOGGING AT Thu Jan 10 03:00:02 2019