srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
<svanheule>
hurricos: pong from a different time zone
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
felix has quit []
felix has joined #openwrt-devel
<stintel>
Grommish: pong
<Grommish>
stintel: I am working to get mips64 working with libc that rust uses.. in it, O_LARGEFILE isn't defined.. it's defined for b32/mips as O_LARGEFILE as like 0x2000.. Would that be a sane value to set it to for b64/mips64?
<Grommish>
Google has turned up nada (some aarch64 patches) and I'm not a programmer, so I have no idea if that's "good enough" or not
mangix has joined #openwrt-devel
<jow>
Grommish: defien it as 0
<jow>
Grommish: O_LARGEFILE is used on 32bit arches to select 64bit syscalls
<stintel>
mangix: that's why you should split bump and switch to whatever build framework into separate commits. now we revert due to breakage and lose the version bump in the process
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<stintel>
ok I definitely do have issues now with mt76. I switched the AP upstairs to a channel in the upper 5GHz band, to avoid interference with neighbour APs, due to that it's using much lower txpower (13 vs 21 dBm) but as upstairs is a single room that shouldn't matter
<stintel>
now the corp macbook is having bad latency and it's killing barrier (synergy fork) usability
<stintel>
switched back to channel 48 and still unusable
<stintel>
I'll bisect
srslypascal has joined #openwrt-devel
<nbd>
stintel: which chipset?
<stintel>
nbd: 7915
<stintel>
rtt min/avg/max/mdev = 1.744/36.839/137.562/40.475 ms
<stintel>
same room, -45dBm RSSI -92dBm noise according to the mac
<nbd>
do you ping from the mac itself?
<nbd>
or are you pinging the mac from another device?
<stintel>
I ping from another device
<nbd>
in that case, the latency looks normal
<stintel>
but it's not just ping, barrier is unusable
<nbd>
how are you using barrier?
<stintel>
the mac connects to my workstation
<nbd>
i guess my question is, do input events for barrier go out from the mac, or are you controlling the mac from the workstation?
<stintel>
I am controlling the mac from the workstation
<nbd>
right
<nbd>
then you're seeing the effects of 802.11 powersave
<stintel>
are you saying powersave got only implemented in the most recent bump ?
<nbd>
running
<nbd>
no, powersave is controlled by the client, not the ap
<stintel>
the mac cannot reach the workstation, it's corp hardware, so it goes in an isolated network
<nbd>
ah
<stintel>
there is only a DNAT rule for barrier
<nbd>
i'm thinking that maybe something else changed that caused the mac to generate less traffic
<stintel>
I'm building previous mt76 version and I'll know soon ;)
<nbd>
whenever the mac generates traffic, it can wake up immediately
<nbd>
whenever something tries to reach the mac, the ap needs to wake up the mac
<stintel>
would it do powersave whenm plugged in ?
<nbd>
yes, i think so
<nbd>
i don't think wlan powersave gets toggled based on AC/battery status
<aparcar>
nbd: did you read my message regarding mt76 and 802.11s?
<stintel>
lol trying to find if ps can be disabled on the mac and people suggest "use wired ethernet"
<nbd>
stintel: try ping -i 0.1 on any ip behind wlan that you can reach from the mac
<nbd>
doesn't need to be the workstation
<nbd>
that should keep it awake
mattytap has joined #openwrt-devel
<stintel>
nbd: there isn't any ;p
ecloud has quit [Ping timeout: 480 seconds]
<stintel>
nbd: but does it have to be reachable? I get icmp reply from the gateway
<nbd>
as long as it responds to arp, it's fine
<nbd>
it doesn't even need to reply to the icmp packets
<nbd>
so whatever ip ends up being the source address for packets from workstation to mac is definitely fine
<nbd>
(after nat)
<stintel>
nbd: ok, running that now, barrier is still unusable
<nbd>
how's ping latency from the workstation now?
<stintel>
mouse jumps from coordinate to coordinate a few times per second
<stintel>
the latency appears without spikes, so the ping latency can be linked to PS, but then barrier is another issue
<nbd>
ok
<nbd>
did you try another ap, just to rule out network issues?
ecloud has joined #openwrt-devel
<stintel>
can't really use barrier if the mac is not on my desk ;)
<stintel>
I can move the APs arround but as this worked fine for >2 months I'll first revert the mt76 bump and see what that brings
<nbd>
ok
<stintel>
I could switch to ethernet but I rather keep the mac on wifi, I'm using this with barrier every day so it's a good way to spot problems
Guest9490 has left #openwrt-devel [#openwrt-devel]
<stintel>
every workday*
<nbd>
definitely
<nbd>
let me know when you've made progress bisecting. i'll help you get this fixed
<stintel>
the mac roamed to AP downstairs, 2.4 GHz and also the same problem
svlobanov has joined #openwrt-devel
<nbd>
did you try rebooting the mac as well?
<stintel>
yeah, that's the first thing I did
<nbd>
ok
<nbd>
just checking, because i've seen similar crap on my own mac in the past which disappeared after a reboot (and a few hours of chasing ghost issues) :)
<stintel>
looks like it might be barrier this time :/
<stintel>
oh yes, mac reboot is the very first step, always
<stintel>
it's unreliable as fuck
<svlobanov>
hi. Is it possible to force add V=sc for feeds/packages CI? I want to get detailed build log from CI (in case when build is OK)
<nbd>
for me it was mostly reliable, only had to reboot once every few months or so
<stintel>
when I initially got it, every day to every other day
<nbd>
oh, that's nasty
<stintel>
when I upgraded to the latest, don't remember the name, DNS resolution broke after a minute of uptime or so
<stintel>
I then removed the wireless connection in the network settings, rebooted, added again, and much better since then
<nbd>
so far i'm really happy with the new m1
<stintel>
ah, I'm a contractor so I get recycled stuff ;p
<stintel>
it's *only* a 2020 MBP
<stintel>
but apparently the problem was barrier on the workstation this time
<nbd>
interesting
<stintel>
systemctl restart --user barrier.service --> this hung for a while and then restarted and was fixed
<stintel>
the hang was already a good indicator
<stintel>
because normally it restarts in < 1s
<stintel>
and the previous time I spoke of a regression ... where throughput dropped from >600 to <200, apparently the galaxy s21 ultra sometimes doesn't connect to some 5GHz channels, and due to that it was on the 2.4GHz network
<nbd>
:)
<stintel>
although I do check in wifi the link speed and first time I think I saw 1.1Gbps and still had slow throughput
<stintel>
now I didn't and that's what made me look deeper
<stintel>
nbd: btw did you make any more changes that could solve the mt7163 stalls ?
<nbd>
i don't think so, not sure
<nbd>
didn't have any time to look into it any further
<stintel>
got it, wifi5 is low prio everywhere ;)
<stintel>
sad though, neither qca nor mtk can be recommended now :(
<nbd>
well, 7615 should be fine
<nbd>
the 7613 stalls shouldn't appear on 7615
<stintel>
maybe we should stop providing images for devices with known issues
<stintel>
and/or set a flag in the device, that could show a warning when logging via SSH or in LuCI
<stintel>
I think barrier might get confused when the link between client and server disappears a few times, which definitely happened during the weekend, if can get it in the same state I'll try getting a core dump first and report it
<robimarko>
hauke: Did somebody submit QRTR/MHI to backports mailing list?
Guest2082 has quit [Ping timeout: 480 seconds]
<mangix>
stintel: OTOH I already had a fix posted as a PR. Doesn’t seem like I should bother now.
mattytap has quit [Quit: Leaving]
<aparcar>
mangix: have you ever seen: executable path /usr/sbin/wpad does not match process path (/proc/exe)
rmilecki has quit [Remote host closed the connection]
rmilecki has joined #openwrt-devel
<rmilecki>
stintel: what are those 7613 stalls?
<rmilecki>
stintel: does traffic stops for like 5 seconds and they goes back to normal?
<stintel>
much longer
<stintel>
the root cause is believed to be stuck packets in a queue and the queue filling up, iirc
<rmilecki>
nbd: can those 7613 stalls be related to what I saw on Xiaomi Mi Router 4C (MT7628AN) and Netgear R6220 (MT7621ST (SoC) + MT7603EN (WiFi) + MT7612EN (WiFi))?
<rmilecki>
nbd: i reported those iperf stalls taking from 5 seconds
<rmilecki>
they seem to happen high traffic only and are present in the latest mt76
<stintel>
I was reliably hitting it with my laptop in the bedroom, where there is no AP, so with the client being further away from the AP
<stintel>
but I was hitting it without high traffic
<stintel>
and could not reproduce with clients in the same room as the AP
<rmilecki>
so maybe it's another issue
<stintel>
I think so, iirc this was related to client assoc or disassoc
<stintel>
and when the traffic on my laptop stalled, disabling wifi on my phone would fix the situation
<stintel>
so the disassoc of the phone from the same bssid as the laptop is connected triggered something
<aparcar>
nbd: if you have the time please look at 802.11s, it's broken for MT7622 and MT7915E, the logs are just flooded with "wlan0: new peer notification for <mac>"
<stintel>
nbd: do you also experience load avg of >= 1.00 on mt76 devices?
Gaspare has joined #openwrt-devel
<rsalvaterra>
stintel: Not here… 0.00 0.05 0.01 1/132 13081
<stintel>
I'm seeing this on eap615-wall/mt7915, and iirc also on eap235-wall/mt7613+?? and u6lr
<stintel>
ehr s/u6lr/u6lite/
<stintel>
currently not seeing it on u6lr but that could be due to no clients
<rsalvaterra>
mt7615e and mt7603e seem to be fine, then.
<nbd>
stintel: no
Acinonyx_ has joined #openwrt-devel
<stintel>
nbd: any suggestions to debug where this is coming from? I've seen this a few times in some drivers but never figured out how to find the root cause
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openwrt-devel
Gaspare has quit [Read error: No route to host]
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
valku has joined #openwrt-devel
<hurricos>
svanheule: Thank you. I ended up figuring out the RS232 pinout on the GS1900-24HP. It runs 100% fine with a tiny tweak to th GS1900-24HPv2 device tree (reduced memory to 0x4000000)
<hurricos>
I also have a GS1900-24P next to my desk which I will be porting along with it soon^tm
<mrkiko>
nick[m]1234: aparcar: I am an RT3200 happy user; experiencing issues only with builtin's Wi-Fi (mt7622), where after some days of use it seems clients are no longer able to pass traffic. Some time ago it used to crash upon reboot, now it seems not; ifconfig wlan0 down ; sleep ...; ifconfig wlan0 up seems to fix the proble,still iDevices connected to the wlan seem to disconnect more freuqnely, and
<mrkiko>
connect only when pressing home button or something. Still, all of this is "impressions2, no data, so I am not sure about anything. Not experiencing issues with mt7915 instead. Now I am running latest mt76 as committed to OpenWRt git tree, lets see if this happens again.I do like this router a lot, dangolle did a fantastic work on it. :)
<stintel>
it's just calling epoll_pwait all the time
<stintel>
maybe that just triggers load >= 1.00 due to some other thing which is mt7621 specific, or maybe related to one of the non-default options in my .config
<stintel>
uledd -S shows nothing
* ynezz
lookups what -S does
<stintel>
stderr
<ynezz>
you probably need to recompile with ULEDD_DEBUG and then use `-d -S`
<ynezz>
(if you don't see -d switch in your --help output)
rua has quit [Ping timeout: 480 seconds]
<ynezz>
I think, that the issue might probably be that singular timer.c, which seems to be running even without any work scheduled
shibboleth has joined #openwrt-devel
<stintel>
ynezz: could it be related to running on a device that doesn't have any rgb LEDs?
<Tapper>
Hi people I have a strange thing going on with my r6260. When streeming from bbc sounds or Spotify the streem just stops after about 10 mins. If I go in to the app and tell it to play again it will start again and keep playing for 9 or 10 mins. The devices that are acting up are a android phone gs9 and a google home mini.
<Tapper>
stintel No I have loging turned off so I will do a build now with logging and see what it says.
<Tapper>
Yes I do my builds.
<stintel>
Tapper: ok, I would first revert e045e40671ab6f689b79a2b51ec9eb9461423d46 and test if that resolves your issue
<Tapper>
Is it just "git revert e045e40671ab6f689b79a2b51ec9eb9461423d46"
<stintel>
if that's the case, you could use CONFIG_SRC_TREE_OVERRIDE and bisect mt76 commits between current and previous hash in package/kernel/mt76/Makefile
<nlowe>
blocktrron nbd I see there's a provisional patch to move to hostapd 2.10 - awesome - is there anything holding this up for merge for the master branch? After it's merged, we could consider enabling hash to element for SAE alongside hunting and pecking in the hostaod conf generated as this is now being done on commercial APs - Cisco, Extreme etc.
<Tapper>
stintel: I am getting
<Tapper>
Mon Feb 7 17:38:25 2022 daemon.info hostapd: wlan1: STA fa:14:8d:4b:85:c8 IEEE 802.11: as
<Slimey>
really i just need to find out if that kernel patch is still needed and the mtdsplit_uimage.c modifications
<hurricos>
also the whole 'active if supplied root' thing
<Slimey>
right
<hurricos>
What's your logic there?
<hurricos>
Is it something that u-boot needs?
<hurricos>
(for A/B)?\
<Slimey>
intramfs it works beautifully
<Slimey>
so adtran has this on the waps
<Slimey>
in uboot env
<hurricos>
Definitely sounds like the issue is mounting your rootfs. Sounds like you're doing this stuff to take care of A/B mounting. On the other hand, basically all other devices that have A/B partitioning are in NAND, if I'm not mistaken
<Slimey>
boot_bank A would be like bootcmd 0x9f300000 'console=ttyS0,115200 root=31:06 rw rootfstype=jffs2 init=/sbin/init mem=128M root= rootfstype=jffs'
<Slimey>
boot_bank B would be like bootcmd 0xa0000000 'console=ttyS0,115200 root=31:08 rw rootfstype=jffs2 init=/sbin/init mem=128M root= rootfstype=jffs'
<hurricos>
I don't think preserving A/B is an *awful* idea, but all other boards that have A/B booting and boot from NOR just "give up" on it :(
<hurricos>
for example, RTL838x switches have multiple boot partitions (iirc)
<Slimey>
bootcnt is kept set at zero unless bank 'A' fails 3 times then switches to B automaticly
<hurricos>
You'd do yourself a service to look at how ipq806x devices treat it under nand
<Slimey>
you get the idea..
<hurricos>
I *believe* they rely on Ubi magic
<hurricos>
I do!
<Slimey>
so its easier to just blast it and have one firmware part?
<Slimey>
i really dont care about reverting back to factory
<hurricos>
That would be very easy, and that's what all boards whose OEMs give A/B, but which use NOR flash to boot, do under OpenWrt.
<hurricos>
Our Aerohive AP370 port even does the same thing.
<hurricos>
Ditto for WS-AP3825i :^)
<hurricos>
I was lazy when I said the NAND A/Bers all use UBI
<hurricos>
in fact, they actually all communicate using the bootcmd.
<hurricos>
Slimey, is the boot_bank logic stored in variables which can be overridden?
<Slimey>
yes
<hurricos>
So, yeah: on one side, definitely consider making it a pain in the butt to restore to stock
<hurricos>
(not that it's that hard -- just copy the data down, then when you want to restore, boot an initramfs, insmod mtd-rw, and rewrite the whole flash. Easy.)
<hurricos>
I think making changes to mtdsplit would be a bit of a pain.
<Slimey>
cap324 is the clone of this
<Slimey>
with i have on the way
<hurricos>
You're directly giving major/minor device numbers, which can ...
<hurricos>
well, the minor numbers can change if there are any partition tweaks needed.
<Slimey>
if anything ill just copy its flash over and keep my art partition
svanheule has joined #openwrt-devel
<Slimey>
and the mac addresses of course
<hurricos>
You could try instead adjusting the variables so that booting bank B does, yes, boot from kernel 0xa000000, but does not point root at a major/minor device number, instead using something like append-rootblock
PtitGNU has quit [Remote host closed the connection]
dedeckeh has quit [Remote host closed the connection]
shibboleth has quit [Quit: shibboleth]
<hurricos>
stintel: > stop providing images for devices with known problems in WiFi driver, e.g. qca ac wave1
<hurricos>
This irks me. I've never had a wave1 ath10k have a wireless hardware crash resulting in the inability to communicate with the AP, but I have had that happen with ath10k wave2
<dwfreed>
I have an ath10k wave2 device; it just reboots every few days, so I don't have to worry about it
<russell-->
my paste was bogus anyway, because i was running the command from the feed (not topdir, d'oh)
<russell-->
this seems to be my problem: bash: /home/openwrt/src/lede/staging_dir/hostpkg/bin/scons: /home/openwrt/src/lede/staging_dir/host/bin/python: bad interpreter: No such file or directory
<stintel>
russell--: did you upgrade python on your distro recently ?
<PaulFertser>
I'd just manually create the right link.
<stintel>
probably _slightly_ faster :D
<Grommish>
stintel: You ready to tell me I was wrong about the dynamic vs static linking? You've made me question it now :D and since I don't know either way
GNUmoon has joined #openwrt-devel
<Grommish>
I honestly wouldn't know the difference as far as OpenWrt is concerned because I never had to