That not the case with ALL-SG8208M, right?
The ALLNET ALL-SG8208M is supported as Proof of Concept:
To install, upload the sysupgrade image to the OEM webpage.
I stand corrected. I have no experience with the ALLNET switches.
What I do know is that the Netgear GS108Tv3 will allow you to flash any image with a matching U-Boot image header, but will cut off the file at the size given by that header. Which means that it will write only the kernel part of an OpenWrt sysupgrade image, silently dropping the rootfs, and therefore brick the device.
The ZyXEL GS1900-10HP on the other hand, will only accept images with a ZyXEL specific trailer indicating that it is intended for that specific hardware (using a ZyXEL version number with a 4 letter hardware code). It cuts off the file like the Netgear firmware, so it can't write a kernel+rootfs sysupgrade image either. But it cuts the file before validating the trailer. Which means that we have to include the trailer in the kernel part of the image (inside the size covered by the U-Boot header). This should only be done for the initramfs images, thereby preventing the sysupgrade images from being flashed directly from stock firmware.
I'm totally confused on how to actually access the switch after getting the initial image installed! I've started with a GS108Tv3. Uploaded the initramfs image via the OEM Web access. I can see from the serial port access that OpenWrt is running, but I can't seem to access it from any of the Ethernet ports! From what I've read it should be available at 192.168.1.1 from ports 2-8.
After using Borromini's posted UCI defaults above I was successful in connecting to the switch. Perhaps the default should be changed to something similar so that initial login won't be a crap shoot if you don't have serial access!
Currently, the management interface (luci, ssh, etc.) is only available on port 1 and VID 100, so you need to connect your computer to port1 and configure your computer's network card to use (tag all packets with-) VLAN ID 100 (then you can connect to 192.168.1.1).
Certainly not my favourite either, but it works. I'd be very much in favour of changing the defaults as well, but it is a bit more complex to get this 'right', as it's still a switch and not really a router with routing, NAT, and a DHCPd running - somehow I don't think change this in the last minute (for 21.02.0) would be the best idea (personally I'd favour it to be configured for DHCP-client, but then it gets very special, with even more default assumptions that might go wrong…).
How many people are going to know how to set up their computer's network card to tag all packets with a specific VLAN ID? It would make more sense to set up all ports to the same IP address just like most of the OEM firmware does.
I'm not arguing against that at all, on the contrary, but I do see problems in trying to rush a change (keeping in mind that the realtek target looks like being present in openwrt-21.02) - as a bodged attempt may be more problematic than considering the current state a technology preview with known quirks.
This is definitely a bit late, but I still believe it's better to fix it now before the very first release of this target. A number of advanced early adopters have already been bitten by the issue. There is no doubt that it will cause endless confusion for end users trying to flash an official 21.02 image without having console access.
I'll see if I get around to cook up something later today.
We should also fixup default configuration for switches with more than one mac address, storing the full range in "u-boot-env2" like the ZyXEL GS1900 does.
And the PoE package should go in. It's working very well, and is required for the PoE feature. I see no reason to keep that out of 21.02. It will just confuse and annoy users who have to jump through burning hoops for no reason at all.
Seriously, I have been advocating this from the beginning of Realtek switch support. And I will bring it up once more, and then never again:
If you create OpenWrt for a device, make it an OpenWrt device.
This means using the same default config and the same default packages as any other device. Even if it doesn't look like other devices, or was a different device before (as if that was a factor anyway.)
As much sense as it makes to you to have some pre-configuration that moves it closer to the device it once was, it makes your device "based on OpenWrt" rather than "running OpenWrt." Case in point: It is easier to introduce a VLAN than to remove it. It is easier to disable the default dhcp server and firewall than to recreate it if you need it. It is easier to set an interface to DHCP from the default static adress than the other way around (yes, unfortunately this actually happens on some devices/targets.)
I'm trying to add support for the Netgear GS308T and GS310TP, but because of the horrible default network setup I'm having difficulty determining whether the issues I'm having is related to my total misunderstanding of using tagged VLANS or if there is an issue with the actual device! I get link lights on both the switch and the connected device, but can't get a response from ping or any other service! How exactly must the connected device be configured to access the switch?
# ip link add link enp2s0 name enp2s0.100 type vlan id 100 # ip link set dev enp2s0.100 up # ip addr add 192.168.1.10/24 dev enp2s0.100
on your client will give you full access to the management interface (well, at least if plugged into port 1), including ssh/ luci, etc.
Important part to note: It will only work on port 1. That's the only port where VLAN 100 is configured.
(another reason this is a bad idea: port 1 is special on the PoE powered devices like the GS108Tv3, and using it for even temporary management might be a problem if you can't easily reconfigured the PSE)
Late as usual, but submitted now: https://lists.openwrt.org/pipermail/openwrt-devel/2021-April/034652.html
Not tested as hard as I'd like, so I'd appreciate testers adding Tested-by. I guess support of 21.02 backporting is important too..
The resulting default config on my Netgear GS108Tv3 is:
root@OpenWrt:/# cat /etc/config/network config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config globals 'globals' option ula_prefix 'fd1a:643c:5c9c::/48' config device 'switch' option name 'switch' option type 'bridge' option macaddr 'bc:a5:11:9f:e1:23' config bridge-vlan 'lan_vlan' option device 'switch' option vlan '1' option ports 'lan1 lan2 lan3 lan4 lan5 lan6 lan7 lan8' config interface 'lan' option ifname 'switch.1' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' option ip6assign '60' config device 'lan_switch_1_dev' option name 'switch.1' option macaddr 'bc:a5:11:9f:e1:23'
Did whoever decided on this default configuration ever purchase a switch? Every switch I've ever bought has been configurable from any port! And most will pass traffic without any configuration. A switch isn't supposed to be a firewall!
got a decommissioned TP-Link T1600-28TS v3 which I could use for testing. Should be RTL8382M platform. Is there anything useful I can provide/do/test. Pcb pictures, uart/console log, GPIO mapping, devicetree file, ...?
Just tell me what would be a good starting point.
I don't know if your switch uses the Realtek CLI. If it does,
show tech-support board-info (IIRC) gives you an overview of the configured GPIOs. For most it doesn't say what they are used for, but at least you get an idea of what's configured as input, output, etc.
PCB pictures can also help with figuring out what auxiliary chips are on the board: RTL8231 ICs, shift registers, RAM and flash size, etc.
The T1600G-28TS has the CLI interface footprints on the mainboard but they are not populated.
- not sure
- Anpec Electronics Coroporation APW8720B
- Nanya Technology Corporation NT5CC128M16IP
- GigaDevice Semiconductor 25Q256CFIG
- Realtek RTL8214QF
- Realtek RTL8231
- Bothhand G4P109RN-A LF
I'm impressed they implemented two serial port options (RS-232 and micro/mini-USB).
Going by pictures of the front panel, that RTL8231 appears to be driving two LEDs per port and two system LEDs. Can you tell/measure how the strapping pins are configured? I would like to see an RTL8231 used in mixed LED/GPIO mode for once, but it's probably going to be shift register mode...
Is there any GPIO expander near the SFP cages? I wonder how the I2C lines of the modules are hooked up.
The SoC seems to be below the soldered heat spreader. Are you able to access the console? What does the boot log say, which SoC it is? I have seen the 8214QF only in combination with an 8390 so far.