**** BEGIN LOGGING AT Fri Sep 28 03:00:02 2018 Sep 28 04:04:01 what i'm doing wrong? Sep 28 04:04:14 git clone https://git.openwrt.org/openwrt/openwrt.git/ Sep 28 04:04:33 git checkout openwrt-18.06 Sep 28 04:04:50 git log -p kernel-version.mk Sep 28 04:05:20 ~~~~~~~kernel: bump 4.14 to 4.14.72~~~~~~ Sep 28 04:21:30 nbd, Hauke: at the moment I can't reproduce my WDS problems between two ath9k devices (BT HH5a (WDS-AP, 2.4 GHz) && tl-wdr4300 (WDS-Client) && tl-wdr3600 (WDS-Client), r8155-c662299bf9), but with my nbg6817 (ipq8065/ QCA9984, WDS-AP) I can reproduce it acting as WDS-AP with both ath10k (4.18 based backports and 4.19~ (r8155-c662299bf9) based backports) and ath10k-ct (r8170-d8274451cb); it is working Sep 28 04:21:36 fine with r8137-e9d92bf1e1 on the nbg6817 (WDS-AP) and ath10k Sep 28 06:25:51 jow:ping Sep 28 07:32:37 wish openwrt will be more friendly for mods someday. Sep 28 07:32:43 https://forum.openwrt.org/t/wr841n-v13-usb-spi-mod-universal-solution-for-tp-links-ramips-routers/22173 Sep 28 08:08:23 ds_shadof: git log -p openwrt-18.06 -- include/kernel-version.mk Sep 28 08:29:09 dedeckeh: pong Sep 28 08:47:41 jow:is it expected behavior that you can rename an uci section to an existing uci section ? Sep 28 08:48:40 dedeckeh: in libuci or in the ubu rcp binding? Sep 28 08:48:45 *ubus rpc Sep 28 08:49:02 in libuci Sep 28 08:49:25 I honestly can't tell. I found the libuci error handling and argument checking to be severily broken Sep 28 08:49:42 or lacking, rather Sep 28 08:49:50 libuci basically does not check anything Sep 28 08:50:02 check the semantics of the cli Sep 28 08:50:12 It looked odd to me; as you could have simliar options in both sections Sep 28 08:50:26 it might be that you have to perform the existence check yourself in the user code before invoking rename Sep 28 09:33:09 dedeckeh: does it merge or replace? Sep 28 09:34:33 karlp: my hunch would be that it appears as if it'd overwrite, and then it segfaults :P Sep 28 09:34:40 heheh Sep 28 09:34:52 ldir: "fatal: bad revision 'openwrt-18.06' ? Sep 28 09:35:11 ds_shadof: what's "wrong" with that anyway? (when yo uuse include/kernel-version.mk) ? Sep 28 09:36:09 git log -p origin/openwrt-18.06 -- include/kernel-version.mk is the same as checkout branch and git log -p include/kernel-version.mk here Sep 28 09:37:32 i see last commit "Wed Sep 26" Sep 28 09:38:51 is'nt it should be LINUX_VERSION-4.14 = .68 Sep 28 09:39:50 why shoudl it be? Sep 28 09:40:02 Wed Sep 26: bump 4.14 to 4.14.72 ? Sep 28 09:40:17 try writing a longer sentence with more detail to your question? Sep 28 09:41:08 if i switch to branch openwrt-18.06 and build openwrt, what kernel version will be in my build? Sep 28 09:42:41 what do you think? and what is leading you this opinion that something is wrong? Sep 28 09:42:43 ds_shadof: depends on your target Sep 28 09:43:31 it'll be either 4.9.129 or 4.14.72 Sep 28 09:44:45 i think 4.14.72, but in openwrt releases kernel 4.14.63. I though i will get something close to release if branch 'openwrt-18.06' Sep 28 09:46:28 if you want it to resemble the images of the download servers, use a tag Sep 28 09:46:34 git checkout v18.06.1 Sep 28 09:47:19 jow, got it Sep 28 09:53:15 karlp: can't all be perfect Sep 28 10:10:52 karlp:it merges the sections; keeping the common options intact of the existing section Sep 28 10:12:52 well, that seems eminently reasonable then :) Sep 28 11:06:51 Hi all, just wondering if someone could help me with this post please: https://forum.openwrt.org/t/unable-to-unmount-rootfs-partition/22152/3 Sep 28 11:07:17 basically I don't understand even theoretically how you can possible unmount rootfs considering that init process is running and the kernel needs access to its text section for it to run Sep 28 11:13:47 Neighbor11111114: usually by replacing init Sep 28 11:14:12 Neighbor11111114: the idea is to instruct pid 1 to exec() into another process not running off the rootfs Sep 28 11:15:17 on openwrt this is the `ubus call system sysupgrade '{ "command": "..." }'` which does exactly that Sep 28 11:17:22 on traditional sysvinit a similar thing can be achieved by midifying /etc/inittab and sending a specific signal Sep 28 11:17:30 *modifying Sep 28 11:19:15 Neighbor11111114: you're still asking this because you have some yaffs root you want to reformat? Sep 28 11:19:32 can you not just discard the original entirely and install it from scratch? Sep 28 11:19:49 how many of these devices do you want to sysupgrade? Sep 28 11:24:22 wow, really really interesting jow. I'll go check that now. The only thing that confuses me is that "ubus call system upgrade" is called before switch to run_ramfs as shown here: https://pastebin.com/rdBTFNqB Sep 28 11:24:51 good memory karlp, actually we have many multiple 10ks of units running this Sep 28 11:26:15 but all previous yaffs issues are fixed now, other than this small memory leak on reboot. It is so small we can live with it as long as there is a workaround. Being able to upgrade to the same firmware to 'defragment' (for lack of a better word) is an adequate solution. Sep 28 11:50:03 Neighbor11111114: ok, was gonna say, you seem to be goin gabout it a very complicated way if you didn't have a lot of these to work with :) Sep 28 11:50:36 heh yeah I would definitely prefer to use ubi but this is kinda a hard constraint lol Sep 28 13:41:34 hello some equivalent of srp.identify for cli curl? Sep 28 14:28:28 why not look in curls manual for that? are you in the right channel? Sep 28 14:52:47 hi all.. when making an opkg how can I get it to add the /etc/rc.d/ entries when it's installed? Sep 28 14:53:13 as it is right now it is installed but not enabled, so I have to call enable after installing it. Sep 28 16:03:10 luaraneda, I uploaded latest beta builds for 9984, 9980, 4019, 9888. You probably want the community full htt variety Sep 28 16:03:32 https://www.candelatech.com/ath10k-10.4.php Sep 28 16:03:54 and, new wave-1 betas uploaded as well in case someone wants to try those: Sep 28 16:04:04 https://www.candelatech.com/ath10k-10.1.php Sep 28 16:31:03 greearb_ Hi is there a wiki on how to install the write ath10k ct fermwair? Sep 28 16:35:23 short answer is you copy it to your firmware dir, named properly, and reboot. The web page I link has some info...but if you are feeling newbie-ish, then maybe best to let someone else help with your particular system. Sep 28 17:02:09 Tapper: even shorter answer, install a snapshot built within the last 2 days - those come with ath10k-ct and firmware-ath10k-ct by default (not the new beta versions announced just an hour ago, but the slightly older versions) Sep 28 17:28:07 greearb_: I installed the new beta on my UAP-AC-PRO (9880) and it seems to work fine. Thank you for providing the improved firmware! Sep 28 17:30:05 mamarley, thanks for testing Sep 28 17:30:43 once it has had a bit of time, I can re-name the files to a permanent location and maybe someone can update OpenWRT build scripts to pull in the newer firmware Sep 28 17:31:01 stintel: ^ :) Sep 28 17:33:37 most visible change, I think, is making it do fewer retransmits for probe packets and such...probably this is good, but possibly it would make the connection more likely to drop in some cases. Sep 28 17:34:39 10.4 firmware has a fix(?) for some multi-vif concurrency issues as well, and maybe a wild DMA read fix...not sure it could really happen or not. Sep 28 18:05:34 greearb: Well, I'm always up for exploding stuff, will throw at APs and see what sticks. ;) Sep 28 18:22:24 greearb_: changelog? Sep 28 18:23:37 I haven't been following, have been vacationing Sep 28 18:23:46 oh Sep 28 18:24:04 there is a changelog Sep 28 18:24:21 release_notes, linked from my download pages Sep 28 18:24:36 I guess it would not be clear what changed since what date though Sep 28 18:25:02 in general, probably the new firmware will act similar (and previous firmware worked well afaik) Sep 28 18:26:53 did we already update the driver to 4.16 since the mac80211 bump? Sep 28 18:27:27 Yes. Sep 28 18:27:38 you are using the 4.16 ath10k-ct driver? Sep 28 18:27:49 I haven't updated my APs in weeks Sep 28 18:27:58 I suspect it's going to be 4.13 still Sep 28 18:28:18 both should work I think...I mostly work on 4.16 these days Sep 28 18:28:27 greearb_: stintel: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c662299bf98b6214628168379edd642f1b942b98 Sep 28 18:28:37 18:28:34 up 36 days, 4:07, load average: 0.00, 0.00, 0.00 Sep 28 18:28:38 heh Sep 28 18:28:56 running ancient stuff according to that uptime :D Sep 28 18:30:09 I guess I should think about updating on Sunday Sep 28 18:30:25 right now we passed beer o'clock and tomorrow is a busy day Sep 28 18:30:33 Hauke, thanks for doing that patch Sep 28 18:31:15 either way, 36d uptime with ath10k-ct and ct-htt firmware Sep 28 18:31:39 rock solid. should we ever meet at an openwrt summit or so, remind me to buy you beer Sep 28 18:31:57 heh, if it is ever in my part of the world I'll see if I can make it Sep 28 19:01:43 greearb_: no problem, as we anyway just switched to a more recent mac80211 it also made sense to updateh ath10k-ct Sep 28 19:14:19 hmm, just reverted to ath10k-ct CT_KVER="-4.13" for testing, same problem in WDS-AP mode for QCA9984 as with ath10k and ath10k-ct CT_KVER="-4.16", so that's not the problem. I'll have a look QCA9880-BR4A (BT HH5a) later. Sep 28 19:31:42 I asked on the ath10k mailling list to udpate the board-2.bin files in linux-firmware Sep 28 19:45:53 fortunately that's not so much an issue with QCA9980 and QCA9984, as it is for ipq40xx, where the older board data is fatal Sep 28 19:45:59 jow: nbd: what do you think of my tarpitting proposal for the firewall? Sep 28 19:48:41 oops, gotta go. Sep 28 20:05:53 greearb_: do you plan to update ath10k-ct to a more recent version? Sep 28 20:06:06 like 4.19 or something? Sep 28 20:06:09 yes Sep 28 20:06:42 eventually, but will likely be a while, I'm planning to ship 4.16 in my own product coming up, and I haven't looked at more recent kernels yet Sep 28 20:06:56 ok Sep 28 20:07:17 it is a fair bit of pain to rebase all of my patches Sep 28 20:11:54 I was just looking at the patches we had on top of the old ath10k driver compared to ath10k-ct Sep 28 20:12:14 and many of them were backports which are still missing in ath10k-ct Sep 28 20:41:40 https://github.com/openwrt/openwrt/pull/1412 is needed for ath10k-ct on most ipq806x devices, likely on ipq40xx as well (well, needed in the sense of LED operations); unfortunately upstreaming of that patch seems to have stalled in ath10k upstream as well Sep 28 20:45:03 This will probably fix my bandwith reporting problem: https://git.kernel.org/linus/91493e8e10f0f495b04a5c32096d56ea1f254c93 Sep 28 21:38:54 pkgadd: pushed Sep 28 21:51:24 thanks :) Sep 28 22:44:39 ACTION  Sep 28 23:09:02 Hauke, I will consider applying any backported patches you think are useful to my 4.16 kernel, which will then get propagated into the ath10k-ct driver package. Sep 28 23:09:16 But, it cannot break functionality when compiled directly into my 4.16 kernel. Sep 28 23:09:58 And, I've uploaded new 10.4b firmware for 9984 for anyone that wants to test. This is the 'non-stable' ath10k-ct 10.4 firmware branch Sep 28 23:10:27 https://www.candelatech.com/downloads/ath10k-9984-10-4b/ath10k-fw-beta/ Sep 29 01:30:06 jow: ping Sep 29 02:46:34 greearb: I tested the firmware-5-ct-full-community.bin (MD5 a5076587943b59b7822d8fe5a3dc3f0a) Sep 29 02:46:39 Disassociations are less frequent but I'm still experiencing packet loss on my phone (Whatsapp web disconnects) Sep 29 02:47:00 This is an extract from the relevant log: https://pastebin.com/BtuF9mAc Sep 29 02:47:00 Look for device6 on the log. device5 and device6 are smartphones (same model), and at the time the tests were performed device6 was closer to the router Sep 29 02:47:21 unfortunately, I won't be able to run more test for at least two weeks Sep 29 02:48:00 I just found the option disassoc_low_ack in luci, I'll try disabling it for the next tests (when if I have time) Sep 29 02:49:06 I think it might be related to a power saving feature, because only embedded clients have problems Sep 29 02:50:16 I'm not sure if hostapd option uapsd_advertisement_enabled is relevant, I play with it too next time Sep 29 02:51:22 For now, reverted to kmod-ath10k + ath10k-firmware-qca4019 + manually copied board-2.bin, and everything is working fine **** ENDING LOGGING AT Sat Sep 29 03:00:00 2018