**** BEGIN LOGGING AT Mon Nov 18 02:59:57 2019 Nov 18 04:54:15 mangix: its called progress, you can say the same about kernel as well :) Nov 18 04:59:25 there's also the 'issue' that kernel and userland are getting fixed to use the newer gcc, while they slowly lose support for older ones. especially ARM targets will profit from the newer toolchain as well Nov 18 05:17:26 or switch to clang http://paste.ubuntu.com/p/vdnjdYdD8R/ ? :p Nov 18 05:40:02 ynezz: I will note that clang has a -Oz option that makes smaller binaries than Os Nov 18 05:40:51 pkgadd: it's not that bad. there's still support for GCC 4.8 Nov 18 05:42:45 does it matter on the host? Nov 18 05:43:26 No. Nov 18 05:43:34 * mangix was thinking along different lines Nov 18 05:49:44 * mangix checks out the forum. Nov 18 05:49:53 looks like people are interested in cifsd Nov 18 05:52:55 -Oz doesn't make any difference Nov 18 05:54:37 in order to be fair, I've now stripped the binaries Nov 18 05:54:47 http://paste.ubuntu.com/p/BG78C3SWJC/ Nov 18 05:54:53 clang has -Oz Nov 18 05:55:21 xback: the bump to 4.9.202, 4.14.154 and 4.19.84 needs http://paste.debian.net/1116738/ (tested on ath79, lantiq and ipq806x) Nov 18 05:57:23 what the...19.07 has luci-app-cifsd but no cifsd or cifsd-tools Nov 18 05:57:38 someone goofed Nov 18 06:03:14 mangix: luci as a whole was synced back to 19.07 Nov 18 06:10:58 i also didn't know someone added a luci-app-cifsd. interesting... Nov 18 08:03:42 pkgadd: Thanks for the info. I've already made that one last Friday :-) Nov 18 08:04:04 Hauke: Thank you for the patch. I'll give it a spin this morning Nov 18 08:10:45 it's a shame that luci-app-cifsd dependencies ALSO don't build on mac os - just like samba4 Nov 18 08:49:59 which package's Makefile edits the 'configure.ac'? I was told to use sed, I'm not sure where/how in the Makefile to do it Nov 18 08:52:38 do I just do it under 'define Build/Prepare'? Nov 18 09:27:40 hi, i am trying to push JIT-support into libpcre for select architectures and came up with the following solution: https://github.com/gladiac1337/openwrt-packages/commit/f5883064799471c98aa2f013657b4ae0b580c08f Nov 18 09:28:40 the Config.in enables a config-option for use in "make menuconfig" on officially supported architectures and is enabled by default on select architectures which I can test Nov 18 09:29:31 if there are no objections I will make a PR because I think the 10x speed improvement is worth it Nov 18 09:46:58 oh and pcre2 will be next Nov 18 10:21:54 hi all Nov 18 10:22:29 any pointers on where I could find some info on building openwrt for an Allwinner S3? Nov 18 10:22:43 is there a lot of porting work to be done? Nov 18 10:22:52 has it even been considered? =) Nov 18 10:23:54 probably not much, just choose sunxi. Nov 18 10:24:05 what hav eyou tried already? Nov 18 10:24:15 gladiac1337: I'd like all that, but I'm no dev to answer =) Nov 18 10:27:11 karlp: I don't have the S3 based board yet, so I haven't tried anything. I'm considering whether I should =) Nov 18 10:28:07 btw, there's been a number of reports now that 5GHz with ath10k is unsuable on 19.07 Nov 18 10:28:08 karlp: I have recently built a custom device from an A13, based on the A13-SOM profile by Olimex, so I know sunxi a bit. Nov 18 10:28:34 should we revert form ath10k-ct to ath10k? Bump mac80211? Hope it'll solve itself? Nov 18 10:29:37 revert to ath10k and we will get other reports Nov 18 10:29:46 anybody using ath10k ? Nov 18 10:29:52 or ath10k-ct? Nov 18 10:29:55 I guess we should try to find out which one is causing more issues Nov 18 10:29:59 I've onl ath9k and mt76 hardware Nov 18 10:30:06 I'm on ath10k-ct Nov 18 10:30:07 jow: i have ath10k-ct and it works fine on master Nov 18 10:30:18 gladiac1337: question is whether it works fine on 19.07 Nov 18 10:30:31 that i do not know, sorry Nov 18 10:30:39 using ath10k-ct on master at home as well Nov 18 10:30:54 I was about to ditch all my ath10k-based APs because near unusable (random non-auto-recovering crashes, sometimes within a day of uptime), until I switched to ath10k-ct Nov 18 10:31:00 a certain amount of "my wifi is unstable" is normal for each release announcement Nov 18 10:31:11 which initially was dog slow in combination with MFP, but that was solved Nov 18 10:31:14 but the number of "5ghz is broken since 18.06" is unusually high Nov 18 10:31:31 although now it looks like there might be a regression as my upload speed from laptop is limited to 20-30Mbps Nov 18 10:31:31 broken meaning unstable, devices being associated but having not internet conneciton / dns etc. Nov 18 10:32:34 and switching to ath10k makes the problem dissapear? Nov 18 10:33:02 jow: I rather have a go at debugging and fixing those, with greearb__ Nov 18 10:33:16 if that doesn't work out within a recent timeframe ... we could revert Nov 18 10:33:20 no idea, I fear its simply broken nd unstable in general Nov 18 10:33:24 I build my own images anyway Nov 18 10:33:33 and anyone is on master Nov 18 10:33:39 but vanilla ath10k is unusable for me Nov 18 10:33:42 so no test coverage for 19.07 Nov 18 10:34:00 prpl is on 19.07 for some time Nov 18 10:34:17 using ath10k-ct? Nov 18 10:34:25 good question :) Nov 18 10:34:39 what device is that? Nov 18 10:34:47 https://bugzilla.kernel.org/show_bug.cgi?id=188201 Nov 18 10:34:55 I can test 19.07 on archer c7v5 today Nov 18 10:35:56 if we revert, https://bugs.openwrt.org/index.php?do=details&task_id=333 becomes relevant again Nov 18 10:36:14 there's only one other user that reported a "me too" but I'm sure people in here had the same issue Nov 18 10:36:35 I've 5x as well Nov 18 10:38:05 my opinion about -ct stand. at least greearb__ is actively fixing bugs. atheros doesn't care because too busy designing new bugs Nov 18 10:38:26 jow: BTW https://bugs.openwrt.org/index.php?do=details&task_id=2575 (requested re-open) Nov 18 10:39:56 ynezz: so far I've seen reports about R7800, R6100, R6220, C2600, Archer C7 Nov 18 10:40:49 ynezz: I will not work on bug 2575, it appears to be an LXC specific problem Nov 18 10:41:03 hi Nov 18 10:41:11 Has anyone experience issues with TCPMSS lately? I tried changing the MTU for my WAN interface to 1447, but MSS is still 1460 Nov 18 10:41:13 and the fct that running iptables or iptables-save once fixes it, hints at the fact that some kind of autoloading is at play here Nov 18 10:41:20 Or maybe this is more a uestion for openwrt-user Nov 18 10:41:29 jow: fine with me, I'll reject the request as "Different project" Nov 18 10:41:53 has anyone heard already about 'low-cost' QCA 11ax, the IPQ8070 platform? blogic? Nov 18 10:44:15 jow: as I can't find those bugs on flyspray, I assume the reports are on forum? Nov 18 10:44:37 ynezz: yes, in response to the release announcement and scattered in various topics Nov 18 10:44:46 also some issues in the luci ticket tracker Nov 18 10:45:26 issues seem to center around 5Ghz Nov 18 10:48:58 jow: while I probably will make some people angry stating this, I agree with seriously thinking to propose a revert to upstream ath10k vs ath10k-ct Nov 18 10:49:38 xback: I have no stake in it. To me the antire ath10k story is a sad state of affairs compared to ath9k Nov 18 10:50:05 the reasoning behind -ct was that we have a chance to receive fixes Nov 18 10:50:15 ath10k-ct should bring us extra features vs upstream .. but I've spend weeks testing an trying and whining and they simply don't work well imho Nov 18 10:50:17 firmware ones that is Nov 18 10:50:36 but I've heard from others that e.g. mesh is unsupported Nov 18 10:50:57 and IBSS doesn't work when using encryption Nov 18 10:51:09 I'd have no problem reverting to ath10k in 19.07 at least Nov 18 10:51:14 Indeed, seems that OSS-wifi hayday was 9k... and even if not thinking OSS, it was still best working stuff in general.. Nov 18 10:51:29 but I'll glady follow the opinion of those who actually use it Nov 18 10:51:31 a 2nd large argument is that ath10k-ct only picks up upstream fixes very slowly. Nov 18 10:51:58 I really wonder why upstream QCA doesn't enable/support other modes besides classic AP/STA Nov 18 10:52:16 xback: send an RFC revert patch to the list? Nov 18 10:52:39 or rather an s/-ct// one Nov 18 10:52:55 Generally I'm happy that -ct indeed even exist... Nov 18 10:53:14 I'm currently investigating what is wrong with multicasting in IBSS encrypted .. and will do the proposal based on that Nov 18 10:53:20 it's no thanks to qualcomm Nov 18 10:53:53 I really appreciate Ben's amazing work .. but I really feel there is no added value if the extra's don't work well compared to upstream Nov 18 10:54:30 xback: upstream doesn't work well in some situations and nobody cares (see the bug reports linked earlier) Nov 18 10:55:07 setup $500k kickstarter, buy the ath10k sources, leak them, problem solved Nov 18 10:55:27 ynezz: 500k might be not enough Nov 18 10:55:57 probably cheaper to hire a hacker to steal them Nov 18 10:56:03 whatever would make chinese interested Nov 18 10:56:08 stintel: I could also imagine that AP mode is not that interesting to upstream Nov 18 10:56:16 stintel: can I kindly ask you to drop a link or 2? I'm curious Nov 18 10:56:26 I mean besides OpenWrt and some enthusiasts, who cares about mac80211 AP mode? Nov 18 10:56:40 most simply want their laptop radio to work well in client mode Nov 18 10:56:43 mm, like implied before, qualcomm doesn't care generally shit... -ct at least tries to improve.. while it might not be so called perfect fix, but what do ou really expect from this situation? :) Nov 18 10:56:50 xback: https://bugs.openwrt.org/index.php?do=details&task_id=333 https://bugzilla.kernel.org/show_bug.cgi?id=188201 Nov 18 10:56:54 and commercial integrators tend to use proprietary offers anyway Nov 18 10:57:03 jow: that ath10k problem, is it only about what is by default in image? Nov 18 10:57:13 jow: except client mode was a complete disaster too last time I tried Nov 18 10:57:30 jow: https://bugzilla.kernel.org/show_bug.cgi?id=196361 Nov 18 10:57:34 stintel: maybe NetworkManager is good enough in papering over it Nov 18 10:57:37 again, nobody cares Nov 18 10:57:41 jow: no, it's not Nov 18 10:57:50 does anybody care about anything in the kenrel bugzilla? Nov 18 10:58:14 I always thought its just a feel-good ticket sink for users Nov 18 10:58:36 guess that's another story Nov 18 10:58:37 actual bugfixes and q/a likely only happens through distros Nov 18 10:58:38 and good place to check if someone already reported the same problem you have ;) Nov 18 10:58:47 it's becoming frustrating Nov 18 10:59:16 high traffic mailing lists are ... ugh. and there you get ignored as well Nov 18 10:59:32 not on linux-wireless I would say Nov 18 10:59:35 and the coc doesn't help. you are no longer allowed to insult people for breaking stuff :P Nov 18 10:59:38 wasn't it even offical policy that kernel qa happens downstream now? Nov 18 11:01:18 jow: downstream? Nov 18 11:01:26 probably not offical policy, I can't seem to find that article anymore Nov 18 11:01:43 stintel: yeah, by distros Nov 18 11:01:54 heh Nov 18 11:08:33 jow: that ath10k problem, is it only about what is by default in image? Nov 18 11:08:56 stintel: did you test 19.07 past 0e7113e6ece03c879bf99dff097dd868e3453f27? Nov 18 11:09:14 hexa-: no, I'm running master Nov 18 11:09:20 sure Nov 18 11:09:37 anyway, that's what made ath10k wave1 devices like uap-ac-mesh work for us again Nov 18 11:09:59 that's in gluon actually, where we're using ap/mesh Nov 18 11:22:59 jow: to me it seems little bit overreacting to switch from ath10k-ct to ath10k for 19.07.0-rc2 based just on the feedback from those forum posts Nov 18 11:23:47 jow: they would need to be proper bug reports, someone needs to examine the behavior in 18.06 vs 19.07 as the versions are very different Nov 18 11:24:48 I bet they would get same "issues" on the master as well, because I think, that 19.07/master has fixed some stuff obviously, like TX power levels, DFS Nov 18 11:25:08 and I'm probably not able to replicate them anyway here Nov 18 11:25:46 I don't have xbox or other devices they mention in their posts Nov 18 11:26:38 I have xbox one x and xbox one, both work fine Nov 18 11:26:59 and I don't see "by switching to master and/or ath10k problems dissapear" either (which would back your reaction) Nov 18 11:27:02 and I am sure it is using 5GHz since I mac-filter the xboxes on 2.4 because they are too stupid to know that 5GHz is almost always better than 2.4GHz Nov 18 11:27:26 would be nice if you could try 19.07-rc1 Nov 18 11:27:46 but then we would need to be lucky, that you've some ath10k radio etc. Nov 18 11:27:53 s/some/same/ Nov 18 11:31:43 FWIW, I've just looked and I've switched $$ project to 2155e94d4b8e (pre 19.07.0-rc1) on October 14th and don't have any complains related to ath10k-ct 5GHz yet Nov 18 11:38:06 ynezz: does it have to be 19.07-rc1? Nov 18 11:38:18 or can I build HEAD from 19.07 branch Nov 18 11:38:31 just download the image? Nov 18 11:38:33 lol Nov 18 11:39:22 I'm not going to figure out what packages I need to install on a default image Nov 18 11:39:56 and risk losing their config on the next sysupgrade Nov 18 11:40:19 I'm willing to try 19.07-rc1 but default images are not an option Nov 18 11:41:03 just backup your mtd, install 19.07.0-rc1, setup wifi, test, flash back your backup, done Nov 18 11:41:59 brrrrr Nov 18 11:42:20 quite a lot of changes related to wifi since 19.07.0-rc1 http://paste.ubuntu.com/p/5Krc8d7Fh6/ Nov 18 11:42:39 if I cannot just sysupgrade I don't have time for it Nov 18 11:43:33 sysupgrade from master to 19.07 and back? :) Nov 18 11:45:01 stintel: you can also flash the HEAD image Nov 18 11:48:20 ynezz: if I lose my config I completely lose access to the AP, need to change VLANs on the switch etc. it's just too much hassle / downtime Nov 18 12:00:27 I might be late to the party - personally i use ath10k for Mesh networks (Freifunk) as well as at home (QCA9882) and never encountered problems. It's not all roses, as disabling 802.11b rates does not work on the 2.4 GHz part of a IPQ40xx for example. Nov 18 12:00:57 I think we can try to ship ath10k-ct for 19.07 and see whether or not we receive more / less / none complaints about it Nov 18 12:02:57 I think a problem might be the hard assoc limit, but this is only something i vaguely remember. Nov 18 12:05:15 This was one of the main points which drove us away from using ath10k-ct for the MRMCD2019's outdoor coverage (~150 users in an ETSI-DFS environment / 3 APs) Nov 18 12:22:05 greearb__: there seems to be a regression in ath10k-ct wave1 with MFP enabled, I am back to upload speeds of ~30Mbit/s from connected clients vs almost 400 with MFP disabled :( Nov 18 12:25:02 I'll try to bisect tonight Nov 18 12:26:27 I noticed this the first time on september 5, but didn't verify if this was MFP related or not. I suspect it will be Nov 18 12:48:25 Hey channel, I have been struggling with a thing for the past couple of days. Would appreciate if anyone can think of a solution. Basically I want to route my wlan0 clients differently from wlan1 Nov 18 12:48:55 I was thinking of an "ip rule" rule that would take incoming interface and lookup a different routing table Nov 18 12:50:54 the problem seems tobe that the kernel is assuming all packets come in "br-lan" instead of "eth0", "wlan0", "wlan1" Nov 18 13:00:01 barhom: use the iptables physdev match to add an fwmark Nov 18 13:00:08 then make your ip rules target that Nov 18 13:01:29 Barhom: or make own network for wlan0, or take out from br-lan bridge.. depending what exactly is what you want to do Nov 18 13:02:02 (Incl. What jow says possibly) Nov 18 13:02:36 jow: I tried to do that but I couldn't get the iptables rule to mark the packets Nov 18 13:02:41 if you want to route an interface differently, then it indeed makes sense to separate it into another network (e.g. br-lan2) Nov 18 13:02:54 and add this new network to the lan firewall zone Nov 18 13:03:08 zorun, almari: Yes but I do not want to have a different range for DHCP for wlan0/wlan1 Nov 18 13:03:23 ah, that's a problem then Nov 18 13:03:51 barhom: using the physdev match? A naive -i wlan0 will not work Nov 18 13:03:59 so you want them to be in the same L2 network but be routed differently? Nov 18 13:04:04 zorun: yes Nov 18 13:04:12 jow: thats what I did, I dont know how to run a physdev match Nov 18 13:04:19 Ill google a bit, thanks Nov 18 13:04:24 good luck ;) but it's certainly possible with jow's method Nov 18 13:04:46 regarding ath10k-ct, we are planning to use Archer C7 v5 routers with 19.07 in my community networks Nov 18 13:04:53 so I distributed a few models around with the rc1 Nov 18 13:05:00 everything seems OK so far Nov 18 13:05:20 barhom: iptables -t mangle -I PREROUTING -m physdev --physdev-in wlan0 -j MARK --set-mark 1 Nov 18 13:05:48 zorun: ah, great, saved me some work :) Nov 18 13:06:03 barhom: you also need to install iptables-mod-physdev Nov 18 13:06:23 ynezz: you mean with testing? more testing is always better :) Nov 18 13:07:23 wireless issues sometimes pop up because of buggy or newer stations, so it's hard to be sure it will work in all situations... Nov 18 13:08:04 I know, with the switch to ath10k we'll just switch to different issues Nov 18 14:02:20 Just throwing it out here: I'm seeing a lot of these often on 19.07 --> ath: phy0: unsupported hw bitrate detected 0x1b using 1 Mbit Nov 18 14:02:48 sometimes it harmless, other times wifi stalls after this Nov 18 14:05:01 I can't find any issue with `unsupported hw bitrate detected` on https://github.com/greearb/ath10k-ct/issues Nov 18 14:06:45 wasn't it fixed in some recent firmware/drivers bumps in master? Nov 18 14:06:51 barely remember something like that Nov 18 14:17:21 Hauke: pkgadd: Thanks for the (V2) patch Nov 18 14:17:28 it fixes the issue nicely Nov 18 14:18:04 backporting to 19.07 only requires the patch to be located in subsys behind 354- (which also alters fq*) Nov 18 14:28:56 ynezz: the issues are ath9k :-) Nov 18 14:29:42 ah Nov 18 14:30:25 so reboot the box when you see this error message, problem solved :) Nov 18 14:31:34 got to love forum posts Nov 18 14:32:00 jow: 0 0 MARK all -- any any anywhere anywhere PHYSDEV match --physdev-in wlan0 MARK set 0x1 Nov 18 14:32:07 I cant get it to mark the packets Nov 18 14:32:14 https://forum.openwrt.org/t/openwrt-19-07-rc1-archer-c7-v2-5g-wifi-died-after-trying-to-change-channels/48182/53 --> problem with WPA3? ath10k-ct? DSS? ... Nov 18 14:33:28 ynezz: that's a bit difficult when the device on which this occurs is on a structure 50km offshore Nov 18 14:33:31 ;-) Nov 18 14:33:55 and you can't reboot it? Nov 18 14:34:10 and then eventually it seemed to be a client issue? Nov 18 14:34:46 yeah, I've installed network backdoors on all structures (4G/LTE) Nov 18 14:35:03 stintel: I would ignore any kind of wpa3 feedback for now Nov 18 14:35:27 xback: I mean, there is a bunch of such messages related to ath9k firmware (crashes?) so you can't recover from them otherwise then by reseting the card Nov 18 14:35:42 ynezz: exactly Nov 18 14:36:29 sometimes it still works, but it seems locked to very slow rates Nov 18 14:36:54 other times it's just blocked completely. like a queue stall or so Nov 18 14:38:31 barhom: that was in mangle/PREROUTING ? Nov 18 14:40:57 jow: yes, https://0bin.net/paste/SEx8V0gh3CldVuf2#3p3JWqGW39X7jJOtruzHoRHE84T78dSTxknyB9ya7SX Nov 18 14:41:17 I can see the rules clearly in iptables -L -t mangle -v Nov 18 14:41:23 but the counters are not increasing Nov 18 14:41:42 tried marking wlan0 and wlan1 differently Nov 18 14:42:48 Rebuilt the firmware to include kmod-ipt-physdev and iptables-mod-physdev Nov 18 14:43:03 maybe you need INPUT instead of PREROUTING, depending on your usecase Nov 18 14:43:24 let me try Nov 18 14:45:01 PREROUTING, INPUT, FORWARD, none works Nov 18 14:56:16 iptables -t mangle -I PREROUTING -i br-lan -j MARK --set-mark 1 (works) Nov 18 14:56:27 iptables -t mangle -I PREROUTING -i eth1 -j MARK --set-mark 1 (works) Nov 18 14:56:39 wlan0 does not as you said earlier jow, unsure why Nov 18 14:56:56 trying all sorts of ways, the physdev isnt working yet Nov 18 14:57:26 do you have offload? Nov 18 14:57:51 zorun: I dont know, I havent enabled anything Nov 18 14:58:12 probably not then Nov 18 15:03:23 My best guess is that its being affected because wlan0/wlan1 is in a bridge Nov 18 15:03:36 but there must be someway to mark the packets anyway Nov 18 15:23:52 Is ntp building for anyone on 19.07? Nov 18 18:19:26 stintel, are you using the 5.4 driver or something older? We've not done any serious testing on 5.4 yet. Nov 18 18:19:45 firmware shouldn't have changed much recently, but of course some bug could have slipped in. Nov 18 18:20:16 greearb__: this is on openwrt master, both ar71xx and ath79 Nov 18 18:20:47 greearb__: one of them is 4.19, the other is 4.14 Nov 18 18:21:13 ok, hopefully not hard to bisect at least the ath10k-* parts Nov 18 18:21:55 will definitely be annoying due to toolchain updates Nov 18 18:23:36 you should be able to tweak the makefiles to pull in older ath10k-ct drivers, and just copy older firmware into the file system and reboot Nov 18 18:31:38 nbd: thanks for the information Nov 18 18:32:27 are package/kernel/ath10k-ct/patches being kept up to date with all these mac80211 & ath10k-ct changes ? Nov 18 18:33:09 pkgadd: thanks for the fix Nov 18 18:36:09 pkgadd: I missed that change the new one is backwards compatible Nov 18 18:38:32 ldir: there are some patches missing for ath10k-ct Nov 18 18:38:43 but last time I chekced they are not important Nov 18 18:39:17 openwrt master and 19.07 are both using ath10k-ct 4.19 Nov 18 18:59:13 jow: I think 5GHz with ath10k-ct is working for me, I can check later this evening Nov 18 19:06:09 I did just update an c7 v2 to master, with ath10k-ct, generally works... 11w required failed with computer but not with phone, I don't know what's to blame there Nov 18 19:06:28 olmari: what computer? Nov 18 19:06:46 OS/NIC etc Nov 18 19:07:10 18.04 ubuntu, intel 7260 (rev bb) Nov 18 19:07:27 hmm that should work Nov 18 19:07:33 I'm inclined to blame ubuntu here :P Nov 18 19:08:01 olmari: using NetworkManager or plain wpa_supplicant or something else? Nov 18 19:08:07 I do feel any computer I've owned has always failed with 11w Nov 18 19:08:26 I only use it with iiw optional Nov 18 19:08:28 I'm using 11w for many years with my XPS13/Gentoo Nov 18 19:08:35 just NM for now, I wasn't going to debug 11w on this location, while it occurred on mind Nov 18 19:08:36 and required for sae Nov 18 19:08:40 I use 11w optional too because otherwise some devices cannot connect Nov 18 19:08:50 but `iw wlan0 station dump` shows MFP: yes Nov 18 19:09:03 optional it works here too, I bet it optos to not use it Nov 18 19:09:26 I have a 7260 client at home Nov 18 19:09:34 wit debian oldstable Nov 18 19:09:37 with Nov 18 19:09:49 but more or less this is on my client location, I can't start do solo stuff Nov 18 19:10:23 .tough this still brought up an idea to that I now have one surplus similar c7 v2 where I could try to actually dbug this when I get the time Nov 18 19:10:57 (and by client location I mean real human clientele that pays me to do stuff, not debug mine own shit 😁 ) Nov 18 19:11:09 older ath10k driver/fw versions had problems with 11w Nov 18 19:15:06 tough when I do get time in relatively soon (few days), I do require help to actually know what to look for.. I know linux, I know openwrt in general, I have no deep insight how to debug this kind of stuff :) Nov 18 19:15:23 I mean if it would have any help, I'd be glad to do something Nov 18 19:18:27 when mfp works but is slow, usually block-ack is failing Nov 18 19:18:50 that was the ath10k-ct wave-1 bug I fixed. wave-2 always worked as far as I remember Nov 18 19:19:58 greearb__: I used it with wave 1 Nov 18 19:20:08 works good now Nov 18 19:22:31 Hauke: have you tried uploading something from a client? I get ~30Mbps with MFP on and ~400Mbps with MFP off Nov 18 19:22:53 no not really Nov 18 19:23:20 stintel, if you sniff, see if you are just seeing normal ack. And, normally it seems it is a receiver-decode issue, so if upload fails, then maybe problem is on peer. Nov 18 19:27:58 greearb__: if it is a receiver-decode issue and I upload from an intel client to an ath10k AP the problem is on the AP side no? Nov 18 19:28:16 yes, at least somewhat likely Nov 18 19:29:01 sniff the block-ack setup packets, make sure client sends them encrypted (ie, if you see them open-auth encoded, sender is issue) Nov 18 19:29:18 ok, so I reverted back to firmware 10.1-ct-8x-__fH-022-8f2afb9e but without reverting the driver, now I also get the slowness without MFP Nov 18 19:29:36 yah, fixed :) Nov 18 19:30:26 ? Nov 18 19:30:51 you will really want to spend some quality time with a sniffer to see if block-acks are working or not, and if BA setup frames are properly encrypted Nov 18 19:35:55 stintel: can you look at this? https://github.com/openwrt/packages/issues/10543 Nov 18 19:37:04 mangix: later, quite busy with other stuff Nov 18 19:37:19 mangix: also after adding dep on telldus-core I get linking failures :/ Nov 18 19:40:43 well I hope RPi4 wifi supports monitor mode Nov 18 19:40:50 the only other 5GHz clients I have are android Nov 18 19:41:17 ah. maybe I can use my DIR860L Nov 18 19:43:09 stintel, it does with nexmon Nov 18 19:44:10 that doesn't seem to be available for openwrt? Nov 18 19:45:34 I don't think so Nov 18 19:49:24 are there some easy steps to speed up building times by making the makefiles smarter? Nov 18 21:29:42 any dma experts around ? Nov 18 21:29:52 i have a chunk from dma_alloc_coheren() Nov 18 21:30:00 and i have a pointer int hat region Nov 18 21:30:21 so this is a virtual ptr with 0xCxyz1234 Nov 18 21:30:34 how do i turn this into a 0x8xyz1234 on arm "A0.) Nov 18 21:33:53 jow: Thanks for the physdev tip. It worked after I enabled net.bridge.bridge-nf-call-iptables Nov 18 22:26:19 if I compile in CONFIG_MTD_SPI_NOR in a raspberry pi kernel, will it probe all chips defined in drivers/mtd/spi-nor/spi-nor.c on the available SPI buses or is that wishful thinking?> Nov 18 22:32:39 stintel: that is wishful thinking, as spi does not support autodetect Nov 18 22:33:18 so I'll have to add stuff to devicetree or use an overlay Nov 18 22:33:30 pfffft and I don't know the partition layout of this thing Nov 18 22:34:35 bricked my power8 box by flashing a wrong image, tried to recover the chip with flashrom, but that's not sufficient as it writes empty partitions but with incorrect ECC data Nov 18 22:34:53 so the thing still doesn't boot Nov 18 22:46:24 blogic: dma_alloc_coheren() returns the phisical and the virtual address Nov 18 22:57:41 stintel: what power8 box? Nov 18 22:57:57 russell--: TYAN TN71-BP012 Nov 18 22:58:16 you don't happen to have one of those, do you :) Nov 18 22:58:40 I think if I can get a dd from their prom I'd be able to unbrick mine Nov 18 22:58:54 s/their/anyone's/ Nov 18 22:59:39 s/prom/pnor/ Nov 18 23:01:01 * russell-- tattoos "always make a copy of original contents" on the back of his hands Nov 18 23:01:11 yeah Nov 18 23:01:27 I have that habit when messing around with embedded devices Nov 18 23:01:35 didn't do it with this box :( Nov 18 23:03:21 i don't suppose that tyan might help you out? Nov 18 23:03:53 nah, it's written explicitly on their website that they cannot help with broken "BIOS" Nov 18 23:04:19 what is worse is that I cannot access the BMC either. and I cannot reset the BMC creds via local ipmitool because I cannot boot an OS Nov 18 23:05:02 guess I'm going to have to figure out the partition layout, and then figure out how to fix ECC in the partitions inside the image, before flashing with flashrom Nov 18 23:05:17 I should have just bought 2 of these boxes Nov 18 23:05:22 yes Nov 18 23:07:10 almost can't believe that I didn't take a dd of that prom though Nov 18 23:07:13 * stintel looks again Nov 18 23:07:50 * russell-- recalls the movie North Face about the eiger and not leaving a path of retreat leading to tragedy Nov 18 23:10:37 https://en.wikipedia.org/wiki/North_Face_(film) ... the cliff on the right is the power8 box, and the guy dangling from the rope is you ;-) Nov 18 23:14:53 :P Nov 18 23:19:54 hmmm maybe there is a backup on the disks in the power8 box itself Nov 18 23:23:55 [632564.621775] BTRFS error (device sdh2): sectorsize 65536 not supported yet, only support 4096 Nov 18 23:23:56 FML Nov 18 23:26:02 so in theory if I compile an image for RPi4 with CONFIG_ARM64_16K_PAGES I should be able to access it Nov 18 23:26:58 ehr, CONFIG_ARM64_64K_PAGES Nov 18 23:32:31 mangix: thanks Nov 18 23:34:05 mangix: in case I miss it, ping me when CI finishes? Nov 18 23:34:40 wait Nov 18 23:35:13 I missed the telldus part Nov 18 23:35:27 I will have to compile-test that locally for x86/64 first **** ENDING LOGGING AT Tue Nov 19 02:59:58 2019