**** BEGIN LOGGING AT Thu Oct 11 02:59:59 2018 Oct 11 03:06:04 build #144 of x86/geode is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/x86%2Fgeode/builds/144 Oct 11 03:16:11 build #144 of kirkwood/generic is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/kirkwood%2Fgeneric/builds/144 Oct 11 03:23:53 build #144 of ramips/rt288x is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/ramips%2Frt288x/builds/144 Oct 11 03:32:38 build #137 of brcm47xx/generic is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/brcm47xx%2Fgeneric/builds/137 Oct 11 03:42:35 build #144 of octeontx/generic is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/octeontx%2Fgeneric/builds/144 Oct 11 03:58:17 build #141 of sunxi/cortexa53 is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/sunxi%2Fcortexa53/builds/141 Oct 11 04:09:31 build #90 of oxnas/ox820 is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/oxnas%2Fox820/builds/90 Oct 11 04:33:15 build #139 of x86/64 is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/x86%2F64/builds/139 Oct 11 04:42:34 Hello all .. Do anyone here has tried Arpwatch utility in OpenWRT ?? I am using it and recently I found a critical issue with it .. I need to know if anyone uses it here Oct 11 04:49:49 build #136 of brcm47xx/mips74k is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/brcm47xx%2Fmips74k/builds/136 Oct 11 05:11:49 build #134 of pistachio/generic is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/pistachio%2Fgeneric/builds/134 Oct 11 05:11:49 build #141 of ath25/generic is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/ath25%2Fgeneric/builds/141 Oct 11 05:31:22 build #87 of mediatek/mt7623 is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/mediatek%2Fmt7623/builds/87 Oct 11 05:47:04 hi Oct 11 05:50:17 build #132 of apm821xx/sata is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/apm821xx%2Fsata/builds/132 Oct 11 05:54:58 'lo Oct 11 06:08:30 mangix: https://patchwork.ozlabs.org/patch/971873/ and https://patchwork.ozlabs.org/patch/971879/ dont apply, please resend Oct 11 06:19:49 dedeckeh: a while back we added a default dhcp script for dnsmasq to invoke /etc/hotplug.d/{dhcp,neigh,tftp} on lease/expire/update etc. events Oct 11 06:20:13 dedeckeh: is odhcpd (specifically the ipv6 part) invoking the same hotplug events? If not what would it take to do so? Oct 11 06:21:40 jow:odhcpd is not invoking the same hotplug events Oct 11 06:22:37 jow:currently it has not event mechanism to trigger a script when a lease expires/updates Oct 11 06:22:58 *no Oct 11 06:23:41 jow:it's on my TODO list but lately I've been lacking time to work on it Oct 11 06:24:13 thats fine, maybe I can take a stab at it Oct 11 06:24:56 ermmm Oct 11 06:25:04 git cloning fails in the latest checkout ?! Oct 11 06:25:17 echo "Checking out files from the git repository..."; mkdir -p /src/merge.git/tmp/dl && cd /src/merge.git/tmp/dl && rm -rf procd-2018-10-11-94944ab0 && [ \! -d procd-2018-10-11-94944ab0 ] && git clone /project/procd.git procd-2018-10-11-94944ab0 && (cd procd-2018-10-11-94944ab0 Oct 11 06:25:27 PROJECT_GIT evals to "" Oct 11 06:25:30 !?!? Oct 11 06:27:25 blogic: cannot confirm that Oct 11 06:27:34 locally modified include/download.mk ? Oct 11 06:27:48 old branch? project_git was added after lede-17.01 iirc Oct 11 06:27:53 nope Oct 11 06:27:55 this is HEAD Oct 11 06:28:00 inside my merge tree Oct 11 06:28:10 i never make any cutom stuff here, this is pure vanilla Oct 11 06:28:14 jow:fine Oct 11 06:28:19 even closed the terminal and opened a new one Oct 11 06:28:24 -PKG_SOURCE_URL=$(PROJECT_GIT)/project/procd.git Oct 11 06:28:25 +PKG_SOURCE_URL:=$(PROJECT_GIT)/project/procd.git Oct 11 06:28:29 = vs. := Oct 11 06:28:48 is the only relevant change I see Oct 11 06:28:59 "procd: Install hotplug files as 600" Oct 11 06:29:08 has to be Oct 11 06:29:28 which interestingly is also the latest commit :) Oct 11 06:29:36 mangix: i fogot how much i hate your patches Oct 11 06:30:42 only procd and usbmode use PROJECT_GIT with := Oct 11 06:30:51 I suppose that'll make usbmode broken the same way Oct 11 06:31:01 what did you do to trigger it? Just "make" ? Oct 11 06:31:13 yes Oct 11 06:31:17 git version bump Oct 11 06:31:31 make it clone a new tree and then gen the new mirror hash Oct 11 06:32:55 yeah, I missed the error but in the command sequence I see [...] && git clone /project/procd.git procd-2018-08-06-e29966f0 Oct 11 06:33:26 i'll revert all of rosens patches, problem solved, note made not to touch them again Oct 11 06:33:29 let me quickly confirm usbmode Oct 11 06:33:53 that's a little bit harsh Oct 11 06:34:11 but I agree that a "procd: Install hotplug files as 600" should not touch unrelated makefile variables Oct 11 06:34:46 and the firewall patch Oct 11 06:35:03 but than I personally fucked up every single one of my last luci commits so I will not impose double standards :P Oct 11 06:35:13 neither will i Oct 11 06:35:22 just saying that the patches are a tarpit Oct 11 06:35:52 indeed, the firewall change is broken too Oct 11 06:36:06 so i'll revert the firewall and procd patch and leave the other 4 in the tree Oct 11 06:36:15 he needs to resend 2/8 and 8/8 anyhow Oct 11 06:37:42 $ grep -lr 'PKG_SOURCE_URL:=$(PROJECT_GIT' package/ | xargs -L 1 git log --format="%aN" -1 -- Oct 11 06:39:06 i've just fixed them all and will push a patch Oct 11 06:39:08 gimem a sec Oct 11 06:45:34 mangix: pong Oct 11 06:47:14 jow: do you know your war around ncurses ? Oct 11 06:47:20 https://patchwork.ozlabs.org/patch/975078/ Oct 11 06:47:34 isn't the w variant the wide version Oct 11 06:51:36 blogic: well this patch essentially attempts to shadow the host ncursesw6-config Oct 11 06:51:48 should be okay, I think or curses is only wide nowadays Oct 11 06:52:19 of course it would be simpler to fix gpsd, but I guess scons is an even larger lost cause than autofailbreak Oct 11 06:52:44 patch is extremely ugly though Oct 11 06:52:58 and I just noticed, not really applicable Oct 11 06:53:21 if at all he should install relative symlinks, otherwise it breaks relocatability (I think the SDK would still fail) Oct 11 06:54:53 true Oct 11 06:55:57 really, gpsd should be fixed Oct 11 06:56:07 this is just papering over a hole in the wall Oct 11 07:43:17 can openwrt disable the wifi by itself? Oct 11 07:43:34 Rene__: some units have a rfkill switch Oct 11 07:48:07 i am currently on vacation. using a tp841 as wifi router, so device is ap and client Oct 11 07:49:19 when i am using a chromecast it sometimes breaks the wifi. not a big deal just restart tge device. Oct 11 07:50:14 Hauke: the more & more I look at https://github.com/openwrt/openwrt/pull/1386 i don't like it Oct 11 07:50:25 but yesterday the wifi did not came up. when i looked in the wireless config the option disabled 1 was present Oct 11 07:50:29 Hauke: it's the "Initial kernel 4.19 support" one Oct 11 07:52:39 blogic, hmm i did touch the buttons on the back before it restarted the device Oct 11 07:53:20 that could be the source thanks Oct 11 08:23:03 blogic: mind if I take care of https://github.com/openwrt/openwrt/pull/866 ? Oct 11 08:34:08 xback_: go for it Oct 11 10:54:12 ldir: ping Oct 11 11:16:11 Does anyone know which driver powers qca9558? Oct 11 11:17:05 rgrep -i in the kernel source tree? Oct 11 12:11:36 jow: pong Oct 11 12:18:10 ldir: about that bthh5 Oct 11 12:18:32 I wonder if you could perform a little test for me eventually Oct 11 12:20:31 of course Oct 11 12:30:11 can you give me a hint what I might be looking for.... eventually :-) Oct 11 12:32:48 The grail Oct 11 12:33:10 again? Oct 11 12:33:33 It gets lost a lot Oct 11 12:36:35 ldir: basically flash a standard 18.06.1, try to change the lan ip in luci, and tell me what happened Oct 11 12:36:51 further questions might or might not arise from there Oct 11 12:38:22 * karlp is curiosu from that description why it would be bthh5 specific... :) Oct 11 12:39:08 its one of the devices where the luci rollback reportedly "does not work" and "is broken" Oct 11 12:39:19 I heard similar reports about ath79 (in contrast to ar71xx) Oct 11 12:39:31 I want to figure out if network reload vs. network restart is broken Oct 11 12:39:47 I'm sure I had rollback work on one of mine at some point Oct 11 12:40:28 unfortunately I was unsuccessfull in extracting detailled info from the reporting users Oct 11 12:40:31 jow: I think users "do not work" and "are broken" ;P Oct 11 12:40:31 most simply want to rant Oct 11 12:40:36 I'll unleash it from its box and give it a go... hopefully this afternoon. Oct 11 12:41:17 I may see if the Crashhub 5A still works Oct 11 12:41:37 crashhub ? you have a special version? Oct 11 12:41:44 Very special Oct 11 12:41:46 Special needs. Oct 11 12:42:44 * ldir has special knees Oct 11 12:43:01 Using the 5Ghz radio eventually causes it to freeze, it took a while to figure that out Oct 11 12:43:08 So now it's a testbed with a single radio :P Oct 11 12:43:37 And some bits torn off the board.. Oct 11 13:17:50 jow: ping Oct 11 13:19:24 so, am I changing the lan ip within the same subnet, and/or am I changing it to a different subnet as well? Oct 11 13:22:08 ldir: try both Oct 11 13:22:25 i.e. once 192.168.1.1 -> 192.168.1.2 and once 192.168.2.1 Oct 11 13:23:49 ok, so doing 192.168.1.1 > 1.2. I get the 'config has been rolled back' message Oct 11 13:25:25 which makes sense to me as the web page doesn't know the router has moved to 192.168.1.2 Oct 11 13:25:55 so the issue is more complex Oct 11 13:26:13 I guess the users reporting issues do more things than they claim to Oct 11 13:26:29 maybe they tro to connect to the new IP during those 30s Oct 11 13:26:43 during the 30 second wait for the box to appear, the device responds to the new IP address. Oct 11 13:27:23 I usually get reports about both IPs being unreachalbe until a reboot Oct 11 13:27:56 hwoever recently another user had a corner case I did not anticipate; his lan and wan ip ranges were identical Oct 11 13:28:07 That's special. Oct 11 13:28:07 acess from lan still worked (likely due to arp) Oct 11 13:28:46 however due to the network reload/rollback etc. the arp got flushed and the ip conflict became apparent, at this point no access to lan and wan was possible after rollback Oct 11 13:29:04 can't think of a solution to this apart from giving wan dhcp a higher metric by default Oct 11 13:30:26 so if I do apply the changes... then I get a box 'device unreachable!' - well 'err yeah.. 'cos you're trying to talk to it on the old IP. Oct 11 13:31:08 and at that point the web page is basically dead. But it does say "You might need to reconnect if you modified network related settings such as the IP address or wireless security credentials." Oct 11 13:31:25 so no rollback? Oct 11 13:31:35 ah if you apply anyway Oct 11 13:31:44 I applied anyway. Oct 11 13:31:49 and afterwards you can connect to the new ip? Oct 11 13:31:57 and the ui works, ssh too? Oct 11 13:32:08 which is basically what you *should* do. Oct 11 13:32:12 web ui works..... Oct 11 13:32:33 and ssh Oct 11 13:33:10 I'd *expect* changing the lan ip to be a bit 'bumpy'...... that's sort of the point really. Oct 11 13:33:44 well I *guess* that most people simply exepct the gui to become unreachable and attempt to conenct to the new ip Oct 11 13:34:04 so they'll navigate to the new ip without waiting for the rollback Oct 11 13:34:22 then the new one will work for a few sec and then suddenly become unreachable Oct 11 13:34:31 which is likely what happens... hmm Oct 11 13:35:38 so why is it rolling back? Oct 11 13:36:30 because the browser was not able to request a confirmation url within 30s which would abort the scheduled rollback timeout in rpcd Oct 11 13:36:32 because the web page doesn't know to redirect to the new address Oct 11 13:37:11 which is the entire point more or less. The idea is that e.g. faulty switch changes or broken firewall rules do not lock you out upon apply Oct 11 13:37:25 at least not permanently Oct 11 13:38:38 it saved me the other day.... I screwed up my switch vlan config.... and it all rolled back 'cos I didn't make contact in time :-) Oct 11 13:39:35 ip changes are hard to solve Oct 11 13:40:01 access by hostname (via mdns etc.) could help, but I guess clients will be too slow to update their caches or renew dhcp Oct 11 13:46:21 jow: any other thing you wish me to try before I put it back in its box?! Oct 11 13:47:36 ldir: no, for now this is enough. Thanks for smoke testing it! Oct 11 13:48:16 * ldir tries to put the smoke back its box. Oct 11 13:48:24 in its Oct 11 13:51:34 ldir: You may have to get some replacement smoke from Lucas Oct 11 13:54:19 jow: horrible idea alert - how about making router IP address changes a) not go through the rollback scenario b) standalone ie. you cannot have any other change ? Oct 11 13:55:12 hm, a) might actually not be a bad idea after all Oct 11 13:55:34 assuming that the change is safe in a sense that any connectivity is preserved Oct 11 13:55:53 however there's another secario I learned about today... changing the PSK via wifi Oct 11 13:56:05 allegedly the 30s are not enough to reconfigure it on the client Oct 11 13:57:23 I can't help but feel that some of this is simply people shooting their own feet. Oct 11 13:57:34 I can believe it, especially if you're doing it with a suboptimal device Oct 11 13:57:44 yeah, I'd need more than 30s to get that done reliably. Oct 11 13:57:49 Like some sort of touchy screeny toy instead of an actual computer Oct 11 13:58:38 120s seems reasonable Oct 11 13:58:40 :D Oct 11 13:58:42 maybe the netire process should be changed into an apply-but-do-not-commit one Oct 11 13:58:47 ok so there's two things that shouldn't go through the rollback routine Oct 11 13:59:03 next ui interaction after a 10s cooloff period will trigger the commit Oct 11 13:59:11 jow: Apply, verify, commit and it's on you if you goofed Oct 11 13:59:25 if connectivity is lost, one can yank the power to get back Oct 11 13:59:31 does not help in remote scenarios though Oct 11 13:59:44 Remote reconfig is always a loaded gun Oct 11 14:00:00 even if it's just upstairs ;-) Oct 11 14:00:28 Even if it's sat right there on the desk but you just removed the serial header and reassembled the bastard. Oct 11 14:00:48 "oh f* hell, I've got to go in the cupboard of doom again!" Oct 11 14:00:53 There's a reason my RE350 hasn't got back together yet Oct 11 14:01:12 one could still install a long running reboot timer (10minutes or so?) which will get cancelled if a the verify-commit works Oct 11 14:01:37 would help in remote cases and should be plenty of time to reconnect to a reconfigured router Oct 11 14:01:48 impatient local users can simply yank power Oct 11 14:03:22 I don't like this yank power thing - fsck. Oct 11 14:03:33 so to summarize: apply changes and schedule reboot now+10m, upon next ui contact commit changes and cancel reboot timer Oct 11 14:03:44 Man up and give it a good yank Oct 11 14:03:44 if no ui contact anymore, reboot after 10m Oct 11 14:03:47 The higher the voltage the better Oct 11 14:04:00 I do like the 'rollback' thing. But there are a couple of scnerios where that method shouldn't be used. Oct 11 14:04:41 the orther, way simpler solution I had in mind was to simply offer a "apply don't care" button, maybe as dropdown choice to the normal one Oct 11 14:05:28 Which 90% of people will use and then whine. :P Oct 11 14:05:37 yes, thats my expectation too Oct 11 14:06:07 Make something idiot proof and they'll only build a better idiot. Oct 11 14:20:03 default to a force apply on ip & psk changes. Oct 11 16:51:40 blogic: I assumed it = vs. := was an oversight. duly noted. Oct 11 16:56:19 stintel: CVE-2018-18065 for net-snmp was made public recently. can you handle it? Oct 11 16:58:18 requires authenticated user, and only for agents using table_helper. Oct 11 16:58:33 I mean, sure, but that's hardly stop the presses. Oct 11 17:00:26 mangix: either make a PR, or file an issue to remind me. I really don't have time for it this week :( Oct 11 17:02:10 ok Oct 11 18:41:16 rmilecki: I haven Oct 11 18:41:41 rmilecki: I haven't found the time to look closely into the kernel 4.19 pull request Oct 11 18:43:48 rmilecki: I would like to get rid of many of the pending and hack patches wrere I do not know why we need them Oct 11 18:44:07 to get kernel 4.19 closer to mainline Oct 11 20:40:41 trying to build a ap83 image from chaos_calmer but it says Checking 'git'... failed. when i know its installed Oct 11 20:40:58 this is when running ./scripts/feeds install -a Oct 11 20:41:42 Build dependency: Please install Git (git-core) >= 1.6.5 Oct 11 20:41:42 ~/chaos_calmer$ git --version Oct 11 20:41:42 git version 2.17.1 Oct 11 20:43:42 Slimey: you can expect such issues to happen with a long abandoned code base. that particular issue can be ignored though, in the past the packages containing git were called git-core in Debian (because another "git", as in "GNU interactive Tools", was already packaged under that name), CC doesn't know about that and complains if git-core is absent Oct 11 20:44:27 how to get around make nenuconfig complains about the same git error Oct 11 20:44:56 let it complain? if it actually breaks the build, git grep for git-core and remove the check Oct 11 20:45:11 k Oct 11 20:47:20 you are quite likely to fall into other issues that aren't as easy to get rid of Oct 11 20:49:07 your chances would probably be better if you'd compile under an equally old build OS (e.g. Debian 7 "wheezy" or some 2013-2014 era Ubuntu) Oct 11 21:57:09 Hello, anyone know how to get the port mask of a switch? Oct 11 21:57:16 ucidef_set_led_switch "lan_link" "lan_link" "$boardname:green:lan_link" "switch0" "0x1e" Oct 11 21:57:23 I'm trying values from other routers, but I would like to know how to get the "0x1e" of my router Oct 11 21:57:31 (I'm trying to support Strong 1200) Oct 11 22:00:14 vk496_2: trial and error? or maybe a datasheet. Oct 11 22:10:36 pkgadd you think ubuntu-14.04.5-desktop-i386 would be old enough? Oct 11 22:11:36 yeah, that should be fine. Oct 11 22:11:39 Slimey: probably, I'm not following Ubuntu (but Debian wheezy should be) Oct 11 22:11:50 I used a ubuntu vm last time I needed an old cc build iirc. Oct 11 22:12:22 cool cause i have that iso on hand from something unrelated Oct 11 22:53:33 success under ubuntu 14 Oct 11 22:53:52 rusell--: Trying it, with no luck :/ **** ENDING LOGGING AT Fri Oct 12 03:00:00 2018