AFAICS /etc/board.d/03_gpio_switches is missing the command
. /lib/functions.sh
although it uses the board_name function from that file.
Sourcing lib/functions.sh is the first thing uci-defaults.sh does, so that appears to be OK. The 03_gpio_switches file from ath79 has the same structure, and that doesn't appear to be causing any issues.
No, and my tinkering window for this weekend is closed now, sorry.
Sorry for not coming back during the last months. I was busy with a lot of other things. I got a build environment and I just looked at the dts file for the DGS-1210-16, but that looks exactely the same as for the 21.02 branch (see https://github.com/openwrt/openwrt/blob/openwrt-23.05/target/linux/realtek/dts-5.15/rtl8382_d-link_dgs-1210-16.dts versus https://github.com/openwrt/openwrt/blob/openwrt-21.02/target/linux/realtek/dts/rtl8382_d-link_dgs-1210-16.dts)
So I am not sure, if it makes sense to tinker with tzhe dts at all. The question therefore would be, what could have changed in regards to reboot between 21.02 and newer.
I broke my bootloader, could someone post an extracted bootloader image for Zyxel GS1900-10HP? Thank you very much!
You can find it here.
2 Likes
Thank you very much, you saved my life!
1 Like
Happy to help. I didn't have a backup handy for my GS1900-10HP, but I do for all my wireless hardware. Should be doing that for the wired ones too by default...
2 Likes
I was unable to get my Trendnet TEG-S750 to work given the lack of PHY drivers and difficulty reverse engineering the binary to create working ones myself, so I decided for now to pick an easier target, the TEG-S380. From what I can read drivers shouldn't be an issue there and all that's required would be a dts file.
I have lost track of what changes have accumulated in @olliver 's WIP branch and whether they're moving upstream, so I was wondering if I should just work against master for now?
Also: Mine is still on the way but I was curious if anyone in this thread might have a TEG-S380?
Good question 
Upstream doesn't have the resources to upstream it, and if it's an RTL93xx based switch, you more or less need my branch. Though I haven't checked this thread in 6 months, nor my patches 
I've seem to have run into the same issue on a Netgear GS750E with RC3. Getting a build environment setup and going to try a revert of 4ebba8a05d0 on the v23.05.0-RC3 as suggested by @Borromini. I'll get back with my results but am also open to ideas of what the root cause might be.
The symptoms that led me to looking into this we're having no connectivity after tftpbooting the kernel-initramfs image. The switch seemed to come up properly and got happy LEDs on connected ports but was unable to get any traffic into or out of the switch.
Oddly enough pinging from the switch would result in the LEDs flickering as if there was activity but nothing would appear on a tcpdump from the connected devices. Pinging the switch from the connected devices would not result in any LED activity.
Can confirm that reverting the above commit did correct the MAC address issue. However I was still unable to communicate with the switch. Going back to RC2 was the same.
So I'm going to say that the GS750E is broken for time being, I've reverted to stock firmware for now but left the UART semi permanently attached and put it back in the rack. I'll hopefully have time this weekend to see what's going on.
Again if anybody has any ideas about what the issue might be I'd love to hear them.
The MAC address issue that exists since 03_gpio_switches was added seems to be caused by board_config_update and board_config_flush. The actual problem is that the network-device object in /etc/board.json gets renamed to network_device.
It can be easily reproduced like this:
. /lib/functions/uci-defaults.sh
CFG=/etc/board.json board_config_update
CFG=/etc/board.json board_config_flush
5 Likes
That sounds like a bug in one of those functions within uci-defaults.sh.
1 Like
Yes, it seems the hyphenated version isn’t found anywhere else in the code.
3 Likes
It appears that https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=9290539ca9c7b296891b1b386052c0fe308e9a62 is the offending commit. From Dec 2020, so almost 3 years ago! Curious why it hasn't caused other issues until now!
1 Like
Not many targets use the function, fortunately.
$ git grep ucidef_set_network_device_mac
package/base-files/files/lib/functions/uci-defaults.sh:ucidef_set_network_device_mac() {
target/linux/qoriq/base-files/etc/board.d/02_network: ucidef_set_network_device_mac "$device" "$mac"
target/linux/ramips/mt7621/base-files/etc/board.d/02_network: ucidef_set_network_device_mac eth0 $(macaddr_add "$label_mac" 3)
target/linux/realtek/base-files/etc/board.d/02_network:ucidef_set_network_device_mac eth0 $lan_mac
target/linux/realtek/base-files/etc/board.d/02_network: ucidef_set_network_device_mac $lan $lan_mac_start
Are you able to submit a patch? If not I'll try to find time to work one up tomorrow.
The hyphenated variant (i.e. network-device) is actually the one that works, see netifd: https://git.openwrt.org/?p=project/netifd.git;a=blob;f=config.c;hb=afcd3825dad9b6a6712fbf6ed8e4434819a34009#l735
So, this has worked the entire time. The issue only occurs if another board.d script runs board_config_update and board_config_flush after 02_network (thus changing the key to network_device which netifd doesn't understand).
3 Likes
Thanks for clarifying. What changes the object name? I guess that’s the mystery…
EDIT: So this is a fundamental problem with libubox / jshn where it loads a variable while substituting special characters with underscore. So it's the board_config_update that transforms the name.
So using the hyphen was a sad choice.
See the name changed immediately when jshn reads the file.
jshn -R /etc/board.json
It comes from the alphanumeric check in jshn:
And someone realized this last year in the commit comments.
4 Likes