<huaracheguarache>
Good morning. I've made a pull request a couple of days ago to enable Operating Channel Validation for hostapd/wpa_supplicant in OpenWrt. Would somebody mind taking a look at it to check if it's fine or if I need to change something?
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<Slimey>
hi
Borromini has joined #openwrt-devel
Lynx- has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<Slimey>
i have a device that runs great on v19.07.8 but past that I start to have network issues over LAN interface, how to trouble shoot this
<hurricos>
Hey Slimey
<hurricos>
What's the device?
goliath has quit [Quit: SIGSEGV]
<Slimey>
interesting enough its that cap324 i got
<hurricos>
Oh hey. Yeah, was it already running ath79 by the time v19.07.8 came around
<hurricos>
It must have been.
<hurricos>
There was a device tree :P
<Slimey>
over wifi its fine, but anything over lan it times out or just has trouble reaching the device over ssh, or web
<hurricos>
The config is stock config, right?
<Slimey>
yeah
<hurricos>
Or perhaps stock config with some tweaks to have it be a DHCP client
<Slimey>
i almost would have chalked it down to a hardware problem but like i said on 19.x its fine
<hurricos>
Could you try it on a 10/100-only switch?
<hurricos>
If you still have one of those around
<Slimey>
yeah did that with 2960 10/100
<jow>
Slimey: there were some reports about eee causing troubles, maybe it's the same with your device
<jow>
just a totally random guess
<hurricos>
Oh, 11z?
<Slimey>
if its networked related odds are good i have the hardware ;)
<hurricos>
or, no. I've already made this mistake and sounded like an idiot. But it has to do with power saving on ethernet ports, right?
<jow>
ah no, nvm. that eee think was mediatek
<jow>
*thing
<Slimey>
whats interesting this bsap1925 board, same guts and no issues
<jow>
hurricos: yes, energy efficient ethernet, some kind of powersave feature
<Slimey>
been down that rabbit hole with EEE
<hurricos>
Got it. I wonder whether the two boards you referred to have a different phy -- or does the AR9344 have an integrated gigabit PHY?
<Slimey>
as far as i know its integrated
<hurricos>
I do see a comment `/* default for ar934x, except for 1000M */` in the dts.
<Slimey>
yeah not sure what that ment
<hurricos>
You're having issues in kernel 5.4, I understand?
<Slimey>
yeah and 5.10
<hurricos>
Right. If you had a fast and reproduceable build process you could potentially try to bisect to an OpenWrt commit, but from a quick look there are some partitioning changes.
<hurricos>
(less fun)
<hurricos>
If the bootloader on the device follows the content of bootcmd, you could potentially change the bootcmd so that it sets up networking and boots from an initramfs.
<hurricos>
This would make bisection easier, but in no case fun ...
huaracheguarache has joined #openwrt-devel
<Slimey>
1925 snapshot 5.10
<Slimey>
cap324 19.07.8 4.14.241
<Slimey>
[ 0.956085] ag71xx 19000000.eth: connected to PHY at mdio.0:00 [uid=004dd072, driver=Qualcomm Atheros AR8035]
<hurricos>
Can you directly confirm the issue in 5.4 on the 324? I'm assuming you have serial/
<hurricos>
I'm alsso a little worried about exact config, as I always am. Looking closely at the output of `netstat -peanut` to make sure you're running services on port 80/22/443 and that you are not actually firewalling those ports on that interface would be healthy
<blocktrron>
Slimey: if it is broken in 21.02 and worked on 19.07 - at803x did not disable any PHY-internal RX-/TX clk delays on the rgmii interface.
<blocktrron>
So phy-mode "rgmii" might have RX/TX or both delays enabled.
<blocktrron>
so try rgmii-id, rgmii-txid, rgmii-rxid as modes
<Slimey>
ok
<huaracheguarache>
blocktrron: Hi! From what I can see you make a lot of hostapd-related commits. Would you mind taking a look at my pull request when you have time to check if it's ok? https://github.com/openwrt/openwrt/pull/5033
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
<blocktrron>
huaracheguarache: looks good as far as i can tell
<blocktrron>
one question: does this feature depend on the presence of a TLS libary or can it work with a non-crypto full build?
<huaracheguarache>
No, it shouldn't depend on that.
<huaracheguarache>
blocktrron: I assume the question is why I decided to make it a part of the -openssl and -wolfssl variants?
<russell-->
hauke: seems like a reasonabe fix
goliath has joined #openwrt-devel
srslypascal has quit [Quit: Leaving]
srslypascal has joined #openwrt-devel
<huaracheguarache>
blocktrron: On second thought, I'm actually not sure if it works without openssl or wolfssl.
<huaracheguarache>
blocktrron: The reason I chose to enable it for those packages is that one of the variants, can't remember which now, is the default package for the R7800.
<huaracheguarache>
blocktrron: And if the size increase is acceptable, then why not include it by default? Might as well do that since it's a security feature that will probably become standard in the future.
Levitator has joined #openwrt-devel
<Levitator>
Greetings.
<Levitator>
Marvell 8997 support is bork.
<Levitator>
Has been for ages.
<Levitator>
Though, I was hoping someone could point me in the right direction.
<Levitator>
mwlwifi kernel panics after failing to locate two calibration files.
<Levitator>
mwifiex can be forced to work if you track down the firmware file which is missing from the firmware package (lolwut?).
<Levitator>
But then it craps out and crashes when you go to handle RTP packets. Maybe a WMM issue? Who knows.
<Levitator>
Or maybe I chose an unlucky firmware image.
<Levitator>
Ok, well, since everyone's asleep, I'm just going to continue fucking around with the one that occasionally works. Maybe I'll find a lucky firmware file, or the OpenWrt 21 kernel might be more compatible. Could get lucky. You never know.
minimal has quit []
Levitator has quit [Remote host closed the connection]
<blocktrron>
huaracheguarache: feature-parity between -ssl and non-ssl packages is desired.
mattytap has joined #openwrt-devel
<huaracheguarache>
blocktrron: hmm, ok. I'll check if it works with the non-ssl variant and include it in the PR if it does.
<blocktrron>
also the hostapd config-generation looks of
<blocktrron>
ocv depends on 80211w
<blocktrron>
wtf, hostapd magically overrides 80211w settings in case ocv is enabled
<huaracheguarache>
Yeah, that's intended behaviour per the hostapd config: # Enabling this automatically also enables ieee80211w, if not yet enabled.
<blocktrron>
yes, but it is when parsing the config file
<blocktrron>
and to me it looks like it depends on whether & in which order the pmf config is consumed
<blocktrron>
it's not openwrts fault, but it looks off
<blocktrron>
when i read the ocv config, enable pmf, read the pmf config and disable pmf
<blocktrron>
can you check this?
<huaracheguarache>
Wait, I'm a bit confused. We're talking about the runtime config, right?
mattytap has quit [Ping timeout: 480 seconds]
<huaracheguarache>
blocktrron: Ok, I think I understand what you mean: so ocv=1 is parsed first which enables 802.11w, but you also have 80211w=0 in your config file and when that is parsed it gets disabled, right?
Borromini has quit [Quit: leaving]
Luke-Jr has quit [Remote host closed the connection]
<huaracheguarache>
blocktrron: Yeah, I think I need to move append bss_conf "ocv=$ocv" "$N" further down in the config generator to a place below all of the other stuff that can set 802.11w.
<blocktrron>
this is my theory, yes.
<blocktrron>
I did not confirm it. But this is how i read the code.
eduardo010174 has quit [Remote host closed the connection]
<blocktrron>
That being said - moving this down in the config generation is not the fix for that (if it is an issue at all, see my last message)
Lynx- has joined #openwrt-devel
<blocktrron>
this would need to be fixed upstream
<blocktrron>
not a blocker per-se. I need to wrap my head around this at another time.