**** BEGIN LOGGING AT Thu Dec 06 03:00:01 2018 Dec 06 04:17:38 mkresin: should be reverted Dec 06 04:33:36 actually probably just second change. I will send a patch Dec 06 06:04:40 in case somebody has experience with OpenWrt in qemu-kvm: https://social.atypique.net/@zorun/101192568523413195 Dec 06 06:09:54 kvm has many fiddly bits to make everything fast Dec 06 06:10:19 I don't claim to understand any of them well Dec 06 06:34:27 uberushaximus: hmm, I'm running qemu manually, maybe I should trust libvirt or some other layer to set the right parameters then Dec 06 06:39:51 zorun: you certainly can, qemu has a bad case of legacydefaultitis Dec 06 06:42:39 I use some of these flags emulating windows, perhaps they will help Dec 06 06:43:04 qemu-system-x86_64 -net nic,model=virtio -net user -object rng-random,id=rng0,filename=/dev/urandom -device virtio-rng-pci,rng=rng0 -m 1337 -cpu host -device virtio-scsi-pci,id=scsi0 -drive file=yourfile.qcow2,if=virtio,cache=none -smp 8 -enable-kvm -machine q35,accel=kvm -device virtio-balloon "$@" Dec 06 06:43:11 set -m and -smp to sane values Dec 06 06:43:27 for ram and "cores" Dec 06 06:44:33 you probably also want something more performant than user,tap, or bridge Dec 06 06:44:45 I don't know which net driver fits that bill Dec 06 06:45:21 perhaps you can pass through the whole switch into qemu at the pci layer Dec 06 06:47:39 http://pcengines.info/forums/?page=post&id=77FF51E3-8ACA-4B79-BD2C-1380B9B48B5D Dec 06 06:50:51 interesting, thanks Dec 06 06:51:14 though in my use-case, I don't want to give the whole NIC to the VM Dec 06 06:52:00 the goal is to have ~10 OpenWrt VM all sharing the same WAN port, and each having their own LAN (based on VLANs) Dec 06 06:52:37 keep in mind that context switching is expensive Dec 06 06:55:03 *yawn* Dec 06 06:55:21 morning blogic Dec 06 06:58:10 something like this is probably the *fast* way to do it https://wiki.qemu.org/Documentation/vhost-user-ovs-dpdk Dec 06 06:58:15 probably not the simplest Dec 06 07:04:07 right, a working dpdk setup would be a PoC in itself :) Dec 06 07:06:35 * blogic completes booting Dec 06 07:17:23 rmilecki: ping ... https://patchwork.ozlabs.org/patch/1008468/ Dec 06 07:17:30 so i am thinking Dec 06 07:17:31 blogic: pong Dec 06 07:17:46 1) there should be a generic hotplug helper inside possibly libubox Dec 06 07:18:06 sounds good! Dec 06 07:18:07 2) this should not just fork/waitpid but utilize uloop_process Dec 06 07:18:43 I should be able to do that :) Dec 06 07:19:43 so the signature would be hotplug_call(char *subsystem, char **envp) Dec 06 07:20:21 i think that would be the most correct way of doing it and prevent blockd getting to mountd's state Dec 06 07:20:40 alright Dec 06 07:20:52 i'll work on that, probably today, thanks for a review Dec 06 07:25:18 blogic: i'm looking at libubox and i'm not sure if it fits anywhere Dec 06 07:25:26 blogic: should I use a new hotplug.[ch] Dec 06 07:25:33 rmilecki: https://patchwork.ozlabs.org/patch/1007584/ replied and marked accepeted but push it yourself please Dec 06 07:25:44 yes Dec 06 07:26:05 ok Dec 06 07:26:13 blogic: i'll update commit & push, thank you! Dec 06 07:26:16 mkresin: https://patchwork.ozlabs.org/patch/1005805/ i nak'ed this on github Dec 06 07:32:52 blogic: and I can't remember to have delegated the patch to myself Dec 06 07:33:18 !? Dec 06 07:33:47 you were faster than me Dec 06 07:34:03 anyway, changed the status to rejected. never intended to commit the patch. should be added as module and all is fine Dec 06 07:34:04 https://patchwork.ozlabs.org/patch/1003936/ Dec 06 07:34:11 https://patchwork.ozlabs.org/patch/1004265/ Dec 06 07:34:15 i'd merge these 2 Dec 06 07:34:22 they look sane and worked for me when i tried Dec 06 07:35:41 there is a little chance that these cause warnings in case a target doesn't provide its own diag.sh and doesn't use the devicetree Dec 06 07:36:29 we could test for /proc/device-tree Dec 06 07:36:29 but it's more crystalball reading, as I haven't checked for such a target nor tried if really a warning is issued Dec 06 07:37:50 true, i'll see if i can test that today Dec 06 07:39:20 it should be safe. the only source for a warning would be get_dt_led(). and there are plenty of checks Dec 06 07:39:41 yes Dec 06 07:39:46 i just concluded the same Dec 06 07:40:56 feel free to add my ACK Dec 06 07:43:07 argh, too late already pushed, sorry Dec 06 07:43:45 even better, only you will be blamed if something is wrong ;-) Dec 06 07:43:55 hrr hrr Dec 06 07:44:28 right, my 1 hour merge slot of the day is over Dec 06 07:44:40 now i will enjoy the qsdk wifi driver for the rest of the day Dec 06 07:45:00 or i'll drive a pen into my eye, not sure which will be more fun Dec 06 08:44:34 where has our kernel bumper gone? :-) Dec 06 09:07:39 stintel: hoping to make a bump today Dec 06 09:08:17 My kid was admitted to the hospital .. so I've been away for a few days Dec 06 09:15:38 xback: oh my goodness!!! better now? or improved at least? Dec 06 09:15:58 well enough to be at home again Dec 06 09:16:20 phew! Dec 06 09:23:52 there's a fake doorbell patch that needs a tweak....looks like it's just going to be a bit shuffle. Dec 06 09:24:33 but I see there's a mac os security bump that I'd like to do before I look closer Dec 06 09:32:07 xback HI I hope your kid gets better soon mate. I have 5 and when any of them get ill it scares the crap out of me! Dec 06 09:33:00 Hey all Dec 06 09:33:31 I want to install openwrt on rtl8197fn Dec 06 09:33:37 how to get started? Dec 06 09:35:08 Take your time with the bump, kids are more precious than kernels. :-) Dec 06 09:36:06 Tapper Sorry couldn't get you Dec 06 09:36:35 Sorry that was at xback not you mate. Dec 06 09:37:29 Also, I've got the link for rtl819x kernel from https://forum.archive.openwrt.org/viewtopic.php?id=46606 Dec 06 09:38:26 Guest76126, i have replied in #openwrt Dec 06 09:39:07 realtek 8197fn != realtek 8197d / e Dec 06 09:53:18 Tapper: thank you :) Dec 06 09:53:38 xback: yeah, all the best. hope it'll sort itself out soon Dec 06 09:55:12 Tapper: amazing to have 5 of them .. my hands are already full with 2 of them :p kudos to you :) Dec 06 09:55:20 Bumping currently .. Dec 06 10:03:29 More a linux question. But is there a linux build target that checks .config for conflicts? Dec 06 10:05:40 conflicts? Dec 06 10:06:19 In the kconfig format you can set dependencies Dec 06 10:06:50 I believe it can be possible to have a conflict. For example you could have a CONFIG_A and CONFIG_B set even though CONFIG_A states that CONFIG_B must b n Dec 06 10:07:58 I believe you'll just get build failures if they're actual conflicts, Dec 06 10:08:28 there's a note at the top of the file that says # Automatically generated file; DO NOT EDIT. Dec 06 10:08:32 there's a reason for that too... Dec 06 10:08:56 so it's somewhat, "if you aim your gun at your foot, and shoot, you might shoot yourself in the foot" Dec 06 10:10:33 heh understood Dec 06 10:10:52 I'm actually playing around with OpenWRT overrides. Wondering if they did something smart to detect conflicts. I guess just run it is a good idea Dec 06 10:11:11 not good idea, more only practical way in the short term Dec 06 10:28:47 what do you mean by overrides? Dec 06 10:49:30 jow: would that be possible to update LXR on your server? Dec 06 11:01:55 blogic: do I really want uloop_process? it seems the only gain from uloop_process_add() is having a callback called by libubox Dec 06 11:02:14 what I need is just waiting for process to finish Dec 06 11:02:29 so I can use some mutex + callback releasing the mutex Dec 06 11:02:46 or I can just stick to the waitpid Dec 06 11:03:35 i think using waitpid is just wait simpler here Dec 06 11:10:55 rmilecki: only for the most simple usecase Dec 06 11:11:16 as soon as it is gtting async or you need to do other things in the mainloop, the uloop solution will be smaller/simpler Dec 06 11:11:51 jow: do we even have some mutex thing in ubox? Dec 06 11:12:00 so i can wait for the callback to release the mutex? Dec 06 11:12:40 what do you need the mutzex for? Prevent concurrent hotplug calls? Dec 06 11:13:08 no, i want process to finish before I continue Dec 06 11:13:21 how do blockd/mountd play together? on an old system I had non mountd, but the block-mount package, and while I got no events for sd card insert/removal, thigns were mounted ok on boot and after "block info" Dec 06 11:13:29 will I need _both_ mountd and blockd in the future? Dec 06 11:13:34 just one? Dec 06 11:14:17 karlp: mountd was dropped, you need fstools only (which provides block-mount with "block" binary) and blockd (which handles autofs) Dec 06 11:14:18 rmilecki: in this case a blocking wait might make the most sense if you do not need to handle other things in the meanwhile, like incoming uevents or something Dec 06 11:14:27 i don't Dec 06 11:14:44 (i don't need anything meanwhile) Dec 06 11:15:11 you could get really dirty and just use system() :P Dec 06 11:15:37 ldir: stintel: kernel bumps for master pushed to my staging. please remark that the 4.9 bumps still contain a build error which I'm checking currently. 4.14 will probably be final Dec 06 11:15:48 jow: possibly, mountd was doing that Dec 06 11:15:53 I wanted something nicer ;) Dec 06 11:18:35 xback: cool - I doubt I'll get to it today now..... I'm told there's a trip to ikea in my very near future - save me now!!!! Dec 06 11:20:32 karlp: i was supposed to share my summary document Dec 06 11:20:47 karlp: i wrote it in .odt format... Dec 06 11:20:52 karlp: so there's a PDF http://files.zajec.net/openwrt/storage.pdf Dec 06 11:21:30 it's not much Dec 06 11:21:47 but I was really confused when I looked at all that software so I needed sth like that Dec 06 11:23:34 I would _always_ encourage you to just write straight into the wiki yourself, but I'll help get it into the wiki. Dec 06 11:23:44 I'll test out some things myself as I go. Dec 06 11:24:47 just have to try and resolve the superior version of https://openwrt.org/docs/guide-developer/obtain.firmware.sdk and https://openwrt.org/docs/guide-developer/using_the_sdk ifrst.... Dec 06 11:24:57 ldir: I clicked some Save button on my screen, but it didn't help ;-) Dec 06 11:27:46 karlp: i usually write using plain text at least, I guess I wanted some fancy table for that one Dec 06 11:28:50 karlp: I love this statement in the former article: " Some SDK versions have bugs. " Dec 06 11:31:35 rmilecki: even your plain text onthe wiki would be easier to find than on your personal computer :) Dec 06 11:32:07 wiki gardners are happy to refomat and cleanup, but we need landscape architects to put in the initial content :) Dec 06 11:39:03 karlp: Overrides are the kernel configs generated from packages. You can see in Kernel/Configure/Default Dec 06 11:40:26 build #669 of layerscape/armv8_64b is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/layerscape%2Farmv8_64b/builds/669 Dec 06 12:17:10 hi all, i'm looing for some help with swconfig on customer hardware. swconfig see my switch and can detect port stats, but i can't seem to assign any ports to anything i create in /etc/config/network Dec 06 12:18:43 what did you try and how did you came to the conclusion that it didn't work? Dec 06 12:20:48 ugh, hate it when bugs arent reproducible Dec 06 12:21:46 something is up with ipt-netflow but i cant recreate it in a vm :( Dec 06 12:24:39 stintel: Holy crap, wpa_supplicant got a new release. Dec 06 12:28:11 well, massive pile of code changes in it, all the wpa3 stuff has been in git for a while now Dec 06 12:28:50 I create the switch,vlan anwan ifname as dhcp in network config. but it is not showing and link detection on "ip -c a" for the eth0.2, but "swconfig dev switch0 show|grep link" shows the link status as up Dec 06 12:29:29 karlp: It's long overdue Dec 06 12:29:47 crmingle: pastebin your /etc/config/network Dec 06 12:30:44 can the SDK not build new images as well, only packages? Dec 06 12:32:41 rmilecki: ok Dec 06 12:32:44 waitpid then Dec 06 12:32:51 blogic: i sent patch minute ago Dec 06 12:32:53 :) Dec 06 12:32:57 you would have to change the code to be re-entrant otherwise Dec 06 12:42:17 build #1106 of ramips/rt3883 is complete: Failure [failed targetupload] Build details are at http://phase1.builds.lede-project.org/builders/ramips%2Frt3883/builds/1106 blamelist: Rosen Penev , Petr ?tetiar , Chuanhong Guo , David Bauer , Mathias Kresin , Chen Dec 06 12:42:17 Minqiang , Ram Chandra Jangir , Hans Dedecker , Jonathan Thibault Dec 06 12:47:17 so... didn't build packages initially. need to use SDK to get packages built, then use imagebuilder with orginal packages + packages from sdk to get a new image built. Dec 06 12:55:23 karlp: sdk is meant to build single packages or to port software Dec 06 12:55:37 yeah, I think I've figured it out a bit now. Dec 06 12:55:39 karlp: it cannot build images Dec 06 12:55:49 I didn't build all packages when I made my "release" but I built the sdk and the IB, Dec 06 12:55:55 so I just used the SDK to build some extra ones, Dec 06 12:55:57 I wouldn't actually document using sdk + ib to create images Dec 06 12:56:04 and I can copy those into the ib. Dec 06 12:56:09 I'm not going to add it to the wiki Dec 06 12:56:14 ah ok :) Dec 06 12:56:31 the proper openwrt IB has all the packages available standard already Dec 06 12:56:44 I just didn't build all of them, only a few that seemed like reasonable optional extras. Dec 06 13:40:54 I'm trying to compile nightly with external kernel and external tool-chain. If I set to "Toolchain prefix" to "aarch64-linux-gnu-" then libnl-tiny doesn't find libc.so.6 . If I set it to "aarch64-linux-gnu" "make[5]: aarch64-linux-gnugcc: Command not found" . So there seems to be a mismatch here? Dec 06 13:41:45 compilation of libnl-tiny works fine with "aarch64-linux-gnu" Dec 06 13:43:26 "Package libnl-tiny is missing dependencies for the following libraries: libc.so.6" Dec 06 13:46:15 SwedeMike: thats usually an indication that the project didn't get cross compiled at all Dec 06 13:47:07 SwedeMike: pastebin the output of make package/libnl-tiny/{clean,compile} V=s Dec 06 13:48:10 jow: http://paste.ubuntu.com/p/MtF9Fz4crr/ Dec 06 13:49:34 did you miss - on the end if prefix? Dec 06 13:49:36 of* Dec 06 13:50:00 jwh: "If I set to "Toolchain prefix" to "aarch64-linux-gnu-" then libnl-tiny doesn't find libc.so.6" Dec 06 13:50:33 jwh: so I have tried both with and without, and I get different problems depending on what I do Dec 06 13:51:00 oh right Dec 06 13:51:09 yeah you need - anyway Dec 06 13:51:17 yes, that's what I figured. Dec 06 13:51:25 so question is, what's wrong with libnl-tiny? Dec 06 13:51:39 or is this just a symptom of something completely different problem? Dec 06 13:51:46 glibc image? Dec 06 13:52:05 ah, glibc indeed Dec 06 13:52:14 its a nightmare, half the time it just doesnt work Dec 06 13:52:28 building on a musl host yields more success Dec 06 13:52:31 SwedeMike: did you configure the proper library glob patterns? Dec 06 13:53:27 jow: I'll look into that again, I think I did. Dec 06 13:54:48 SwedeMike: in Base System -> libc -> Configuration --> Dec 06 13:55:23 SwedeMike: as well as libgcc, libthread, librt, libssp Dec 06 13:56:02 SwedeMike: the "libc shared library base directory" is probably the most important setting, the defualt glob patterns should work for glibc Dec 06 13:56:24 SwedeMike: afterwards, pastebin the complete output of "make package/toolchain/{clean,compile} V=s" Dec 06 13:56:49 this should create libc_...ipk, libgcc_...ipk etc. Dec 06 13:57:25 if that worked okay (libc.so.6 & friends actually got copied into the .ipk), then retry make package/libnl-tiny/{clean,compile} Dec 06 13:58:02 jow: ok, looking into that now. Dec 06 14:00:10 jow: right, so all those weren't found so there is indeed a lib path problem, let's see if I can figure out what needs to change Dec 06 14:01:19 right, so cp: cannot stat '/home/parallels/kernel/toolchain/gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu/./lib/librt.so.*': but the files are in /aarch64-linux-gnu/libc/lib/librt.so.1 so I need to add this to the lib path Dec 06 14:09:43 I'm failing to figure out which path I need to add aarch64-linux-gnu/libc so it'll find those files? Dec 06 14:11:14 it's not "Toolchain library path" anyway Dec 06 14:15:26 adding it to base system libc etc fixes some of the problems, but not all Dec 06 14:15:33 now libnl-tiny compiles correctly anyway Dec 06 14:53:47 build #330 of ipq40xx/generic is complete: Failure [failed pkgbuild] Build details are at http://phase1.builds.lede-project.org/builders/ipq40xx%2Fgeneric/builds/330 blamelist: Rosen Penev , Petr ?tetiar , Chuanhong Guo , David Bauer , Mathias Kresin , Chen Dec 06 14:53:47 Minqiang , Ram Chandra Jangir , Hans Dedecker , Jonathan Thibault Dec 06 14:56:14 how easy would it be to add disk image creation to octeon? Dec 06 14:56:28 like x86, but without grub... just fat32 and squashfs Dec 06 14:56:34 shouldn't be too hard Dec 06 14:57:02 the ubnt ones in particular often have usb keys, and without a factory image its already a pain to convert to openwrt Dec 06 14:57:09 disk image to dd would make it abit easier Dec 06 14:57:27 or fix factory images I guess Dec 06 14:57:43 although both would be quite nice Dec 06 14:58:39 jwh: if you look at Image/Build/grub2 of target/linux/x86/image/Makefile Dec 06 14:58:48 hmm, I'll look at the disk images, shouldn't be much different from x86 Dec 06 14:58:49 jwh: you basically need to do the same, just without the grub parts Dec 06 14:58:51 yeah Dec 06 14:58:59 cool thanks Dec 06 14:59:10 so the key is $(SCRIPT_DIR)/gen_image_generic.sh Dec 06 14:59:12 I'll check that out later and send patches if it works... Dec 06 14:59:51 sat on the floor in telehouse atm provisioning a new octeon, blank key, so it crossed my mind heh Dec 06 15:17:05 jow:ping Dec 06 15:17:23 dedeckeh: pong Dec 06 15:18:37 while I'm here, is there any native nat64 support in firewall stuff? Dec 06 15:18:42 nope Dec 06 15:19:06 hmmmm Dec 06 15:21:44 jow:related the firewall redirect src_dport issue is there a reason why port_redir is set to port_dest if port_redir is empty ? Dec 06 15:21:58 jow:https://git.openwrt.org/?p=project/firewall3.git;a=blob;f=redirects.c;h=6cd09f16143d84d3737c3157e4c3b23b1e280f94;hb=HEAD#l353 Dec 06 15:22:21 dedeckeh: yes, this mimicks the behaviour of the old shell script based firewall Dec 06 15:22:30 as this triggers the issue in case of SNAT rules with src_dport being set Dec 06 15:22:47 it should probably be restricted to target == DNAT Dec 06 15:23:07 ok that was my next question if it should be restricted to DNAT Dec 06 15:26:26 in retrospect it was a mistake to cram the snat funcitonality into the dnat section type Dec 06 15:29:17 as it causes too much confusion related to the different parameters (overloading) ? Dec 06 15:41:03 dedeckeh: yep, exactly Dec 06 15:48:14 guess I should really fix the ipip package Dec 06 15:49:30 however, should I split it into 2 options Dec 06 15:49:49 that is, should it depend on ipv4 and ipv6 kmods seperately, or just select all? Dec 06 15:50:32 should probably be seperate I guess Dec 06 15:50:43 so people can choose to compile with or without either Dec 06 15:50:56 install rather Dec 06 16:03:23 hm so in the absence of netifd support, is rc.local type thing the only other place to put network config? Dec 06 16:14:19 jwh: I'd use /etc/hotplug.de/net/ Dec 06 16:14:41 with [ $ACTION = add -a $DEVICE = ethX ] Dec 06 16:14:45 or whatever you need Dec 06 16:16:10 hmmm Dec 06 16:16:12 ok Dec 06 16:16:36 I'll look at ipip real quick, I don't think it would really be much trouble to make it a bit more useful Dec 06 16:16:45 that is, support things other than just ipv4 in ipv4 Dec 06 16:16:52 the thing with rc.local is that its almost always too early Dec 06 16:16:55 yeah Dec 06 16:17:03 in this case I just want a couple of tunnels Dec 06 16:17:06 and it also does not cope well with any kind of hotpluggable devices (usb nics etc.) Dec 06 16:17:16 no underlying physical interface dependencies Dec 06 16:17:30 but obviously /etc/config/network would be much more preferable Dec 06 16:17:44 in this case I'd probably still wait for at least "lo" to appear Dec 06 16:17:49 yeah Dec 06 16:20:12 blogic: pong Dec 06 16:20:16 how would you feel about making the ipip.sh netifd-proto script accept a mode param and attempt to apply the config? Dec 06 16:20:18 erm, protocol error Dec 06 16:20:21 blogic: ping Dec 06 16:20:33 not sure how useful sanity checking is going to be Dec 06 16:20:58 jwh: what would be the effect of the mode param? I recall that you wanted to add something to ipip sh but I forgot about the details Dec 06 16:21:03 yeah Dec 06 16:21:18 I wanted to make ipip generic, so it can handle any sort of ipip tunnel (v4 in v4, v6 in v4, etc) Dec 06 16:21:22 or v4 in v6 Dec 06 16:21:27 ah Dec 06 16:21:34 so a bit like ppp Dec 06 16:21:41 but the way the kernel implements it, they're all seperate kmods Dec 06 16:21:52 so either I split it, or make it optional Dec 06 16:22:12 in that if you don't have the relevant kmod installed, it just does nothing Dec 06 16:22:24 you can still offer dummy 6in4, 6to4 etc. packages which depend on ipip + kmod-whatever Dec 06 16:22:38 well 6in4 is already handled by another package Dec 06 16:22:55 ipip itself should probably depend on nothing and simply throw a netifd proto error if kernel side support is lacking Dec 06 16:23:00 I was going to try and roll them into one, since 6in4 is the same Dec 06 16:23:03 yeah thats what I was thinking Dec 06 16:23:25 I can just check for the module being loaded and bail if the correct one isn't loaded Dec 06 16:23:43 dedeckeh: thoughts? since you're the maintainer :D Dec 06 16:23:50 overall I like the idea of unifying all ip tunnel protocols Dec 06 16:23:55 yeah Dec 06 16:25:20 I was going to coerce 6in4 but it makes some assumptions Dec 06 16:25:43 hm, who bumped iproute2 recently? Dec 06 16:25:45 in my current case I just want a generic v4 in v6 tunnel but theres no existing support for that Dec 06 16:26:27 dedeckeh: ping Dec 06 16:31:03 hm, not sure whether to explicitly check for each kmod, or let iptunnel error Dec 06 16:31:24 or whatever the call is Dec 06 16:34:49 jow:pong Dec 06 16:35:20 dedeckeh: seems you bumped iproute2 recently. A user reported incompatibilities with our kernel Dec 06 16:35:46 https://forum.openwrt.org/t/strange-behavior-of-ip-rule/26597 Dec 06 16:36:34 will have a look Dec 06 16:37:42 hmph Dec 06 16:38:13 regarding the unifying of the ip tunnels how do you seen 6rd/ds-lite/map-t beinginified ? Dec 06 16:38:25 *being unified Dec 06 16:38:37 they have some level of autoconfig Dec 06 16:39:03 ds-lite and map are close enough to be unified, but at least the statically configured ones should be easy enough to unify Dec 06 16:39:04 yes but they have their own logic Dec 06 16:39:26 but honestly, right now, I just want generic ipip support Dec 06 16:39:27 heh Dec 06 16:39:44 would be a good starting point at least Dec 06 16:40:00 as presently there is no way to actually configure sane any-in-any ipip tunnels Dec 06 16:40:47 I think I'm doing something wrong with the config though, I can't get it to create a tunnel Dec 06 16:41:48 as in, with the existing ipip package Dec 06 16:42:44 proto, ipaddr, peeraddr should be enough, right? Dec 06 16:44:04 oh Dec 06 16:44:09 "code": "INVALID_PROTO" Dec 06 16:44:10 hm Dec 06 16:44:11 yes with your peeraddr being reachable by one of the existing route Dec 06 16:44:24 oh hm Dec 06 16:44:35 that may not be ideal, shouldn't really depend on anyting Dec 06 16:44:37 anything Dec 06 16:44:45 "proto": "none", Dec 06 16:44:58 that' the way how we do it for all tunnels Dec 06 16:44:58 that may be why then... Dec 06 16:45:26 you peeraddr must be reachable; no ? Dec 06 16:45:28 am I being a potato? I just have option proto 'ipip' Dec 06 16:45:36 it may not be when the interface is first configured Dec 06 16:45:46 IGP, BGP etc may be required Dec 06 16:45:58 or some other external package Dec 06 16:46:20 don't really want to block config if people are using 3rd party stuff Dec 06 16:47:33 because since the tunnels are stateless theres no dependency on the network even functioning Dec 06 16:48:30 however, I can't even figure out why it won't bring up a tunnel Dec 06 16:48:42 proto is none Dec 06 16:52:28 oh, am I totally misunderstanding what ipip.sh does Dec 06 16:52:31 I think I might be Dec 06 16:58:18 but either way, doesn't explain why it isn't setting this interface up Dec 06 16:59:21 unless its just failing in the same manner it does manually and thats translating to weird runtime config Dec 06 17:01:07 would probably help if busybox had 'tunnel' param Dec 06 17:02:31 guess it should depend on ip-full Dec 06 17:11:13 meh, ip6tunnel is still broken anyway Dec 06 17:11:28 root@fw1:~# ip -6 tunnel add name blah mode ipip6 Dec 06 17:11:28 add tunnel "ip6tnl0" failed: File exists Dec 06 17:12:58 lol, right so it throws that error if there are missing params, loving the consistency Dec 06 17:14:32 jow: so uh, should I use something other than 'proto_add_tunnel' for ip -6 ops? Dec 06 17:15:15 or will it figure it out... Dec 06 17:17:46 that would be a no, ok Dec 06 18:26:13 https://www.jool.mx/en/index.html Dec 06 18:26:14 hm Dec 06 18:26:20 * jwh adds to the list Dec 06 18:26:37 xback: I hope all is well with your kid! Dec 06 18:36:56 stintel: thanks :) just had some new from the wife that he already east more and plays again :-D Dec 06 18:37:14 eats* Dec 06 18:37:18 ah, good stuff! Dec 06 18:38:44 oh .86 already Dec 06 19:00:37 xback: going to test 4.14 on brcm2708, maybe also x86/64 Dec 06 19:01:03 xback: if you still have doubts about 4.9, may I ask to push the 4.14 bump already and maybe send a request for test mail to the ML for 4.9? Dec 06 19:02:04 there are still doubts about 4.9 Dec 06 19:02:38 I cherry-picked the bumps in my local master branch, rebased my brcm2707-4_14 branch on it, and as that is getting close to ready it would be nice if 4.14.86 is in master so I can (hopefully) soon also push 4.14 support for for brcm2708 Dec 06 19:02:49 stintel: 4.9 produces a build error on brcm2708 Dec 06 19:03:05 oh Dec 06 19:03:13 have a log about that perhaps ? Dec 06 19:03:17 the reason is the arm spectre stuff Dec 06 19:03:39 https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=blobdiff;f=target/linux/brcm2708/patches-4.9/950-0063-Improve-__copy_to_user-and-__copy_from_user-performa.patch;h=c1e5858bce9bbb2ee23ee00016fc58d8c4fb52b9;hp=016d48dd2c53dc3204fa75c1847e3f76b5938d2a;hb=c3cf02992305718ec5cdc25168313b85c0cbf0c2;hpb=3896e7f84b6e0ffe0bdecabdfb3ec86b9c1eaca9 Dec 06 19:03:59 xback: hmm, not seeing that on 4.14 Dec 06 19:04:39 I was thinking of just dropping the "improved copy" stuff in asm, and just follow upstream here Dec 06 19:04:40 xback: https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=blob;f=target/linux/brcm2708/patches-4.14/950-0061-Improve-__copy_to_user-and-__copy_from_user-performa.patch;h=115ad0c10c7d268e6b8bf852194c23ad1549152a;hb=9dd950d5bbb08ac9705cf8ead154c17e05354f58#l270 Dec 06 19:04:57 xback: I don't object Dec 06 19:05:03 otherwise I would need to adapt the ASM manually without any proper testing at my ends Dec 06 19:05:16 xback: if all goes well I'll ditch 4.9 support from brcm2708 soon anyway Dec 06 19:05:24 xback: well I could test it on 4.9 Dec 06 19:05:51 I've got 4 RPi Zero's and a 3B+ now Dec 06 19:06:19 this is the only thing holding the 4.9 bump back Dec 06 19:07:06 hold on, i'll start a build to show the error. will take 15 mins Dec 06 19:07:21 xback: let me have a look at it, if it's the same ASM code that has gone into 4.14, there is no reason for it to fail the build Dec 06 19:08:26 stintel: building .. Dec 06 19:10:03 gonna split 4,14 support for brcm2708 into a couple of patches meanwhile Dec 06 19:31:41 stintel: I recall it now Dec 06 19:31:55 there are 2 issues left open in 4.9 and brcm2708 Dec 06 19:32:24 1) There are changes in the ASM as mentioned before. This part compile fine, but I cannot validate it on correction functioning Dec 06 19:32:42 2) build error within the vfp module: https://pastebin.com/raw/GyewZgbY Dec 06 19:33:03 it's been a few days since actually building it .. Dec 06 22:07:46 anyone available? I need some dev feedback Dec 06 22:08:07 would like to know if/when the builds for the rPi 3 B+ will be fixed Dec 06 22:23:42 csrf: whats wrong with the rpi 3 b+ builds? Dec 06 22:26:00 jow: apparently, won't boot, but i'm working with stintel to try to figure something out Dec 06 22:37:02 build #1107 of ramips/rt3883 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/ramips%2Frt3883/builds/1107 Dec 06 23:51:32 jow: the @lt4.12 stuff doesn't seem to work for KCONFIG:= Dec 06 23:51:37 just tried it again Dec 07 00:16:07 ndb: do we have to use openwrt master to use mt76 master? Dec 07 00:16:45 menat nbd: Dec 07 00:27:28 biangbiangmian: testing will tell you sooner than waiting for europe to wake up Dec 07 00:32:42 build #1132 of archs38/generic is complete: Failure [failed targetupload] Build details are at http://phase1.builds.lede-project.org/builders/archs38%2Fgeneric/builds/1132 blamelist: Daniel F. Dickinson , Petr ?tetiar , Chuanhong Guo , David Bauer , Mathias Kresin Dec 07 00:32:43 , INAGAKI Hiroshi Dec 07 00:33:02 i had already tested, got blocked by some implicit function declaration warnings Dec 07 00:34:30 just want to know what the go is so i can decide if i can help, or if they have some plans already Dec 07 00:49:57 build #1141 of x86/geode is complete: Failure [failed targetupload] Build details are at http://phase1.builds.lede-project.org/builders/x86%2Fgeode/builds/1141 blamelist: Daniel F. Dickinson , Petr ?tetiar , Chuanhong Guo , David Bauer , Mathias Kresin , Dec 07 00:49:57 INAGAKI Hiroshi Dec 07 01:54:29 xback: compile-tested 4.14.86 on brcm2708/bcm27{08,09,10} and runtime-tested on brcm2708/bcm27{08,10} Dec 07 01:57:11 xback: about the ASM changes, I did it the same way for 4.14 and did not run into issues Dec 07 02:10:37 build #331 of ipq40xx/generic is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/ipq40xx%2Fgeneric/builds/331 Dec 07 02:53:18 can we do something about this: Source of feed has changed, replacing copy Dec 07 02:53:52 this is a great way of destroying work without a lot of warning **** ENDING LOGGING AT Fri Dec 07 03:00:01 2018