<rsalvaterra>
enyc: These vulnerabilities exist at the kernel and firmware level. When (if, depending on the hardware) they're fixed upstream, the patches will be backported to stable kernels. It's business as usual.
<enyc>
rsalvaterra: hrrm, is this why there are things like candelatech modified atheros firmwares and so-on ?
<enyc>
rsalvaterra: [upstream wifi chip vendor not supporting fw] etc...
<Q_>
I had to switch back to ath10k because the -ct version just crashes randomly and upstream says they can't fix it.
<rsalvaterra>
enyc: In case of ath10k, it started with fixing vendor firmware bugs and including features it didn't implement.
<rsalvaterra>
Q_: What ath10k hardware are you using?
<Grommish>
rsalvaterra: ping
<rsalvaterra>
Grommish: pong
<Q_>
QCA9880 / QCA9560
<Grommish>
rsalvaterra: Would you know how to add .ko deps to a kmod_ package? I've got a kmod_nf_nat that needs 2 .ko files that aren't being copied
<Grommish>
the kmod package is confusing and scary :D
<rsalvaterra>
Q_: For QCA9880, you need the -ct firmware if you want WPA3 support without fatal firmware crashes. The crashes will still happen, but the -ct firmware is able to recover.
<rsalvaterra>
Grommish: Sure, I've done it before. Do you know the exact dependencies?
<Grommish>
I'm doing a POC build to ensure the drivers are all kernel based
<Grommish>
before I go ripping them out and putting them into 5.10
<Grommish>
I tried a 19.07 build, but it just stopped at the Booting Kernel stage.. so, I'm trying main branch again
<rsalvaterra>
Grommish: Ripping them out… as in the source code, right? Not the compiled modules.
<Grommish>
Right
<Q_>
It works without problems with the non-ct version. I've not checked that WPA3 works properly, it might not have any devices that connect to it using WPA3.
<Grommish>
rsalvaterra: I know better than that :) But, I also have the full ralink source in the kernel gpl.. and all kinds of tasty configuration options now with a proper dts and whatnot
<rsalvaterra>
Q_: I failed to mention that the problem is also present for WPA2 with MFP (802.11w). MFP is the culprit (and it's mandatory in WPA3).
<Grommish>
rsalvaterra: HW IPSec and HW Nat enabled. The HW Crypto engines, etc
<rsalvaterra>
Grommish: That's mighty sweet…!
<Grommish>
rsalvaterra: If I can get it to build.. but, I keep learnnig new things and hitting new walls..this is the latest :)
<Grommish>
That kmod libs have to do with the hw nat, so I need to add them to the kmod file
<rsalvaterra>
Grommish: Hm… That hwnat implementation is probably too ad-hoc to be merged upstream. It needs to be a hardware flow offloading implementation on a DSA switch, like we have on MT7621, for sure…
<Grommish>
One thing at a time.. Once I get it working, I've got the technical sheets for the RTL8367RB
<Grommish>
Although this is a legit driver for that board
<jow>
you just need to figure out a way to let the "Dismiss" button also delete the notifaction
<jow>
either by attaching an event handler after the fact (ui.addNotificatio() returns the div node of the banner) or by changing ui.addNotification() itself to allow more control over the rendered contents
<aparcar[m]>
Perfect. I confused it with this modal thing which takes over the screen
opal has quit [Ping timeout: 240 seconds]
opal has joined #openwrt-devel
brentmagma has quit [Remote host closed the connection]
victhor has joined #openwrt-devel
Borromini has joined #openwrt-devel
AlexisEvelyn has quit [Read error: Connection reset by peer]
brentmagma has joined #openwrt-devel
AlexisEvelyn has joined #openwrt-devel
AlexisEvelyn has quit [Read error: Connection reset by peer]
AlexisEvelyn has joined #openwrt-devel
cheakoirccloud has quit [Quit: Connection closed for inactivity]
<jow>
that service() function thing which was added a while back is really weird
<jow>
service help -> listing
<jow>
service foo -> listing
<jow>
service list -> listing
<jow>
service dnsmasq -> help
Borromini has quit [Ping timeout: 268 seconds]
brentmagma has quit [Remote host closed the connection]
brentmagma has joined #openwrt-devel
<aparcar[m]>
jow: looks like only a "help" function is really missing
<aparcar[m]>
if service exists: show possible options, if not, show available services (with status)
brentmagma has quit [Remote host closed the connection]
brentmagma has joined #openwrt-devel
indy has quit [Ping timeout: 260 seconds]
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
brentmagma has quit [Remote host closed the connection]
brentmagma has joined #openwrt-devel
indy has joined #openwrt-devel
<nbd>
rmilecki: ping
<rmilecki>
nbd: pong
<nbd>
i've taken a quick look at your patch regarding 'config bridge' support
<nbd>
first of all, i think it would be a good idea to simply rename the 'ports' option to 'ifname' in config_init_bridges
<nbd>
in order to avoid processing two potentially conflicting options for the same thing on config device/interface sections
<nbd>
with rename, i mean using uci_rename
<nbd>
so sticking to your syntax in actual config files
<nbd>
and then there's another thing:
<nbd>
since you wanted to have bridges that are brought up by default, i think the new config syntax is a good opportunity to do so without potentially adding regressions to old configurations
<rmilecki>
nbd: sounds good
<rmilecki>
nbd: any hint how to handle that?
<nbd>
how about having a 'config bridge' section imply the creation of an implicit proto=none interface with the same name
<nbd>
that would allow you to use ifup/ifdown on the bridge as well
<rmilecki>
oh, that magic creation of interfaces worries me
<rmilecki>
more magic I mean
<rmilecki>
jow: ^^
<rmilecki>
nbd: could bridge.c code simply create bridge on device_create() callback?
<rmilecki>
nbd: why do we need actual event to create bridge?
<jow>
14:34 < nbd> how about having a 'config bridge' section imply the creation of an implicit proto=none interface with the same name
<jow>
please no!
<jow>
more magic implicit state
<nbd>
i mean right now, you can use ifup/ifdown to recreate the state of dynamically created interfaces like vlans, bridges, etc.
<nbd>
creating bridge devices without any interface user breaks that
<nbd>
or we would need to add a separate devup/devdown, or parameters to ifup
<nbd>
but then we have a lot of potential for bad interactions with device refcounting
<nbd>
and the internal data model of netifd starts getting more messy than it already is
<nbd>
so while in principle i agree with having less magic, the implicitly created interface is the least intrusive and least problematic way of implementing this feature that i can think of
<nbd>
and it's easier to handle from CLI if you can just use regular ifup/ifdown on it
<nbd>
if you guys can think of a better way, please let mek now
SamantazFox has quit [Ping timeout: 260 seconds]
<rmilecki>
jow: this is a bit too complex for me at this point, let me (us) know if you know how it could be handled
<rmilecki>
for now i'm voting for 1. no magic interface 2. having to create UCI interface config even if its dummy
brentmagma has quit [Remote host closed the connection]
brentmagma has joined #openwrt-devel
Nick_Lowe has joined #openwrt-devel
<nbd>
rmilecki: in that case, i don't know if it's such a good idea to merge the patch that adds the 'config bridge' support
<nbd>
because then it simply introduces yet another way to configure the exact same thing, except for one renamed config option
<rmilecki>
nbd: let me quickly share my long term plan
<rmilecki>
nbd: i want new UCI section syntax (type actually)
<rmilecki>
then I want to translate old syntax to the new one
<rmilecki>
then drop old syntax support
<rmilecki>
that applies to bridge as well as other types
<rmilecki>
jow: ^^
<nbd>
i think any change that leads to eventually breaking old configs should come with some significant benefits
<nbd>
otherwise you're simply adding lots of migration churn, ui changes, etc.
<rmilecki>
i believe it's going to result in cleaner UCI and LuCI in the final form
<nbd>
then maybe we should hold off on these sorts of changes until we have a draft for the final form
<nbd>
and migrate to that
<rmilecki>
nbd: I can document that first if it helps, sure
<nbd>
that would be helpful
<rmilecki>
will do
<nbd>
because the ifname->ports change alone is not enough to justify it, in my opinion
<nbd>
and if you support a half-baked new syntax, and people start using that before we've even implemented the full new syntax, we have even more extra churn and nasty surprises for users
brentmagma has quit [Remote host closed the connection]
plntyk has quit [Read error: Connection reset by peer]
plntyk has joined #openwrt-devel
<aparcar[m]>
lynxis: looks like you did 34df4d40e20, comments?
<aparcar[m]>
the kernel already uses EPOCH afaik
<jow>
aparcar[m]: changing the busybox dns resolving preference just like that is asking for trouble
<jow>
I'd strongly advise against it
<jow>
broken ipv6 is far more common than one might expect
nast has joined #openwrt-devel
brentmagma has quit [Remote host closed the connection]
<jow>
ideally I'd use happy eyeballs for its primitive resolver functions
<jow>
s/I'd/it'd/
nast_ has quit [Ping timeout: 260 seconds]
<jow>
sorry, that was bs, not for resolving, but for connecting() and stuff like that
brentmagma has joined #openwrt-devel
<jow>
in general this looks like a case of PR activism to me
<jow>
"mhh... my OpenWrt is having 4 NTP peers instead of just one"... "hmm ntpd behaves weird"... "hmm busybox sucks"... "Change all the things!!!!"
<jow>
proposing to change the resolve preference without any sort of information about conducted tests, possible regressions etc. is an absolute no-go"
<aparcar[m]>
jow: well you know me, I'm not looking for trouble
<svanheule>
Borromini has an EAP235-Wall, I'm sure he'd be glad to test any proposed solutions :)
<blogic>
well, he is an usual suspect so I would expect a 'yes'
<blogic>
;)
<svanheule>
ok, I'll cook up a patch to export a fixed-regulator with that GPIO, and ask if he has time to test :-)
<blogic>
cool
<svanheule>
then that would provide a second type of "PoE controller" you can use to cook up a uci-syntax
<blogic>
once that is ready I will adapt it for the ubnt er-x* units
<blogic>
yeah
<blogic>
it wil take a bit of desing considoration to find a generic approach
brentmagma has quit [Remote host closed the connection]
brentmagma has joined #openwrt-devel
AlexisEvelyn has quit [Ping timeout: 250 seconds]
AlexisEvelyn has joined #openwrt-devel
brentmagma has quit [Ping timeout: 265 seconds]
Ansuel has joined #openwrt-devel
<Ansuel>
ping greearb ?
brentmagma has joined #openwrt-devel
brentmagma has quit [Remote host closed the connection]
brentmagma has joined #openwrt-devel
Borromini has joined #openwrt-devel
DirkS has quit [Ping timeout: 240 seconds]
f00b4r0 has quit [Quit: Quitte]
dedeckeh has quit [Ping timeout: 240 seconds]
DirkS has joined #openwrt-devel
brentmagma has quit [Remote host closed the connection]
noltari_ has quit [Ping timeout: 252 seconds]
noltari has joined #openwrt-devel
<pkgadd>
Ansuel: just as a quick update, root@nbg6817:~# uptime --> up 20:57, all fine with your current dsa PR - now preparing a new build including tsense/ PCI I/O changes ;)
brentmagma has joined #openwrt-devel
einaar has joined #openwrt-devel
einaar has quit [Client Quit]
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Nick_Lowe has joined #openwrt-devel
<Ansuel>
pkgadd: nice! any difference with speed and cpu load?
ivanich has quit [Quit: Konversation terminated!]
<pkgadd>
Ansuel: my 'feeling' suggests that it might be a little slower (~365 MBit/s vs 420-430 MBit/s), but hard to say for sure
<Ansuel>
pkgadd: you mean with the old patch or with swconfig ?
<pkgadd>
right now I'm referrring to the old dsa patch, but swconfig in general might have been a little faster (slightly less CPU intense) overall, it's hard to say for sure
<pkgadd>
I'm not far away from the ceiling ipq8065 can do without NSS - and reliable speedtests are also hard to get at 400/200 MBit/s ftth
<pkgadd>
so the results may vary unrelated to the router as well
<Ansuel>
what i notice from the swconfig driver is that the dsa driver massively pool the mdio interface to get the port status while swconfig didn't use that at all... think this is what slow down the driver...
<pkgadd>
iirc that has been an issue with swconfig before, so the polling was tuned down