guerby_ has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
<mrkiko>
pepes: what wi-fi chipsets will the newer turris use?
hanetzer has quit [Ping timeout: 480 seconds]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
dangole has quit [Ping timeout: 480 seconds]
hanetzer has joined #openwrt-devel
Tapper has joined #openwrt-devel
lmore377 has quit [Remote host closed the connection]
lmore377 has joined #openwrt-devel
srslypascal is now known as Guest1123
srslypascal has joined #openwrt-devel
Guest1123 has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest1124
srslypascal has joined #openwrt-devel
MaxSoniX has joined #openwrt-devel
Guest1124 has quit [Ping timeout: 480 seconds]
<pepes>
mrkiko: There's going to be Wi-Fi 6 edition of Turris Omnia and Turris MOX. We will be using AsiaRF AW7915 (for one device AW7915-NPD, for the other one AW7915-NP1). If you mean with the newer Turris the 10 Gbps one, then it was also marketing sneak preview and it is not going to be this year
<pepes>
But there is nothing wrong with Armada 385 if you compare it to Armada 3720, there are so many unresolve issues. :-(
<Mangix>
right. it's nice and stable
<Mangix>
but slow
<Mangix>
I have an armada 388 based NAS(same as 385 really). it's quite slow.
<pepes>
It depends what you do or what is your's use case, it is still a good device and quite powerful than most OpenWrt devices.
<pepes>
But it is kinda old SoC, that's true.
<rmilecki>
does anyone remember using uci for states? that was used years ago by mountd which stored its state in the /var/state/mountd (instead of nice ubus object)
<rmilecki>
# cat /var/state/mountd
<rmilecki>
mountd.mountd.count='1'
<rmilecki>
mountd.mountd.mounted='0'
<rmilecki>
was there a way to read such state files using "uci"?
<rmilecki>
i'd like something like "uci -c /var/state/ show mountd" but that won't work because "uci" expects config file format
<rmilecki>
jow: ?
<Mangix>
pepes: my NAS runs armbian. I believe the toolchain is not an optimized one like the one in OpenWrt. As an example, I see THUMB instructions being used.
Tapper1 has joined #openwrt-devel
cbeznea has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
<jow>
rmilecki: that's a delta file, use the `-P` flag for that
<rmilecki>
works! uci -P /var/state/ get mountd.mountd.path
<rmilecki>
thank you jow
<jow>
I wonder why you need it though, I thought that state file path is there by default
<jow>
but maybe I confuse it with the changes directory
<jow>
it really is an arcane mechanism that should die :)
<Habbie>
Package uclient-fetch (2021-05-14-6a6011df-1) installed in root is up to date.
<Habbie>
did wget always point to that?
<jow>
Habbie: since two or three releases yes
<Habbie>
ok, must have always just blindly used it instead of trying to install it, thanks :)
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<rmilecki>
jow: i'm doing the last maintenance release based on 17.01 for some old device
robimarko has joined #openwrt-devel
danitool has joined #openwrt-devel
Mangix has quit [Read error: No route to host]
Mangix has joined #openwrt-devel
<Mangix>
pepes: this thing just rebooted. I think because of the watchdog
cbeznea has quit [Remote host closed the connection]
srslypascal is now known as Guest1132
srslypascal has joined #openwrt-devel
cbeznea has joined #openwrt-devel
Guest1132 has quit [Ping timeout: 480 seconds]
srslypascal has quit [Quit: Leaving]
srslypascal has joined #openwrt-devel
<ctdvqgg445[m]>
hi, folks! What does this error mean:
<jow>
as I understand it, they want to figure out the highest index of netdevs named "eth*"
<jow>
then assign temporary "eth*" names starting after the highest index (to avoid collisions)
<jow>
simpliy falling back to "0" should be fine if no eth* exists at all
<jow>
also I don't understand the logic that bumps max_eth if next_eth is higher
<jow>
shouldn't max_eth be determined by that grpe thing before the loop?
<jow>
why bump again
<nbd>
jow: btw. just a quick heads up: i'm planning on adding support for defining wlan devices in board.json like this: ucidef_set_pci_wlan radio2g 0001:01:00.0
<nbd>
and then add support for referencing the device in /etc/config/wireless via the alias name
<jow>
elco echo | grep | tr ...
<jow>
*also, that could be a simple substitution
<nbd>
that way if the pci device ever gets renumbered, we can just update the board.d file
<nbd>
without breaking people's configs
<jow>
nbd: yes, blogic told me
<jow>
nbd: did you consider simply renaming the phys?
<jow>
and then refer to them using the existing option phy
<jow>
instead of doing the alias logic in uci/associated scripts
<nbd>
i thought we had some assumptions in the code somewhere about phys being in the format phy%d with %d being the phy index number
<jow>
I don't think there are, but even if, we should fix that
<jow>
there is one kernel imposed limitation, you might not set phy[0-9] as custom name
<jow>
so iw phy phy0 set name phy1 will be rejected with EINVAL iirc
<nbd>
okay, so i'd do it like this:
<nbd>
i keep the part in board.json (i also plan on allowing adding more attributes to describe the radio type, e.g. for pure scanning radios)
<nbd>
i add a ieee80211 hotplug script which checks board.json and does the phy rename
<nbd>
on wifi config, i need to also do the lookup (in case there are race conditions)
<jow>
or simply reject phy[0-9] in wifi config
<jow>
it means that it hasn't beenrenamed/dealt with by definition
<nbd>
there might be hotplugged usb wifi devices
<jow>
then rely on being triggered by the ieee80211 hotplug handler again
<nbd>
which should not be in board.json
<nbd>
or boards which don't define their wifi devices yet
<jow>
ieee80211 hotplug handler would do:
<jow>
new phy? => check if board.d mapping. yes? => rename to given name and call wifi config
<jow>
not in board.d => do not rename and call wifi config with some kind of force flag
<nbd>
but in the mean time another phy might have appeared as well, which hasn't been processed by the hotplug handler yet
<nbd>
so wifi config would see phyX for that one
<jow>
or rename it too using some autogenerated name, maybe based on bus type. eg usb0
<jow>
but I see the issue you describe, yeah
<jow>
the lookup/phy matching logic should be sharable
<jow>
so that we can reuse it in various places
<nbd>
right. i'd prefer to leave unmapped phy* devices alone for now
<jow>
will you addd it to iwinfo, or add it as "wifi phylookup" subcommand or similar?
<jow>
user logic will likely be something like desired_name=$(lookup_phy_wanted_name_command $actual_name); if [ $desired_name = $actual_name ]; then ... proceed ...; else ... ignore ...; fi
<nbd>
i could keep the entire logic within /lib/wifi/mac80211.sh, because that gets called on hotplug as well
<nbd>
and it already iterates over phys
<nbd>
looks like i will need to make some fixes for iwinfo as well
<nbd>
since it also has the wiphy index <> phy%d assumption
<oliv3r[m]>
jow hopefully the maintainer can agrue all of that. RIght now, on switches, we have lan1-lan12 for example in addition to eth0. So if this loop executes, we grep for eth[0-9]* in a list (eth0 lan1 lan2 ...) which works great for eth0; but fails for lan1. What happens there is that 'next_eth' becomes 'empty' which causes an evalution error ( '' -gt 0). This then caueses errors. I only fixed that bit; the deeper logic of that loop, well
<oliv3r[m]>
idk what the author intended or desired :)
<oliv3r[m]>
and I think it even 'aborts' the for loop, or even the function, but not sure if we have 'set -e' set generally, or if the loop just happily continues. Actually, from my observations, it does continue ...
<nbd>
jow: what do think about also changing the name of the created ifnames for renamed radios? e.g. radio1 has radio1ap0, radio1sta0, etc.
<nbd>
makes it easier to figure out which netdevs belong to which phy
<nbd>
because right now usually wlan1 belongs to phy1
<nbd>
after the rename it would become a bit more confusing
<nbd>
also, do you have a preferred naming scheme?
<robimarko>
This should be what you need for that Realtek PHY
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
<jow>
nbd: yes changing name style makes sense
<jow>
nbd: radio# prefix is too long
<jow>
make it r#
<jow>
ap/sta/mesh/etc. as suffix makes sense
<jow>
and numbering should follow the declaration order of /e/c/wireless (not hostapd's bringup order or other implementation details)
<jow>
then we'll have predictable wifi ifnames and might even consider allowing them in /e/c/network
<jow>
radio phy names should be ordered by band
<jow>
in case there's multiple radios
<jow>
r0 => 2.4 GHz, r1 => 5 Ghz, r2 => 6 GHz
<jow>
and ifnames would be r0ap0, r0sta0, r1ap0, r1ap1 etc.
<jow>
maybe w# instead of r#
<jow>
w0ap0, w0sta0, ...
<nbd>
0, 1, 2 doesn't really work
<nbd>
radios can be dual-band
<nbd>
2.4+5 or 5+6
<nbd>
and there can be multiple radios supporting the same band
<nbd>
maybe wl2g, wl2g5g, wl2g5g1 (if there is a second one of the same type)
<nbd>
and maybe a0, s0, m0 as suffixes
<nbd>
allowing wifi ifnames in /etc/config/wireless is still problematic
<nbd>
not just because of the bringup order (needs to be controlled by wireless)
<nbd>
but also because the numbering can change if you reorder sections, disable the first interface on the same ap, etc.
<nbd>
btw. i managed to fix nl80211 issues with renamed phy
<jow>
a disabled section should still take the "slot"
<nbd>
but if you delete it, the order changes
<jow>
sure
<jow>
I still believe that a predictable naming schema would provide benefits
<jow>
and that the numbering should follow the config order, regardless of implementation details
<jow>
we need to generate and specify the ifnames anyway per wifi-iface, so it's just a matter of fixing the generator sequence
<nbd>
sure
<jow>
not sure if naming radios after bands make sense
<jow>
especially since a single digit "2" for 2.4Ghz is somehhow confusing
<jow>
but if we do, then dualband radios should probably be "wl25g..." or similar
<jow>
in case of multiple, wl25g..., wl25g1..., wl25g2...
<jow>
followed by ...ap#, sta#, mesh#, ibss#
<jow>
on my apu here it would then be wl25g and wl25g1, so no benefit over wl0... and wl1...
<jow>
but on typical white box devices it'll likely work out nicely
<nbd>
maybe we should use slot numbers then
<nbd>
start with platform wmac, then number by pci bus/slot
<nbd>
defined by the board.d file (with platform specific fallback)
<nbd>
and just allow the board.d file to add additional metadata to the board.json entries
<nbd>
for scripts which are interested in that
<nbd>
so if you don't care about the extra capabilities stuff, you would simply have wl0, wl1, wl2... in a stable predictable order based
<nbd>
but there might be gaps
<nbd>
if you have a wmac and 2 pci slots and the first pci slot isn't populated, you get wl0 and wl2
goliath has joined #openwrt-devel
<f00b4r0>
i'm catching in flight here but what about radios where a specific band is disabled? Would that change their names? That would be a bummer imho
goliath has quit [Remote host closed the connection]
goliath has joined #openwrt-devel
<nbd>
f00b4r0: i would rely on the board.d script to provide the name
<nbd>
so i wouldn't rely on autodetection for that
<f00b4r0>
ok, playing devil's advocate here: either the name is static and includes bands, and a user setting their dualband radio on a single band would possibly be confused by having both bands in the name;
<f00b4r0>
or the band reflects the actual active band and we end up with ifaces that change names depending on which band is enabled
<nbd>
i was planning on making the name depend on hardware capability only, not user configuration
<f00b4r0>
either way, that sounds like a bad idea in my very humble opinion
<nbd>
but i don't think i like the capability based name anymore
<f00b4r0>
(not to mention namming clutter)
<nbd>
i think we should stick to stable slot based numbering
<f00b4r0>
fully agree
<f00b4r0>
short, consistent names is ideal
<nbd>
the board.d script can provide some extra metadata about the radio types
<f00b4r0>
*nod*
<nbd>
i guess the remaining question is what do we do about devices that have multiple phys? (e.g. DBDC)
<nbd>
wl0b0, wl0b1...?
<nbd>
maybe just wl0, wl0b1, ... otherwise detection gets racy
<f00b4r0>
why not incrementing normally? They're separate devices aren't they?
<f00b4r0>
network devices*
<nbd>
if you increment normally, slot assignment is no longer deterministic
<f00b4r0>
ah right
<f00b4r0>
well... isn't it? The number of phys is fixed?
<nbd>
well, path is provided by board.d, slot assignment as well
<nbd>
at that time, the devices may not be present yet
<f00b4r0>
ah i see
<f00b4r0>
well I guess there's no way around suffixing then indeed. Not sure what 'b' stands for?
<nbd>
band
<f00b4r0>
hmm. Might be confusing with 2 and 5. How about 'p' for 'phy'?
<hurricos>
oliv3r[m]: The logic pretty straightforward: > # Find and move netdevs using eth*s we are configuring
<hurricos>
Iterate over the list of `network-device`s in the json, and then move the corresponding actual devices out of the way *somewhere*, before moving them back.
<hurricos>
It would have been more complicated, but probably better, to avoid moving devices that already have the right name
<hurricos>
jow: < why bump again > because at every point in that loop, max_eth points to an existing eth$max_eth netdev. We can't use that name, we must bump.
<hurricos>
We keep max_eth true when we do `ip link set "$netdev" name eth$((++max_eth))`
<hurricos>
we keep its property, of describing the highest eth netdev name*, rather
soxrok2212 has quit [Remote host closed the connection]
soxrok2212 has joined #openwrt-devel
minimal has joined #openwrt-devel
soxrok2212 has quit [Read error: Connection reset by peer]
soxrok2212 has joined #openwrt-devel
dangole has quit [Ping timeout: 480 seconds]
<f00b4r0>
hostapd: wlan0: STA 9e:4d:25:de:b8:a7 IEEE 802.11: did not acknowledge authentication response
<soxrok2212>
Mangix: if you're referring to the BSS coloring one, I did try that without success
Piraty_ has joined #openwrt-devel
<Mangix>
there's also he_su_beamformee
<soxrok2212>
Sorry my bouncer is down for another week or two, in the process of moving
<soxrok2212>
I tried that one as well, no luck either
<Mangix>
you try rolling back to ac?
<soxrok2212>
On my MT76 devices, yep and that worked. On the current ATH11k, I haven't tried that yet.
<soxrok2212>
I think people are being slightly mislead that its specific to MT76 drivers (which I can't blame them because those are the only ones officially supported).
<Mangix>
sure
<Mangix>
it's a broadcom incompatibility from what I can tell
<soxrok2212>
I think I'd agree. MT76 clients attached in 802.11ax mode seemed okay. Only looks like Broadcom
<soxrok2212>
I didnt try on stock fw though, and I no longer have any devices running it so I don't have a way of testing that
Piraty has quit [Ping timeout: 480 seconds]
<Mangix>
not the first time broadcom has been a thorn
<soxrok2212>
Does anyone here have any means to create a bug report?
<Mangix>
to what?
<soxrok2212>
bcm
<Mangix>
haha no
<soxrok2212>
i'll fill an apple bug report but that prob wont go anywhere
<Mangix>
they really don't care
<Mangix>
the issue has to be worked around in mac80211
dangole has joined #openwrt-devel
<soxrok2212>
IIRC setting the AP to 160MHz fixed the issue, even though apple devices can't use more than 80MHz
<Mangix>
weird
<soxrok2212>
k i put in a bug with them but that'll probably end up in the trash
<Mangix>
the router i'm using right now doesn't do 160MHz unfortunately
<Mangix>
I *think* it does 80+80 but I don't know if OpenWrt supports that.
<soxrok2212>
ill have to try it again on the qhora-301w
soxrok2212 has quit [Remote host closed the connection]
<dfceaef[m]>
Hi, i'm trying to porting openwrt to a new device. I managed to recorgnize switch but still no Internet, however if I try to ping from the device, eth0 rx errors grows. What is the possible cause?
<Ansuel>
nha it's good could be that i'm nitpicking too much on enforcing kernel commit rules ahahah (sorry for that if i'm annoying)
<Ansuel>
but in theory for someone who is handy with git it's really 1 sec to make the fix
<Ansuel>
anyway I notice you are having fun with scanning each base files script thanks a lot
<hurricos>
dfceaef[m]: Nice work.
<oliv3r[m]>
Ansuel Nah, i rather get it down and do it right; though I have to warn you; sometimes I make the same mistake many times :D
<oliv3r[m]>
not su much fun; just bugs that I bump into :(
<Ansuel>
in my mind fun = suffering AHAHAH
<oliv3r[m]>
:(
<hurricos>
dfceaef[m]: Hmm, not sure. Isn't that the same switch chip in the WRT1200AC's silicon?
<oliv3r[m]>
i have a couple of other small MR's for your suffering; erm fun :)
<Habbie>
Ansuel puts the fun in dysfunctional!
dangole has joined #openwrt-devel
<oliv3r[m]>
btw, I heard that there is this 'gitlab' experiment; how is that experiment fearing? I much rather do MR's there :D github's UI is ... sad
<Ansuel>
Habbie ahaha exactly
<Ansuel>
oliv3r afaik we voted for github at the end
<hurricos>
oliv3r[m]: there are some serious complaints with gitlab. It's really heavy, requires somewhat heavy management ... I run gitlab.laboratoryb.org, it's not trivial.
<hurricos>
It's also sort of becoming a walled garden.
<hurricos>
A few folks *really* like gitea / codeberg
<hurricos>
gitea is fast / small / manageable / featureful
<hurricos>
it's more focused on APIs than features, too, which lets you be flexible. I know stintel was a fan of that
<oliv3r[m]>
that's so sad :(
<oliv3r[m]>
but that's self-hosted vs clou hosted; running github surely also mst be quiteheavy
russell-- has quit [Quit: leaving]
<oliv3r[m]>
it's sad as using github is somewhat conflicting with the purpose of openwrt; a bit of a conflict
<oliv3r[m]>
a bit of a curse I meant
<oliv3r[m]>
Suppose 'vendor lockin' and 'inertia' is the suck we get ourselves in ...
<Ansuel>
well we also had to face reality and the fact that github offer good service for free on opensource project
<oliv3r[m]>
dance with the devil and all that :p
<oliv3r[m]>
and gitlab, for opensource is also a very good service for opensource projects :p I think they do not diferentiate that much; where one is of course 'open-core' and the other; 'propriatery from mega corp' :)
<mrnuke>
Holy poop! I've tried to use GitLab on internal company server, and the thing sucked. Long load times, unresponsive, et cetera. Not to mention Bitfucket, which is worse in every concievable way
<mrnuke>
Look at the bright side: Github being reliant on git, gives you, by definition, a local copy of all your data. So is it that bad then that github is a service?
<hurricos>
Yeah, gitlab is mega slow
<hurricos>
My understanding is that people wanted self-hosted but without a huge maintenance burden. Gitlab has a pretty severe maintenance burden associated with it, even if it is very featureful. We get a lot of participation from Github, so having some sort of Github-facing area for PRs is probably a good idea
minimal has quit [Quit: Leaving]
<hurricos>
If we end up going self-hosted, Gitea beats everything else handily
<hurricos>
that at least gets OpenWrt away from webgit
<oliv3r[m]>
We use GitLab $work (we are in AMS/NL) and speed-wise it's actually really good. Bitbucket, yes a pile of steaming crap, and the features are to cry for :p
<mrnuke>
oliv3r[m]: You misspelled Bitfucket :p
<oliv3r[m]>
yeah, self-hosted I get; U-Boot also self-hosts, as a few others, there's also freedesktop that offers 'hosted' gitlab though; but if you want fully selfhosted ... yep, that's effort
<hurricos>
Upgrading Gitlab is horrifying. I've had to do it :^)
<oliv3r[m]>
I don't get though, that 'we want self-hosted, that's easy; well then lets just stay with github' which is the opposite. I do get the whole innertia thing though; people know github; so if you want those contributions, you'll have to keep that open
<hurricos>
One of the other big pulls was automatic package CI
<oliv3r[m]>
lol mrnuke I've misspeled butbucket as butbucket so often
<oliv3r[m]>
erm lol; that was an freudian slip!
<hurricos>
rip
<hurricos>
We knew that Github worked great for CI
<mrnuke>
Say we decide not to use Github anymore. What's the alternative? raw git and mailing lists? We alreade have that self-hosted
<hurricos>
gitea! :^)
<mrnuke>
oliv3r[m]: Ooh, you are correct. That is also a valid spelling :)
<mrnuke>
hurricos: okay. gitea is an alternative :p
<hurricos>
The PR structure is very featureful, almost a clone of Github's
<oliv3r[m]>
quick question; I see we use packages/boot/uboot-envtool/files/* to generate /etc/fw_env.config; this seems to be runtime configuration; where does this file live on the target, as it seems to get renamed?
<Ansuel>
there are some function that adds info to it
<Ansuel>
they are in the target board.d
<oliv3r[m]>
are you sure? i only see leds, network, default_network on my actual target
<oliv3r[m]>
perfect, thanks that's exactly what I was after
<hurricos>
oliv3r[m]: I was looking for this the other day and couldn't find it.
<hurricos>
Thanks for poking me to look again
<oliv3r[m]>
Right now, our platform uses a lot of switch-cases to get the sizes of the various partitions for the different targets. Any objections on getting that from /proc/mtd or the devicetree or something? I mean the actual data is right there, runtime, should just levarage that
<jow>
hurricos: hmm
<jow>
hurricos: if you look for all existin eth*s on a system, and take the highest index
<jow>
hurricos: and then you iterate a set of devices and rename to eth${highest_index+n}
<mrnuke>
hurricos: okay, I must admit, it is fast, even when using fireforks
<jow>
it is guaranteed that there will be no conflict
<hurricos>
oliv3r[m]: It's about you encode it; device tree has to follow bindings. Can we gather eraseblock info from the bindings of the underlying blockdev?
<hurricos>
mrnuke: that's all I use :^)
<jow>
so I was confused about the seemingly redundant -gt checks inside the loop
<jow>
I still am tbh
<hurricos>
Hmm, good point, wasn't very smart of me
<mrnuke>
Ansuel: I remember seend a PR of yours with DSA for ipq806x. Couldn't find a reason why that didn't land
<Ansuel>
mrnuke no multicpu and a little bit of perf regression
SlimeyX has quit [Read error: Connection reset by peer]
<Ansuel>
qca8k patch are all there so it's really a matter of update dts and board.d
<oliv3r[m]>
hurricos Thed evicetree gives me the start address, /proc/mtd gives me the size and eraseblocks; so the data is there, so parsing and runtime, vs 'manually adding stuff in two places' seems like a good idea
<hurricos>
oliv3r[m]: does it, though? How do you know which ones are u-boot config partitions?
<hurricos>
Some are named differently, partitions cannot always be renamed
<jow>
hurricos: however as far as I understood, the idea is to find a somewhat simple way to just obtain some unique name
<jow>
it's going to be renamed anyway
<mrnuke>
Ansuel: What is the plan with it? Is there something that needs to get fixed, or general fear?
<Ansuel>
mrnuke no general fear just people compialing with worse performance
<oliv3r[m]>
hurricosfor our platform, for now, yes; we can always make a switch-case to select the name(s) for those targets that cannot be changed, and the default uses what we CAN change :p that makes our file still MUCh easier and much better ot maintain; granted, it would still be limited to 'realtek' and not generic enough for everybody
<hurricos>
oliv3r[m]: True. Risk is lots of churn, though.
<hurricos>
Well, sorry, if your interest is just applying this to realtek, then not really
<mrnuke>
Ansuel: Is that "performance deficit" something that can be improved? An artifact of using DSA?
<hurricos>
oliv3r[m]: Be interested to see, aren't there multiple config partitions? fw_setenv vs fw_setsys?
<oliv3r[m]>
yep, but that's not a big issue imo
<oliv3r[m]>
let me cook something up :)
<oliv3r[m]>
I think I just re-triggered 'sh: out of range'; not sure if it was because of what you suggested, or something else
<Ansuel>
mrnuke well not that much honestly... the perf problem comes from the cpu having to tag every packet... also the other problem is that the entire switch is limited to single cpu port
<Ansuel>
so wan + lan traffic and you saturated the switch
<hurricos>
Ansuel: is there no support accepted upstream for multicpu in qca8k?
<hurricos>
jow: I was afraid of a bug there where a hole created by one move would be filled by another, but I realize that the target name is strictly monotonically increasing
<hurricos>
Oh, yes, that's still a bug
<mrnuke>
Ansuel: How come that limitation is not observed with swconfig?
<hurricos>
so I don't want to assume anything about what the kernel will use for prefixes, even sth. like `tmp`
<hurricos>
OpenWrt sees `xaui`s e.g.
<Ansuel>
mrnuke works differently... no tag and on swconfig a cpu port is entirely assigned to the wan port
<jow>
hurricos: I'm afraid I don't follow
<jow>
hurricos: ah, right. The current script doesn't actually rename in two cycles
<hurricos>
if the system enumerates by any chance eth0 and eth2, and then first processes eth2 -> eth1
<hurricos>
then you get eth0 -> eth2, and you're back at square 1
<jow>
which I've been saying all the time. rename in two cycles
<hurricos>
Right
<jow>
first all ifnames to a temp namespace
<jow>
then all temp named ifaces to their final name
<hurricos>
a netns?
<jow>
no, namespace as in set of names not currently used
<hurricos>
well, no, I don't want to run into the issue of assuming what the kernel is naming netdevs for any reasons
<hurricos>
unless there is an enumeration of namespaces?
<hurricos>
that I have sources for
soxrok2212 has joined #openwrt-devel
<jow>
why do you need to know that?
<mrnuke>
Ansuel: so why can't DSA use a separate port for WAN, but swconfig can? Just a limitation of DSA?
<hurricos>
well, a crackpot kernel change may introduce a naming scheme like tmp :^)
<jow>
wouldn't hurt
<hurricos>
it's a goose chase
<jow>
the code I pasted would deal with that
<hurricos>
but then the issue I described applies. Kernel initiates tmp0, tmp2
<Ansuel>
mrnuke yes with 6.1 you will be able to create a LAG between cpu port or assign a specific cpu port to a port
<hurricos>
but if tmp2 is processed first to tmp1, then deals with tmp0 ... it becomes tmp2.
<jow>
no it keeps increasing the index until it finds a free one
<hurricos>
yes, tmp2 is free as soon as tmp2 -> tmp1
<jow>
let me whip up a more complete example, maybe that will make the point clearer
<hurricos>
Note that if you start i=$max_eth, the problem goes away
<hurricos>
since you have monotonically increasing rename targets AND all rename targets are higher than existing netdevs
<jow>
granted, that assumes that the target names and the temp names use different prefixes
<jow>
but it can deal with existing netdevs using a temp name prefix
<jow>
it just needs to find *some* free name
<dfceaef[m]>
hurricos: 88E6176 for WRT1200AC, but this is 11 port 88E6095F, i've searched all dtses but none of them use 11 port mv88e6085 (if i got it correct
<hurricos>
dfceaef[m]: underlying compatible / driver is the same I *thought*, may have only been historically true in swdev world
<hurricos>
jow: yeah, I don't want to assume much
<hurricos>
I don't want to assume what namespaces kernel will use, and don't want to assume we can control the json object's order
<jow>
you don't need to control the order
<hurricos>
and I don't want to assume <that assumes that the target names and the temp names use different prefixes>
<dfceaef[m]>
RX errors indicates something goes wrong between switch and soc mac. I've tried changing CPU port from eth0 to eth1 and got no RX errors, but I don't know how to debug RX errors (tcpdump shows nothing
<jow>
hurricos: you don't need to assume that, you know that
<jow>
since you know how the target devices will be named, you can use a temp name that will not interfere
<jow>
I mean we will nto ship boards with netdevs named tmp#
<hurricos>
jow: kernel decides, not us
<jow>
huh?
<hurricos>
I'm under the impression that the kernel enumerates the netdev names?
<jow>
the whole point of the rename script is that we decide how we name our netdevs?
<hurricos>
Oh, I see, targets
<jow>
so the idea is: 1) enumerate list of devices we want to rename 2) find *any* free name with a prefix guaranteed to not collide with the final target name (we control the target name through board.json) 3) remember the free temp name we found, push it onto a list 4) iterate list of remembered temp names 5) pop desired name off final name list 6) rename temp name to final name
<jow>
required input is a list of devides we want to rename and a list of target names in equivalent order
<jow>
(outside ash one would use a dictionary, due to a lack of that in ash we need two equivalently ordered lists)
<hurricos>
The second phase (for netdev in $temp_names; do) is what we do right now. I don't like using shell logic, so I don't really want to track the names; the only other option I have is renaming everything higher than it is now
<jow>
the lists can be built by iterating the json keys and then pushing source name and final name each to the lists
<hurricos>
find all eth's, create logic (max_eth+1) that is independent of it, use those, call it a day
<hurricos>
then move them back as per the second wave
<hurricos>
I'm very weak with jshn which is why I didn't implement it that way
<hurricos>
https://github.com/openwrt/openwrt/pull/10782 looks like it's cleaning up the shell implementation, and some unnecessary extra checks. Fixing the bug it points at could just as easily be done by just removing the check `[ "${next_eth}" -gt "${max_eth}" ];` though, since we know we won't encounter any of those netdevs, since we know the max from the start.
<jow>
I must admit that I am throughly confused by the purpose of the script :D
<jow>
I thought it was the thing to assign predefined names to eth ports in a detemrinistic order (to match case labels and the like)
<hurricos>
It is, it's just a question of implementation
<hurricos>
lots of gotchas when you rely on simple code
<jow>
but this one here just seems to rename some netdevs to eth${highest_known_index+n}
soxrok2212 has quit [Remote host closed the connection]
<jow>
so the actual target name is not specified in board.json