**** BEGIN LOGGING AT Sat Jan 09 02:59:57 2021
Jan 09 08:17:53 <aliceussr> Hello! Can you please tell me where you can change the hostapd configuration?
Jan 09 08:23:18 <aliceussr> Hello! Can you please tell me where you can change the hostapd configuration?
Jan 09 08:24:29 <PaulFertser> aliceussr: /etc/config/wireless
Jan 09 08:27:15 <aliceussr> PaulFertser: Not right!
Jan 09 08:27:38 <PaulFertser> aliceussr: hostapd configuration is auto-generated from that file, so that's right.
Jan 09 08:31:44 <aliceussr> PaulFertser: What script generates hostapd config?
Jan 09 08:35:52 <PaulFertser> aliceussr: /lib/netifd/hostapd.sh
Jan 09 08:39:52 <PaulFertser> aliceussr: /lib/netifd/hostapd.sh
Jan 09 09:43:47 <aliceussr> Can you please tell me how to force hostapd to set the hw_mode = n parameter?
Jan 09 09:56:52 <PaulFertser> aliceussr: are you sure such a hw_mode exists at all? You're supposed to be using a for 5 GHz.
Jan 09 09:57:18 <PaulFertser> 802.11n features are enabled with a separate option
Jan 09 10:00:54 <aliceussr> .!..
Jan 09 10:01:11 <Borromini> morning guys
Jan 09 10:02:05 <PaulFertser> aliceussr: are you seriously asking me how to generate a config with which hostapd won't start at all?
Jan 09 10:02:07 <Borromini> svanheule[m]: hi. Adrian merged my patches, but he left the switch SFP macros out. So they still look OK compared to the old DTS, or am I wrong?
Jan 09 10:05:10 <svanheule[m]> Borromini: doesn't look like they changed the merged patch, so no loss of functionality :-)
Jan 09 10:05:52 <Borromini> yeah :)
Jan 09 10:06:12 <Borromini> so that's good then.
Jan 09 11:02:14 <aliceussr> Can you please tell me how to force hostapd to set the hw_mode parameter to n?
Jan 09 11:05:22 <PaulFertser> aliceussr: I've already told you that's most likely not going to work!
Jan 09 11:05:44 <PaulFertser> hostapd won't even start due to incorrect parameter, and that's all.
Jan 09 11:34:35 <hgl> a newbie question. how do i contribute to openwrt? If I want to add a feature, where do i propose to see if it's even wanted?
Jan 09 11:40:14 <Borromini> hgl: ideally by sending in a patch - see https://openwrt.org/submitting-patches
Jan 09 11:41:17 <hgl> thanks, checking
Jan 09 11:44:17 <hgl> is it possible to propose the feature first to see if it's wanted? or it must be submitted via a patch?
Jan 09 11:45:55 <Borromini> you can always ask. but if you want to see something supported you'll need to provide code, not just an idea
Jan 09 11:47:04 <hgl> sounds fair, if i ask, should i ask in the mailing list?
Jan 09 11:48:13 <Borromini> sure, or here (or both)
Jan 09 13:27:50 <blocktrron> nbd: do you have a clue, whether or not HE160 / 80P80 capability is  from the EEPROM
Jan 09 13:29:13 <blocktrron> do you have a clue, whether or not HE160 / 80P80 capability is indicated from the EEPROM. mt76 advertises HE160 for my U6 Lite, however if turned on clients will stick to non-ht rates.
Jan 09 13:30:00 <blocktrron> Ubiquiti does not advertise HE160 for this product, so my naive assumption is that this is a hard limitation somewhere and not just fuzz from the product management
Jan 09 13:45:56 <blogic> blocktrron: what client is that
Jan 09 13:46:08 <blogic> blocktrron: I have not seen clients that are 80p80 capable
Jan 09 13:46:17 <blogic> and HE160 requires 8x8
Jan 09 13:47:24 <blocktrron> It was an AX210
Jan 09 13:48:14 <blogic> HE PHY Capabilities: (0x0e3f0200fd09800ecff200):
Jan 09 13:48:14 <blogic> 				HE40/2.4GHz
Jan 09 13:48:14 <blogic> 				HE40/HE80/5GHz
Jan 09 13:48:14 <blogic> 				HE160/5GHz
Jan 09 13:48:20 <blogic> that cant do 80p70
Jan 09 13:48:26 <blogic> but claims 160
Jan 09 13:48:49 <blocktrron> let me check
Jan 09 13:49:09 <blogic> 				80MHz in 160/80+80MHz HE PPDU
Jan 09 13:49:24 <blogic> ok, it claims that it can do he80 on a he160 80p80
Jan 09 13:49:34 <blocktrron> ah okay
Jan 09 13:49:38 <blogic> however, i do not recall hapd having the code to negotiate that
Jan 09 13:49:42 <blocktrron> then i misred that
Jan 09 13:49:59 <blogic> unless someone added that code, but i never handled that case when i wrote the HE support for hapd
Jan 09 13:50:39 <blogic> HE PHY Capabilities: (0x0e3f0200fd09800ecff200):   is what the phy is capable of, yet that requires userland code to properly tell the kernel how to assoc
Jan 09 13:51:37 <blocktrron> still, is 160MHz support  potentially limited in hardware on the MT7915 / by the caldata?
Jan 09 13:51:53 <blogic> not sure
Jan 09 13:53:20 <blogic> I have a dlink ax1800 here which is mt7621/7915, planning to make that work tomorrow
Jan 09 13:53:31 <blocktrron> i'll try to reproduce (and document) what I'm facing here
Jan 09 13:53:38 <blogic> cool
Jan 09 13:53:53 <blocktrron> maybe the AX210 isn't the best to test against in it's current state
Jan 09 13:54:51 <blocktrron> the d-link uses DBDC on the MT7915?
Jan 09 13:58:05 <blogic> not sure
Jan 09 13:58:10 <blogic> and ax201 works well for me
Jan 09 14:01:29 <blocktrron> blogic: https://gist.github.com/blocktrron/6e78e367f536b7fe69caa665b5c57e73
Jan 09 14:01:55 <blocktrron> Using AX200
Jan 09 14:02:39 <blocktrron> iwinfo reports only 54 Mbit/s non-HT in RX direction when iperf is running
Jan 09 14:05:02 <blogic> iwinfo does not handle HE
Jan 09 14:05:13 <blocktrron> ah sorry
Jan 09 14:05:18 <blocktrron> i mean iw on the client side
Jan 09 14:05:21 <blogic> iw dev wlan0 station dump
Jan 09 14:08:03 <blogic> is one iperf3 running on the device ?
Jan 09 14:08:55 <blocktrron> no, its running on the GW (x86)
Jan 09 14:08:59 <blogic> kk
Jan 09 14:08:59 <blocktrron> https://gist.github.com/blocktrron/66540b2d24e475b76f0c3b3f495ebbe9
Jan 09 14:09:06 <blocktrron> this is from the AP
Jan 09 14:09:17 <blogic> ok, something is wrong then
Jan 09 14:10:29 <blocktrron> Does your D-Link advertise 160MHz capability?
Jan 09 14:11:45 <blocktrron> I don't have a problem with 160MHz not working on the U6 Lite IF it is due to a limitation somewhere and it just needs to stop advertising HE160, being it by adding a property to the WiFi node or evaluating a maybe-existant flag in the eeprom
Jan 09 14:12:18 <blocktrron> I just don't know if this is the case or it's a 160MHz specific mt76 problem
Jan 09 14:13:17 <blocktrron> Hence why i bring this up :P
Jan 09 14:19:03 <blogic> yeah
Jan 09 14:19:06 <blogic> blocktrron: pm
Jan 09 14:26:11 <dangole> blocktrron: could be a limitation of the frontends/mixers used in that device, try finding the datasheet of those maybe. but the 'Lite' in the name hints that maybe there aren't any...
Jan 09 14:27:50 <blogic> dangole: lite becasue it is ax1800
Jan 09 14:27:58 <blogic> dangole: and yes could be shitty eeprom
Jan 09 14:32:04 <dangole> blocktron: just checked some, SKY85408-11 for example states only up to HT80
Jan 09 14:40:56 <blocktrron> dangole: still iexpect the rate controller do do more than 54 Mbit/s
Jan 09 14:43:38 <blocktrron> the board to me looked like there were no external frontends
Jan 09 14:44:25 <blocktrron> I'll upload the pictures i did. The board is different from the one pictured at the fcc
Jan 09 14:53:11 <blocktrron> https://imgur.com/a/54IQyIB
Jan 09 14:53:36 <olmari> hmm... I'm trying to put bind in openwrt to act as dns server, but also resolver... AFAIK configs should be fine, but  it fails to resolve anything with permission denied
Jan 09 14:53:41 <olmari> Sat Jan  9 16:50:40 2021 daemon.info named[9615]: permission denied resolving '_.fi/A/IN': 2001:500:12::d0d#53
Jan 09 14:54:46 <olmari> hmm.. now that I think of it, all denies are IPv6... Which this conneciton still does not sadly have... I'll dif more
Jan 09 14:56:44 <olmari> so.. not likely openwrt issue itself, but now I wonder how I'd tell Named to query only through IPv4
Jan 09 15:13:59 <dangole> blocktrron: right, there is nothing there, antennas connected more or less straight to the wifi chips
Jan 09 15:40:01 <aliceussr> Comrades! Please advise the OpenWRT firmware for MTK7620A with FLASH 32M so that the WiFi speed is at least 80-90 Mbps.
Jan 09 15:44:49 <olmari> okay I made bind to only use ipv4 ever anywhere by editing init.d file, good enough for now :)
Jan 09 15:45:23 <f00b4r0> I wonder if we could get rid of the soviet troll?
Jan 09 15:48:38 <dangole> aliceussr: maybe you are better off with Wive-NG-MT using proprietary driver then: https://gitlab.com/Ntemis/wive-ng-mt
Jan 09 15:51:32 <ldir> f00b4r0: ignore, will go away at some point, probably when Trump is finally kicked out ;-)
Jan 09 15:51:48 <f00b4r0> ;-)
Jan 09 15:53:03 <aliceussr> dangole: How to connect it to OpenWRT?
Jan 09 15:53:08 <f00b4r0> ldir: although i thought trump was supposed to prevent soviets from taking over america? ^o^
Jan 09 16:03:02 <dangole> aliceussr: no, this is a different distribution, not connected to OpenWrt. the vendor driver requires outdated platform kernel. no way to use this on recent OpenWrt. there are forks of 15.05 out there with prehistoric kernel patched in to work with that vendor driver...
Jan 09 16:04:58 <dangole> aliceussr: of course, if you want to use OpenWrt you can go ahead and improve rt2x00 driver to match your performance needs on the device you are using. i'm not saying this is impossible to achieve.
Jan 09 16:07:21 <aliceussr> dangole: Thank you very much for the information, comrade!
Jan 09 17:11:40 <olmari> BTW, miniupnpd also now works with current master, so thank you for that too (no public ipv6 here, does it affect or not, ULa is stil lexisting)
Jan 09 17:12:10 <olmari> I know IPv6 and UPnP (port forwards) doesn't generally relate, but wouldn't be first time combo had proplems in the history =)
Jan 09 20:18:04 <hurricos> blocktrron: FCC has posted photos?
Jan 09 20:18:48 <hurricos> https://fccid.io/SWX-U6LITE ?
Jan 09 20:19:04 <hurricos> Still under confidentiality. I must be misreading you.
Jan 09 20:56:15 <hurricos> blocktrron: Thanks for the photos. Uploaded to https://wikidevi.wi-cat.ru/Ubiquiti_Unifi_6_Lite
Jan 09 20:56:25 <hurricos> (I never know whether to focus on Wi-cat or techinfodepot)
Jan 09 20:57:02 <aparcar[m]> adrianschmutzler: please look at https://github.com/aparcar/devices/pull/2 as an example
Jan 09 21:29:22 <ldir> anyone seen rsalvaterra recently?
Jan 09 21:32:46 <pkgadd> recently as in yesterday morning (and he's connected( idle right now)
Jan 09 22:11:49 <dangole> just realizing tplink-v1 ath79 snapshot images are not booting because lzma decompression on tp-link loader fails, probably kernel grew too large and we need to wrap that one with okli as well
Jan 09 22:12:31 <Borromini> dangole: tplink-v1?
Jan 09 22:15:32 <dangole> Borromini: ie. non-safeloader non tplink-v2-image devices. all the legacy tp-link devices but mostly also all the other vendors which adopted tp-link-v1 image format (and bootloader)
Jan 09 22:17:57 <Borromini> oh
Jan 09 22:23:28 <pkgadd> I've pretty much lost track of all the different (recent'ish) tp-link firmware formats by now (only having old-style devices, tl-wr941nd v2, tl-wr1043nd v1, tl-wdr3600, tl-wdr4300)
Jan 09 22:26:22 <Borromini> they'll all break at some point :P
Jan 09 22:27:20 <pkgadd> uboot-mod is working pretty well on my tl-wdr3600/ tl-wdr4300, the OEM u-boot can recovery reliably on the tl-wr1043nd v1, but the tl-wr941nd v2 can't recover without serial console access
Jan 09 22:33:20 <Borromini> i installed breed on my archer c5 v1, haven't set it up yet though.
Jan 09 22:33:29 <Borromini> what uboot-mod are you using pkgadd? pepe2k?
Jan 09 22:33:33 <pkgadd> yes
Jan 09 22:33:47 <Borromini> but not on the 1043 v1 i suppose?
Jan 09 22:34:16 <Borromini> i tried to find it for that one a few years ago but no binaries, compiled it myself but it broke the v1 :P
Jan 09 22:34:43 <pkgadd> works nicely (but to be fair, the OEM bootloader was working well on the tl-wdr3600/ tl-wdr4300 as well, needed to recover those a couple of times). sadly no uboot-mod for the tl-wr1043nd v1 (but it still recovery reliably using the -updated- OEM bootloader)
Jan 09 22:35:56 <Borromini> that's good
Jan 09 22:36:01 <Borromini> i assume you keep it for testing?
Jan 09 22:36:21 <Borromini> btw is there a way to find out the kernel size from a running system?
Jan 09 22:36:23 <pkgadd> well, they're mostly sitting around unused these days
Jan 09 22:36:26 <Borromini> :)
Jan 09 22:36:39 <pkgadd> they've had their years of active service
Jan 09 22:37:42 <pkgadd> I wanted to use the tl-wdr3600 for the last few months of my VDSL2/ PPPoE service, but it was crashing constantly over ~summer
Jan 09 22:38:00 <pkgadd> now I'm using the bthub5 instead
Jan 09 22:43:31 <pkgadd> I'd love to use the map-ac2200 instead of the bthub5, but just not enough ethernet ports to be useful for that (perhaps I'll fetch another gs1900-whatever to help with that ;)
Jan 09 22:57:52 <mangix> the snapshot SDKs do not use latest master
Jan 09 22:57:57 <mangix> wonder what's going on...
Jan 09 22:58:22 <mangix> date looks good
Jan 09 23:01:14 <hurricos> Anyone have any clues why two nodes, each with two WNICs, each in 11s mode, bridged to the same network, would cause a broadcast storm?
Jan 09 23:01:24 <hurricos> s/would/does/
Jan 09 23:03:00 <hurricos> With eth switches I think STP prevents cycles, but 11s doesn't seem to do anything like that.
Jan 09 23:03:40 * hurricos thinks he's answered his own question
Jan 09 23:04:18 <PaulFertser> hurricos: but you can enable STP on those Linux software bridges that are bridging wireless to wired
Jan 09 23:05:00 <hurricos> PaulFertser: You mean the if named by default `br-lan`?
Jan 09 23:05:05 <PaulFertser> hurricos: yes
Jan 09 23:07:51 <hurricos> PaulFertser: Thanks, I've been trying to answer that one since June 2019.
Jan 09 23:08:17 <PaulFertser> hurricos: I'm not promising it will help, I do not know enough about STP. But it might.
Jan 09 23:08:53 <Borromini> pkgadd: well there's more in master now :D
Jan 09 23:09:04 <Borromini> and you can add the non-PoE when you get it :P
Jan 09 23:09:23 <hurricos> It's easy enough to try, and makes sense to me
Jan 09 23:09:36 <pkgadd> yep, I've seen the patches going in :)
Jan 09 23:09:52 <Borromini> pkgadd: you can probably just flash the GS1900-8HP image onto it since PoE isn't handled through devicetree
Jan 09 23:10:07 <Borromini> yes, i gave adrian a fulltime job on the review :-/
Jan 09 23:10:43 <pkgadd> yep, depends on what I'll get (I have my eyes on a gs1900-8, a gs1900-24e and a gs1900-24) - just waiting how the prices will evolve
Jan 09 23:11:53 <Borromini> :)
Jan 09 23:13:04 <Borromini> with bkobl announcing support for a multi-gigabit RTL9xxx SoC, i gotta admit i've been eyeing the ZyXEL XGS1210-12 as well :-/
Jan 09 23:13:08 <Borromini> no usecase though :P
Jan 09 23:13:57 <pkgadd> I really want 10 GBit/s, but not for the current prices
Jan 09 23:14:20 <Borromini> a full 10 Gb switch? :)
Jan 09 23:14:27 <Borromini> that's still 500-ish apparently
Jan 09 23:14:40 <Borromini> XGS1210-12 has 2x 2,5 and 2x 10 (SFP+)
Jan 09 23:14:45 <Borromini> for ~200
Jan 09 23:16:26 <pkgadd> I'd like a full 10 GBit/s one, but prices are just insane - none of my computers currently have >>1 GBit/s ethernet connectivity (but that could be changed, even for reasonable prices).
Jan 09 23:17:32 <Borromini> hehe
Jan 09 23:22:47 <pkgadd> Borromini: ah, do you happen to know what functionality the hidden button sw1 is supposed to provide?
Jan 09 23:23:41 <pkgadd> top right, https://biot.com/switches/_media/wiki/gs1900-24e-pcb-top.png under s1
Jan 09 23:24:57 <Borromini> pkgadd: no, sorry. i've seen them on my GS1900-8HP PCB too, though
Jan 09 23:26:26 <pkgadd> btw. I've taken a peak into my old TP-Lik TL-SG1016D v1 unmanaged switch, the markings on the pcb suggest broadcom "(BCM)" - but I do see a suspicions unpopulated 4 pin header on the pcb...
Jan 09 23:27:01 <Borromini> :)
Jan 09 23:33:30 <pkgadd> judging from (presumably) similar (managed-) routers, it's not running linux though (around half a MB firmware size)
Jan 09 23:40:02 <rsalvaterra> ldir: I'm here :)
Jan 09 23:42:15 <Borromini> pkgadd: you think the exposed chips might not be the SoC?
Jan 09 23:45:25 <pkgadd> Borromini: there are huge heat sinks over all the interesting chips, so no real idea what's beneath them (just guessing based on the (BCM) marking), but the unpopulated 4 pin header is tempting my interest nevertheless
Jan 09 23:47:29 <Borromini> =)
Jan 09 23:51:41 <nlowe> Even with AX Wi-Fi, there remains extremely little genuine/real use cases for a backhaul above 1 Gb/s
Jan 09 23:51:58 <nlowe> And many/most are using Wi-Fi as the access medium these days
Jan 09 23:52:44 <pkgadd> Borromini: https://sl-h.de/tmp/IMG_20210106_043227.jpg
Jan 09 23:52:45 <nlowe> I have zero use for mgig or 10 Gb/s switching personally
Jan 09 23:53:23 <Borromini> nlowe: at this point, neither do i.
Jan 09 23:55:34 <pkgadd> I'd really like having >>1 GBit/s between my workstations (and their storage backend)
Jan 09 23:57:24 <dorf_> 2.5 is the logical upgrade.
Jan 09 23:57:33 <dorf_> no need for new cabling.
Jan 09 23:57:44 <pkgadd> perhaps, but I'm not paying for /just/ that
Jan 09 23:58:37 <dorf_> yeah, sure, 1Gb/s isn't too bad.
Jan 09 23:59:36 <dorf_> if you're pushing a bunch of 4K videos over the lan, then maybe an upgrade is a good idea.
Jan 09 23:59:56 <dorf_> otherwise, I agree, it's hard to make a case for a switch and adapter upgrade.
Jan 09 23:59:57 <pkgadd> and at least for me, the important systems (which do profit for ethernet performance most) are sitting in one room, so cables wouldn't be a problem with 10GBase-T either (at <10m, even the existing patch cables should do)
Jan 10 00:00:46 <nlowe> For those editing 4K footage and backing it up/transferring it around, makes perfect sense
Jan 10 00:01:15 <pkgadd> I do regularly transfer files in the ~150 GB range over the network
Jan 10 00:03:41 <Borromini> guys, the LEDs on my R6800 don't seem to do anything... how do i 'tickle' them?
Jan 10 00:04:02 <Borromini>  /sys/class/leds/ only has mt76 phy0/phy1 entries
Jan 10 00:04:37 <dorf_> I use the Luci app to tickle leds.
Jan 10 00:04:39 <Borromini> the predefined white:lan1/lan2/... ones in /sys/bus/platform/devices/leds/of_node/ have a file 'gpios' that's empty
Jan 10 00:04:48 <Borromini> dorf_: that's not working here :(
Jan 10 00:04:51 <Borromini> first thing i tried too.
Jan 10 00:05:12 <dorf_> hmm
Jan 10 00:05:48 <Borromini> it's very weird. LAN2 is on now, now that there's a loose cable inserted (...)
Jan 10 00:05:52 <dorf_> what if you set the discovered leds' default state to on, Borromini?
Jan 10 00:06:04 <dorf_> just to see if anything responds..
Jan 10 00:06:08 <Borromini> when it had a device on the other end, it was off >_>
Jan 10 00:06:10 <Borromini> sec
Jan 10 00:10:11 <dorf_> the other thing to try in luci is adding an led action to any and every led that's not explicitly referenced in the UI (there are probably a bunch of unmapped dummy leds there)
Jan 10 00:11:22 <Borromini> yeah, but the led name is a dropdown menu that basically only shows the phys
Jan 10 00:11:26 <Borromini> which is a bit eird
Jan 10 00:11:31 <Borromini> * weird
Jan 10 00:11:55 <Borromini> even the predefined lan leds fall back to the phy ones when you edit them >_>
Jan 10 00:13:15 <dorf_> I've noticed some weirdness with editing, as an aside. Here the configs save fine, work ok, but a router reboot resets them until you tweak a single led def, and then the previously saved configs kick in.
Jan 10 00:13:31 <Borromini> ok
Jan 10 00:13:39 <Borromini> are you on master or 19.07?
Jan 10 00:13:52 <dorf_> 19.07.04
Jan 10 00:14:03 <Borromini> ok
Jan 10 00:24:18 <Borromini> hmmm.
Jan 10 00:24:33 <Borromini> it looks like someone tore out the whole led code from the r6800 dts in master.
Jan 10 00:27:50 <Borromini> ok into a dtsi, so that shouldn't be an issue. weird.
Jan 10 00:27:59 <Borromini> anyway... way past bedtime. goodnight!
**** ENDING LOGGING AT Sun Jan 10 03:00:21 2021