**** BEGIN LOGGING AT Thu Jul 12 03:00:01 2018 Jul 12 03:21:15 Thu Jul 12 03:20:01 2018 daemon.info hostapd: wlan0: STA 0c:60:76:0a:4b:ed IEEE 802.11: disconnected due to excessive missing ACKs Jul 12 03:22:11 i see a lot if this when send huge amounts fron lan to wan Jul 12 03:22:50 MediaTek MT7628AN Jul 12 06:31:43 * blogic looks around Jul 12 06:31:48 did i miss anything ? Jul 12 06:32:06 your keys! Jul 12 07:00:07 mangix: marked the mtk ethernet patches as rejected Jul 12 07:00:25 we'll wait till the upstream driver is clean and it'll treacle downstream with the next kerne update Jul 12 07:44:49 blogic: do you have any ideas about the memory leak i'm seeing on mt7621 with wifi (but no client devices or at least no client traffic)? Jul 12 07:45:17 russell--: using mt76 Jul 12 07:45:22 yeah Jul 12 07:45:46 and disabling mt76 you dont see the leak Jul 12 07:45:47 ? Jul 12 07:45:59 if that is the case you need to hunt nbd Jul 12 07:46:15 right. or if there are active clients or, bizarrely, if openvpn is running. Jul 12 07:46:38 ok, that would mean its not wifi related Jul 12 07:49:04 my vague theory is that something is piling up relating to wifi, but if something comes along and tickles the right kernel interface, the memory gets reclaimed, but that's based on not-very-much Jul 12 07:50:01 i'm not sure how to instrument the kernel in a way to trace what's really happening Jul 12 08:00:23 Has anyone ported QCA-SSDK for OpenWRT? Jul 12 08:00:37 Specifically for IPQ4019 based platforms? Jul 12 08:01:27 ToT OpenWRT shows very less throughput between LAN to WLAN. I am able to see only 600Mbps Jul 12 08:01:42 just a simple L3 mode and no NAT and such. Jul 12 08:03:50 by WLAN you mean wireless? Jul 12 08:04:13 oops.. It is WAN to LAN. Jul 12 08:04:17 no wlan. Jul 12 08:04:24 thanks Jul 12 08:05:13 This seems like the behaviour even on 4.9 openwrt kernel also Jul 12 08:08:41 bhr-4grv2-kernel.bin is too big Jul 12 08:10:23 wrong window, sorry Jul 12 09:39:49 dedeckeh: ping Jul 12 09:41:24 nbd: ping Jul 12 09:42:21 Any NO alternative to: yes "" | make kernel_oldconfig CONFIG_TARGET=subtarget ? :] Jul 12 09:44:29 yes "n" | ... Jul 12 09:44:43 will respond with "n" to any query Jul 12 09:44:55 or "n\n" rather Jul 12 09:45:01 oh, superb Jul 12 09:51:00 Networking CAKE Is Ready For Tasting With Linux 4.19 https://www.phoronix.com/scan.php?page=news_item&px=CAKE-Qdisc-Linux-4.19 Jul 12 09:52:10 Tapper: neat! Jul 12 09:52:17 russell--: pong Jul 12 09:52:58 It's bin a long road for cake! Jul 12 09:55:35 russell--: does running 'wifi' after the memory has accumulated free it up? Jul 12 09:55:53 wifi alone? Jul 12 09:56:00 jow:pong Jul 12 09:56:19 if traffic is sent over the wireless link, it gradually recovers Jul 12 09:56:56 i mean just restarting wifi Jul 12 09:57:01 without any extra traffic Jul 12 09:57:18 ah, i'll try that Jul 12 09:58:00 i will try to reproduce it, but it's not the first time i hear of this issue Jul 12 09:58:19 i'll let you know in 20 minutes Jul 12 09:59:13 will "wifi restart" do what you want? Jul 12 10:08:18 <_lore_> ping nbd Jul 12 10:11:04 russell--: yeah, or just 'wifi' Jul 12 10:11:36 _lore_: pong Jul 12 10:12:48 <_lore_> hi, mtk agreed to push mt7662u fw to linux-firmware with mtk license Jul 12 10:13:59 <_lore_> since you already did it, what is the process to do it? just send a patch to linux-firmware? Jul 12 10:22:09 dedeckeh: hi. I've question regarding dynamic interfaces Jul 12 10:22:48 dedeckeh: I'm extending luci's network interface overview to display dynamic interfaces as well Jul 12 10:23:08 dedeckeh: and I've been wondering if it makes sense to expose things like ifup/ifdown for them as well Jul 12 10:23:50 if one ifdown's a dynamic interface, it vanishes and I am unsure how the various protocols would react to it Jul 12 10:24:32 e.g. will pppoe readd a dynamic wan_6 interface upon next reconnect? Jul 12 10:28:01 any hopes for MT7628NN wifi? latest trunk - stalled connections, can't even transfer few gigs Jul 12 10:29:13 jow:yes it will recreate the dynamic wan_6 interface on the next reconnect Jul 12 10:30:24 nbd: answer is no, the memory does not free up on a wifi restart Jul 12 10:30:58 wifi down stops the leakage (over a few minutes it is basically stable) Jul 12 10:31:14 jow:but I'm unsure if ifup/ifdown needs to be exposed to the user for dynamic interfaces Jul 12 10:31:22 wifi up restarts the leakage from where it stopped Jul 12 10:31:54 iirc, leaving wifi down for an extended period, and it will eventually recover Jul 12 10:32:16 jow:in the case of a dynamic created 6rd interface ifdown will delete it; but upon the next DHCP renew the dynamic 6rd interface will be created again Jul 12 10:32:37 _lore_: yes, send it to linux-firmware Jul 12 10:32:57 <_lore_> ok, what about license? Jul 12 10:33:07 russell--: is it specific to 2.4 ghz or 5 ghz, or does it affect both equally? Jul 12 10:34:10 nbd: seems to affect both equally, the module mt76x2e seems to support both radios on this device (dir860l-b1) Jul 12 10:34:21 ah Jul 12 10:34:53 if i down one of the radios, the rate of leakage seems to drop in half from about 800k per minute to about 400k per minute Jul 12 10:35:57 do you have any device with mt7603 as well? Jul 12 10:37:18 no Jul 12 10:38:26 oh, wait, does mt7603e count? Jul 12 10:39:11 yes Jul 12 10:39:53 and also maybe an ath9k device Jul 12 10:39:57 i have a linkit 7688 Jul 12 10:40:15 i haven't seen it on ath9k Jul 12 10:40:50 although, i think all of ath9k devices are on 4.9 Jul 12 10:41:00 and this behavior appeared at the transition to 4.14 Jul 12 10:41:43 is your ath9k device supported by ath79 yet? Jul 12 10:42:14 i tried ath79 for one of them when it first appeared, but something was broken, i can try again Jul 12 10:42:41 i think wndr3800 was what i tried before Jul 12 10:47:27 the linkit 7688 doesn't seem to show any evidence of the leak (it's on a 4.14.41 image from back in may), has an ap-mode wifi interface. Jul 12 10:48:14 can you try a current image? Jul 12 10:49:02 yeah, i will, might take a bit the ath79 image is building now Jul 12 11:13:04 hmm, ath79 on wndr3800 doesn't find the radios Jul 12 11:16:53 russell--: yeah, pci radio is not supported yet on ath79 Jul 12 11:22:13 oh, i tried ath9k on an meraki mr24 (ppc apm821xx) on 4.14.x and didn't see the leak there Jul 12 11:32:23 okay, then please also double check the linkit with a current image Jul 12 11:32:33 to make sure the leak also isn't there Jul 12 11:32:39 i will look into mt76x2 soon Jul 12 11:34:36 nbd: yeah, just got linkit running Jul 12 11:39:45 still early, but it looks like it is leaking ... more slowly since it's a single radio device. will give it some more time. Jul 12 11:51:11 ha. New toys delivered. Let's see if I can make the hAP mini work without breaking a sweat Jul 12 12:04:15 someone with access to mt7621A and mt7530 datasheet? I want to know when external phy is connected to GSW switch or 2nd GMAC of the mt7621. Jul 12 12:05:19 older datasheet that I have arent clear about that. Jul 12 12:25:04 nbd: i'm going to say it's not leaking. free stalled out at around 86-87MB and mostly just bounced around there, which seems different than what i've seen on the dir860l. i'm going to sleep, i'll check again when i wake up. Jul 12 12:43:35 russell--: it seems that i can reproduce the issue Jul 12 12:43:39 will look into it some more Jul 12 12:43:45 awesome! Jul 12 13:37:30 we should eventually consolidate our protocol error codes: https://pastebin.com/qmaRBeze Jul 12 13:39:04 jow: take the apple approach and replace with 'something went wrong' or even a single '?" :-) Jul 12 13:39:41 we could use the microsoft approach and use these codes as seed for pseudo randm uuids Jul 12 13:39:48 looks more technical and complicated Jul 12 13:41:03 "Connection failed: 618d9d34-4f2b-4c45-8382-5654890261e0 - please ask your administrator or buy a newer device" Jul 12 13:41:21 0x8000CCCDEADBEEF Jul 12 13:41:32 yeah, and make sure the log file is in binary so you need to run another tool to translate in 'english' Jul 12 13:41:49 error: no error (success) Jul 12 13:42:01 ha! Looks like you've implemented already :-) Jul 12 13:43:09 I especially like DISCONNECT_FAILED Jul 12 13:43:24 this inspires a lot of confidence in qmi & friends Jul 12 13:46:24 anyhow, I think at least "BAD_DEVICE" and "UNSUPPORTED_MODEM" should be merged Jul 12 13:47:36 as well as INVALID_ADDRESS / MISSING_ADDRESS Jul 12 14:01:54 well that was easy Jul 12 14:02:01 hAP mini supported. incoming PR Jul 12 14:36:08 PR#1170 for your consideration :) Jul 12 14:40:51 dunno if that's expected but the output of the Overview in Luci is quite garbled with Safari 10.x Jul 12 15:08:15 its not, but then I don't have any OS X around either Jul 12 15:08:31 i can provide VNC remote :) Jul 12 15:08:39 have to run an errand, bbl Jul 12 15:10:25 (I would typically expect safari and chrome the behave the same since they share the same rendering engine - might be proven wrong tho) Jul 12 15:10:26 * f00b4r0 runs Jul 12 15:12:12 f00b4r0: are you still using the material theme? because that's none to have bustage in it. Jul 12 15:24:58 karlp: using whatever the default them is Jul 12 15:25:02 theme* **** BEGIN LOGGING AT Thu Jul 12 15:33:40 2018 Jul 12 15:33:57 i'll be looking at the hAP AC2 over the weekend i think Jul 12 15:34:13 have to say mikrotik did seriously improve their casing design :) Jul 12 15:50:17 fwiw this commit https://github.com/openwrt/openwrt/commit/81d446b045176e3e25bb0ef74e3d060b51a0a353 Jul 12 15:50:20 is rather wrong Jul 12 15:50:32 it's hard to understand how this got accepted Jul 12 15:51:27 its actually quite simple to understand Jul 12 15:51:38 people complain about prs and patches never getting merged or bikeshedded Jul 12 15:52:01 * f00b4r0 shrugs Jul 12 15:52:09 so blogic merges stuff that does not look seriously broken, compiles and passes a smoke test Jul 12 15:52:34 thats about all that can be expected for random board support commits Jul 12 15:52:50 care to elaborate whats rather wrong about it? Jul 12 15:53:20 it's using a different hardware initialization routine. I suspect the author booted whatever he cared to hack and "it worked for him" so that was it Jul 12 15:53:34 the code requests GPIOs for LEDs that don't match this hardware, god knows what this could break internally. Jul 12 15:53:51 that is impossible to tell from the referenced commit without any hardware access Jul 12 15:53:53 do you have this hardware? Jul 12 15:54:08 jow: in fact it's very possible to tell when you look at the mikrotik code Jul 12 15:54:16 which is exactly what I'm doing since I don't have the hardware Jul 12 15:54:33 the fact that the commit specifically mentions that it's using the routine for that other hardware is also quite telling. Jul 12 15:54:39 nobody reviews vendor sdk code for every single ar71xx board support commit Jul 12 15:55:01 and not just ar71xx Jul 12 15:55:09 "this change lacks LED support" should be a red flag. Jul 12 15:55:18 the author didn't bother checking GPIOs Jul 12 15:55:28 it's possible the reset button doesn't even work Jul 12 15:55:49 yeah, wahtever Jul 12 15:55:58 * jow is out Jul 12 15:56:03 * f00b4r0 shrugs Jul 12 15:57:20 if you really know it's wrong, you could fix it Jul 12 15:57:44 sure. So that *I* get bikeshedded to death and asked for extra testing? Thank you but no thank you :P Jul 12 15:58:39 been there before, not going back. Jul 12 15:59:48 better than just opening a ticket Jul 12 16:00:31 who said anything about opening a ticket ;P Jul 12 16:01:40 certain devices have had broken support for years, sometimes later fixed, sometimes not Jul 12 16:03:09 the patch acceptance system is not perfect, but it keeps improving Jul 12 16:08:06 so, you're going to complain it's brokne, but you're not at all interested in fixing it, just complaining? Jul 12 16:08:11 that will go down well :) Jul 12 16:08:38 i'm not complaining. I'm noticing. Jul 12 16:09:23 the noticing took a lot of work whether you acknowledge it or not. in for a penny, in for a pound. Jul 12 16:09:28 no Jul 12 16:09:30 it didn't Jul 12 16:09:37 i just edited that file, see pr#1170 Jul 12 16:09:48 i noticed the odd reuse of the machine init code Jul 12 16:09:56 git log was all it took to find the commit Jul 12 16:09:59 git blame in fact Jul 12 16:10:23 meanwhile, I'm out. Jul 12 16:44:14 hm Jul 12 16:45:49 looks like theres no generic macsec offload support :( Jul 12 16:45:51 sadface Jul 12 16:46:45 memleak on ramips fixed: https://git.openwrt.org/0c285bd081da55bd63da18f7596e7107a46bb798 Jul 12 16:47:01 theres a number of nics that do it now, shame Jul 12 16:47:46 nbd: backported to 18.06 too? Jul 12 16:48:16 mind you, ixgbe doesn't even have macsec support anyway Jul 12 16:48:18 intel, you suck Jul 12 16:53:56 DonkeyHotei: not yet. i'm going to run a few more tests Jul 12 16:53:58 such a waste of hardware, nics will do wirespeed packet filtering and macsec but neither supported Jul 12 17:02:09 Hello guys. I am trying to get valgrind working on a 32-bit glibc build of openwrt, but no luck. The 64-bit version works fine, after adding -DPURIFY to openssl Makefile, if your program uses it, also indirectly. But for 32-bit I hit an illegal instruction in a glibc function liek process_env_vars. Anything I might watch out for or something? Jul 12 17:03:19 on x86? Jul 12 17:03:28 sorry, yeah, x86 32-bit Jul 12 17:04:08 running on qemu; no stropping, debug symbols included in binaries Jul 12 17:04:53 *stripping* Jul 12 17:06:11 I had to select binutils 2.29.1, because the 2.30 version had some issues, ld segfaulted Jul 12 17:06:22 things like ld[21079]: segfault at 55c6552e49a0 ip 000055c643c4c5ea sp 00007ffe8858cc40 error 4 in ld[55c643bc3000+2f2000] Jul 12 17:07:29 if its an illegal instruction you may need to change the cpu type qemu is emulating (perhaps compiled expecting newer cpu, and thus instructions) Jul 12 17:08:53 jwh: thank you, I never tought about this. I pass to qemu "-cpu host" Jul 12 17:08:54 iirc you need to compile specifically for pentium4 to get 32bit qemu to work Jul 12 17:09:40 mhmmm... so I need to pass that to qemu, too Jul 12 17:09:48 yeah, or compile for an older cpu Jul 12 17:09:50 to gcc Jul 12 17:10:05 nobody should still be using 32bit anyway :D Jul 12 17:10:47 I am trying now with --march=native in gcc Jul 12 17:10:58 my host system is 64-bit BTW Jul 12 17:11:02 umm Jul 12 17:11:03 use --march=pentium4 Jul 12 17:11:05 why woul you use native? Jul 12 17:11:07 would* Jul 12 17:11:10 but ok, I have a new "variable" to experiment with Jul 12 17:11:12 that tries to match the cpu its built on Jul 12 17:11:21 which will not match whatever you're emulating Jul 12 17:12:12 I expected "-cpu host" to match it. Jul 12 17:12:44 it usually doesn't, even minor variations in instructions etc can break stuff Jul 12 17:16:24 ok, so I'll try things now... What do you recommend me, qemu at the moment offers me pentium, or pentium2, pentium3 Jul 12 17:16:26 no pentium4 Jul 12 17:16:31 may I choose a kvm32 ? Jul 12 17:16:59 I didn't expect this Jul 12 17:18:28 umm, you should have a *lot* of possible cpus Jul 12 17:18:43 so on 64-bit I did not hit this problem maybe bewcause there are less chances of having incompatible instructions? Jul 12 17:19:25 http://ix.io/1gZB Jul 12 17:19:39 jwh: yeah, infact. I was justl ooking at pentium* names. I do not know much about cpu variantsI would say Jul 12 17:19:45 they can all (with the obvious exception of kvm64) operate in 32bit mode afaik Jul 12 17:20:30 I saw the link, thanks; yeah, infact, I have a lot of cpus, too. Ok, I'll try some Jul 12 17:27:50 mmm, to add a new kernel branch, need to define it and then refresh patches against new version right? removing ones that are no longer relevant Jul 12 18:14:32 jwh: I think so, yes Jul 12 18:14:55 need me some 4.18 goodness when its out :D Jul 12 18:24:03 aw, no tc by default Jul 12 18:24:10 is it a standalone package? Jul 12 18:25:35 ah god it Jul 12 18:26:38 got8 Jul 12 18:26:40 llh Jul 12 18:26:41 ffs Jul 12 18:30:21 need me some more ebpf and xdp too Jul 12 18:31:41 jwh: if you want to be thorough also do a build with all kmods enabled and fixup any (re-)moved modules or new config symbols Jul 12 18:32:04 ah mmk Jul 12 18:33:14 I only use 2 kmods (external to the kernel), everything else is built in so will have to see how much work its going to be (not like its going to be upstreamed) Jul 12 18:37:21 jwh: just start with a fresh config and select ALL_KMODS, then try a build. done ;) Jul 12 18:38:30 I guess heh Jul 12 18:38:35 but if you don't plan to push/submit it, then you don't need to obviously Jul 12 18:39:12 well, I doubt anyone would be interested in supporting mainline/stable kernels in openwrt anyway Jul 12 18:39:16 its a lot of effort Jul 12 18:41:19 but nice new things like XDP and such Jul 12 18:41:38 ? mainline/stable kernels are what all targets use as a base Jul 12 18:41:50 4.9 and 4.14 are lts though Jul 12 18:42:08 which makes sense, given the support load Jul 12 18:42:28 whereas stable is currently 4.17 and mainline (will be) 4.18 Jul 12 18:43:23 right, but having non-lts kernels supported in trunk/master for a while isn't uncommon for openwrt, to keep newer kernel tested and the amount of work to switch to newer kernels reasonable Jul 12 18:43:42 ah, makes sense Jul 12 18:44:38 well, I can add 4.17 I guess, since its "stable" Jul 12 18:44:46 mainline is a pain in the ass to track Jul 12 18:46:26 CONFLICT (content): Merge conflict in package/network/config/netifd/Makefile Jul 12 18:46:29 sadface Jul 12 18:49:56 evidently I still don't understand rebase, as fixing conflicts and git add;git rebase --continue just says there are no changes Jul 12 19:41:05 thank you for all guys, and sorry if I lost messages. Exiting. Have a nice night. :) Jul 12 19:51:00 nbd: after another 7 hours, linkit seems to not be leaking Jul 12 20:07:35 mmm, how do they decide which branch is going to be the next long term stable kernel? Jul 12 20:07:42 seems adhoc Jul 12 20:08:49 the rough guideline would be the first released in the new year Jul 12 20:09:05 as fara as I can tell from reading lwn, it is rather adhoc, and largely around the needs of whoevers employer was reading for a new one. Jul 12 20:09:32 mmm Jul 12 20:09:51 probably due a bump to 5.0 soon anyway :D Jul 12 20:15:36 ok so uh, I added 4.17, forgot already how to generate a config-4.17 Jul 12 20:15:50 generic one, that is Jul 12 20:16:13 copy 4.16 and work off that? Jul 12 20:16:25 guess I could do that Jul 12 20:16:35 thought there was some magic to generate a default set of symbols Jul 12 20:16:36 :D Jul 12 20:19:14 heh theres a *lot* of patches Jul 12 20:21:58 lol Jul 12 20:22:04 first time bumping a kernel? :P Jul 12 20:22:23 yes :( Jul 12 20:22:45 patch can't figure out that the line it needs to patch is offset by 7 Jul 12 20:22:45 :( Jul 12 20:23:21 you might be taking on a bit too much no offense Jul 12 20:23:37 its a lot of effort heh Jul 12 20:24:08 might all be in vain anyway if the lts isn't for another few versions too Jul 12 20:24:21 do you need it? Jul 12 20:24:37 mmmm, kinda Jul 12 20:24:40 as in Jul 12 20:24:44 very much want, so kinda need Jul 12 20:24:51 so no Jul 12 20:24:55 :P Jul 12 20:25:06 want the XDP stuff and such, backporting to 4.14 looks like a giant effort Jul 12 20:25:11 but may actually be easier Jul 12 20:25:17 you should use KanjiMonster's script Jul 12 20:25:20 that is a good start Jul 12 20:25:23 script you say Jul 12 20:25:33 yes, that will refresh openwrt's patches Jul 12 20:25:45 keep in mind a lot of patches might have been accepted upstream or will break Jul 12 20:25:48 yeah Jul 12 20:26:09 this one is a bit silly as the content hasn't changed just the offset Jul 12 20:26:53 it will generate noise so weeding out stuff breaking is harder, so it makes sense to adjust those patches as well Jul 12 20:26:59 yeah Jul 12 20:27:12 wheres the script live? Jul 12 20:27:29 sec Jul 12 20:29:13 https://git.openwrt.org/?p=openwrt/staging/jogo.git;a=blob;f=scripts/update_kernel.sh;h=061e6e7fb75bbf7461ef0eb80b988fac33d43c08;hb=refs/heads/update_kernel_sh < there Jul 12 20:29:47 thanks Jul 12 20:29:55 actually, i have no idea if that will help in bringing up a new minor release Jul 12 20:29:59 jwh: Borromini: use that one https://github.com/KanjiMonster/maintainer-tools/blob/master/update_kernel.sh Jul 12 20:30:07 I'm *hoping* the bump to 4.18 won't be so terrible if I fix up 4.17 now Jul 12 20:30:19 KanjiMonster: ty Jul 12 20:30:24 ta Jul 12 20:31:40 4.18 is what I'm really looking forward to (but its not out until next month and theres still a load of patches in the queue that linus hasn't merged yet) Jul 12 20:32:12 AF_XDP and a few other bits Jul 12 20:32:18 good luck with it, i'm out Jul 12 20:32:50 also kinda hoping he'll merge the netfilter<->bpf/xdp stuff Jul 12 20:33:20 then uh, on hardware that supports it, filtering can be done on the nic rather than wasting cpu time Jul 12 20:34:07 without having to add support for it to anything, since it *should* be transparent once an iptables rule is added Jul 12 20:46:43 KanjiMonster: mm, that only works for bumps in the same branch, right? Jul 12 20:46:48 or am I misunderstanding it Jul 12 20:51:55 jwh: not sure what you mean by branch, but you pass it a kernel release, and optionally a patch version; so if you want to refresh/update for 4.17 you just run update_kernel.sh 4.17 Jul 12 20:52:19 ah hm Jul 12 20:53:14 russell--: i've pushed a fix. it slows down the leak, but i think i need to fix mt76 as well Jul 12 20:53:20 so I added 4.17 to kernel-version.mk, I just get "no support for 4.17" when running it like that, not having done any kernel bumps I dunno what else I need to do heh Jul 12 20:53:42 but guessing since nothing exists as-is, will need to do the manual work first? Jul 12 21:00:06 nbd: thanks! Jul 12 21:10:50 hooray for dropping "bridge: port isolate" :) Jul 12 21:10:59 great to see it upstream Jul 12 21:36:12 I don't know if that matter, but I read a couple days ago in another channel some guy having issues with 4.17 and up and hostapd Jul 12 21:36:27 due to I believe wmm patches added in 4.17 Jul 12 21:37:09 the configuration was working fine in 4.16 but didn't anymore in 4.17 Jul 12 21:55:06 weee, at least 2 upstreamed patches so far, progress Jul 12 21:55:53 I should preserve the commit messages in the top of the patches right? Jul 12 22:10:16 nope, I'm out far too many half committed bits Jul 12 23:35:56 http://ix.io/1d3T Jul 12 23:36:02 thoughts? shall I bother sending to the list? Jul 12 23:41:23 oh, i fucked it Jul 12 23:45:38 apart from the obvious noobery Jul 13 00:08:04 Howdy partners Jul 13 00:08:10 I made a booboo Jul 13 00:09:15 Trying to make an image with OpenWisp-Config for my device with only 4MB storage I didn't include a DHCP daemon, and now I don't know how to access the device Jul 13 00:09:20 any ideas? Jul 13 00:10:02 flash an image with dhcp in it Jul 13 00:10:03 :D Jul 13 00:10:10 :) Jul 13 00:10:11 also, Jul 13 00:10:14 TFTP? Jul 13 00:10:14 #openwrt Jul 13 00:10:25 I'm in the wrong room? Jul 13 00:10:34 kinda Jul 13 00:10:40 sorry, and thanks Jul 13 00:10:46 but yeah, tft Jul 13 00:10:47 p Jul 13 00:11:13 unless you have console/uart, in which case you could assign it manually and sysupgrade Jul 13 00:12:06 The leads aren't soldered so I'll try TFTP first, thanks again! Jul 13 00:13:12 the device probably has a static ip Jul 13 00:13:37 if it has default config, yeah Jul 13 00:14:14 if you set your laptop/whatever to a compatible static ip, you should be able to ping/ssh Jul 13 00:14:58 I'll look for the defaults, so far 192.168.0.1 and 192.168.1.1 haven't worked out Jul 13 00:15:24 md5: /join #openwrt Jul 13 00:18:13 aaaaaaalso, http://ix.io/1d4a Jul 13 00:18:14 :D Jul 13 00:18:27 I think I did it right but that makefile is a mess Jul 13 00:57:49 oh also, I stumbled upon an article that suggests now (because lts window is 6 years rather than 2), lts should be every 5 versions (which holds true for 4.4, 4.9, 4.14) Jul 13 00:57:55 so next one should be 4.19 Jul 13 00:58:38 which is just delightful Jul 13 01:03:55 like supporting ridiculously old kernels wasn't bad enough heh Jul 13 01:04:43 google demanded, obviously they should provide the support for them but they probably won't Jul 13 01:21:14 The last thing I read about LTS kernels, is that they will not be announced until tagged/released, so vendors won't rush to include not properly tested code Jul 13 01:21:38 So, 4.18 could be an LTS kernel. We'll only know once it's released **** ENDING LOGGING AT Fri Jul 13 03:00:01 2018