**** BEGIN LOGGING AT Fri Jan 25 02:59:58 2019 Jan 25 08:08:12 xback: about that sdhci build error Jan 25 08:08:40 xback: I think the current kernel 4.14 branch lacks this commit: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/mmc/host/Kconfig?id=99d570da309813f67e9c741edeff55bafc6c1d5e Jan 25 08:08:52 looks like that should have been backported Jan 25 08:11:56 at least drivers/mmc/host/sdhci-msm.c in linux-4.14.y sets .write_w = sdhci_msm_write_w; (with .write_w being protected by #ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS) without selecting MMC_SDHCI_IO_ACCESSORS in the Kconfig "config MMC_SDHCI_MSM" entry Jan 25 08:55:27 mangix: Jan 25 08:55:45 in your aria2 patch refresh you dropped the patch header etc. was that intentional? Jan 25 08:55:56 lynxis: ping Jan 25 09:02:00 jow: good morning Jan 25 09:02:06 thank you for the quick fix Jan 25 09:02:26 looking at the patch. it's dated from 2017 which means upstream is still wrong here? Jan 25 09:02:57 I simulated the issues yesterday and notified the patch author and the mmc mailinglist Jan 25 09:03:57 I think it's not good practice to make a struct member optional in the definition in the header, but not adding code to make the assignment also optional Jan 25 09:05:13 next to that, checking kernel_menuconfig shows that this option was not selectable for that target as it lacked other specific dependencies Jan 25 09:06:46 xback: I think its an upstream mistake Jan 25 09:07:04 ps. apologies for the breakage, it's nearly impossible to compile-test every possible target on my local hardware :) Jan 25 09:07:09 xback: it seems they forgot to pick the Kconfig update when backporting the driver code setting write_w Jan 25 09:07:27 no need to apologize, your failure rate is well below what used to be the norm Jan 25 09:09:42 jow: just got a reply back from the patch author. I forwarded it to you fyi Jan 25 09:10:03 xback: so its essentially what I did, good to know Jan 25 09:12:27 excellent. thanks again jow :) really appreciate your fast interventions! Jan 25 09:32:05 jow: was lazy. it's back now Jan 25 09:43:40 nbd, why won't 6in4 wan6 connection status on the Staus --> Overview page show the actual (configured) IPv6 address instead of '::'? - https://imgur.com/a/SnXMRyr Jan 25 09:45:06 Strykar: "::" is the gateway Jan 25 09:46:09 which is also correct, a 6in4 tunnel typically specifies no specific default gw ip, just the interface Jan 25 09:48:50 jow, oh I assumed the client was always set as 2001:470:1f06:8df::2 and the server ipv6 of 2001:470:1f06:8df::1 was the gateway. but I see your point, it's not native ipv6 Jan 25 10:17:18 jow, are odhcpd-ipv6only dhcpv6 leases not shown on the Status-Overview page? will dnsmasq-full display dhcpv6 leases on Overview? Jan 25 10:18:07 they're shown for me Jan 25 10:18:45 maybe your hosts do not actually do dhcpv6 but stateless autoconf, such things are not shown since the router is not aware of them Jan 25 11:55:50 jow, hmm weird... all clients in the LAN receive IPv6 addresses and ipv6 works, but they don't show up on the Overview page or in the leasefile - https://paste.ubuntu.com/p/D4JmhJtwFv/ Jan 25 11:56:33 Strykar: android devices don't ask for DHCPv6 based address, so they won't show up there. Jan 25 12:05:45 SwedeMike, the LAN has linux notebooks, desktops and ubnt APs, all of which have ipv6 from the router Jan 25 12:06:19 Strykar: yeah but what kind of ipv6, stateless or stateful? Jan 25 12:06:50 if the ipv6 addresses contain ...ff:fe.... then they're not assigned by DHCPv6 Jan 25 12:06:59 most likely not that is Jan 25 12:08:07 Strykar: look in interfaces->edit the interface, go into dhcp server -> ipv6 settings and check what the dhcpv6 mode is. If it's stateless, then you won't see any clients because there is no DHCPv6 addresses handed out. Jan 25 12:11:41 SwedeMike, both dhcpv6 and ra are set to server - https://paste.ubuntu.com/p/YWYtvB89h3/ Jan 25 12:11:50 jow it's a link-global address Jan 25 12:12:28 dhcpv6 mode is set to stateless+stateful, perhaps that needs changing to just stateless? Jan 25 12:12:41 right, so ra-management = 1 should mean clients should ask for dhcpv6 IA_NA Jan 25 12:12:42 Strykar: the ipv6 in the paste is not a dhcpv6 address Jan 25 12:13:33 Strykar: tcpdump -vvv port 546 and 547 on br-lan and pastebin the output from a client connecting Jan 25 12:13:57 "tcpdump -vvv -i br-lan port 546 or port 547" Jan 25 12:14:19 jow, er, inet6 2001:470:8c1f:0:c225:e9ff:fe18:833b/64 isn't? Jan 25 12:15:01 Strykar: no, that's an EUI64 address that the client assigned itself. Jan 25 12:18:51 crap these have 8 day lease, lemme clean the lease file Jan 25 12:22:47 SwedeMike, hmm, it receives an up but tcpdumb shows no traffic Jan 25 12:22:50 IP Jan 25 12:23:19 Strykar: ok, if you have a linux box on your lan, install ndisc6 and run "rdisc6 " and pastebin the output Jan 25 12:26:30 SwedeMike, https://paste.ubuntu.com/p/Ncjcb7cJnQ/ Jan 25 12:26:45 Strykar: "rdisc6 " Jan 25 12:26:57 good lord, srt Jan 25 12:26:59 sorry Jan 25 12:28:13 SwedeMike, https://paste.ubuntu.com/p/pYCm8BSKk2/ Jan 25 12:28:47 Strykar: ok, "Stateful address conf. : Yes" tells devices to ask for DHCPv6 IA_NA, so I don't know why that isn't happening. Jan 25 12:29:34 you should be seeing 546/547 traffic when devices connect to this LAN. Jan 25 12:30:45 SwedeMike, Im going to try changing dhcpv6 mode to stateful instead of stateless+stateful. should I change RA service mode from server, to say hybrid? Jan 25 12:31:20 Strykar: no, keep it in server. Jan 25 12:31:40 the RA service seems to work correctly. Jan 25 12:38:54 SwedeMike, welp, changing dhcpv6 to stateful only doesnt fix it Jan 25 12:40:22 reading https://github.com/openwrt/luci/issues/2147 I thought it was dnsmasq that was showing the leases on the Overview page and not odhcpd-ipv6only Jan 25 12:41:25 SwedeMike, the clients with an EUI64 address have ipv6 connectivity, is that expected? Jan 25 12:42:24 yes Jan 25 12:46:29 SwedeMike, jow, found it! both the linux clients boot to their DE, and network manager's IPv6 configuration was set to Disable. changing it to Auto or DHCPv6 works Jan 25 12:46:32 thank you Jan 25 12:47:11 Network Mangler Jan 25 12:47:38 yup, so much fun adding another layer to peel through Jan 25 12:50:06 * Strykar makes a note of Android's not requesting DHCPv6 Jan 25 12:50:15 thank you Google engineer Lorenzo Colitti - https://www.techrepublic.com/article/androids-lack-of-dhcpv6-support-frustrates-enterprise-network-admins/ Jan 25 12:51:07 Strykar: he has good reasons, and I agree with him. Jan 25 12:56:38 SwedeMike, I get the notion that DHCPv6 on cellular networks, but wifi too? hm, he's also the lead author of RFC 7934 Jan 25 13:17:17 Strykar: yes, the rationale for the refusal to do IA_NA is to achieve RFC 7934 goals. Jan 25 14:54:43 Some one has just told me that there will be no more updates to the mwlwifi driver. I hope they are rong. Jan 25 14:56:00 The opensourse one anyway. Jan 25 15:13:14 <\x> hey guys Jan 25 15:13:25 <\x> why is /dev/zram0 is mounted as /tmp Jan 25 15:13:29 <\x> not tmpfs? Jan 25 15:36:18 type tmpfs, not the mount point. Jan 25 15:52:05 <\x> karlp: https://termbin.com/4m7l Jan 25 15:52:21 <\x> how do i grow /tmp then Jan 25 15:52:31 <\x> i tried those things on the wiki it doesnt work Jan 25 15:52:47 <\x> sysupgrade on me fails because of this Jan 25 15:53:13 <\x> i have 32M flash and i cant even fit a 16MB+ image Jan 25 15:57:11 how much ram? Jan 25 15:57:17 <\x> 512MB Jan 25 15:57:24 hm Jan 25 15:57:44 <\x> its because of that limited /tmp Jan 25 15:57:55 <\x> idk why it mounts like that Jan 25 15:58:26 <\x> https://termbin.com/yh5x Jan 25 15:58:30 none of mine have zram, you could just disable it Jan 25 15:58:38 default tmpfs seems to do the right thing Jan 25 15:58:56 ooooor Jan 25 15:59:05 <\x> i tried removing zram-swap and kmod-zram Jan 25 15:59:06 just mount a larger tmpfs ontop of /tmp to upgrade? Jan 25 15:59:08 <\x> same thing happens Jan 25 16:05:06 <\x> same thing jwh Jan 25 16:05:18 <\x> i removed zram-swap and kmod zram Jan 25 16:05:23 <\x> same thing happened. Jan 25 16:06:13 weird Jan 25 16:06:22 <\x> https://termbin.com/cp52 Jan 25 16:06:43 <\x> OpenWrt SNAPSHOT, r9131-5bac623895 Jan 25 16:07:08 thats not /tmp Jan 25 16:07:37 <\x> tmp should be tmpfs Jan 25 16:07:43 <\x> i dont have anything on my fstab Jan 25 16:08:00 you didn't mount larger tmpfs on /tmp Jan 25 16:08:02 <\x> that will eff it up Jan 25 16:08:06 /tmp/shm isn't the same thing Jan 25 16:08:15 yes it will, but it should let you upgrade Jan 25 16:08:16 <\x> yeah i know Jan 25 16:08:23 <\x> but why does it do this Jan 25 16:08:33 fyi, defaults on my 512M box: tmpfs 196.5M 652.0K 195.8M 0% /tmp Jan 25 16:08:39 so something is wrong, probably zram Jan 25 16:08:58 <\x> are you on snapshots? Jan 25 16:09:03 ye Jan 25 16:09:20 probably a couple of weeks ago now, but I don't imagine its changed Jan 25 16:10:00 <\x> >The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform. Select 'Force upgrade' to flash the image even if the image format check fails. Use only if you are sure that the firmware is correct and meant for your device! Jan 25 16:10:02 <\x> yep Jan 25 16:10:05 <\x> this happens again Jan 25 16:10:18 <\x> ¯\_(ツ)_/¯ Jan 25 16:10:29 <\x> i guess ill just use breed Jan 25 16:10:52 <\x> file format check fails cuz it wont fit Jan 25 16:11:17 <\x> https://forum.openwrt.org/t/no-space-left-in-tmp/11000/5 Jan 25 16:11:23 <\x> looks like its the same as this Jan 25 16:12:04 <\x> ah shit Jan 25 16:12:06 <\x> dead link Jan 25 17:08:05 blocktrron, did it work? Jan 25 17:09:21 <\x> solved it jwh Jan 25 17:09:29 what was it? Jan 25 17:09:33 <\x> it happens when you have kmo-zram built in Jan 25 17:09:36 <\x> kmod* Jan 25 17:09:39 yeah Jan 25 17:09:44 I expected something lik that Jan 25 17:09:45 like* Jan 25 17:10:13 so whats the actual fix for it? Jan 25 17:10:37 <\x> $ cat .config | grep zram Jan 25 17:10:37 <\x> # CONFIG_PACKAGE_zram-swap is not set Jan 25 17:10:37 <\x> # CONFIG_PACKAGE_kmod-zram is not set Jan 25 17:10:40 <\x> thats the fix. Jan 25 17:10:42 <\x> lmao Jan 25 17:10:58 <\x> tho i think its because the zram script gets executed twice? Jan 25 17:10:59 fix for the problem, not a workaround :P Jan 25 17:11:14 <\x> if you have one on the /rom Jan 25 17:11:20 ah hm Jan 25 17:11:40 is there even enough of a benefit to using zram? Jan 25 17:11:47 or zswap or whatever it uses Jan 25 17:11:57 <\x> its like this Jan 25 17:12:14 <\x> no zram or swap > zram > swap Jan 25 17:12:27 lol Jan 25 17:12:49 <\x> well performance wise yeah Jan 25 17:12:57 <\x> well i had to use zram on my older router Jan 25 17:13:03 I always felt like it was a hack, and proper in-memory page compression would be fine Jan 25 17:13:14 <\x> i just edited the targets and rebui;t lol Jan 25 17:13:39 zswap is one step away from doublespace :D Jan 25 17:32:32 memstacker Jan 25 17:33:08 superstor Jan 25 17:33:51 lol Jan 25 17:34:39 https://en.wikipedia.org/wiki/Stac_Electronics there were a bunch of others too Jan 25 17:34:49 I remember my father trying them allout :) Jan 25 17:34:50 did you know that you can conserve lots of space by turning structs into unions? Jan 25 17:34:56 <\x> https://pomf.pyonpyon.moe/uxylny.png Jan 25 17:35:02 <\x> breed saved me Jan 25 17:35:10 QEMM! that's the one Jan 25 17:35:17 <\x> lets hope theres no backdoors in it Jan 25 18:01:54 lach1012: not at home atm. gonna test it later or tomorrow Jan 25 18:03:02 blocktrron, k. Jan 25 18:22:21 jow: pong Jan 25 19:01:51 lach1012: just tested it: fixed the crashing on the 4040 and 7530 Jan 25 19:03:39 blocktrron, k Jan 25 19:04:11 I pushed the patch to the uboot-fritz4040 repo Jan 25 19:04:42 and I have a patch for 18.06 too Jan 25 19:05:17 I only tested it thru running ping and tftpboot on both boxes Jan 25 19:05:51 Did not try if it broke something else, although i think this is not very likely Jan 25 19:06:43 Shouldn't it be enough to just bump the package? Jan 25 19:06:55 for openwrt-18.06? Jan 25 19:07:00 yup Jan 25 19:07:37 probably, but it's just this patch Jan 25 19:07:47 I changed some other stuff Jan 25 19:08:30 fair point Jan 25 19:09:05 anyway, thanks for getting this fixed :) Jan 25 19:09:16 thank you for reporting it ;) Jan 25 19:22:42 build #1175 of ipq806x/generic is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/ipq806x%2Fgeneric/builds/1175 Jan 25 19:27:54 Fri Jan 25 18:05:27 2019 kern.warn kernel: [2299534.405772] WARNING: CPU: 4 PID: 6887 at 0xffffffffa023a335 [nf_conntrack_rtcache@ffffffffa023a000+0x3000] Jan 25 19:27:58 bleh Jan 25 19:28:24 starting to become a pain in the ass Jan 25 19:29:52 thats on 4.14.82, seems to coincide with rib churn Jan 25 19:30:13 other than disabling it, any other suggestions? Jan 25 22:28:13 jow: thank you for your answer to mirko - very good one Jan 25 22:54:26 OpenWrt website is 404 Jan 25 22:54:56 forum is up **** ENDING LOGGING AT Sat Jan 26 02:59:57 2019