<f00b4r0>
gch981213: as long as we *support* iptables, we should apply relevant patches, imo
<robimarko>
I agree
<robimarko>
AFAIK, iptables are still supported
<f00b4r0>
that's my understanding
<robimarko>
So unless somebody doesnt agree with that I was planning to merge the offload without nftables today after letting CI do its magic
<gch981213>
dwfreed f00b4r0 robimarko: OK.
<dwfreed>
I was just joking about how the patches are patching patches
<dwfreed>
I have no input
<f00b4r0>
:)
<robimarko>
its always nice to patch patches :)
<robimarko>
Hm, something really changed as another commit ended up without commiter being updated
<robimarko>
Which I dont see how it could happen
<gch981213>
robimarko: If the PR is already ahead of main, it just get pulled directly.
<robimarko>
You are onto something, this particular one did not allow a force push from maintainers for whatever reason so since it applied cleanly anyway it just got pulled
<slh>
while I don't have an opinion of flow-offloading for iptables, I'd just like to remind that this had been rejected mainline (nftables-only) and was plagued by weird bugs in the past, so it may be easier to leave it nftables-only (with fw4/ nftables being the default, that shouldn't be much of a problem)
rmilecki has joined #openwrt-devel
<Ansuel>
jow don't know if you read the cover letter in the mailing list... an alternative solution might be hostpad firing an event and some script reacting on it... but no idea how to handle that correctly... wifi scripts would subscribe to an ubus event? Is it ok to do? nbd maybe can hint on something?
Mangix has quit [Read error: Connection reset by peer]
<jow>
f00b4r0: xt_FLOWOFFLOAD is openwrt specific though
<jow>
we could drop it and still support iptables
<f00b4r0>
ok, but we're still shipping the feature, and in that case we should ship a working one, shoudln't we? :)
<jow>
f00b4r0: strictly speaking we're not shipping it in master, we're shipping nftables
<f00b4r0>
ok, but doesn't that affect released code (23.05 maybe?)
<f00b4r0>
in which case it's probably better to have it in master so we can cleanly cherry-pick
<jow>
didn't check for which branch this patch applies
<jow>
for master I'd say drop iptables flow offloading, for 23.05 aply the fix
<jow>
anyhow, let's nbd make the descision, it's his code
<f00b4r0>
*nod*
robimarko has quit [Ping timeout: 480 seconds]
<mrkiko>
Regarding bump script discussion - ok, but please do not drop entirely the possibility of submitting patches via ML if possible. Working with web-centric tool can become quickly a pain
<jow>
well, it's the usual outburst of frustration due to not accepted aptches
<f00b4r0>
that.
<jow>
abandoning the ml will not change anything
<jow>
just increases the github pile
<mrkiko>
even tough they have good CLI APIs sometimes, an incomplete part of the API is enough to make things complicated for both parts (who's using the web side and who's using the CLI side)
<f00b4r0>
i think both have their use cases, and it "works" so far, so "if it ain't broke, don't fix it"
<mrkiko>
jow: yes
robimarko has joined #openwrt-devel
<nbd>
jow, f00b4r0: i'd prefer to keep iptables flow offloading in master for as long as firewall3 remains supported
<jow>
nbd: do we support device type "process handlers" in netifd?
<jow>
like ppp.sh for pppoe but for device types instead of protos
<jow>
thinking about potential 802.1x support and how it would fit into the config structure. Intuitively I'd make it a "config device" type, but one needs a backing wpa_supplicant process
<jow>
but maybe it also works to have those "config device; option type 8021x" entries in /e/c/network and let netifd simply claim them once they appear and handle the actual wpa_supp spawning through an init script or similar
slh64 has joined #openwrt-devel
<mrkiko>
the "pcoesse model" has the nice property of being more general, and maybe useful to handle other complex devices / scenarios
<mrkiko>
I tried hard to write "process" right but... :D
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
<stintel>
hahaha hotel with 2.4G Wi-Fi only. what is this, 1998?
<enyc>
:O m I only just set up a better quality 5ghz with EA8300
<enyc>
stintel: still wondering what may trigger a 23.05.3 tagging :O
<stintel>
I haven't been in OpenWrt context for a while now, I'm really not up-to-date on anything
<f00b4r0>
well we have a nasty on 7915, but I doubt it'll be fixed in time. Other than that I don't know :)
<csharper2005>
I mean drop-down list. For example, Etisalat, MERCUSYS etc.
<csharper2005>
PaulFerser: Do you know what has happened?
torv has joined #openwrt-devel
<csharper2005>
* PaulFertser:
<PaulFertser>
csharper2005: odd, I wasn't the one removing anything from those dropdowns. Do you think you know about when it happened?
<csharper2005>
PaulFertser: I just noticed this. I wanted to add Routerich AX1800 and found that there is no such brand anymore.
<PaulFertser>
Probably jow or somebody can take a look at the logs. I'm afraid the wiki engine itself doesn't allow to see the history of changing data aliases via web interface...
<csharper2005>
I feel like the list has gone back several years. "Old" brands like ASUS, TP-Link are in place. "New" (Etisalat, Beeline, MERCUSYS, MTS, Rostelecom, Routerich, WiFire) are missing.
mattsm has joined #openwrt-devel
csharper2005 has quit [Read error: Connection reset by peer]
<jow>
PaulFertser: I think this happend during the wiki migration
<jow>
PaulFertser: the datatable stuff reverted from our custom mysql backend to the upstream sqlite one
<jow>
PaulFertser: and I think it now simply uses whatever metadata happened to lie around on the filesystem in the sqlite3 database file from the point in time when we switched to our custom mysql backend
<PaulFertser>
jow: hm, that would explain it. How long ago was the migration? And do you think it's worth adding back brands manually one by one as requested by users?
kenny has quit [Quit: WeeChat 4.2.1]
<jow>
I guess we could bulk-add them by scanning the existing hwdata pages
<jow>
do some dirty script to assemble the list of items to set in the webadmin config
<mrkiko>
Ansuel: regardinr PR 14883 - do you think the same strategy by editing the u-boot env could help in making reovery easier for this device? I would be grateful if you could test that with stock bootloader and maybe let me know so I can edit the wiki, or edit the wiki yourself?
<mrkiko>
Ansuel: I am a fan of easy recovery you know
mrnuke has joined #openwrt-devel
<mrnuke>
Should I buy a switch whose GPL sources have the following devicetree entry, what are the chances I could get it working with openwrt? compatible = "marvell,msys", "marvell,msys-ac3", "marvell,msys-ac3-db", "marvell,armada-370-xp";
<slh>
mrnuke: if your intention is to run OpenWrt on it, no - otherwise, perhaps
<slh>
that doesn't mean it would be impossible to support, just that you'd be starting from minus zero, with the SOC bringup
<mrnuke>
I'm trying to gauge the effort ahead of time. Is there even a target for this SoC in openwrt? I see some basic support in linux.
<mrnuke>
How bad are marvell SoC wrt to firmware? Are they as headache inducing as QCA ?
<slh>
no one knows, there is no OpenWrt support for those SOCs so far
<slh>
may be reasonable, may be non-existent, someone would have to start from scratch
<mrnuke>
I am tempted, I must admit
<mrnuke>
grepping for the "compatible" strings in the upstream linux tree, I find a lot of them.
<slh>
while it would be great to get alternatives to realtek, I'd expect that to be a many-months endeavour, in the best case of everything necessary being open (if!)
<slh>
you'd start by just trying to recompile it, if that succeeds and leads to a similar image size than the original one, step one completed
<slh>
then you'd go over to actually checking the source
<slh>
diff'ing it against the vanilla kernel
<slh>
and dissecting all the rest of it
<mrnuke>
I'm feeling adventurous with soldering a serial header and jumping straight to initrmfs :p
<slh>
always worth trying, just with a smaller chance of success
rua has quit [Remote host closed the connection]
<mrnuke>
If they put that stupid TPLINK BOOTUTIL like they did on their realtek switches, I would be annoyed, I admit
rua has joined #openwrt-devel
<slh>
I don't want to discourage you, on the contrary, I'd really like to see marvell and broadcom switches to gain OpenWrt support as well - but that's not going to be easy and will be a long term aspiration
<mrnuke>
From the u-boot sources, it looks like they did that silly BOOTUTIL with no option to drop to a u-boot shell. That's annoying