**** BEGIN LOGGING AT Tue Nov 13 02:59:59 2018 Nov 13 05:01:48 nbd: gl-mt300n-v2 (mt7628) after pinging most of 24 hours: "[86333.726041] mt76_wmac 10300000.wmac: MCU message 8 (seq 15) timed out" Nov 13 08:24:44 nbd: it was running a recent build (r8448-81d7f82441). it killed the ping that was running with "Network unreachable", but reassociated after a couple seconds, and I could subsequently start a new ping. Nov 13 08:29:43 * russell-- also just cracked open a zyxel c3000z that came to me via a neighbor Nov 13 08:30:06 CFE seems pretty limited Nov 13 08:30:23 also, i can login to a limited shell Nov 13 08:30:31 nand flash Nov 13 08:33:35 ldir: I've been holding off to bump as 4.14.81 already got rc1 stage a day single day or so after release of 4.14.81 :) Nov 13 08:33:58 last part: 4.14.80 Nov 13 08:55:05 xback: oh :) Nov 13 08:56:02 well I was building an image for our firewalls at work and I prefer to have the latest kernel at that time, because we don't regularly update them Nov 13 08:58:10 stintel: sure. good thing it got bumped :) Nov 13 08:58:21 still suffering from the memleak? Nov 13 08:58:46 yes Nov 13 08:58:56 btw. what is your opinion on: http://patchwork.ozlabs.org/patch/996191/ ? Nov 13 08:59:00 it looks ... odd Nov 13 09:02:07 xback: https://www.linux-ipv6.be/OpenWrt/3CvbYigUpxbUukBT.png Nov 13 09:02:15 seems a bit less but still happening Nov 13 09:02:20 xback: I like the idea Nov 13 09:02:36 xback: I didn't like the 3x # kX.XX Nov 13 09:03:22 please don't add arbitrary whitespace to avoid patch conflicts Nov 13 09:03:30 this just feels wrong Nov 13 09:03:51 jow: so that's a NAK from you :) Nov 13 09:04:04 personally, I would nack it too Nov 13 09:05:13 I understand the kernel bumps are annoying to some .. but if it's needed .. it's needed Nov 13 09:05:42 if it is really such a big concern, a cleaner way would be moving all version related variables into a separate .mk file each Nov 13 09:05:48 xback: I have 4.14.80 for 18.06 in my staging tree Nov 13 09:05:55 then rework the code to include all *.mk files Nov 13 09:06:08 xback: you're running some 18.06 devices, right ? Nov 13 09:06:34 stintel: no, not in the field at least. but I can test 18.06 builds Nov 13 09:06:59 jow: the downsize is that the kernel version info gets decentralized Nov 13 09:08:23 stintel: want me to test it? Nov 13 09:08:31 otherwise ill start a build right now Nov 13 09:09:59 xback: I did x86/64 build and test in qemu Nov 13 09:10:24 stintel: can you push your 18.06 branch to your staging please? Nov 13 09:10:34 is it not htere ? Nov 13 09:10:45 last update: 3 weeks ago Nov 13 09:10:52 specifically 18.06 branch Nov 13 09:10:54 ah Nov 13 09:11:06 I thought I pushed it, now I did Nov 13 09:11:24 ack. build running Nov 13 09:11:34 cns3xxx, imx6 Nov 13 09:11:39 awesome, thanks! Nov 13 09:11:58 kinda go jealous of your dev box :P Nov 13 09:12:00 got* Nov 13 09:12:32 i'm spoiled .. I really am .. :) Nov 13 09:12:49 thats the cool part of working a small company with people aged round ~ 30 Nov 13 09:12:59 sometimes these things are possible .. just because it can Nov 13 09:15:23 I used to have a beefy box (6C/12T/32GB), but it's 6.5y old :) Nov 13 09:17:03 recently upgraded to 64GB, now it's at max RAM Nov 13 09:18:30 still a sweet machine if you would ask me :) Nov 13 09:19:33 yeah Nov 13 09:19:40 I spoilt myself too, back then :) Nov 13 09:22:43 building packages on both .. Nov 13 09:22:55 eta 10 mins or so Nov 13 09:26:31 do you do a full build ? Nov 13 09:26:56 yes Nov 13 09:27:00 tools .. toolchain .. etc Nov 13 09:27:00 wow :) Nov 13 09:27:07 yeah but I mean all packages ? Nov 13 09:27:25 in this case no Nov 13 09:27:28 ok Nov 13 09:27:47 just checkout. select target and build Nov 13 09:28:16 I've been thinking about automating those kernel bumps Nov 13 09:28:22 likewise Nov 13 09:28:26 got a partial script Nov 13 09:28:39 which often polls the kernel.org site for changes Nov 13 09:28:55 effectively, just pointing at the next url Nov 13 09:29:17 should be doable Nov 13 09:29:45 the plan I had was to automatically alter kernel file, start builds, and flash to my devices for testing Nov 13 09:31:53 but still .. I mostly check all commits in a new bump, and try to test it if a lot of changes were done in some part Nov 13 09:32:07 like a few weeks ago with the ubi that got broken upstream Nov 13 09:39:54 are there any openwrt targets that support the bcm63138 (cortex a9)? initial grepping says no Nov 13 09:41:15 admin:tP2w1wFvu8GXo:0:0:Administrator:/:/bin/sh Nov 13 09:41:17 admin:QIfo12L2DFL42:0:0:Administrator:/:/bin/sh Nov 13 09:42:27 stintel: Tested-by: Koen Vandeputte cns3xxx, imx6 Nov 13 09:42:39 xback: build+run ? Nov 13 09:42:43 yes Nov 13 09:42:48 aight Nov 13 09:42:48 both run-time tested Nov 13 09:43:30 [ 0.000000] Booting Linux on physical CPU 0x900 Nov 13 09:43:31 [ 0.000000] Linux version 4.14.80 (koen@bob) (gcc version 7.3.0 (OpenWrt GCC 7.3.0 r7385-e58dc7000c)) #0 SMP Tue Nov 13 09:05:28 2018 Nov 13 09:43:32 [ 0.000000] CPU: ARMv6-compatible processor [410fb024] revision 4 (ARMv7), cr=00c5787d Nov 13 09:43:34 [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Nov 13 09:43:35 [ 0.000000] Machine: Gateworks Corporation Laguna Platform Nov 13 09:43:53 I'll push it then, thanks Nov 13 09:44:27 WTF Nov 13 09:44:43 remote: No matching SoB line found for author Stijn Tintel Nov 13 09:44:52 oh Nov 13 09:44:53 nvm :) Nov 13 09:45:20 stintel: I would check your mailbox ? :p Nov 13 09:45:42 hmm? Nov 13 09:46:03 it's a pre-receive hook Nov 13 09:46:09 I just had another commit without SoB Nov 13 09:47:10 bad joke :) "Dear Stintel .. we thank you for your contributions in the past .. but .. bla bla .. has been revoked .. bla bla" Nov 13 09:47:18 LOL Nov 13 10:45:49 stintel who? Never heard.... Nov 13 10:51:43 that Belgian weirdo who fled to Eastern Europe 😂 Nov 13 10:51:58 lol Nov 13 11:22:16 if you want a dev box that builds fast just apply for an account on https://cfarm.tetaneutral.net/ :) Nov 13 11:23:21 some nice ones for building are gcc10, gcc67, gcc122, gcc123, gcc135 Nov 13 11:23:54 https://cfarm.tetaneutral.net/machines/list/ Nov 13 11:24:58 zorun: actually I plan to get a Power9 workstation myself :) Nov 13 11:30:44 stintel: oh, you're that rich? :D Nov 13 11:31:23 I actually have no idea how much that thing costs, but I guess $$$ Nov 13 11:32:37 zorun: I'm self-employed and can buy it with my company. it's still expensive, and I had actually hoped to have it already Nov 13 11:32:48 but life is full of surprises :) Nov 13 12:06:28 the power9 stuff isn't _that_ expensive really. Nov 13 12:15:23 stintel: the # kX.XX are required to give context to the kernel-bump patches. The comment could be any text, but it should be different for every big kernel version. Otherwise quilt/git might get confused. Nov 13 12:15:45 xback: jow: they are empty spaces with a purpose. Anyway, I understand the NAK. Should I try a different approach, like splitting the files (kernel-version-kX.XX.mk) or just leave it in its current state? Nov 13 12:54:48 luaraneda: I must be stupid - I don't get what you're trying to solve Nov 13 13:00:00 stintel: ok, it makes sense Nov 13 13:22:44 ldir: I was trying to rebase the k4.19 PR on github, and then Hauke's k4.19 branch and I found merge conflicts every time I did a rebase because the branches were based on a old version, and on master the kernel has been bumped already Nov 13 13:23:45 luaraneda: the biggest reason for my nak, is that the problem gets shifted Nov 13 13:23:48 For k4.14 and 4.9, which has nothing to do with the branch adding support for k4.19 Nov 13 13:23:56 So the patch groups kernels by version (which is fine), and add some empty lines with comments to generate enough space (not ok) so that when someone add/bump/delete a kernel, the context lines in the patches won't include information from other kernels Nov 13 13:24:12 1st solution would be to add the whitespaces/comments .. but it doesnt look fine imho Nov 13 13:25:01 2nd solution would be to splitup the version in separate files. But as I'm mostly bumping the version. it means I have to alter different files multiple times. and the kernel info gets decentralized Nov 13 13:25:34 adding a new kernel only happens once a year, while bumping can be twice a week :) Nov 13 13:26:01 xback: ok, I understand that, I can try another solution that makes everyone happy. I'm not trying to impose a solution, just get, what I think is a problem, fixed Nov 13 13:26:10 I do understand that adding a kernel spans a few weeks :) Nov 13 13:27:46 xback: a few weeks for the genetic, but some targets are migrating for months Nov 13 13:28:26 fully agreed. Im expressing acknowledgement of the amount of work that it takes :) Nov 13 13:37:48 Could we at least group the LINUX_VERSION-X.XX and LINUX_KERNEL_HASH-X.XX.y variables? So at least the conflicted lines are grouped. Nov 13 13:37:48 There probably is a reason for keeping them separate, but I'm failing to see it Nov 13 13:38:51 my guess here would be that hystorically the file looks cleaner this way Nov 13 13:47:11 I'm happy to group the version & hash - and I agree it is a pain how they're split at present. Nov 13 15:36:08 meh, my domoticz hangs again Nov 13 16:11:44 and when starting it with gdbserver it ignores argsd Nov 13 16:13:43 and running it locally in gdb is useless coz no debugging symbols Nov 13 16:14:25 strace is useless too, it only shows nanosleep Nov 13 16:33:14 .... why does it ignore args? Nov 13 16:34:22 good question ... Nov 13 16:35:28 I now tried with --attach Nov 13 16:35:42 let's see if that can help me when it hangs next time Nov 13 17:02:51 and then the power went byebye Nov 13 17:05:31 and I'm missing nut-upscmd so no querying the battery status Nov 13 17:47:28 going to be a while before it's fixed too Nov 13 17:47:37 time for social life then 😂 Nov 13 17:52:04 what's happenin' Nov 13 17:52:10 and who broke what Nov 13 18:20:15 can someone help me please understand how variables in /etc/wireless/config get to hostapd.sh Nov 13 18:23:50 I wish to add a new variable something like 'utf8ssid' that will end up in /var/run/hostapd-phy0.conf for the hostapd daemon. Nov 13 18:25:06 ldir: there should be a wrapper script somewhere parsing the configs in /etc/config/ Nov 13 18:28:31 but you probably surmised that already. Nov 13 18:28:46 no I'm totally confused Nov 13 18:30:00 wasn't 802.11r added recently? Nov 13 18:30:11 if you can find the commit for that it might enlighten you Nov 13 18:30:30 goodevening Nov 13 18:31:32 hello Nov 13 18:31:38 i have a question regarding a part of the wiki i would like to alter.. Nov 13 18:32:18 ThijsNL: just ask your question, don't ask whether you can ask it Nov 13 18:32:58 https://openwrt.org/toh/cisco/epc3925 the part of 'debricking'.. i have succesfully captured the required files like the bootloader, and image1 e.g. but i doubt it would be legal to put them on the wiki Nov 13 18:33:22 as it is proprietary afaik Nov 13 18:33:25 i don't think it would be smart either Nov 13 18:33:53 if the wiki doesn't explain yet how to explain those you could add explanations for that though, that should be less iffy at least Nov 13 18:35:03 so e.g. a statement... if bricked, you need to flash back a bootloader that you backuped yourself? Nov 13 18:35:08 ldir: i'll fire up my desktop and grep through the logs, going to tinker anyway Nov 13 18:35:35 ThijsNL: exactly. stronger even: link/explain first how to back up the bootloader, only proceed if you have a backup Nov 13 18:35:45 stronger = more strongly worded Nov 13 18:36:23 thanks Nov 13 18:36:28 graag gedaan :) Nov 13 18:37:10 . Nov 13 19:11:42 ldir: just `git grep` the answer, `git grep hostapd.sh` etc. Nov 13 19:52:39 ldir: https://paste.debian.net/hidden/51c1dd52/ Nov 13 19:52:48 that should get you started i reckon :D Nov 13 20:20:06 ldir: its complicated Nov 13 20:20:29 ldir: upon start, netifd scans all wireless handlers in /lib/netifd/wireless/ Nov 13 20:21:08 ldir: so for mac80211 that'd be /lib/netifd/wireless/mac80211.sh Nov 13 20:22:34 ldir: the handler tells netifd about which options it recognized, for mac80211.sh this can be seen in drv_mac80211_init_device_config() (for config wifi-device) and drv_mac80211_init_iface_config() (for config wifi-iface) Nov 13 20:24:00 anyone good in decompressing a (partly)compressed bootloader? Nov 13 20:24:17 * Borromini somehow knew jow would come to the rescue Nov 13 20:27:26 ldir: netifd reads /etc/config/wireless, converts it into json and eventually passes it via various indirections back to the script Nov 13 20:28:07 ldir: it will execute something like /lib/netifd/wireless/mac80211.sh mac80211 setup radio0 '{ lots of json encoded uci options }' Nov 13 20:29:20 ldir: this invocation is catched by `init_wireless_driver "$@"` in /lib/netifd/wireless/mac80211.sh (declared in the shared /lib/netifd/netifd-wireless.sh) Nov 13 20:31:03 jow: thank you - I shall try to digest this. Nov 13 20:31:38 ldir: init_wireless_driver() will parse the passed json into shell variables and dispatch back to one of the drv_*() functions in /lib/netifd/wireless/mac80211.sh Nov 13 20:32:02 e.g. /lib/netifd/wireless/mac80211.sh mac80211 setup radio0 '{ lots of json encoded uci options }' will eventually call drv_mac80211_setup() Nov 13 20:32:48 drv_mac80211_setup() will have access to all the uci config variables via the loaded jshn environment so you can accesss them using json_get_vars, json_select etc. Nov 13 20:33:15 the radio we're operating on is passed as "$1" and will contain the uci wifi-device section name, e.g. "radio0" Nov 13 20:35:11 from then on its "just" shell magic translating things back and forth, writing temporary hostapd config etc. and eventually instructing netifd to launch a hostapd process using wireless_add_process() Nov 13 20:35:50 executive summary Nov 13 20:36:03 that's hell on a stick :-) Nov 13 20:36:26 btw the executive summary was 'it's complicated' ;-) Nov 13 20:36:33 - register new config options in /lib/netifd/wireless/mac80211.sh using either drv_mac80211_init_device_config or drv_mac80211_init_iface_config - for utf8ssid you likely want drv_mac80211_init_iface_config Nov 13 20:36:50 jow: so libpfring has a problem where the Makefile calls lex, which the buildbots do not have. Is the proper solution to patch the package or add a symblink to flex? Nov 13 20:38:33 correction; register it in hostapd_common_add_bss_config() of /lib/netifd/hostapd.sh Nov 13 20:38:47 arch linux symlinks flex to lex for example Nov 13 20:39:07 - and process it in hostapd_set_bss_options() Nov 13 20:39:12 thats it Nov 13 20:39:20 jow: in theory I've done that - I noticed mac80211.sh has a 'common' set options Nov 13 20:39:36 you most likely need to restart netifd for it to become aware of the new option Nov 13 20:39:50 du to the uci->blob->json->string->jshn call chain Nov 13 20:40:30 ha! I bet that's the thing I'm missing. Nov 13 20:41:05 mangix: either would work for me Nov 13 20:41:53 mangix: we could extend tools/flex/Makefile to stage a lex->flex symlink as well Nov 13 20:42:26 mangix: the simpler way is to just patch the makefile to use $(STAGING_DIR)/host/bin/flex Nov 13 20:43:16 I'll patch the package for now. Nov 13 20:43:27 it seems upstream was lazy Nov 13 20:45:35 using LEX = lex instead of LEX = @LEX@ Nov 13 20:45:47 like done elsewhere Nov 13 20:46:46 jow: does this look ok? https://gist.github.com/neheb/523652648e9480ee0fef44499f4e7df2 Nov 13 20:48:45 mangix: almost, make the syslink relative Nov 13 20:48:51 *symlinl Nov 13 20:48:55 **symlink Nov 13 20:49:10 $(LN) flex $(STAGING_DIR_HOST)/bin/lex Nov 13 20:49:21 no wait, thats backwards Nov 13 20:49:28 nvm, no its right Nov 13 20:49:53 ldir: I wonder if utf8ssid shouldn't be an implicit default Nov 13 20:49:58 arch PKGBUILD has it as ln -s flex "${pkgdir}/usr/bin/lex" Nov 13 20:50:06 ldir: at least I consider /etc/config/* to be utf8 encoded by convention Nov 13 20:50:29 luci will certainly write utf-8 into it Nov 13 20:51:31 jow: should I add PKG_RELEASE? That's currently missing Nov 13 20:51:49 where, in tools/flex/ ? Nov 13 20:51:53 yeah Nov 13 20:52:04 that's true - hmm - okay I'll default to enabled with the option to disable Nov 13 20:52:05 no Nov 13 20:52:28 I don't think it makes sense for tools/* as we do not generate ipk artifacts from that Nov 13 20:52:36 and we do not revision other parts of the buildroot either Nov 13 20:52:43 ok Nov 13 20:53:12 actually hmmmm... I don't think this is right Nov 13 20:54:52 what exactly? Nov 13 20:54:55 actually nvm, I'm confusing myselfg Nov 13 20:55:03 so the package calls lex Nov 13 20:55:17 $(LN) flex $(STAGING_DIR_HOST)/bin/lex should be fine Nov 13 20:55:20 but BUILD_DIR should export the tools Nov 13 20:55:31 "place a symlink pointing to "flex" into $(STAGING_DIR_HOST)/bin/lex" Nov 13 20:55:39 even if missing on the host Nov 13 20:56:23 so calling $(STAGING_DIR_HOST)/bin/lex will call $(STAGING_DIR_HOST)/bin/flex Nov 13 20:56:37 and $(STAGING_DIR_HOST)/bin precedes the standard $PATH Nov 13 20:57:00 ok yeah that makes sense Nov 13 21:04:52 bbl Nov 13 21:06:33 nevermind, got it uncompressed Nov 13 21:08:22 nbd: kernel panic on mt7628: https://pastebin.com/eLTwgLJF Nov 13 21:12:15 Hi I am trying to remove odhcp from my build for my c7-v2 but it will not un select. Any know what's rong? Nov 13 21:12:26 Any one** Nov 13 21:13:09 I am using make menuconfig and am building with luci in my build Nov 13 21:13:36 Can I edit the config file by hand in a txt editer? Nov 13 21:14:20 I cant remove firewall ether. Nov 13 21:15:02 Tapper: i think ipv6 support requires it Nov 13 21:15:18 just hit question mark on your keyboard when your cursor is on the entry Nov 13 21:15:28 and it will show you dependencies and what depends on it Nov 13 21:15:33 So under packages remove IPv6? Nov 13 21:15:58 that'll break v6 :/ Nov 13 21:16:16 It says allow packages to be built with IPv6 functionality Nov 13 21:16:41 I will have a look now Nov 13 21:17:56 I dont need IPv6 for a dumb AP do I. My wan is IPv4 only. Nov 13 21:22:30 if IPv4 is enough you can do without, but you should double check if it's IPv6 keeping it in Nov 13 21:22:42 it's a hunch, but i'm not 100% sure nor can i check myself atm Nov 13 21:52:53 just got u-boot working on the epc3925 Nov 13 22:03:33 nbd: my kernel panic is from r8448-81d7f82441 (pinging in station mode) Nov 13 22:03:35 wtf my ipsec config disappeared Nov 13 22:05:13 and my keepalived config Nov 13 22:05:13 wtf Nov 13 22:06:06 power outage wreaked some havoc Nov 13 22:08:05 and the power outage took down the log server, so no idea what caused those few files to be lost Nov 13 22:08:32 Thievin' gremlins Nov 13 22:13:21 nbd: WDS test still dies after a couple of recoveries. Nov 13 22:14:46 must have been the init script that overwrote my ipsec config Nov 13 22:15:04 /etc/ipsec.secrets: include /var/ipsec/ipsec.secrets Nov 13 22:15:14 /etc/ipsec.conf: include /var/ipsec/ipsec.conf Nov 13 22:15:20 grrr Nov 13 22:16:33 and /etc/strongswan.conf: include /var/ipsec/strongswan.conf Nov 13 22:18:05 and the init script hasn't been touch for almost a year Nov 13 22:21:56 file_reset() must have caused this **** ENDING LOGGING AT Wed Nov 14 03:00:00 2018