**** BEGIN LOGGING AT Tue Feb 05 03:00:01 2019 Feb 05 10:21:18 https://community.ubnt.com/t5/UniFi-Updates-Blog/FIRMWARE-4-0-21-9965-for-UAP-USW-has-been-released-Stable/ba-p/2652388 Feb 05 10:21:25 > [UAPG1] Switch to LEDE framework.* IMPORTANT NOTICE BELOW Feb 05 10:21:32 😂 Feb 05 10:51:21 can someone silence Avengeance in #openwrt for a while ? Feb 05 10:52:06 'sec Feb 05 10:53:24 thanks Feb 05 11:05:26 Hi, I just posted on the forums but there is one question that you may be able to answer quickly Feb 05 11:05:43 I want to install openwrt on an ARMv7 Mikrotik device (https://forum.openwrt.org/t/building-for-mikrotik-armv7/30752) Feb 05 11:06:15 But the existing builds are for ath processors, would it be possible to build the existing ath images but for ARMv7? Feb 05 11:08:04 stintel: switched to lede for a couple of devices now, still no gpl source :D Feb 05 11:08:32 bet they're using the hardwork of volunteers too, not even writing their own board support Feb 05 11:08:37 wankers Feb 05 12:06:43 gef3233: there is no generic armv7 target/support, you always need to have the drivers for the specific SoC you target. if the device has a ipq4019 SoC, then you can use the ipq4019 target, else you will need a different target or create a new one Feb 05 12:08:42 Hi KanjiMonster, I was not aware of that, I will check it, thanks Feb 05 12:11:06 KanjiMonster, so I should set the target to IPQ40xx, right? Feb 05 12:15:47 gef3233: yes. could be as easy as adding a new dts file and defining a new device in image/ Feb 05 15:32:38 <\x> hello guys Feb 05 15:32:39 <\x> https://paste.ee/p/nzllY Feb 05 15:32:57 <\x> is it just me that expriences these om mt7621 ? Feb 05 15:33:15 <\x> i now rebuilt without sqm as the bugtracker says that its the problem Feb 05 15:33:26 <\x> will report back if so Feb 05 15:40:54 What to do if a package maintainer is unresponsive? this is for bird-openwrt - https://github.com/openwrt/packages/issues/5329 Feb 05 15:49:23 hi there (repost from #openwrt), quick question, is libnfc definitely out of the repositories ? I couldn't find an aswer to why it seems to have disappear in openwrt >v15 Feb 05 15:50:10 Strykar: Noltari has been MIA for a long time Feb 05 15:53:05 Strykar: not sure if that kernel module belongs in openwrt. it could go in the packages feed in kernel/. I wouldn't call it either (a bird or openwrt package issue). it's optional, and not sure if I want to relay on md5 for anything Feb 05 15:53:18 rely* Feb 05 17:01:45 stintel, fair enough, but would it hurt to offer the module via opkg? Feb 05 17:04:38 Strykar: sure, send a PR for packages repo that adds it Feb 05 17:07:02 someone knows a way to install packages with opkg utililty and with a tool like ansible without python (a module using raw module? ash?) Feb 05 17:33:30 oh nice, an rtcache reboot loop Feb 05 17:33:35 so thats definitely gone now Feb 05 17:33:52 maybe I wrongly blamed offload, or it's actually both Feb 05 17:35:13 either way, can't use it as it's broken heh Feb 05 17:37:45 stintel, ugh, 'CONFIG_TCP_MD5SIG' cannot be built as a module Feb 05 17:38:17 :D Feb 05 17:38:46 but that makes sense since it touches tcp handling Feb 05 17:46:22 oh :( Feb 05 17:47:53 hm Feb 05 17:48:07 so how much of a perf hit am I likely to see without nf_conntrack_rtcache? Feb 05 17:48:14 shouldn't be that significant right? Feb 05 17:49:42 <\x> is it your erx jwh? Feb 05 17:49:53 no Feb 05 17:49:54 x86 Feb 05 17:50:25 first version I've included iptables/firewall stuff in... I think every bit has actually caused a problem Feb 05 17:51:09 it had looked like offload was broken, but that may be a side effect and it was actually rtcache thats broken as thats whats been causing issues lately with offload disabled Feb 05 17:51:49 by problems I mean forwarding stops for 5-10 seconds and kernel oops,then eventually panic, usually resulting in a reboot loop for affected devices as it dies as soon as it starts forwarding traffic again Feb 05 17:51:55 so yeah, not great Feb 05 17:52:37 moved the .ko out of the way on affected devices, all of the ones I've done that on haven't complained since Feb 05 17:55:21 I can't readily reproduce it though, but I did dump the oops a while back Feb 05 17:57:09 https://gist.github.com/joeholden/8d3e147f08ef50fc67ae7d76cf87bafb Feb 05 17:57:12 there it is Feb 05 18:56:19 (test, ignore) Feb 05 20:16:40 Any suggestions on using trace-cmd or other tools with mac80211? (CONFIG_PACKAGE_MAC80211_TRACING=y and CONFIG_PACKAGE_trace-cmd=y done) Feb 05 20:22:58 jeffsf: https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/tracing Feb 05 20:23:36 Thanks, looking at that and hoping that the output means something to me ;) Feb 05 20:34:44 hm, what was that project that was trying to get automated runtime testing of openwrt? (and is there something similar one can setup?) Feb 05 20:40:27 jwh: https://github.com/mattsm/boardfarm/ ? Feb 05 20:44:07 oh that looks pretty cool, thanks Feb 05 21:03:41 ath11k (no typo here), interesting: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=ath11k-bringup&id=258bbf525e652e244aa8b2331f55fda573fbe926 Feb 05 21:11:40 All we need is some affordable hardware ;) Feb 05 21:21:30 so it's still "atheros" after all these years.... Feb 05 21:27:34 "Atheros became a subsidiary of Qualcomm operating under the name Qualcomm Atheros" -- Wikipedia -- surprised me Feb 05 21:29:28 eh? Feb 05 21:29:33 has been like that for a few years Feb 05 21:34:55 ah, finally, QCN5124/ QCN5154 support, nice :) Feb 05 21:43:03 with the corresponding https://github.com/kvalo/ath11k-firmware Feb 05 21:44:15 No, what surprises me is that they still want to keep the Atheros heritage alive. Feb 05 21:44:32 trying to appear less awful by keeping the name? :d Feb 05 21:44:34 :D* Feb 05 21:44:43 * mamarley 's brain prints "ath11k_pci: firmware crashed!" to the kernel log just thinking about the new driver. Feb 05 21:44:58 atheros had a decent reputation really, qualcomm don't Feb 05 21:45:27 Probably... or Qualcomm will ditch them sometime soon Feb 05 21:51:29 lach1012: i'm not so sure it's about heritage. way more about what the atheros name means in the FOSS community Feb 05 21:51:38 with jwh ^^ Feb 05 21:51:55 everyone knows now though, they should just ditch it instead of trying to pull a fast on Feb 05 21:51:58 one* Feb 05 21:52:39 they aren't marketing that to their OEMs though, they still use some variant of their proprietary ath_pci (both 802.11ac and 802.11ax) Feb 05 21:53:09 what's ath11k? google doesn't even show any resulst for it :-/ Feb 05 21:53:27 something something qsdk-qca-wifi Feb 05 21:53:32 Borromini: the (new) driver necessary for Qualcomm-Atheros 802.11ax (ipq807x) Feb 05 21:53:33 wow Feb 05 21:53:39 after all this messing about... https://github.com/AdelieLinux/gcompat/tree/master/libgcompat Feb 05 21:53:44 pkgadd: the driver name reminds everyone about ath9k though :) Feb 05 21:53:45 ok Feb 05 21:53:47 Borromini: A new way to cause FW crashes on your router xD Feb 05 21:53:48 uh, https://github.com/AdelieLinux/gcompat Feb 05 21:53:52 mamarley: hahaha Feb 05 21:54:08 a new wave to crash your router >:-) Feb 05 21:54:19 question is: will there also be a ath11k-ct ? Feb 05 21:54:54 ipq807x SOC code will be a bigger issue before it comes to that Feb 05 21:55:19 some of it is already upstream Feb 05 21:55:54 I've only given it a small look so far, but it doesn't quite seem to be complete (and submissions stopped around may/ june 2018) Feb 05 21:56:20 it should be "enough" to get a initramfs + serial Feb 05 21:56:29 to boot. Feb 05 21:56:29 just enough to make their job easier, not enough to enable others to boot their own stuff Feb 05 21:56:32 :D Feb 05 21:56:58 what's interesting with the FW is that they no longer ship any board-2.bin Feb 05 21:57:27 a bunch of bdwlan* seem to be needed instead Feb 05 21:58:16 let's hope that these are all in the ART Feb 05 21:59:05 I wouldn't be too optimistic about that Feb 05 22:01:34 only caldata.bin seems to come from ART Feb 05 22:02:41 isn't ART only calibration data for the radios? Feb 05 22:03:11 more or less, yes (plus MAC addresses - *if* the OEM filled it out) Feb 05 22:03:46 sven actually looked what the FW did with the pre-cal and board data Feb 05 22:04:22 but from what I remember it also depended on values in the OTP Feb 05 22:05:40 My best guess is that they needed to have a way to update the caldata during a product's lifetime. Feb 05 22:09:47 what would be the rationale behind that? Feb 05 22:22:41 If I were rolling out a new technology, I'd want to e able to update things when I found out how it all performed "in the real world" Feb 05 22:31:40 depends like +LIBCURL_WOLFSSL:libwolfssl, they're like an if(LIBCURL_WOLFSSL) DEPENDS+=libwolfssl, right? Feb 05 22:47:35 something like that Feb 05 22:48:19 <\x> oh wow ath11k Feb 05 22:54:42 karlp: thanks Feb 05 23:00:07 so far now compiler hiccups due to musl 1.1.21 Feb 05 23:00:35 ah good I was just pondering that Feb 05 23:01:59 *no Feb 05 23:02:21 jwh: it makes it hard to make prerolled binaries installeable for people of course. Feb 05 23:02:37 karlp: hm how do you mean? Feb 05 23:03:21 what's setting libcurl_woflssl? Feb 05 23:03:26 you hhave to choose taht in menuconfig Feb 05 23:03:29 from what I know the "+" means that this "selects" the package Feb 05 23:03:29 nothing it was just an example Feb 05 23:03:48 I noticed the +DEPEND:thing, was just wondering if I guessed right Feb 05 23:03:48 heh Feb 05 23:08:46 I think I did based on my quick test results... Feb 05 23:37:09 lach1012: I've just done a quick test of your "ipq806x: 4.19" staging commit on the nbg6817 (ipq8065), very early testing are looking fine (http://paste.debian.net/hidden/19ee43bf/), thanks a lot! Feb 05 23:40:12 pkgadd: hm. doesn't look like usb3 is working. maybe you are still using the dwc-of-simple module? Feb 05 23:43:10 lach1012: hmm, I'm not using USB at all on that device, but I think that should have been left at its defaults/ DEVICE_PACKAGES (diffconfig http://paste.debian.net/1065494/) Feb 05 23:44:17 but, yes - # CONFIG_PACKAGE_kmod-usb-dwc3-qcom is not set Feb 05 23:44:53 ah, yes that's the one. It will be important from 4.19+ Feb 05 23:45:29 http://paste.debian.net/1065495/ Feb 05 23:46:37 hm Feb 05 23:47:02 # CONFIG_PACKAGE_kmod-usb-phy-qcom-dwc3 is not set Feb 05 23:47:18 this is needed as well Feb 05 23:50:36 hmm, CONFIG_PACKAGE_kmod-usb-phy-qcom-dwc3 Depends on: (TARGET_ipq40xx [=n] || TARGET_ipq806x [=y]) && !LINUX_4_19 [=y] && TARGET_ipq806x [=y] && USB_SUPPORT [=y] Feb 05 23:50:50 ooh right Feb 05 23:50:50 I think that means it can't be enabled with kernel 4.19 Feb 05 23:51:02 I added the phy drivers directly to the config-4.19 Feb 05 23:52:21 ah, yep CONFIG_PHY_QCOM_DWC3=y Feb 05 23:52:25 gch981213: ping Feb 06 00:01:16 lach1012: http://paste.debian.net/hidden/841f398a/ now with CONFIG_PACKAGE_kmod-usb-dwc3=y and CONFIG_PACKAGE_kmod-usb-dwc3-qcom=y explicitly enabled Feb 06 00:07:34 pkgadd: http://paste.debian.net/hidden/d71f167a/ Mathias' wpq864 . Maybe something is wrong with the IPQ8065/IPQ8064-V2?! Feb 06 00:08:32 oh well. I think this has to be it for today though. Feb 06 02:47:08 Mangix: pong **** ENDING LOGGING AT Wed Feb 06 02:59:57 2019