<jow>
- leave out the unrelated "network-device" -> "network_device" change
<jow>
- "management" is a rather long ifname (linux maximum length is 16) leaving only 6 bytes for prefixes and suffixes, br-management.4095 would already be too long, maybe consider mgmt
<jow>
- the rename logic might fail in case names need to ber swapped
<jow>
e.g. eth0 <> eth1
<jow>
I see you have some logic in place to use an autogenerated name then
<jow>
I'd suggest to do two cycles; first rename all relevant netdevs to temporary names, then rename them to their intented name in a second cycle
xback has joined #openwrt-devel
goliath has joined #openwrt-devel
* f00b4r0
learns about CVE-2022-38392 and chuckles
danitool has joined #openwrt-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
<rmilecki>
hurricos: i can't make much sense out of "x86 lacks device trees with which to name network port interfaces"
<rmilecki>
hurricos: "mapping from ethernet port name" - do you mean Ethernet interface? that port sounds misleading in this context
<rmilecki>
"to reconfigure all network device names" - i'm not eaxtly sure what names reconfiguration is
<rmilecki>
(i'm trying to understand that patch)
robimarko has joined #openwrt-devel
<xback>
nbd: good morning :-) can I get your ACK on this one? https://git.openwrt.org/?p=openwrt/staging/xback.git;a=commit;h=f2ca7dbcf74a6325cdf5c8020b3029740c04882e
<nbd>
sure
<jow>
robimarko: it's about assigning predictable netdev names
<jow>
sorry, rmilecki ^
<rmilecki>
jow: hurricos: it would be great to put that clear info in a commit :)
mrkiko has quit [Quit: leaving]
mrkiko has joined #openwrt-devel
<stintel>
hurricos: jow: in scripts, use full iproute2 invocations, e.g. ip l should be ip link
<stintel>
also, device tree doesn't allow naming ethernet interfaces either, afaik, it's just DSA ports you can name
<stintel>
so I think this patch could be relevant for all archs not just x86?
<stintel>
and I agree managment -> mgmt, internet should just be wan like we use everywhere else
<russell-->
fwiw, i expect network interfaces to look like network interfaces, cutesy names are just confusing
<stintel>
blame udev ;)
<stintel>
people want wlp0s20f3 rather than wlan0 ;)
<stintel>
need to look that up every time
* stintel
pukes
<Habbie>
tab completion helps ;)
<Habbie>
i'm typing at you from enx3ce1a14cdcac
<russell-->
i heard that once, but ... it doesn't in a non-trivial number of cases
<Habbie>
i recently found it works for tcpdump, which is the only place i ever type that name
<stintel>
iw wlan0 link
<stintel>
use it all the time to see where I'm connected :P
<russell-->
it works for some shells
<russell-->
"net.ifnames=0", ftw
<stintel>
aye
<russell-->
Predictable Network Interface Names really only makes sense is a server in a data center, which seems like the wrong thing to be optimizing for. most machines have one network interface of a particular flavor, and the most predictable name is eth0 or wlan0 </rant>
<Piraty>
predictable network interface names were supposed to address race condition in device enumeration so that eth0 and eth1 are possible mixed up on next boot, which i *never* ran into in my life without predictable network interface names. thanks systemd-udev
<stintel>
I call them Unpredictable Network Interface Names :P
<stintel>
e.g. I have a board with eno1 and enp12s0
<stintel>
suck much, both onboard, why is it not eno1 and eno2 ¯\_(ツ)_/¯
<PaulFertser>
onboard or not is decided based on SMBIOS information (you can see it in dmidecode), so blame your UEFI vendor
<stintel>
no, I blame udev, every body knows vendors suck at making BIOSes, building something that relies on bios info being reliable is a mistake
cbeznea1 has quit [Quit: Leaving.]
<PaulFertser>
Or the ACPI _DSM table. In SMBIOS case, check "dmidecode -t 41", if that lists just a single adapter then it explains why only one is marked onboard.
<PaulFertser>
(the ACPI table is of course made by the same shitty vendor, and they sucked during BIOS times and continue to suck in UEFI times as well, I agree)
cbeznea has joined #openwrt-devel
robimarko_ has joined #openwrt-devel
robimarko has quit [Ping timeout: 480 seconds]
indy has quit [Read error: No route to host]
indy has joined #openwrt-devel
<f00b4r0>
stintel: heh, so damn true. It's not a mistake, it's retarded. I have net.ifnames=0 on all my machines nowadays, including raspis :P
<karlp>
I'm glad you all never had problems, I had many problems with eth0/eth1 swapping, and it was a nightmare.
<f00b4r0>
karlp: static udev rules can fix that though
<PaulFertser>
static udev rules were not convenient when you were just replacing a PCI Ethernet card with another
<f00b4r0>
they were reliable
<PaulFertser>
Yep, but you'd need to reconfigure manually after such a replacement
<Piraty>
stintel: that's a udev rule bug i think
<Piraty>
also, the aliasing is weird
<stintel>
it also doesn't help that at some point Linux introduced a bug that made one of the interfaces not initialize on cold boot
<stintel>
on that board with eno1 and enp12s0
<stintel>
I guess I can just make a static DHCP lease with the same IP for both mac addresses to deal with that :P
<stintel>
or git bisect it but that can be time consuming, it's not my main box, it's not in my office and it doesn't have a BMC
<stintel>
maybe I should put some effort into porting pikvm to openwrt
<stintel>
but RPi camera is broken since 5.15 bump
<stintel>
there's going to be a lot of yak shaving involved :)
<barhom>
I've added a custom service using /etc/init.d/{Service} and it all works. It auto starts when I reboot the server and start/stop=99. However, how would I build my firmware if I wanted to include the service but not autostart it? I've tried issuing "service {service} disable" in uci-defaults, but that seems to not work
<stintel>
I believe miniupnpd is configured to not start by default
<stintel>
other option is to add an "enabled" option in uci and set the default 1
<stintel>
ehr, 0 obviously
<Habbie>
in the end, service enable just puts in two symlinks, right?
<barhom>
<Habbie> "in the end, service enable..." <- I think so, but I'm not sure where. I havent added the symlinks myself and it still autostarts
Gues__________________________ has joined #openwrt-devel
<barhom>
stintel: Oh, so I can add a service and set its enabled/disable state in uci? I missed this
snh has quit [Ping timeout: 480 seconds]
<Habbie>
the init script will have to check that state
<stintel>
barhom: it's not a state really just another option and [ "$enabled" -eq 1 ] || exit
<barhom>
Habbie: this helped, thanks! I see how it works now.
snh has joined #openwrt-devel
<Habbie>
barhom, good, np!
<mrnuke>
svanheule: There isn't a driver for RTL8231 in shit-register mode, right?
<hurricos>
stintel: not just DSA ports! mpc85xx is not DSA yet, but freescale picks up the port names from aliases for you anyways.
<hurricos>
in the OpenWrt context, "device tree", "DSA" and "port disambiguation" are all the same
<hurricos>
wow, glad it was well-received.
<hurricos>
rmilecki: The commit message was not very clear, I just threw something together so I could get a first-pass. I didn't know whether this patch would be controversial
Gues__________________________ has quit [Quit: Textual IRC Client: www.textualapp.com]
<hurricos>
stintel: RE: ip link: sounds good. I think the full invocation is done elsewhere in the same script.
<hurricos>
ultimately the "device tree" complaint was that device trees give an option to name interfaces somewhere linked directly to the device. Whether it's of_ parsing it for us to name the interfaces or not.
<stintel>
hurricos: the fact you can't change a real interface name in dts is the reason I used swethN for the switchports on the m300 rather than simply naming all the ports ethN
Snuupy has quit [Quit: leaving]
Snuupy has joined #openwrt-devel
<hurricos>
stintel: then you can use the ucidefs provided by this patch :P
<mrnuke>
hurricos: hi! I'm contrmplating closing some of the realtek-poe issues on github. Since people no longer complained, I'm assuming the retry mechanism fixed them
<ynezz>
anyone who could help testing 5.15.62 kernel bump on bcm27xx device? there was a lot changes and manual fiddling, and since this target is using 5.15 as default I would like to be sure, that it at least boots :P
srslypascal is now known as Guest813
srslypascal has joined #openwrt-devel
Guest813 has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
<stintel>
where can I find Dockerfile for the containers we publish?
<svanheule>
mrnuke: the RTL8231 in shift-register mode is really just a dumb shift register, doesn't need any special driver when used as a GPIO output
<svanheule>
mrnuke: the LED peripheral on realtek on the other hand, doesn't require an RTL8231 as output in shift register mode, could also be any other non-latching shift register
<hurricos>
wv
Borromini has quit [Ping timeout: 480 seconds]
srslypascal has quit [Ping timeout: 480 seconds]
srslypascal has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
<mrnuke>
svanheule: Thank you! I'm getting my terminology mixed up. Though I wonder, if four 74hc164 could do the job, why do vendors spend money on to put in an RTL8231?
kenny2 has joined #openwrt-devel
kenny1 has quit [Ping timeout: 480 seconds]
<mrnuke>
svanheule: BTW, I am looking at the patch link you provided on github (v4/7), and I do see "create mode 100644 drivers/leds/leds-rtl-switch-port.c", but I don't see the actual file in the ML thread. Is this in error?
<svanheule>
mrnuke: yeaaaah, I messed up that series... that file is in 3/7 (pinctrl patch)
<mrnuke>
svanheule: oh cool. Thank you!
* svanheule
should post a v2 already of the realtek MFD series
<f00b4r0>
mrnuke: pcb real estate, bom and assembly costs, power usage? Lots of reasons :)
<f00b4r0>
mrnuke: that pcb looks fairly crowded to my eyes. The parts aren't everything, the routing takes space
<mrnuke>
f00b4r0: fair enough!
<f00b4r0>
interestingly I can't seem to find a datasheet for the RTL8231: i was trying to figure if there's some killer feature that could be a differentiator :)
<svanheule>
but the regmap maintainer didn't like any approach I proposed on how to handle RMW ops on aliased registers (read for GPIO input, write for GPIO output)
<svanheule>
nobody appeared to have an idea on what would be good approach though, so that got stranded :-/
<mrnuke>
svanheule: don't use regmap then?
<svanheule>
mrnuke: but then I loose the possibility to easily support both the I2C and MDIO modes
<mrnuke>
svanheule: can you have an _ops structure with read() and write() accessors, which gers instantiated depending on the mode?
<svanheule>
mrnuke: and then get told I'm reinventing regmap?
<mrnuke>
svanheule: explain that regman can't handle this use case, add middle finger between the lines
<svanheule>
:P
<barhom>
Is there a hotplugd equivalent to listening to events that are received from "ip -4 monitor neigh" ?
<barhom>
The hotplug.d/neigh/ is not it right? Thats for Neighbor Discovery Protocol for ipv6?
cbeznea has quit [Quit: Leaving.]
Borromini has joined #openwrt-devel
Borromini has quit []
Borromini has joined #openwrt-devel
<f00b4r0>
mrnuke: ok it does look slightly more elaborate than a bunch of 74164 :)
<f00b4r0>
svanheule: *sigh*, what you describe sounds sensible though.
<mrnuke>
f00b4r0: definitely more elaborate in SMI mode. But on the picture I sent, It's used a dump shift register...
<mrnuke>
f00b4r0: although I'm more of a 74hc595 fan myself :p
jlsalvador has quit [Quit: jlsalvador]
jlsalvador has joined #openwrt-devel
<robimarko_>
HC595 FTW
AtomiclyCursed has quit [Quit: ZNC 1.8.2 - https://znc.in]
AtomiclyCursed has joined #openwrt-devel
SlimeyX has quit [Read error: Connection reset by peer]