<hurricos>
So it looks like the 6GHz band is disabled
<hurricos>
but other than that?
<hurricos>
I'm absolutely shocked. I pulled the kmods and grabbed the raw firmware bin files from github , and ...
<hurricos>
everything worked
<hurricos>
rm /etc/config/wireless; wifi config; <- gave all the full DBDC configs ... which then *worked*
<slh>
make sure to update wireless-regdb as well, I'm not sure if it reflects the current state regarding 6 GHz (at least not for ETSI)
<hurricos>
thank you, I was wondering -- I am on snapshot
<hurricos>
unfortunately, I'm up to date :^)
<hurricos>
iw reg get shows US, but ...
<slh>
ax210 only learned 6 GHz/ ETSI in jate january (via a firmware update), wpa_cli -i wlp2s0 status | grep ^freq= \n freq=6135
<hurricos>
I did a quick git log --grep regdb and found HR supports 6GHz
<hurricos>
fwiw I'm on a Fedora laptop on ax210 where `iw reg get` clearly shows country: US with access to all of the 6GHz bands
<hurricos>
just with no-ir
<hurricos>
rather than disabled
<hurricos>
so I choose to believe the regdb is wrong and circumvent it for testing purposes for the next 5 minutes by switching to the wrong country :grimacing:
<hurricos>
and boom,the lower half of 6GHZ is unlocked O_O
<slh>
I wonder who they bought/ rebranded, can't really imagine them having developed a 802.11ax chipset from scratch (considering that realtek doesn't have anything so far)
<hurricos>
slh: looks like they had their earliest designs based on ralink/mediatek
<hurricos>
.... rebadged versions of those*
<hurricos>
a breath of new life for ath9k! Someone submitted the QCN550X black-magic to patchwork :^)
<hurricos>
My understanding was, yes, the driver just needed to be able to handle the config formatting for the 4th chain, since no other ath9k hardware has it
<hurricos>
It's really incredible. Qualcomm didn't document it at all, they just made it and put it out there ...
<hurricos>
someone randomly discovers it and mentions it, and a few months later 4x4 ath9k is headed to mainline.
<slh>
well, cheap re-using of existing designs with few changes
<hurricos>
Right!
<hurricos>
ath9k really is good, cheap, simple hardware
<slh>
or why we have (had) mips based routers to begin with
<hurricos>
back from the days where if you implemented CSMA, RTS/CTS/aggregation/encryptoin in hardware, you had the holy grail
<hurricos>
alas, time marches on
<Namidairo>
yeah, I did wonder where these celeno chipsets came from
<hurricos>
one thing I didn't count on was just how hot these things get ...
<hurricos>
Unfortunately, the MSM466 outdoor APs don't heatsink the hardware much
<hurricos>
it probably helps them that ath9k has, uh, no firmware/CPU ... so it can probably tolerate higher temps
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<hurricos>
grr, unfortunately it hangs immediately if asked to enter IBSS
rua has quit [Ping timeout: 480 seconds]
<hurricos>
It took me more than a few minutes to realize that doesn't matter, as our legacy networks don't support 6E
rua has joined #openwrt-devel
guerby_ has quit [Remote host closed the connection]
guerby_ has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest208
rua has joined #openwrt-devel
srslypascal has joined #openwrt-devel
srslypascal is now known as Guest209
srslypascal has joined #openwrt-devel
Guest208 has quit [Ping timeout: 480 seconds]
Guest209 has quit [Ping timeout: 480 seconds]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
valku has quit [Remote host closed the connection]
rua has quit [Ping timeout: 480 seconds]
Piraty has joined #openwrt-devel
rua has joined #openwrt-devel
Piraty_ has quit [Ping timeout: 480 seconds]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
ekathva has joined #openwrt-devel
ekathva has quit [Remote host closed the connection]
goliath has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openwrt-devel
slingamn has quit [Remote host closed the connection]
slingamn has joined #openwrt-devel
pepe2k has joined #openwrt-devel
GNUmoon has quit [Remote host closed the connection]
Slimey has quit [Read error: Connection reset by peer]
Slimey has joined #openwrt-devel
gch981213 has quit [Remote host closed the connection]
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
danitool has joined #openwrt-devel
GNUmoon has joined #openwrt-devel
gch981213 has joined #openwrt-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
srslypascal has quit []
srslypascal has joined #openwrt-devel
robimarko has joined #openwrt-devel
rua has quit [Remote host closed the connection]
shibboleth has joined #openwrt-devel
rua has joined #openwrt-devel
<shibboleth>
blocktrron, f00b4r0, hapaclite doesn't seem to build from master. known issue or should i find the logs?
<f00b4r0>
shibboleth: not known issue to me
<f00b4r0>
it built when I submitted it, since I tested it too
MAbeeTT5 has quit [Remote host closed the connection]
<shibboleth>
iirc it's the "world" stage, booting the buildbox atm
MAbeeTT5 has joined #openwrt-devel
<f00b4r0>
it's built in snapshots on downloads.openwrt.org
<shibboleth>
could be some non-default config/component then
<shibboleth>
uhm, is there a .log for the prev/last build or will i have to run yet another?
<shibboleth>
no bother, won't take long
<f00b4r0>
i don't think successful build logs are kept
<shibboleth>
path/to/openwrt/build_dir/target-mips_24kc_musl/procd-default/procd-2022-05-03-652e6df0/service/instance.c:426:(.text+0x5b0e): relocation R_MIPS16_26 against `unlink' cannot be used when making a shared object; recompile with -fPIC
<shibboleth>
ad nauseum, for pretty much every pkg, seems like
<f00b4r0>
i'm afraid that's completely unrelated to the device
<shibboleth>
well, i can build other ath79 and ipq806x from the same buildroot
<f00b4r0>
start from distclean then
<shibboleth>
ok, let's see
<shibboleth>
also, and unrelated. the sysupgrade image version magic seems broken for wpa8630 v2
<shibboleth>
if you upgrade an older, ath79 install to ath79-tiny you get the warning about blocksize, etc as expected. so you do a clean flash, repopulate config. but then you get the same warning when sysupgrading ath79-tiny to ath79-tiny / v2/v2
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openwrt-devel
<shibboleth>
f00b4r0, yeah, seems to have worked.
<shibboleth>
is the sysupgrade/config issue solved? with stock/generic 1907 images configs would survive a sysupgrade but then somehow magically be gone on the second reboot?
<f00b4r0>
that shouldn't happen anymore. However preserving configs from 19.07 is an unsafe bet due to network changes
<shibboleth>
sure
<shibboleth>
also also: maybe kmod-usb2 should be selected by default?
<f00b4r0>
it's not necessary to operate the device so I left it out.
rua has quit [Ping timeout: 480 seconds]
<shibboleth>
well, it'd be unfortunate for this to make it into 2203 release without usb support?
<shibboleth>
also, if you're running a master image it'll you won't be able to fetch it at the next kernel bump.
rua has joined #openwrt-devel
shibboleth has quit [Quit: shibboleth]
rsalvaterra_ has joined #openwrt-devel
rsalvaterra_ is now known as rsalvaterra
<f00b4r0>
not sure what he meant.
<rsalvaterra>
nbd: I bumped 5.15 to 5.15.42, but there are many changes in the flow offloading code and the xt_FLOWOFFLOAD patch needs your love. I had to rebase it manually but wasn't successful. It compiled, but now it's crashing my Belkin (MT7622)… :/
<nbd>
are these changes in a staging tree somewhere?
<rsalvaterra>
I can push them out.
<rsalvaterra>
I'm just worried someone might blindingly pull, build and kill their device. :P
<f00b4r0>
nbd: dunno if you saw my earlier question: will mt76 be updated before 22.03.0 is released? If not I think we want to backport the fix for encap offload ethernet type check
<nbd>
f00b4r0: i'll try to get around to it this week
<f00b4r0>
cool, thanks!
<nbd>
rsalvaterra: maybe just put them in a branch
<nbd>
so i can fetch them and make some fixups for you to fold in
<rsalvaterra>
robimarko: Needs fixes from 5.15.42. :)
<robimarko>
Well, at least the FDB violation was finally fixed then
<rsalvaterra>
robimarko: I don't know if it's enough, but someone reported success on a Linksys device.
<robimarko>
Its getting hard to find people to test on those A38X devices
<rsalvaterra>
Yeah… I do quite a lot of testing on my Omnia, but it seems like I'm lucky and everything Just Works™. :)
<robimarko>
Its the switch, those that had issues are quite rare and pretty much only those A38X devices used them
<rsalvaterra>
nbd: I had to introduce an unused struct nf_flowtable *flowtable argument in xt_flowoffload_check_hook to fix the build, but obviously that isn't enough.
<nbd>
you changed the last argument in the call to nf_flow_table_iterate from table to NULL
<rsalvaterra>
Yes.
<nbd>
which means the data argument to xt_flowoffload_check_hook will be NULL as well
<nbd>
and you didn't update the code in xt_flowoffload_check_hook to no longer rely on data
<rsalvaterra>
Hm… misunderstood the code, then.
<nbd>
one moment, need to look at the code in context, then i can tell you how to fix it
<rsalvaterra>
Ok, thanks! I'm going to have lunch soon, but feel free to message me in private, if you prefer.
<nbd>
instead of table = data, you do table = container_of(flowtable, struct xt_flowoffload_table, ft);
<nbd>
that should fix it
<rsalvaterra>
Ugh…! Right, container_of. Me and my lousy C… :(
<nbd>
if you had left 'table' in as the last argument to nf_flow_table_iterate, it would have worked as well
<nbd>
but it's cleaner to rely on the new extra argument now
<rsalvaterra>
Yeah, but I was trying to match the current style. I think the idea will be to remove *data altogether in the future.
Grommish_ has joined #openwrt-devel
Grommish__ has joined #openwrt-devel
Grommish has quit [Ping timeout: 480 seconds]
minimal has joined #openwrt-devel
Grommish_ has quit [Ping timeout: 480 seconds]
bluew has quit [Remote host closed the connection]
robimarko_ has joined #openwrt-devel
robimarko has quit [Ping timeout: 480 seconds]
rsalvaterra has quit [Ping timeout: 480 seconds]
rsalvaterra has joined #openwrt-devel
valku has joined #openwrt-devel
Gaspare has joined #openwrt-devel
shibboleth has joined #openwrt-devel
<shibboleth>
f00b4r0, tested and working fine, configs survive second reboot after sysupgrade. huzzah
<shibboleth>
that being said, i find it odd that kmod-usb2=y isn't the default. it was required for the onboard usb to work on 1907 ar71xx generic
Gaspare has quit [Quit: Gaspare]
Gaspare has joined #openwrt-devel
Gaspare has quit []
Gaspare has joined #openwrt-devel
Gaspare has quit []
Gaspare has joined #openwrt-devel
Gaspare has quit [Quit: Gaspare]
Azq2 has joined #openwrt-devel
<f00b4r0>
shibboleth: it's required for usb to work, it's not required for the device to work
<karlp>
is there any reason _not_ to have it? (I can't think of any?)
<f00b4r0>
feel free to submit a patch
<f00b4r0>
i was under the impression that should only be included the packages _necessary_ for a device to work. Maybe I'm wrong, either way it is what it is.
<Azq2>
Why gdb don't display symbols on x86? I use musl libc and openwrt from master. And my program has debug symbols: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, with debug_info, not stripped
<Azq2>
I see only shit like this: 0x00007ffff7fdc36c in ?? ()
<shibboleth>
f00b4r0, neither is wifi kmod/firmware :P
<f00b4r0>
yes it is for network operation
<f00b4r0>
anyway, this is opensource.
<shibboleth>
f00b4r0, same with leds. listen, your pr, you decide, but find any other device that comes with onboard usb where openwrt doesn't have kmod-usbfoo?
<f00b4r0>
my patch has been merged. If you are unhappy, submit another one and please stop harassing me.
<shibboleth>
harass? well, that wasn't my intention and sure doesn't seem to jive with the dictionary definition. anyway, as i said: your pr, you decide, good job anyway
Azq2 has quit [Remote host closed the connection]
<f00b4r0>
the ar71xx image didn't have kmod-usb2, fwiw.
Azq2 has joined #openwrt-devel
<shibboleth>
indeed
<shibboleth>
because: generic
<shibboleth>
one image: maybe twenty devices
<f00b4r0>
and nobody complained about the situation.
<Azq2>
Lol, with glibc gdb works fine. Okay.................................
pepe2k has quit [Remote host closed the connection]
<shibboleth>
f00b4r0, also didn't necessarily include required device-specific wifi stuff. and no one complained because: generic. anyway, i've said my two cents
<f00b4r0>
it certainly did.
<shibboleth>
for that device in particular, it did
<mrnuke>
Also, I'd like to make the "sendframe" command only available for builds with a special compile-time flag set. Sending frames willie-nillie in production is dangerous -- there's even a command to erase the PSE firmware
<hurricos>
mrnuke: +1. On the other hand, you can always pick the frames before they get sent, similarly to what is done with mtd locking ..
<hurricos>
you can always destroy embedded hardware, it's not hard :^)
mangix has joined #openwrt-devel
<mrnuke>
well yes. But will the package be realtek-poe, or realtek-poe-destroyer?
<mrnuke>
Anyhow, I see "sendframe" only being useful for quick prototyping -- it's faster than coding. Useful for debugging the actual protocol, at which point you're building realtek-poe from sources, and have likely discovered the flag
<rsalvaterra>
mrnuke: I have a technique for that. I start counting parenthesis from left to right. Opening, +1. Closing, -1. If I end up with something other than zero, there's a problem. :P
<rsalvaterra>
Parenthesis refcount, basically. :)
csrf has joined #openwrt-devel
f00b4r0 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
minimal has quit [Quit: Leaving]
<mrnuke>
rsalvaterra: Hehe! I do that too when I get desperate and all other methods have failed. I never thought of it as refcounting. I like that!