**** BEGIN LOGGING AT Tue Feb 26 02:59:57 2019 Feb 26 06:13:17 * russell-- flashed a ubnt nanostation5 xw but eth0 didn't work ... it seemed to be up, but couldn't talk over it. tcpdumping the other side of the ethernet cable across a power cycle, i saw a few ipv6 packets (total of about 600 bytes), but nothing else. Feb 26 06:13:35 flashed the old r42xxx openwrt firmware, and it works fine Feb 26 06:14:11 the new firmware was ar71xx, as ath79 looked not quite ready for the device Feb 26 06:14:50 unfortunately, i don't have more xw's to play with on the bench afaik Feb 26 06:14:59 * russell-- goes to look in the basement Feb 26 06:18:55 unfortunately, nobody seems to wanna touch ar71xx code with a 10' pole now Feb 26 06:20:00 * russell-- has been trying to avoid buying more ubnt gear because of their idiotic locked bootloader shenanigans Feb 26 06:20:29 erx is good, exception granted there Feb 26 06:22:10 i think i have three m xw: a nanostation m2, nanostation m5 and a loco m5 Feb 26 06:51:18 i'm seeing a bunch of these on another ubiquiti loco (not xw). one right next to it, with pretty much the same firmware, works fine: Feb 26 06:51:22 [ 8280.428705] br-pub: received packet on eth0 with own address as source address (addr:68:72:51:0b:c5:38, vlan:0) Feb 26 06:57:50 do you at least have a serial port for debugging/recovery? Feb 26 06:58:52 looks like a bridge loop, but can't imagine how Feb 26 06:59:15 maybe a bug in the gateway router switch Feb 26 06:59:44 * russell-- is logged in over wifi from an adjacent ap Feb 26 07:06:55 there is a switch chip in the loco m2, but only one port shows up Feb 26 07:29:59 literally, the loco next door is configured exactly the same, whisky tango foxtrot Feb 26 07:33:15 the other end (a tplink wdr3600) sees the link change state if i ifconfig eth0 down/up at the loco end Feb 26 08:13:23 mangix: from the quick peek into it, I don't think so Feb 26 08:14:38 mangix: the problem is quite easy to reproduce reliably, so you could revert my fix and try this approach instead and check the result by yourself Feb 26 08:16:35 mangix: BTW I'm wondering if there is any info about the QSDK, so one could understand what this crazy branch names means etc. Feb 26 08:20:41 ynezz: no idea. but their ag71xx driver has useful stuff that can be ported to the one in ath79 Feb 26 08:20:58 their SPI driver too actually Feb 26 08:22:51 there's also this commit. could be similar. https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit/drivers/net/ethernet/atheros/ag71xx?h=NHSS.ILQ.2.15&id=48ced9e16bba60bc30563266ee645b0225342adb Feb 26 08:34:02 mangix: might be similar issue Feb 26 08:44:09 what's the reason behind using the 4.14 kernel? Feb 26 08:53:08 charolastra: what do you mean? Feb 26 08:55:00 we seem to have issues with the mt76 wireless driver. so i checked what kernel versions are in use and 4.14 seems rather old. or are such changes backported nowerdays? Feb 26 08:55:34 4.14 is an LTS kernel Feb 26 08:55:46 the next one, 4.19 is still fairly recent Feb 26 08:56:20 the mt76 pretty up to date Feb 26 08:57:35 https://github.com/openwrt/mt76 Feb 26 09:01:17 afaik that's newer than what is upstream Feb 26 09:01:29 hmm, i see. thanks Feb 26 09:02:06 charolastra: what radio are you having trouble with? Feb 26 09:03:50 the device is a TL-WR902AC Feb 26 09:04:47 and which version of openwrt? Feb 26 09:05:21 and the issue is that after some time the mobile apple clients seem to loose packets and their whole network stops Feb 26 09:06:02 master or 18.06.2 Feb 26 09:07:27 does it throw anything in dmesg? Feb 26 09:08:29 no, that's fine. and other connected clients (android) can continue using the AP without any interruption Feb 26 09:19:05 ac or n? Feb 26 09:20:29 you could try setting up a sniffer and capture that packets in a problematic session, might help someone figure out what's going wrong Feb 26 09:24:39 charolastra: wireless drivers are build out of tree and taken from a much more recent kernel Feb 26 09:25:55 n i guess. already did that by running tcpdump on the router. shows an awfull lot of out-of-order packages, dup ACK, failure to complete SYN, ACK handshakes, etc. Feb 26 09:26:16 thinking about sniffing the over the air traffic now Feb 26 09:26:24 KanjiMonster: thanks for the info Feb 26 09:58:14 does anyone know why the nano-m (loco) has an eth1 in addition to eth0 and why it has a switch and why only one port seems to be active? Feb 26 10:00:26 https://pastebin.com/kx3y82Sm Feb 26 10:03:46 4.19 on mt76 devices when? Feb 26 10:04:47 russell--: because all ath79 SoCs except the first generation (714x/716x/913x) has an integrated FE switch core (and two ethernet macs) Feb 26 10:06:19 KanjiMonster: that makes sense, except for the one port active Feb 26 10:07:51 * russell-- assumes the cpu port is wired straight to the ethernet connector Feb 26 10:08:29 any theories why its seeing its own macaddr? Feb 26 10:09:25 even when the port on the other end of the ethernet cable is detached from the bridge Feb 26 10:12:47 swconfig on the connected router: https://pastebin.com/Qa7MK5dP Feb 26 10:14:30 russell--: AFAIK one of the macs is hardwired to the switch, and one can either be muxed to one of the integrated fast ethernet phys/ports, or exposed to connect your own (probably then gigabit) phy Feb 26 10:17:00 here is the port information on the connected router: https://pastebin.com/Vp79P9fs Feb 26 10:18:11 port 2 is where the ethernet connects Feb 26 10:26:26 hmm, the adjacent loco has the problematic loco's macaddr in its bridge table as a non-local mac Feb 26 10:28:00 i was seeing this problem both with old (1+ years) and new openwrt firmware, but it started suddenly a week or so ago. Feb 26 10:29:05 totally weird, hoping power cycle magically fixes it Feb 26 10:35:16 windows is installed in your router? Feb 26 10:38:18 fyi, x86/geode is broken due to the recent radeon changes: http://phase1.builds.lede-project.org/builders/x86%2Fgeode/builds/1262/steps/kmods/logs/stdio Feb 26 10:38:40 having another look at the buildbot why it's not announcing anything on IRC Feb 26 10:53:17 ah Feb 26 10:53:29 the buildbot is announcing in a different channel nowadays Feb 26 11:05:51 stintel: which one? Feb 26 11:07:20 #openwrt-devel-build Feb 26 11:08:21 also where did you find that info Feb 26 11:08:50 KanjiMonster: in the buildbot config / log Feb 26 11:09:05 I see Feb 26 11:21:54 crim-: after the release of openwrt 19.0x Feb 26 11:25:20 based. Feb 26 12:09:25 Neighbor11111116: please stop your reconnects - its annoying Feb 26 12:13:34 sorry rubberduck it is my laptop moving about Feb 26 12:14:00 having problems with your wifi cable? Feb 26 12:15:21 roaming gone wrong? Feb 26 12:29:47 stintel, o/ Feb 26 12:32:29 nitroshift: yo Feb 26 12:42:04 how would I restart just a single interface from the cli like via luci? Feb 26 12:43:29 Strykar: "restart" in what aspect? Feb 26 12:44:08 ah, the "restart" or "stop" one. Feb 26 12:44:24 SwedeMike, yea Feb 26 12:47:21 SwedeMike, ah, the highly cryptic /sbin/ifup and ifdown will do it :) Feb 26 12:49:42 right, makes sense Feb 26 13:43:30 Hauke: Hi, do You still have espressobin with old U-Boot version (2015.01)? Can You test this https://github.com/tmn505/openwrt/commit/f707184a3d88e8ff679d18fc8afbadb3e0c33ab7 if it boots wihout altering U-Boot environment? Feb 26 14:17:56 U-Boot 2017.03-armada-17.10.1-gaee49fc (Jan 29 2018 - 18:21:49 +0800) Feb 26 14:35:29 given: https://pastebin.com/iwJ9WSLM how to send a swconfig command to disable port 0? Feb 26 14:44:46 fiddling with various bits, still seeing: [16701.869965] br-pub: received packet on eth0 with own address as source address (addr:68:72:51:xx:xx:xx, vlan:0) Feb 26 15:04:17 russell--: that's too fresh one, I've got the same, but thanks for volunteering. Feb 26 16:32:23 Checking current state of ath10k-CT next -- at least previously didn't support mesh (at all) Feb 26 17:55:17 tmn505: ok I will test this Feb 26 21:42:34 Short of looking through the OEM' Feb 26 21:43:00 s GPL drop for U-Boot, is there a way to tell of ATAGs are being passed at all in a FDT AMR boot? Feb 26 21:45:50 https://www.kernel.org/doc/Documentation/arm/Booting makes it seem that if a DTB is passed via the r2 pointer, that there aren't ATAGs Feb 26 21:46:21 (so the ATAG-based command-line "hacks" don't work) Feb 26 21:47:29 s/AMR/ARM/ Feb 26 22:37:24 Gotta love Linux boot code that begins with /* OK... Let's do some funky business here. Feb 26 22:59:25 Yep, /* if we get a DTB here we're done already */ Feb 26 23:00:04 So ATAG-based command-line mangling like other patches gets short-circuited Feb 26 23:01:03 Just glad the kernel isn't written in LISP ;) Feb 27 00:31:29 jeffsf: when it comes to hardware support, there's pretty much always heaps of funky business involved. because even if the hardware is plain mad and wrong, the software will be the one to suffer for fixing it up, because fixing the hardware goes into the thousands or millions. you don't really want to read some of the comments for low level arch and/or driver support Feb 27 00:34:55 LOL, yeah, this is the assembly code when the kernel is first called -- it's "amusing", to say the least Feb 27 00:36:30 Anyone else seeing Feb 27 00:36:31 target/linux/ipq40xx/patches-4.14/901-arm-boot-add-dts-files.patch Feb 27 00:36:39 patch: **** malformed patch at line 38: qcom-msm8960-cdp.dtb \ Feb 27 00:39:31 likely line 37 in master Feb 27 01:08:40 (Looks like my issue, `master` builds OK) Feb 27 01:30:44 Bugger, Linksys didn't include the U-Boot code in the GPL drop **** ENDING LOGGING AT Wed Feb 27 02:59:56 2019