I think your lan_vlan bridge-vlan config should look like this:
config bridge-vlan 'lan_vlan'
option device 'switch'
option vlan '1'
list ports 'lan1:u*'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
list ports 'lan5'
list ports 'lan6'
list ports 'lan7'
list ports 'lan8'
list ports 'lan9'
list ports 'lan10'
list ports 'lan11'
list ports 'lan12'
Assuming lan1 is your uplink to your upstream device.
I thought that ports are automatically untagged when no :t is added. As mentioned this is/was all is in the default config.
I just added :u* to all ports and used list port instead of option ports, but DHCP still doesn't work on the client.
Also just tested with a static IP on the client. There I can ping the switch, but nothing else that is upstream (including the internet).
luci-app-lldpd is now merged into master so those running snapshot builds might want to look at this for a useful UI showing LLDP neighbours on each port and providing a quick way to configure which ports LLDP runs on.
There's some work happening to add extra features for telephony and other LLDP use cases but for now it's already very useful to check port usage on switches.
A bit late, but I have a JG925A available specifically for testing with openwrt. I'm looking into building with your patches.
I have just tried today's snapshot and I don't have the issue any more.
So I guess the router is in a broken state in stable right now, or something else in my network was bugging.
One other thing I noticed while upgrading and not keeping any config:
The switch went back to the default 192.168.1.1/24 address, while the client and upstream router stayed connected (subnet 192.168.40.0/24).
With the switch in OpenWrt factory config, the client could through the switch request an IP in the 192.168.40.0/24 subnet from the upstream router and it could ping the router. The switch could ping neither the upstream nor the downstream ip (which was expected).
Is this an okay behaviour? I just thought if this is due to the forward chain in lan being allow by default?
I noticed, that the following section is missing for vlan11 (D-Link DGS-1210-16):
config device
option name 'switch.1'
option macaddr 'xxx'
However even after manually adding it to the config and switching the lan network to switch.11, I am still stuck in a non reachable state. (neither the switch can ping the gateway nor any other device can ping the switch)
I had also updated to the latest snapshot.
edit: I have also tested the same with the XGS1250-12 (on a snapshot from around 2 weeks ago) and it also fails to be connectable when on vlan11
Is there maybe something general borked right now. As mentioned earlier, with 23.05.3 this works normally (at least for the D-link)
Alternatively, is there maybe a package missing, that is required to fully support different vlans, which is present on the stable release but not snapshot?
Power Consumption w/ 2 connected GbE Ports:
DGS-108: 0.5W
GS1900-8 v1: 3.8W (stock, no openwrt)
wow
The register values to enable LEDs on Netgear GS108Tv3 are the following:
echo 0x2f396a1b > /sys/kernel/debug/rtl838x/led/led_glb_ctrl
echo 0x3ef57dcd > /sys/kernel/debug/rtl838x/led/led_mode_ctrl
echo 0x00000004 > /sys/kernel/debug/rtl838x/led/led_mode_sel
echo 0x0000ff00 > /sys/kernel/debug/rtl838x/led/led_p_en_ctrl
Thanks - I took the liberty to add this information to the Wiki (and I also added the same paragraph with the correct values to the GS308T wiki page).
Hi, I'm trying to add support for XikeStor SKS8300-8X switch.
Specification:
Informations (lang: ja):
https://tomocha.net/diary/?202405a#202405061
Repository:
Currently, only initramfs image is tested and the work is stucking due to the kernel freezing issue while initialization of SerDes.
Using initramfs image:
interrupt booting and open bootmenu with Ctrl + B
press Ctrl + F and login to the vendor-specific CLI with diagshell_unipoe_env
login to the U-Boot CLI by debug_unish_env command
activate a SFP+ port by the following commands:
rtk 10g <port> fiber1g (set to 1Gbps fiber mode)rtk ext-devInit 0 (initialize RTL8231 (GPIO))rtk ext-pinSet <pin> 0 (deassert TX-Disable (HIGH -> LOW))example (SFP+ port "1"):
rtk 10g 0 fiber1grtk ext-devInit 0rtk ext-pinSet 2 0download initramfs image by tftpboot
bootm
Will the HPE 1920-48G work now that the 1920-24G is listed?
No. You can, however, apply @janh's patches and build it yourself - I've done that and my switch is running fine ever since.
Thanks, is the full 32MB available on the 1920 or is it split into A and B partitions?
I just saw this branch is quite old now, have you looked at applying the patchset onto the recent 23.05.x?
I've got the switch off eBay, I'll try to rebase those 1920-48G commits onto 23.05.3 and see if it works.
You're confusing things. The git repo mentioned is forked from main, which is the development tree. You can backport the patches to 23.05, which is older.
Is there any update in plan for 1920-48G JG927A ?
Quite similar to JG923A and JG924A , but could not find Openwrt firmware for it in downloads
Unless you intend to do so: no. You can take @janh's patches, port them to current master and submit them.
It utilizies both partitions, but that's not the full 32MB - it's in the range of 30MB (0x1cf0000), including kernel and rootfs. Mine shows 23MB of free space after a fairly default install.
No. My snapshot works fine, I do not have the need to update at the moment.
Your suggestion to close the thread dedicated to the model (not the chipset), will likely further deprioritize development of the firmware for a decent switch model (HP 1920-45G JG927A) with supported hardware, but still without even a snapshot version of Openwrt firmware. Most applicable models in this thread have at least a snapshot version of the firmware.
No, I suggested to merge the threads. You posted the same question twice to different threads, and this overly complicates things.
And I told you: you can move things forward yourself by porting and testing the patches and creating a PR.