**** BEGIN LOGGING AT Wed Jun 19 02:59:57 2019 Jun 19 06:20:49 *yawn* Jun 19 06:32:43 morning blogic Jun 19 06:33:15 jow: morning Jun 19 06:33:28 jow: i'll put some pressure ont he server funding discussion today Jun 19 06:33:32 not had a reply yet Jun 19 07:01:45 blogic: thanks Jun 19 07:01:53 I'll continue breaking servers Jun 19 07:10:01 jow: whatever takes your fancy ;) Jun 19 07:10:13 it was easy to fix in the end so no harm done :-) Jun 19 07:26:02 * ldir has a god awful hack to get 4.19 building on macos Jun 19 07:26:42 ldir if it works for you then.. Jun 19 07:27:33 Why don't you switch to linux? Jun 19 07:28:03 what needs money right now? Jun 19 07:28:36 Or use a VM. I cant complain tho I use WSL lol Jun 19 07:29:08 dansan me pleas. :D Jun 19 07:30:43 lol!!!!! Jun 19 07:33:53 hrm, what happens to my serial console kernel logging (on an mt7620) when I use kgdb? Does it still spew to gdb and confuse it or does kgdb know to stop spewing the kernel ring buffer to the serial port? Jun 19 07:34:19 Tapper: I would prefer to be able to compile under the native OS for performance and admin really Jun 19 07:34:59 ldir: it's not too bad with all of the virtio and kgb Jun 19 07:35:05 err, I mean kvm Jun 19 07:35:08 ldir yeah. I tryed out wsl 2, but could not work out how to get ssh to the pece of crap. Jun 19 07:35:47 WSL2 has faster IO. I want back to WSL1 because I can get my bin files out of it with no messing around. Jun 19 07:36:10 Tapper: there is also the argument that avoiding monocultures (ie. only building linux on linux) hides cross compile issues Jun 19 07:36:33 I can see the files from WSL1 with windows file explorer. Jun 19 07:36:49 ldir that make sence! Jun 19 07:38:06 I am going to wate until WSL2 has matured a bit and then try again. Jun 19 07:39:34 You're also talking about the issue of 'getting stuff in/out of your vm' yourself, that's something that is avoided by building natively. Jun 19 07:39:54 Has any one had probs building ath79 on latest trunk or is it just my PC being shit again. Jun 19 07:40:16 Yes! Jun 19 07:40:18 * Tapper nods at ldir Jun 19 07:40:33 Thanks. Jun 19 07:40:43 I will try later then. Jun 19 07:41:08 well, are you trying to build under Linux or some VM ? Jun 19 07:41:40 ldir ws1 on windows 10. It will build for mevebu Jun 19 07:42:09 mvebu** Jun 19 07:43:03 is it by any chance failing on building 'calc_vmlinuz_load_addr.c' ? Jun 19 07:45:48 Sorry ldir I did not have loging on and have closed the windo now. Jun 19 07:46:46 I kicked off a new build and will try and find out for you. Jun 19 07:47:50 ldir It could be my PC tho mate. I had to down clock my memmory to keep it stable. I am saving up for a new AMD box soon Jun 19 07:48:38 if one arch builds then I doubt hardware is the problem. Jun 19 07:49:56 ldir you never know with this PC mate trust me. lol Upon everry boot it shuts down 3 times because the bios is dodgy. Jun 19 07:50:13 lol Jun 19 07:52:05 if it fails and makes reference to calc_vmlinux_load_addr then try applying this patch https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commit;h=ede42838534df20b37d2312e27722a7367df579d Jun 19 07:52:45 I'll be sending it to the kernel people later today once I've worked out the commit message wording. Jun 19 07:53:18 ldir want me to rite your masage hahahah Jun 19 07:53:49 you can spol chunk it four me Jun 19 07:55:24 hah Jun 19 07:56:26 my wife is asking me what I am laughing at! Jun 19 07:56:42 She thinks I have lost it hahaha Jun 19 07:57:06 She says i need help! hahahahah Jun 19 07:58:27 we *all* need help in here :-) Jun 19 07:59:30 ldir the build just says Jun 19 07:59:31 make[3] -C package/kernel/mac80211 compile Jun 19 07:59:31 make -r world: build failed. Please re-run make with -j1 V=s or V=sc for a higher Jun 19 08:00:45 Which is not telling us mutch. Jun 19 08:01:33 no, you need to run with 'make -j1 V=s' to see the error Jun 19 08:03:55 ldir running again now. Jun 19 08:06:47 ldir Makefile:19: recipe for target '/home/tapper/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/linux-4.19.52/. Jun 19 08:06:47 modules' failed Jun 19 08:07:59 anything before that - can you pastebin the page ? Jun 19 08:08:18 make: error while loading shared libraries: libc.so.6: failed to map segment from shared Jun 19 08:09:32 ynezz: thanks again for your work on 4.19 Jun 19 08:09:41 ok I have no idea to be honest. Jun 19 08:10:06 * ldir **** me - another stable kernel bump Jun 19 08:11:08 heh Jun 19 08:12:17 this is the best I can get. Jun 19 08:12:20 https://pastebin.com/0EBbYbE7 Jun 19 08:15:24 ok - well let's leave that there and see if anyone else falls over something similar. Jun 19 08:16:13 OK Jun 19 08:23:49 ldir: I don't want to ruin your upstream party with my bikesheding again, but your approach for that fix is likely to be rejected, can you try this instead http://paste.ubuntu.com/p/7hdJzGKSYv/ ? Jun 19 08:25:31 Tapper: indeed, looks like strange error, this is WSL? Jun 19 08:25:53 yeah Jun 19 08:27:21 BTW this is incremental build or build from scratch? Jun 19 08:27:30 ynezz: I like your bikeshed :-) Thanks. I'll test that (I have to do a failing build error log for the commit message anyway) so I can prove the ynezz new improved mega fix works :-) Jun 19 08:29:42 ynezzDon't worry about it for now mate. I will try again in a day or to. If it's not fixt then I will get proper logs and let people know what's going on. My computer is not verry stable tbh Jun 19 08:54:04 anyone know what ryzens are like compared to xeons Jun 19 08:54:10 ... when using top end ones ? Jun 19 08:54:43 looking up prices for our potential new servers Jun 19 08:54:51 one is from Intel and so full of bugs - /me hides Jun 19 08:55:07 ryzen is new and they have not been found yet Jun 19 08:55:10 but yeah Jun 19 08:55:17 ldir: hence my question :-D Jun 19 08:56:00 lol - so assume that both will actually end up running half the speed and be happy when they're faster Jun 19 08:56:54 we are currently considering getting a big storage server with 40TB and 4-5 machines in the "normal server" range Jun 19 08:57:07 and 10TB backup space and 10gb interconnect for all servers Jun 19 09:03:06 Ryzen servers seem more stable than consumer PCs Jun 19 09:03:14 but in any case you need a recent kernel (>= 4.19) Jun 19 09:04:04 having both intel/amd could help with testing as well Jun 19 09:04:57 I've been using a Hetzner server with 24C/48T (AMD EPYC 7401P 24-Core Processor) and it's stable and fast Jun 19 09:05:23 from what I've read, single-core performance is lower than a high-end Xeon but multi-core performance is higher Jun 19 09:05:46 zorun: that is an AX one ? Jun 19 09:05:56 48T, yummy Jun 19 09:06:04 ynezz: ;) Jun 19 09:06:48 we frequently get hardware errors in the logs on our AMD 7401P hetzner server Jun 19 09:06:52 ynezz: they come with 128GB ram and can be pimped to 512gb Jun 19 09:07:06 but it's mostly [3022580.639314] [Hardware Error]: Corrected error, no action required. Jun 19 09:07:06 stintel: ok, so intel it is Jun 19 09:07:25 maybe we simply don't have that logging enabled on our xeon boxes :) Jun 19 09:07:40 stintel: it did not happen then Jun 19 09:08:38 blogic: I would prefer 96T/128GB instead of 48T/512GB :) Jun 19 09:09:17 I have 80T/128GB on my power8 box but the noise it makes :/ Jun 19 09:10:46 yep, looking forward to test gcc112 one day Jun 19 09:11:16 160T/256GB Jun 19 09:13:20 :D Jun 19 09:19:13 blogic: looks like it is (128 GB, NVMe) Jun 19 09:19:42 blogic: yeah if stability is more important than fanciness, go for the Xeon :) Jun 19 09:26:13 ynezz: can confirm your new improved bikeshed works ;-). Will work on the commit message and get upstream. I'll put your SoB if that's ok? Jun 19 09:55:46 xback: on 18.06 I'm getting https://bpaste.net/show/b4c2544c1419 Jun 19 09:56:16 that's brcm2708-bcm2708 and the likely culprit is ca641bae6da977d638458e78cd1487b6160a2718 ("staging: vc04_services: prevent integer overflow in create_pagelist()") Jun 19 10:03:55 ynezz: jow - you guys happy with https://pastebin.com/Ps6vpm7k Jun 19 10:05:11 "which file spec" ? Jun 19 10:07:43 yeah, looks good, but I would remove that advertising at the bottom Jun 19 10:07:45 * ynezz hides Jun 19 10:08:54 heh, I'd leave it :) Jun 19 10:09:05 uerugh it's gone wonky. hold on Jun 19 10:12:18 xback: kernel v4.9.182 doesn't have the vchiq_pagelist_info struct Jun 19 10:14:46 Try this https://pastebin.com/HWWmYCGj the scrollback on my terminal window had gone mental! Jun 19 10:16:10 * ldir keeps a large trout handy for when ynezz reappears Jun 19 10:17:10 :p Jun 19 10:19:31 s/linux/Linux/ s/openwrt/OpenWrt/ s/macos/otherOS/ Jun 19 10:19:38 other then it looks ok Jun 19 10:20:29 anyway, this error seems like it could be reproduced by building OpenWrt under any BSD as well Jun 19 10:20:51 ldir: it's also always nice to put the exact error message(s) into the commit log, so if someone googles for it they will then find your patch/the commit Jun 19 10:22:20 good point - I shall amend. Jun 19 10:22:21 and you got an ok from jow (and ynezz) for putting their SoBs there? Jun 19 10:23:05 I did ask - I haven't sent - am waiting for the ok from jow which is why I'm waving it about a bit :-) Jun 19 10:23:16 ah, okay, good Jun 19 10:25:27 ok, so what's the policy on commit messages that include compile errors that go across the 70 char limit ? Jun 19 10:25:43 it's allowed Jun 19 10:25:51 I think it's acceptable - it's done in the linux kernel as well Jun 19 10:27:05 yeah, when reproducing error messages it's somewhat important to keep then as verbatim as possible Jun 19 10:27:17 better? https://pastebin.com/WvtvMugC Jun 19 10:28:41 I would just keep lines 10 and 11, that compiler command is not important Jun 19 10:29:08 they already know, that you're kevin Jun 19 10:29:11 ) Jun 19 10:30:05 I usually use the non V=c output (so then there'll be just "CC arch/mips/boot/compressed/calc_vmlinuz_load_addr" or whateve the line is Jun 19 10:30:18 my reputation is spreading Jun 19 10:31:06 also "the following error was encountered when building Linux for Openwrt under macos." <- I'd put a ":" at the end there, *nitpick* *bikeshed* Jun 19 10:32:22 green ;-) Jun 19 10:32:42 is it really macos or Mac OS ? :P Jun 19 10:32:43 no, blue! Jun 19 10:32:52 OSX! Jun 19 10:32:58 with or without space? Jun 19 10:33:16 * jow hides Jun 19 10:33:17 you know.. I actually went to look on the Apple web site! Jun 19 10:33:33 unhides jow - is your SOB ok? Jun 19 10:34:59 by OS naming guidelines v1.5 ratified by OS naming steering commitee in 2017 it should be 'macOS' Jun 19 10:35:02 btw, there are also less strong versions of SoBs, like "Suggested-by: " in case there was no actual code contribution, just a hint how to fix it Jun 19 10:36:47 ldir: sure Jun 19 10:37:06 ldir: SUggested-by would be fine too Jun 19 10:37:13 KanjiMonster: I think by now we're all in danger of needing a suggested-by :-) Everyone has contributed some code to this, even if it didn't make it to the final version :-) Jun 19 10:38:59 ok I've 'downgraded' jow to suggested by, kept everyone else as signed-off-by and added a bikeshedded-by for KanjiMonster :P Jun 19 10:39:17 ldir: sure, why not ;P Jun 19 10:39:54 I have seen a few tongue in cheek tags, it doesn't seem to be forbidden Jun 19 10:40:38 lol - there needs to be a 'to-death' sub-tag Jun 19 10:53:11 "No-objection-from-me-by:", "Inspired-by:", "Just-do-it-by:", "Fairly-blamed-by:", "Bug-actually-spotted-by:", "Tentatively-reviewed-by:", "You're-my-ding-a-ling-by:", "Niced-by:", "Okay-ished-by:", "\o/-by:", "Pointed-at-by:", "Brown-paper-bag-to-be-worn-by:", "Rightfully-ranted-at-by:", "Not-longer-ranted-at-by:", "Badly-reviewed-by:", "Cut-and-paste-bug-by:" Jun 19 10:53:26 (these are all from the kernel git) Jun 19 10:55:03 :-) Jun 19 11:34:34 hexa-: thanks for reporting Jun 19 11:34:55 hexa-: I can't test each individual target unfortunately :( Jun 19 11:35:19 xback: obviously you can't; but why doesn't buildbot build changes on the stable branch? Jun 19 11:36:07 it does Jun 19 11:36:11 also I tried to find the v4.9.181 stable review thread but couldn't Jun 19 11:36:13 oh, weird Jun 19 11:36:25 unless you mean 19.07, we didn't setup the infraq for thatz yet Jun 19 11:36:31 18.06 Jun 19 11:36:31 *infra for that Jun 19 11:37:49 all builds listed here are against master http://builds.openwrt.org/builders/brcm2708%2Fbcm2708 Jun 19 11:38:18 I wouldn't know where else to look Jun 19 11:38:29 http://release-builds.lede-project.org/18.06/images/ Jun 19 11:38:32 http://release-builds.lede-project.org/18.06/packages/ Jun 19 11:38:38 ah Jun 19 11:38:52 or rather Jun 19 11:38:53 http://release-builds.openwrt.org/18.06/images/ Jun 19 11:38:56 does that havean openwrt.org name as well? ... Jun 19 11:38:57 http://release-builds.openwrt.org/18.06/packages/ Jun 19 11:39:01 right. yeah, too fast to type :) Jun 19 11:39:44 http://builds.openwrt.org/ still has lede branding fwiw. Jun 19 11:39:44 ah, and there it's still pending, that explains it Jun 19 11:40:18 because all build slaves are offline? Jun 19 11:43:39 yes Jun 19 11:52:22 \o/ 0.000000] Linux version 4.19.52 (kevin@Kevins-MBP) (gcc version 9.1.0 (OpenWrt GCC 9.1.0 r10271-19c8d28260)) #0 SMP Wed Jun 19 10:58:07 2019 Jun 19 11:57:23 GCC 9.1.0? O_o Jun 19 11:58:44 came out may 3, ages ago now :) Jun 19 12:00:14 I mean, GCC9 had some bug iirc Jun 19 12:00:19 heh. isn't this rather large for a kernel module: xt_comment 12288256 Jun 19 12:00:28 ah, the bcache bug Jun 19 12:03:33 gcc9 brings in D. neat. Jun 19 12:09:49 stintel: unstripped debug build? Jun 19 12:10:29 CONFIG_USE_SSTRIP=y Jun 19 12:10:52 * ldir hmms at Jun 19 12:10:58 I mean the actual file itself Jun 19 12:11:08 not what the config says ;) Jun 19 12:11:16 * ldir hmms at F2FS-fs (loop0): Issue discard(4126, 4126, 4) failed, ret: -5 Jun 19 12:11:37 CONFIG_KERNEL_DEBUG_INFO=y Jun 19 12:11:41 KanjiMonster: dunno Jun 19 12:18:11 ldir, I have same issue on 4.19 with f2fs Jun 19 12:21:05 yes, that loop block device is a known problem PR#1800 PR#1847 Jun 19 12:24:59 it was happening on 4.14 as well at least for me, but not that much as on 4.19 Jun 19 12:26:55 last time I've looked at it, they've changed the logging of this stuff after 4.14 so now it's more verbose Jun 19 12:28:50 eeeekj Jun 19 12:28:50 kernel panic on my OpenWrt VM Jun 19 12:28:57 after flashing with image from git HEAD :( Jun 19 12:31:17 [ 4.208002] kmemleak_object 356761KB 361470KB Jun 19 12:31:18 dafuq Jun 19 12:31:53 doesn't really work on a 256MB VM :/ Jun 19 12:34:52 great, and I don't even have /sys/kernel/debug/kmemleak Jun 19 12:35:09 stintel: can we conclude that 4/32 devices are dead then? Jun 19 12:35:28 :P Jun 19 12:35:43 32/512 is the new minimum now Jun 19 12:36:01 didn't even work with 512MB - I increased the VM to 1GB RAM Jun 19 12:36:11 but can't even use the kmemleak crap Jun 19 12:36:34 that's x86? Jun 19 12:36:41 yes Jun 19 12:36:58 I need to reboot this box every 2-3w because there is some memleak Jun 19 12:37:08 I've tried a few times to debug it but keep failing miserably Jun 19 12:41:41 seems like 64M is minimum for x86 4.19 under QEMU Jun 19 12:42:37 it had 256MB Jun 19 12:42:59 just downloaded latest x86_64 snapshot and tried it in qemu again Jun 19 12:47:56 can't get under 40M Jun 19 12:54:24 do option names need to be lower case? Jun 19 12:57:03 there is no requirement for that but they should be Jun 19 12:59:55 ah ok, cause i'm looking how nodogsplash generates the config file from the uci config. the oldschool config file has a GatewayPort Jun 19 13:08:13 the kernel accounts for memleaks? Jun 19 13:19:11 ynezz: thanks for the uqmi push :) Jun 19 13:19:33 (meaning the push email) Jun 19 13:21:49 * blogic takes of protective gear Jun 19 13:21:59 venturing into radiotap hdr generation aint fun Jun 19 13:25:53 ynezz: I don't think I ever saw the error on 4.14 which is why it's so alarming on 4.19 Jun 19 13:26:34 ldir: I just upgraded my openwrt-vpn VM server and I saw the same issue. Jun 19 13:27:31 Hello all, I've noticed a large performance regression with flow offloading since the switch to kernel 4.19 on ath79 (archer c7 v2). I've bisected it to a specific commit. Anyone up for giving me some pointers where to go next? Jun 19 13:28:38 ldir: after restoring my config and a reboot I dont see it anymore. Jun 19 13:29:55 SibrenVasse: if the specific commit is the switch to 4.19, then your next target would be bisecting the linux kernel. that's no easy task though Jun 19 13:30:10 Rene__: have tried a couple of reboots already. Jun 19 13:34:10 KanjiMonster: No I was previously already using the 'testing' kernel. I switched back to 4.14 when I noticed this issue. The issue was introduced for me by 8df12d76c642cd2e094e2c02fdf7b676fb902bc7. (Which is a version bump to 4.19.34) Jun 19 13:34:12 I can provoke the issue by creating a file on the filesystem - touch /etc/config/wibble - will eventually generate an error in dmesg - Jun 19 13:35:00 SibrenVasse: yes, so the specific commit *is* the switch to 4.19 Jun 19 13:35:55 ldir: Technically, yes. Jun 19 13:36:40 SibrenVasse: so 4.19.25 was fine, and 4.19.34 is affected? then you could try to find out which kernel version in between introduced the issue Jun 19 13:38:14 KanjiMonster: that's true, but the commit also changes a patch in hack-4.19/ related to flow offloading, so that could also be the culprit. Jun 19 13:40:09 SibrenVasse: you probably need to find out which commit upstream modified the code that required changing the flow offload patch, and check if the flow offload patch now requires further modifications Jun 19 13:42:33 assuming there wasn't just one commit upstream to the affected code, narrowing down the kernel version might still be benefical in identifing the exact change that broke things Jun 19 13:42:51 or rather made things ineffective Jun 19 13:44:32 KanjiMonster: Yeah flow offloading is essentially not working right now. I'll take a further look later today. Jun 19 13:49:57 FWIW it's likely going to be some backport, because mt7621 crashes with latest 4.14 and enabled flow offloading Jun 19 13:50:17 4.14.123 reported working Jun 19 13:52:44 at least I'm not hitting f2fs_bug_on() Jun 19 14:46:29 in the context of openwrt, what does $1 in init.d scripts refere to? it's not "start, stop,..", right? Jun 19 14:47:41 because after "local cfg="$1"" it gets used in 'procd_set_param file "/tmp/etc/nodogsplash_$cfg.conf"' and will generate a file named nodogsplash_cfg015847.conf. where is the "cfg015847 " coming from? Jun 19 14:48:20 charolastra: if it is used inside a function, it refers to the first argument given to that function Jun 19 14:48:56 that cfg015847 is afaik a UCI thing Jun 19 14:50:28 autoassigned name for an anon section. Jun 19 14:50:50 your'e probably looking at something that has got a foreach in the start_service section, even if's normally only a single instance. Jun 19 14:51:50 exactly @ config_foreach. trying to get a second instance of nodogsplash Jun 19 14:54:20 you can rely on the cfgxxxx being unique, if that's sufficient. Jun 19 14:54:42 you can also just require your sections to have names, if that's nicer for the users Jun 19 16:50:22 build #322 of layerscape/32b is complete: Failure [failed kmods] Build details are at http://release-builds.lede-project.org/17.01/images/builders/layerscape%2F32b/builds/322 blamelist: Hauke Mehrtens Jun 19 17:10:58 Has anyone here thought about / tackled the problems with upgrading NAND-based devices off ar71xx and that existing upgrade scripts don't handle SUPPORTED_DEVICES on targets without firmware metadata? Jun 19 17:12:01 I haven't been able to figure out a "safe" way without duplicating the firmware for every board name, especially when the "old" name collates before the "new" name. Jun 19 17:18:18 xback: revert has just happened Jun 19 17:24:05 build #322 of brcm2708/bcm2710 is complete: Failure [failed images] Build details are at http://release-builds.lede-project.org/17.01/images/builders/brcm2708%2Fbcm2710/builds/322 blamelist: Hauke Mehrtens Jun 19 17:29:43 these kernel updated broke several packages :) Jun 19 17:29:47 *updates Jun 19 17:48:38 KanjiMonster: It's 4.19.26 Jun 19 18:04:53 build #323 of layerscape/64b is complete: Failure [failed kmods] Build details are at http://release-builds.lede-project.org/17.01/images/builders/layerscape%2F64b/builds/323 blamelist: Hauke Mehrtens Jun 19 18:08:37 <_abc_> Hello. Are there any problems installing the build environment for openwrt on an amd64 machine? I think it runs stretch, not sure now, I have several headless zombie machines used for various tasks. Jun 19 18:09:43 _abc_: in general not that I know of Jun 19 18:10:19 <_abc_> The machine/compilers etc may be slightly outdated. I need to upgrade it but that is tricky, I have fpga software with licenses on it, it's a major hassle. Jun 19 18:12:07 <_abc_> So I'll try without upgrade, to see if I can build openwrt specific targets on it, then, if that fails, I'll upgrade and build after it. Jun 19 18:13:46 <_abc_> At this point, I have to say I could REALLY use a non buggy 18.06.4 on tl-wr741 since those zombies tend to not have wireless drivers or cards and use an openwrt router as wifi client sometimes. Jun 19 18:14:43 <_abc_> buggy means network speed hiccuping in the sense I explained with pings yesterday here I think Jun 19 18:20:01 build #343 of apm821xx/nand is complete: Failure [failed images] Build details are at http://release-builds.lede-project.org/17.01/images/builders/apm821xx%2Fnand/builds/343 blamelist: Hauke Mehrtens Jun 19 18:42:11 <_abc_> What routers use powerpc cpu's ? Jun 19 18:45:58 <_abc_> In the sense of https://devuan.org/os/documentation/dev1fanboy/general-information -- what is an "embedded" .xz image? I think I never saw one. Or did and did not pay attention? Where would such an embedded image be found? Jun 19 18:46:07 <_abc_> Sorry wrong channel Jun 19 19:51:33 Hmm... I feel this is stupid question, but what would be openwrt firewall config for equivalent to allow "related, established"? Jun 19 19:52:22 I have VLAN that is generally not alowed to/from wan, but certain machines can, I'd like to allog ping out etc get response etc Jun 19 19:54:03 enabling connection tracking perhaps? Jun 19 19:58:25 nope :) Jun 19 19:59:03 <_abc_> "related,established" :) Jun 19 19:59:26 <_abc_> You can filter by mac address probably? Jun 19 19:59:46 :+1: though I work with nftables, so can't comment on the UCI config or iptables lines Jun 19 20:00:49 :+1: on conntrack -- I never trust IP or MAC addresses to auth, only to deny when they're on the wrong interface/VLAN. Jun 19 20:01:12 well the thing is that for now, as said, default forward for that zone to wan is rejected, and then certain MAC is allowed to forward to wan (traffic rule), and internet works from there, but for example ping doesn't reply back grom eihter IPv4 nor V6 Jun 19 20:01:45 <_abc_> forward icmp too Jun 19 20:03:00 jeffsf: well, this is in network where I have "total" control of things.. or to be more specific, our hackerspace network, where zone in question would be "management" zone where generally nothing needs internet, but I want A computer to be able to update oneself in the zone :) Jun 19 20:05:51 ICMP may be the key there -- I don't trust most of my own machines on the network. You want "special" access? You're on a dedicated VLAN for it, potentially with multiple addresses on a single, physical interface. My hand-crafted rules very early on have a verrevpath/versrcreach and antispoof reject Jun 19 20:07:24 I take the zone forward reject takes predecence over "Allow-ICMPv6-forward" that has echo-reply and from anyhost in wan to any host in any zone? Jun 19 20:09:33 jeffsf: yes, and more generally this propably will not be final setup for this particular device either, but more broadly management VLAN/zone is also not available from generally any random network outlet etc, it is not meant to be totally überly tight from NSA experts, especially if someone really want to get inside from inside premises Jun 19 20:12:44 duh... adding option proto all to that specific traffic rule made that to work :) Jun 19 20:13:49 ..so it wasn't likely that "echo-reply" or equiv was ever problem, but icmp outgoing at all :D Jun 19 20:16:14 jeffsf_ the bouncy guy (: Jun 19 20:29:27 LOL, yeah, my company wireless isn't terribly stable. Jun 19 20:29:49 We're moving next week and I am hoping it gets better. Jun 19 20:30:37 I still can't figure out why freenode sends me TCP RST at home, but I think that's a different problem. Jun 19 20:58:37 build #316 of arm64/generic is complete: Failure [failed kmods] Build details are at http://release-builds.lede-project.org/17.01/images/builders/arm64%2Fgeneric/builds/316 blamelist: Hauke Mehrtens Jun 19 21:57:19 build #310 of brcm2708/bcm2709 is complete: Failure [failed images] Build details are at http://release-builds.lede-project.org/17.01/images/builders/brcm2708%2Fbcm2709/builds/310 blamelist: Hauke Mehrtens Jun 19 22:12:32 build #310 of brcm2708/bcm2708 is complete: Failure [failed images] Build details are at http://release-builds.lede-project.org/17.01/images/builders/brcm2708%2Fbcm2708/builds/310 blamelist: Hauke Mehrtens **** ENDING LOGGING AT Thu Jun 20 03:00:00 2019