gnom has quit [Read error: Connection reset by peer]
xtor is now known as extor
Bertl is now known as Bertl_zZ
nerozero has joined #openocd
sbach has quit [Read error: Connection reset by peer]
sbach has joined #openocd
michalkotyla has joined #openocd
Krazubu has joined #openocd
nerozero has quit [Ping timeout: 240 seconds]
nerozero has joined #openocd
Krazubu has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]
psp has joined #openocd
nerozero has quit [Ping timeout: 250 seconds]
nerozero has joined #openocd
<Xogium>
borneoa_, PaulFertser: well after a full night of test I confirm that whatever this is, it only affect my ubiquiti AP. I can't say for sure if noone else would run into that with another AP or not, but… Yeah. The test AP on my computer didn't move. From 18:50 to 09:30 this morning. Switching it to the ubiquiti AP, not an hour later it already dropped and went back to my test AP
<PaulFertser>
Xogium: good data point!
<PaulFertser>
Xogium: guess ST should get exactly the same AP as you have there and test on their own and complain to cypress/murata/whomever.
<Xogium>
but I wish I could fix this trash lol
<Xogium>
I just have no idea what's wrong
<PaulFertser>
Xogium: what is the exact model and hw revision of your AP?
<Xogium>
hmmm how can I know that ? Model I know, hw revision not sure where to see
<PaulFertser>
Should be also mentioned somewhere in their UI.
<Xogium>
let me check
<PaulFertser>
And firmware version too.
<Xogium>
I only see the model and firmware version
<Xogium>
u6-lr on firmware 5.60.23
<PaulFertser>
Xogium: ok.
<Xogium>
this is the latest firmware for them btw I have enabled the automatic updates
<PaulFertser>
Xogium: btw, when did you get it and what was your rationale choosing that product?
<borneoa_>
Xogium: that's good. On my side I'm investigating on automatic channel hopping. I don't have experience there, maybe PaulFertser has some hint. The code of wpa_supplicant has one build option CONFIG_ACS "Automatic Channel Select". I don't know it it impact only AP mode or also client mode. The wpa_aupplicant in ST image has this option disabled, as it uses the default config from openembedded.
<Xogium>
hmm I got it last year, in september or somewhere around that
<borneoa_>
Xogium: can you fix the channel of the router? Do you see a channel change when MP1 disconnects?
<PaulFertser>
borneoa_: to the best of my knowledge, ACS is only for "auto" channel on AP. And the AP doesn't really change channels without a real need (+.g. radar detect triggered).
<PaulFertser>
wpa_supplicant should receive a message from AP in that case
Haohmaru has joined #openocd
<Xogium>
the rational behind it was that since the isp switched me to fiber in ftth, the router they gave was complete crap, handles only 2.4 ghz band and excuse my french, had a really, really shitty signal. -85DBm from 10 meters away with a single wall in the midle
<PaulFertser>
Hah
<PaulFertser>
Xogium: were your issues reproducible with ubnt on 2.4 band?
<PaulFertser>
(that would exclude channel hopping due to radars)
<Xogium>
the brcm43430 only handles 2.4 ghz
<borneoa_>
My router here is set for auto channel, but since many hours it's stick to channel 6
<PaulFertser>
Right, on 2.4 GHz band it shouldn't be switching the channel ever, unless you reboot it and have it to auto.
<Xogium>
borneoa_: no I don't see anything really… It just disconnects with reason=3 or reason=0, wlan0 lost carrier message, then it moves to my test AP
<PaulFertser>
Xogium: is your ubnt channel set to auto for that band?
<Xogium>
PaulFertser: yep, I've set to auto yesterday to see if it would help, but otherwise it was set to 6
<PaulFertser>
Xogium: so you experienced the same issue with the fixed channel too.
<Xogium>
aye
<PaulFertser>
Disabled ACS is the false lead IMHO.
<PaulFertser>
And it's only for AP mode anyway (wpa_supplicant includes some minimal implementation for AP mode).
<Xogium>
probably. I suppose I could try and enable that in hostapd just to see what it would do
<Xogium>
but yep I reckon its not that
<PaulFertser>
Xogium: don't bother...
<Xogium>
this is a tricky one
<Xogium>
I mean I'd try openwrt on it, but… I don't know how to come back to factory default after or if I brick it
<PaulFertser>
Xogium: are you familiar with TFTP?
<Xogium>
hmm very little
<Xogium>
but I know you can do like nfs rootfs or such and boot boards like that
<PaulFertser>
Xogium: yes, you can but in this case it's not applicable. Since I do not have that device I'm not comfortable to guide you through installing, and especially reverting to stock.
<Xogium>
but I reckon it probably is a software issue on the AP side… something that it does, that the brcm chip doesn't like at all. I doubt it would be hardware problem
<PaulFertser>
Xogium: likely so
<Xogium>
why only with broadcom devices I don't know, but that's seems to be a common occurence
<Xogium>
I have the stm32mp157c odyssey board from seeed studio which also uses a module made from 2 broadcom chips, which are variants of brcm43430
<Xogium>
guess what ? Same problem
<PaulFertser>
Xogium: do you have WMM enabled on 2.4 GHz band? Is there anything special or not default at all about your ubnt config?
<Xogium>
hmm
<Xogium>
I've tried so many things by now that I'm not sure hehe let me check
<PaulFertser>
Xogium: I think you started trying before disabling that buggy kernel module, so probably it's time to revert to all defaults.
<Xogium>
ok so, uapsd is off the multicast enhancement to let devices send multicast at higher rate is also off, bss transition with wnm is off, proxy arp is off, same for l2 isolation, fast roaming is off
<PaulFertser>
Xogium: probably disabling uapsd isn't the right thing unless it's default.
<Xogium>
yeah hm
<Xogium>
ah and connectivity improvement of IOT devices is also enabled
<PaulFertser>
I see, "BSS Transition with WNM" means enabling 802.11v. Shouldn't hurt and shouldn't be relevant.
<PaulFertser>
Xogium: people say it sets DTIM to 1. That might be problematic for various reasons. Better do not.
<Xogium>
alright I disabled it. At this point anything is good to try ;)
<PaulFertser>
Xogium: and not disable uAPSD
<Xogium>
yep
<PaulFertser>
It's U-APSD, sorry, not u.
<Xogium>
alright lets try that
<Xogium>
the good thing is, generally this happens quite fast
<Xogium>
so its not something I have to wait days for to happen
<Xogium>
PaulFertser: though ftr apparently enabling iot device improvement means set dtime to 1 for 2.4ghz… which is already the default dtime even when iot improvement is disabled. It's just that you can modify the dtime if you disable it
<PaulFertser>
Xogium: default dtim period in hostapd is 2.
<Xogium>
hmm interesting
<Xogium>
I'll try 2 too
Bertl_zZ is now known as Bertl
<Xogium>
PaulFertser: disconnected again… Ah well
<Xogium>
we can't say I didn't try
<Xogium>
even with iot improvement disabled, u-apsd enabled, and dtime set to 2
<PaulFertser>
Was worth a try
<Xogium>
I'm running out of ideas to try by now ;)
<borneoa_>
Xogium: and iw info reports the same channel across the disconnect?
<Xogium>
actually it doesn't ever attempt to reconnect to the ubiquiti AP
<Xogium>
it prefers going back to the pc where hostapd runs
<Xogium>
and if I disable this network it just… hang there and doesn't do anything
<Xogium>
if I want my wifi back, sometimes I have to restart the whole networking stack or reboot
<Xogium>
sometimes just restarting the network will work, other times I reboot because the device just won't attempt to connect
<Xogium>
I guess in the meantime I'll keep turning my pc into an AP
<Xogium>
but I'm not sure I want to try my luck with openwrt given that if I brick it I don't heve access to serial
<Xogium>
*don't have access
<PaulFertser>
Xogium: it looks like this one, as all the others from ubnt, can be reflashed with tftp without serial access. Just access to the reset button and tftp server should be enough.
<Xogium>
hmm
<Xogium>
then I suppose I could try it. I'm unclear however how to deal with the fact that the ip it uses by default on its lan port is the very same my router use
<PaulFertser>
Xogium: OpenWrt by default has wifi disabled, and ethernet assigned to LAN.
<Xogium>
right
<Xogium>
but I mean the lan ip on wrt is exactly the ip my router has
<PaulFertser>
Xogium: but you connect it to your PC and reconfigure it to be wan.
<PaulFertser>
Xogium: and change the lan ip to something else
<Xogium>
also… not criticising or anything here but, isn't it a bit weird to disable wifi on a device that is clearly nothing but an AP ? :D
<Xogium>
hmm yeah, I can do that
<PaulFertser>
OpenWrt is consistent on all supported boards.
<Xogium>
I… can see that ;)
<Xogium>
just have to think about how to go back to stock
<Xogium>
I can flash the firmware easy enough but what about my settings and reconnecting the the unifi controller ?
<Xogium>
I just like to figure this in advance so I don't get stuck
<PaulFertser>
No connecting to the unifi controller at all.
<Xogium>
no no not under wrt but back with stock
<PaulFertser>
Settings are all configurable with web interface or by editing /etc/config/ files
<PaulFertser>
Back to stock I have no idea, that's why I'm hesitating to suggest you flashing OpenWrt...
<Xogium>
yeah so do I
psp has quit [Quit: leaving]
<Xogium>
PaulFertser: by the way this is what I get on the AP side with this particular client
GyrosGeier has quit [Remote host closed the connection]
<Xogium>
PaulFertser: holy s… this might actually work. I've been connected for almost one hour and a half. I don't know if it will hold, but it is one of the longest times I managed
Guest365 has joined #openocd
<Guest365>
hello, I'm curious: did somebody manage to make openocd work with i.MX RT series?
Fist0urs has joined #openocd
<Xogium>
PaulFertser: yes, I'd say this constant pinging makes it impossible for the device to time out. I've been connected for almost 3 hours by now, with a few minutes to spare, and it hasn't moved
<Xogium>
PaulFertser: it also prevent the send null to… messages in the AP log. The last message like this is from 13:25, from the time of my pastebin
<Xogium>
PaulFertser: ok so, I stopped the ping at around 17:36, and waited for it. Exactly 20 minutes later
<Xogium>
Wed Jan 26 17:56:22 2022 kern.warn kernel: [3430174.252296] ra0: Send NULL to STA-c4:ac:59:68:fe:0e idle(60) timeout(480)
<Xogium>
restarting the ping stops the timeout that is about to happen
Guest365 has quit [Quit: Client closed]
<Xogium>
this time I stopped the ping really shortly after starting it. It bought me about 3 minutes before the timeout started its countdown
<Xogium>
this is so ultra weird
c4017w has joined #openocd
Guest3 has joined #openocd
<borneoa_>
Xogium: don't know how to change the router behavior, but you could probably get similar effect of the ping by reducing the renew interval of DHCP. Either on client side or on router side if it is programmable.
Haohmaru has quit []
Guest3 has quit [Quit: Client closed]
<Xogium>
borneoa_: hm in this case it is the AP actually causing my dev kit to time out because it doesn't respond to whatever probe its sending
<Xogium>
the only way so far around this is to continuously ping the AP
nerozero has quit [Ping timeout: 256 seconds]
c4017w_ has joined #openocd
c4017w has quit [Read error: Connection reset by peer]
c4017w_ has quit [Read error: Connection reset by peer]
c4017w has joined #openocd
<Xogium>
PaulFertser: trying out beta firmware for the AP
zjason` has joined #openocd
zjason has quit [Ping timeout: 268 seconds]
<Xogium>
PaulFertser: good news ! The beta firmware I've installed *greatly* reduces the issue. It isn't perfectly fixed, but it is a lot better already. I don't have to continuously ping my AP now
<Xogium>
I still get the occasional
<Xogium>
Wed Jan 26 21:01:52 2022 kern.warn kernel: [ 7431.497506] ra0: Send NULL to STA-c4:ac:59:68:fe:0e idle(60) timeout(480)
<Xogium>
but the device doesn't idle for more than 60 seconds now
<Xogium>
which means no disconnect
<Xogium>
at least so far
gnom has joined #openocd
c4017w_ has joined #openocd
c4017w__ has joined #openocd
c4017w has quit [Ping timeout: 240 seconds]
c4017w_ has quit [Ping timeout: 240 seconds]
PLC has left #openocd [Leaving]
c4017w__ has quit [Ping timeout: 240 seconds]
c4017w has joined #openocd
rtucker has joined #openocd
<borneoa_>
Xogium: cool
<Xogium>
borneoa_: ;) yeah… I once again spoke too soon. It is back with a vengence
<Xogium>
I'm now in a super weird state like what PaulFertser found earlier
<Xogium>
bascially I'm still connect to the AP… but I cannot ping or contact even the AP, or the router, or anything
<Xogium>
I cannot do anything
<borneoa_>
PaulFertser: do you know if the AP send some kind of ping to the devices? What type of packets? Maybe something is missing on device side. So far I haven't found such info
<Xogium>
man this is… just wow
<Xogium>
I never thought wifi could be so tricky because of the choice of AP and chip…
<Xogium>
I have one hell of a killer headache now haha
<Xogium>
being spun in every direction with yes, no and maybe and possibly that once again become no, then yes then… erk
<borneoa_>
Xogium: one more test could be to keep the AP disconnected from the Ethernet, so no packets around, and connect only stm32mp1 with wifi. On stm32mp1 run "tcpdump -n -i wlan0" to see what it receives and if it replies.
<Xogium>
aye, that will be actually easy to do… I messed up both ethernet and audio somehow on my build, so I don't even get eth0
<Xogium>
should I uh leave it in that current weird state ?
<borneoa_>
Xogium: the log looks like the AP checks 8 times if the device is present, then drop it from it's internal table. So even if the device claim it's still connected, the AP refuse it's packets
<Xogium>
hmmm that would explain
<Xogium>
but the thing is why does it not respond :/
<PaulFertser>
borneoa_: I think NULL packets mentioned are packets sent by the station itself to signal if it's going to sleep and so asks AP to buffer some packets for it or not.
Krazubu has joined #openocd
<PaulFertser>
borneoa_: but I'm not sure, and I didn't use ubnt firmware and never saw any messages like that.
<borneoa_>
PaulFertser: the daemon named stahtd is also unknown
<Xogium>
PaulFertser: indeed that would match what I read earlier, some issue with esp32 firmware did talk of it as the STA being the one sending the NULL packets
<Xogium>
but I agree… it's rather curious how the message is written and makes it sound like the AP is the one sending the NULL packets and the STA not replying
<Xogium>
but… it might actually be the opposite ?
<Xogium>
soo… STA sending packet… and AP not reacting ?
<Xogium>
PaulFertser: do you think something like tcpdump would help ?
<Xogium>
I reckon this happens at the wifi layer, possibly even offloaded to hardware so wouldn't be visible… but not sure
<PaulFertser>
Xogium: yes, if you disable encryption you can use another device to capture all over the air traffic. But that's all too complicated and still doesn't really help I'm afraid. Do you expect your pcap can convince ubnt or cypress to fix anything?
<Xogium>
no, but at least I'd finally understand what is happening
<Xogium>
but if its all too much work…
<Xogium>
to be clear here I don't blame st at all. I'm sure they picked the murata module for good reasons, and I can't blame them just because I just happen to have an AP with which it misbehave for… whatever reason
<Xogium>
I just need to find a solution for this since it's a personnal project yeah, but meant to be on wifi 24/7 since it will ultimately be portable
<Xogium>
been looking at usb dongle but seeing that currently the prices are going through the roof, I was hoping to figure out what was bothering the brcm or the AP so they could finally be happy… Ah well
<PaulFertser>
You can keep a ping running with it doing one ping a minute.
<Xogium>
all I've gotten for my trouble is a massive headache that I can practically feel down to my jaw lol
<Xogium>
yeah that's worth a try. But maybe I just got very lucky earlier and it was unrelated
<Xogium>
for now I'll try and get some sleep to get rid of this headache ;) thanks for all your suggestions so far peeps, I really appreciate the effort