**** BEGIN LOGGING AT Mon Nov 26 02:59:59 2018 Nov 26 04:46:01 Hello my dudes Nov 26 05:15:34 wadup Nov 26 07:45:38 gch981213[w]: thanks. Nov 26 08:30:24 *tada& Nov 26 08:30:46 * blogic carefully opens patchwork Nov 26 08:36:25 * KevinDB decides it's too early for popcorn and goes for a bowl of porridge instead Nov 26 08:36:54 KevinDB: i had banana/chocolate porridge today Nov 26 08:37:22 hmmm, not sure about the chocolate Nov 26 08:37:24 low carb, high protein/nutrition 185kcal Nov 26 08:37:48 at lunch i'll have a lemon cupcake Nov 26 08:37:56 and for supper a mango curry soup Nov 26 08:38:07 followed by a evening snacl of a protein bar Nov 26 08:38:14 :-) Nov 26 08:38:30 * blogic cant wait till friday, next week i am back on buildup phase Nov 26 08:38:59 anyhow, 122 patches, you can tell that i was offline for a while, i wont even look at github Nov 26 08:39:11 :) Nov 26 08:39:24 yeah I bet - you'll waste away otherwise! Nov 26 08:40:26 some good patches Nov 26 08:46:33 russell--: ping Nov 26 08:47:06 russell--: https://patchwork.ozlabs.org/patch/1002785/ i did not follow v1/2 and there is no changes log below the tearline. looks fine to me, did you fix up all the comments from v2 ? Nov 26 09:01:12 russell--: https://patchwork.ozlabs.org/patch/998802/ please resend this, patchwork failed to pick up the V2 Nov 26 09:04:32 Hauke: tried calling your cell. let me know when you got a sec or just call back. i'd like to merge the cryptodev patch. there are 2 minor nitpicks that i'd cleanup enrouter Nov 26 09:04:37 *en-route Nov 26 10:06:09 rmilecki: https://patchwork.ozlabs.org/patch/980504/ ? Nov 26 10:13:46 KanjiMonster: those 4 63xx patches look legit, can i merge them ? Nov 26 10:14:49 blogic: please don't, these aren't the right way to fix them; I plan to tackle them today Nov 26 10:14:59 KanjiMonster: ok Nov 26 10:15:23 (especially the reset one; writing to random registers is a bit no-no) Nov 26 10:15:33 :P Nov 26 10:16:48 currently updateing the update_kernel.sh script to actually check for missing kernel config symbols again, after that the znc PR and my own PR for golang, then the brcm63xx stuff Nov 26 10:17:59 right, near 100 patches processed Nov 26 10:18:20 some one say something motivational to make me dive into github Nov 26 10:18:22 the update_kernel.sh script used to check for missing kernel config symbols, but that was broken ... in 2012, when we removed the oldconfig call from Kernel/Config/Default Nov 26 10:18:46 :-D Nov 26 10:19:05 I didn't expect my script to be that old Nov 26 10:37:48 Hi! Is there any relationship between spi chipselect and spi duplex mode on mt7621/mt7628? I am totally confused by this code: https://elixir.bootlin.com/linux/latest/source/drivers/staging/mt7621-spi/spi-mt7621.c#L394 Nov 26 10:39:48 certainly looks weird :) Nov 26 11:03:00 there is Nov 26 11:03:33 gch981213[w]: the spi block is really broken on mediatek Nov 26 11:03:46 gch981213[w]: what are you trying to do ? run a flash on the 2nd cs ? Nov 26 11:05:28 KanjiMonster: I think you will have issues with the OPTIMIZE_FOR_SIZE or something symbols Nov 26 11:09:33 Hi can any one tell me what the latest snapshot is pleas? Nov 26 11:09:57 is r8507? Nov 26 11:11:27 blogic: Yes. I'm trying to add a SPI NAND to mt7628. I've read the datasheet and I'm aware that the controller is really stupid but I still don't get the reason for this. Nov 26 11:11:45 blogic: erm, it'll only get worse if you don't? Not sure that's motivational enough ;-) Nov 26 11:12:20 stintel: I won't, because I'm checking the effective kernel config based on .config, not the kernel_*config Nov 26 11:12:45 gch981213[w]: add a devicetree property that allows us to set the duplex mode, keeping the defaults as given if the property is not specified Nov 26 11:14:51 blogic: isn't duplex mode a per-transfer attribute, like speed? I don't think it makes sense as device tree attribute Nov 26 11:14:52 hm. 500 Internal Server error at https://dev.archive.openwrt.org/changeset/46223/ Nov 26 11:15:30 KanjiMonster: the spi is really a sflash controller Nov 26 11:15:41 we abuse it as a spi controller Nov 26 11:16:08 KanjiMonster: i would even be fine with not supporting fullduplex as its silicon level broken for any spi mode than 0 Nov 26 11:16:28 gch981213[w]: could you check if we even use the CS1 in any of our DT files and if not just drop the code Nov 26 11:21:52 I know that the CS isn't designed to be controllable but it's controlled with a clever workaround. The upstream driver has already removed the length limit for half-duplex mode so I assume that the length limit could be solved similarly for full-duplex mode. Nov 26 11:22:12 blogic: alright I'll check that. Nov 26 11:23:05 gch981213[w]: i am happy to take patches Nov 26 11:23:28 and yes, the workaround is pretty ugly. i could not think of any better :-) Nov 26 11:24:20 gch981213[w]: let me also merge your PR with the update Nov 26 11:29:25 blogic: from looking at the mt7621 datasheet, I fail to see why cs0 and cs1 would need to be treated differently ... Nov 26 11:30:16 gch981213[w]: the ususal workaround for that is to mux the CSx pins as GPIO and let the subsystem take care of toggling them, and it seems mt7621 allows you to mux the CSx pins individually to gpio Nov 26 11:30:41 blogic: https://patchwork.ozlabs.org/patch/980504/ no nacks, it should be applied Nov 26 11:30:54 blogic: i'll push it later unless you have time to do that Nov 26 11:30:59 blogic: thanks for pinging me Nov 26 11:31:37 KanjiMonster: CS0 mux isn't individually controllable Nov 26 11:32:01 ah, right, misread Nov 26 11:33:10 blogic: i'm enjoing a fun of debugging x86 ;) Nov 26 11:33:11 KanjiMonster: because the HW is broken Nov 26 11:33:39 blogic: that's one of these cases where code comments are rally handy ;P Nov 26 11:33:42 *really Nov 26 11:33:52 but I guess there is a reason the driver is in staging/ Nov 26 11:34:02 KanjiMonster: it should not be Nov 26 11:34:53 KanjiMonster: i explained to upstream why i think it should not go their and had some redhat folks tell me i am an enemy of foss if i dare question their decisions Nov 26 11:35:10 so i thought bollocks to that and now we have 3 drivers all broken and no one working on them Nov 26 11:35:23 anyhow Nov 26 12:23:06 blogic: thanks for taking care of the patchwork Nov 26 12:38:58 if luci won't display the RAM consumption graph, where would I start to troubleshoot this? This is on OpenWrt SNAPSHOT r8466-251c350727 / LuCI Master (git-18.329.25235-26e903c) Nov 26 12:44:55 blogic: re https://patchwork.ozlabs.org/patch/1002785/ i'm a moron, there was no v2, and yes, i fixed the two comments (add a license and add a compatibility string to the firmware partition). Nov 26 12:45:30 and, i'll resend https://patchwork.ozlabs.org/patch/998802/ Nov 26 12:59:08 blogic: the ath79 patch for ubiquiti airrouter is re-sent: https://patchwork.ozlabs.org/patch/1003237/ Nov 26 13:31:18 blogic: We have several mt76x8 modules registering spidev on cs1 and we got RBM33G registering a SPI flash there! Please revert my backport if you haven't push it because it breaks RBM33G since the upstream driver has the full-duplex hack enabled for MT7621... Nov 26 13:44:10 gch981213[w]: reverted ! Nov 26 14:04:26 blogic: Could you briefly explain the reason for that code? The only thing I'm aware now is that half-duplex code treat all full-duplex message as a rx-only message and this isn't CS related. I'll do the rework to treat half/full-duplex SPI message correctly if there isn't hardware-related reason for this. Nov 26 14:31:59 what is responsible for triggering "block" hotplug.d events? Nov 26 14:32:07 blogic: ? Nov 26 14:34:01 are they triggered by procd parsing hotplug.json and its [ "exec", "/sbin/hotplug-call", "UBSYSTEM%" ] Nov 26 14:46:17 oh crap, fstools/block is a headache Nov 26 14:47:05 so many calls, different commands, block and blockd interacting over and over Nov 26 14:50:05 BTW the current full-duplex code treats only full-duplex message correctly. It's broken on tx-only messages because it updates m->actual_length according to rx_len but rx_len is 0 on tx only messages. Nov 26 15:38:21 <_lore_> blogic: is there any plan to update ramips target to 4.19 lts? Nov 26 15:40:24 _lore_: the plan is to update all targets to 4.19 for the next next release (where feasable) Nov 26 15:40:49 <_lore_> KanjiMonster: thx for the info Nov 26 15:41:20 but first there will be release with everything 4.14. release after that will be 4.19 Nov 26 15:41:28 <_lore_> is there already a release period? sorry I am not up-to-date :) **** ENDING LOGGING AT Mon Nov 26 15:48:38 2018 **** BEGIN LOGGING AT Mon Nov 26 15:50:09 2018 Nov 26 16:01:36 jow: Nov 26 16:01:38 oops Nov 26 16:20:10 _lore_: early next year i believe Nov 26 16:24:28 <_lore_> mangix: ack, thx Nov 26 16:25:53 _lore_: to clarify, next release would be 19.01 and would use 4.14 Nov 26 16:26:56 <_lore_> stintel: thx for the clarification, I would like to carry out some bpf experiments with my home router but I would need a > 4.15 kernel Nov 26 16:32:07 _lore_: https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/kernel-4.19 Nov 26 16:41:17 <_lore_> stintel: thx for the info, but I would need ramips target Nov 26 16:42:28 well, you can always try bumping that to 4.19 starting from hauke's branch Nov 26 16:47:21 <_lore_> ack, will do Nov 26 16:56:31 hi everybody Nov 26 16:56:42 one quick question: Nov 26 16:57:27 mt7621 nand driver can be reused for mt7620, or should i apply patches for 7620 nand (found these out on various tree) Nov 26 16:57:30 ? Nov 26 17:00:15 gch981213[w]: so basically i made cs1 work for MTK/labs when i built the linkit smart for them. the req-sheet said that cs1 should be proper duplex spi. however .... Nov 26 17:00:34 1) the core will always send 1 byte before any transfer, this is the m25p80 command. Nov 26 17:00:49 2) mode 3 is broken and bit reversed (?) Nov 26 17:01:01 3) some bit are incorrectly wired in hw for mode2/3 Nov 26 17:01:50 we wrote a test script and test for [0-0xffff] on all modes and certain bits are swizzled under certain conditions and it was not possible to fix this even using a hack. Nov 26 17:02:06 we then decided to use spi-gpio and i never removed the errornous code Nov 26 17:02:38 basically the spi is fecked for anything but half duplex spi mode0 running a sflash on it Nov 26 17:02:44 psyborg: It can't be reused on mt7620. I remember that MT7620/MT7621 at least has different ECC algorithm. Nov 26 17:03:06 gch981213[w]: correct Nov 26 17:03:38 although i can only see half of the conversation ;P Nov 26 17:03:55 rmilecki: yes Nov 26 17:04:08 some events are sw generated such as iface ones Nov 26 17:04:20 the rest is triggered either via cold or hotplug Nov 26 17:04:38 in the case of block events this is the kernel block subsystem spewing them out Nov 26 17:05:03 rmilecki: blockd is option and adds state. what exactly is the problem ? Nov 26 17:05:23 _lore_: yes, i have been head under with reallife and work Nov 26 17:06:02 _lore_: ath79 and ramips have seen plenty of patches go upstream so i figured to wait till v4.19 until it all got merged and can treacle down to avoid duplicating my work Nov 26 17:06:31 ok thanks for info Nov 26 17:10:12 oh one more thing: when browsed mt7620.dtsi in this tree: https://gl.tossp.com:1443/zh/lede-k3/commit/b52215c8db7e5dc0220a349044eef15ba644b6c8#954754a3e2040cb4baadee7f2e73203340c6398f Nov 26 17:10:18 whoo Nov 26 17:10:23 lots of commits today Nov 26 17:10:36 i dont see nand addresses included in, i suppose this is required? Nov 26 17:11:17 <_lore_> blogic: ack, thx Nov 26 17:11:32 blogic: It's impressive that they managed to screw it up that badly. Nov 26 17:11:55 blogic: That's terrible :( I'll fix the full-duplex function and add a DT option to keep the behavior as-is. And I should probably drop the support for mode 1/2/3 right? Nov 26 17:12:22 where do you look mangix? To know the latest commits? I tried https://git.openwrt.org/ but did not see anything Nov 26 17:15:15 Neighbor11111111: github Nov 26 17:22:10 blogic: Or I should just drop the entire full-duplex mode because it's just broken due to the extra 1 byte sent? All the devices uses spi cs1 for an spidev except RBM33G which uses it as SPI flash. Nov 26 17:23:38 Thanks mangix Nov 26 17:37:25 Monkeh: never verified i guess. they tested half duplex mode1 on an m25p80 prior to tape-out and were happy Nov 26 17:37:41 i was likly the first person ever to hit any of the other registers ever Nov 26 17:38:50 gch981213[w]: imho any support other than mode1 half duplex should be dropped and a comment added stating that this is a sflash core disguised as an SPI and should not be used for any other purpose due to bit swizzle issues that are caused by incorrectly wored HW that cannot be worked around Nov 26 17:39:01 actually it was not bit swizzle but duplication Nov 26 17:39:11 some bits were not wired while others were double wired Nov 26 17:41:58 blogic: Such is the price of cheap chips Nov 26 17:42:07 Monkeh: indeed Nov 26 17:42:21 honestly they are pretty cool though if used within the defined specs Nov 26 17:42:30 i'd use mtk over qca any day Nov 26 17:42:43 blogic: While I've got you, any input on the mystery pin remapping: https://github.com/openwrt/openwrt/pull/1500 Nov 26 17:43:05 ah thats the scfg register ? Nov 26 17:43:13 blogic: Eh, the 7628 is souring me on the whole experience, at least the QCA parts have reliable wifi. :P Nov 26 17:43:14 nudge me tomorrow i am about ot go and do family foo Nov 26 17:43:37 i have the 7628 datasheet so i can look up the register tomorrow Nov 26 17:43:39 blogic: I don't know what register it is - there's a couple undocumented ones being hit by example code, but I can't make heads or tails of it Nov 26 17:43:46 The datasheets I have make no mention of them Nov 26 17:44:00 ok, then i'll mail the PM at mtk we are good buddies Nov 26 17:44:10 If you have _actual_ datasheets, that'd be cool :) Nov 26 17:44:14 nudge me tomorrow and we'll get it sorte Nov 26 17:44:16 +d Nov 26 17:44:20 Will do Nov 26 17:44:29 the mtk datasheets can be a bit wonky at times Nov 26 17:44:32 coolio Nov 26 17:44:34 A bit? Nov 26 17:44:50 The main problem is half of them is missing :P Nov 26 17:46:11 blogic: Thanks for the info :D Nov 26 18:29:52 Monkeh: i think it was 3x2 bits Nov 26 18:29:58 gch981213[w]: sure Nov 26 18:35:12 jow ping Nov 26 18:58:10 blogic: ping Nov 26 18:59:06 blogic: I didn't noticed your number, you can call me if you are still awake Nov 26 19:21:25 Hauke, thanks for feedback on the rtl8812au patch...in case you are excited to get this in faster, you can grab it from here and remove the MYARCH stuff and the commented line that used MYARCH and is not needed. I'm swamped with catchup from the holidays, so will be a while before I get a chance to respin the patch. Nov 26 19:21:42 https://github.com/greearb/openwrt-ct/commits/master Nov 26 19:37:42 cc1: error: unrecognized command line option '-Wno-unknown-warning-option' [-Werror] Nov 26 19:38:00 while building netifd-2018-11-26-dfa4ede4 Nov 26 19:40:24 main error is: if_ether.h:153:8: error: redefinition of 'struct ethhdr' https://paste.debian.net/1053316/ Nov 26 20:03:42 Hauke: gimme a sec Nov 26 20:03:59 rmilecki: so this denx,image thing, can we fix this globally in the tree ? Nov 26 20:04:30 Rene__: you are using an old gcc Nov 26 20:04:41 gcc had a few funky features added recently Nov 26 20:04:45 blogic: if you're patient enough to track all devices that use DTS and standard uimage - yes Nov 26 20:05:04 nope, currently using latest ubuntu Nov 26 20:05:17 well an advance sed/awk for "firmware" | *.dts should be fine or not ? Nov 26 20:05:58 rmilecki: -> /pm Nov 26 20:06:10 blogic: OpenWrt tries multiple parsers when it sees "firmware" Nov 26 20:06:11 specifying "denx,uimage" will trigger only a specific one Nov 26 20:06:22 blogic: modified the header file was enough. Nov 26 20:06:52 rmilecki: i see Nov 26 20:07:10 Rene__: still looks wonky Nov 26 20:11:15 yet an other error :( https://paste.debian.net/1053317/ Nov 26 20:12:07 KanjiMonster: MAIL Nov 26 20:12:12 nbd: Mail Nov 26 20:12:22 Hauke: mail Nov 26 20:12:26 jow: mail Nov 26 20:12:43 stintel: mail Nov 26 20:12:54 nay f'in jokes, this is real life Nov 26 20:13:21 ldir: you did well padawan Nov 26 20:18:52 an accident of time and place Nov 26 20:21:07 ldir: tanks Nov 26 20:21:27 *thnaks Nov 26 20:21:30 blogic: oh lordy who are you invading now? :-) Nov 26 20:25:34 ldir i just BCC'es a far bigger crowd Nov 26 20:36:26 greearb_: does the realtek driver work? Nov 26 20:37:02 I tried some driver once, but OpenWRt removes all the virtual interfaces in the beginning and the driver does not supported adding new Nov 26 20:41:16 Hauke, works in STA mode at least, performs fairly nicely. I hacked the driver a bit to work better and to compile against openwrt Nov 26 20:41:27 thus the makefile references my git repo Nov 26 20:42:03 I had it plugged into my Netgear r7800 running my openwrt repo Nov 26 20:42:45 someone else reported it worked too, but not sure how they were using it. Nov 26 20:45:25 greearb_: there are probably 50 different realtek wifi chips around all with their own driver, probably I used something else Nov 26 20:45:44 dedeckeh: jow - I had a look through the dropbear bump PR and reduced it down to a much smaller number of commits keeping much closer to the release code. https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=shortlog;h=refs/heads/bumpdb It seems to compile & run ok for me. Nov 26 20:48:35 Whether this is actually more secure than the original full PR is a matter of conjecture. I didn't look through ALL of the backported commits but those that I did double/triple check I could find in upstream dropbear's master. Nov 26 20:50:01 As I've said a few times, this would be so much simpler if Matt just did a new release. Nov 26 20:51:08 why isn't he doing that? Nov 26 20:52:36 blogic: valgrind does not compile for me with lto activated Nov 26 20:52:50 on mips32_24kc Nov 26 20:53:08 hi, to remove patch from patchwork, is changing state to `Not Applicable` enough? Nov 26 20:54:26 Borromini: I cannot speak for Matt. Nov 26 21:32:42 Hauke: sure i'll check buildbots tommorow Nov 26 21:33:08 so we hd 400+ pending today 300+ now Nov 26 21:33:28 i was merging at best effort and will fix backlash Nov 26 21:33:45 ynezz: link ? Nov 26 21:33:45 blogic: please revert commits I mentioned here: https://patchwork.ozlabs.org/cover/1000625/#2037720, they are breaking sysupgrade, I'll try to come up with proper transition. Nov 26 21:34:09 ynezz: +thanks for your work, its noted Nov 26 21:34:30 tmn505: let me check Nov 26 21:35:11 blogic: thanks for merging the stuff Nov 26 21:35:17 tmn505: hi Tomasz name-> nick matchingis hard :-) Nov 26 21:36:02 tmn505: should i revrt the whoke series or just part of it ? Nov 26 21:36:27 only the part i mentioned Nov 26 21:36:51 the rest could be useful Nov 26 22:23:35 tmn505: hey, nice you see your contributions :) Nov 26 22:37:59 hello Nov 26 22:39:04 i'm currently using OpenWRT as a base for a low volume project, i've been flashing openwrt using the standard mfg upgrade process and then scp-ing over some packages and config files, and installing with opkg via ssh Nov 26 22:39:31 unfortunately this takes a lot of time per device and i'm trying to speed things up Nov 26 22:40:39 i'm hoping to build a *.bin file that includes all of my modifications and packages so that I can condense the install process to a single step Nov 26 22:40:57 (essentially i'm hoping to build a custom flavor of OpenWRT) Nov 26 22:42:21 if anyone can point me in the right direction for that, i've googled a bit but haven't really found a good starting point for understanding and replicating the process of going from the source to a built copy of OpenWRT in a *.bin Nov 26 22:42:43 if i could build an existing copy of OpenWRT for my device that would be grand Nov 26 22:43:58 https://oldwiki.archive.openwrt.org/doc/howto/build <-- somehow i missed this earlier, i think i'm on the right path now, however any help would be appreciated none the less Nov 26 22:45:20 you're probably looking for https://openwrt.org/docs/guide-user/additional-software/imagebuilder Nov 26 22:59:19 blogic: https://patchwork.ozlabs.org/patch/1002230/ Nov 27 00:00:46 hmph Nov 27 00:03:42 so does netifd handle 6in4 directly? Nov 27 00:05:26 oh no... ok so why are 6in4 and ipip seperate packages? Nov 27 00:10:05 for 6in4, as in he.net, you just need the 6in4 package Nov 27 00:11:18 yeah I'm just wondering why they're seperate Nov 27 00:11:30 since 6in4 is just ipip Nov 27 00:17:42 jwh: looks different than ipip to me, based on package dependencies Nov 27 00:18:27 6in4: DEPENDS:=@IPV6 +kmod-sit +uclient-fetch Nov 27 00:18:51 ipip: DEPENDS:= +kmod-ipip +resolveip Nov 27 00:18:52 hm, how big are the modules Nov 27 00:19:14 I mean, I'm not sure why they're even seperate kmods anyway Nov 27 00:19:32 6in4 provides a bunch of configuration structure Nov 27 00:19:40 ipip is supposed to be inner/outer af agnostic Nov 27 00:19:42 -rw-r--r-- 1 root root 23336 Nov 17 15:27 /lib/modules/4.14.81/sit.ko Nov 27 00:20:08 on ARMv7 Nov 27 00:20:21 hm Nov 27 00:20:30 talk about duplicated code Nov 27 00:20:31 heh Nov 27 00:21:57 so what does sit.ko do differently to ipip.ko? Nov 27 00:22:30 or is it entirely just that whoever wrote ipip support didn't do it like every other OS? :D Nov 27 00:22:44 I still want to re-establish my he.net tunnel ('thanks' to dynamic prefixes from my ISP's native IPv6 connectivity), but so far I haven't really gotten the routing right with both being active (use native IPv6 for outgoing connections, unless explicitly bound to a he.net address, allow incoming connections via he.net) Nov 27 00:23:14 oh hat sounds like fun Nov 27 00:23:16 that* Nov 27 00:23:45 maybe ip rules? or better yet l3mdev? Nov 27 00:24:00 unfortunately IPv6 doesn't care about interface metrics, but goes for the longest match first (so basically always), which means a considerable amount of traffic would go via he.net Nov 27 00:24:27 it doesn't get better by me 'insisting' on dynamic client configurations ;) Nov 27 00:24:32 heh Nov 27 00:24:55 well, dynamic ISP prefixes basically force me to do that anyways Nov 27 00:25:40 but I've had to renumber my LAN often enough (overlapping subnets with mobile ISPs and or VPNs involved) that I really want dhcp/ dhcpv6 (or SLAAC) everywhere Nov 27 00:25:56 you know what, it would be really nice if all this tunnel support didn't add an inerface by defaul Nov 27 00:25:59 t Nov 27 00:26:16 end up with 5 or 6 pseudo interfaces that don't do anything Nov 27 00:27:19 somehow I don't think an implementation without virtual interfaces for the tunnel endpoints would make it considerably easier Nov 27 00:27:39 well I mean, ok for example Nov 27 00:27:51 loading ipip.ko creates 'tunl0' on load Nov 27 00:28:04 even if you never intend to use it Nov 27 00:28:21 it's like an extra limb Nov 27 00:28:22 lol Nov 27 00:28:31 net/ipv4/ipip.c vs net/ipv6/sit.c Nov 27 00:28:35 gre does the same Nov 27 00:28:57 russell--: yeah thats silly tbh, ipip is AF agnostic, thats the point... should really be the same support Nov 27 00:30:51 especially seems ipip actually seems to work just fine Nov 27 00:31:37 well, my desktop has 3 wired ethernet interfaces, one wlan card, 8 tap interfaces on top of the LAN bridge, 4 on top of the jail bridge, two on top of the temp bridge, plus a USB ethernet card connecting to an old ISDN pbx - the number of interfaces doesn't really bother me Nov 27 00:31:43 diff -u net/ipv4/ip_gre.c net/ipv6/sit.c | less Nov 27 00:32:02 gre isn't ipip :P Nov 27 00:32:11 thats a whole different horrible beast Nov 27 00:34:08 just seems kinda silly having different kernel modules for exactly the same thing heh Nov 27 00:34:14 jwh: "This version of net/ipv6/sit.c is cloned of net/ipv4/ip_gre.c" Nov 27 00:34:27 * russell-- suggests taking it up with linux-net people Nov 27 00:34:27 uhhh Nov 27 00:34:35 thats even more special Nov 27 00:39:57 hm, don't have ipip in my images, bleh Nov 27 00:45:21 ugh, need ip6_tunnel anyway, what a mess Nov 27 00:45:37 jwh: "IPIP kind of tunnels is the simplest one. It has the lowest overhead, but can incapsulate only IPv4 unicast traffic," https://wiki.linuxfoundation.org/networking/tunneling Nov 27 00:45:53 that is entirely a lie Nov 27 00:46:05 it's a wiki Nov 27 00:46:26 it should clarify that the *linux* support is limited Nov 27 00:47:38 so the reailty is you may need one of 4 modules depending on which AF you use for inner and outer Nov 27 00:47:39 well, this is linux. not clear what your critique is here. Nov 27 00:47:43 lol Nov 27 00:47:53 I'm all for modularity but thats a bit excessive Nov 27 00:48:24 please take it up with linux-net Nov 27 00:48:44 yeah theres no way I'm walking into that ring heh Nov 27 00:49:02 I've seen enough threads to know that reason doesn't stand up there Nov 27 00:49:54 you can, of course, fork jwhinux Nov 27 00:50:04 ha Nov 27 00:50:27 I can see why they've seperated it, but it's still kinda bizarre Nov 27 00:50:38 legacy that never got refactored I guess Nov 27 00:54:25 [root@pyxis ~]# ip -6 tun add test mode ipip6 Nov 27 00:54:25 add tunnel "ip6tnl0" failed: File exists Nov 27 00:54:27 hm **** ENDING LOGGING AT Tue Nov 27 03:00:01 2018