A bare "vlan N" line never matches conf_cmds (a VLAN entry always carries
a member port or the mgmt/name keyword), so it is never stored. The
c !== "vlan N" comparison could therefore never match an entry; the
startsWith(prefix) check alone covers all stored vlan lines.
The firmware has a single management VLAN (one management_vlan variable),
so a stored config should never carry more than one "vlan N mgmt" line.
When parsing a mgmt command, drop any previously stored mgmt entry so
repeatedly changing the management VLAN no longer accumulates stale lines.
parseConf() only recognized "port N name" in conf_cmds, so "port N <speed>"
lines were treated as unknown commands and dropped on save - configured port
speeds never persisted.
Add the speed command (incl. optional half/full duplex suffix) to conf_cmds,
add a "port N" entry to conf_overwrite so re-saving a speed replaces the
previous value, and guard the per-port name entry so changing a port's speed
no longer wipes its configured name.
The ZX310S-4T2XT is a managed device with 2x2.5GBit and 2x10GBit Ethernet.
It is sold, among others, by Horaco as an unbranded device.
CPU: RTL8372
Flash: 2MByte Winbond W25Q16DV (U3)
PHY 2x RTL8261BE
The vlan/mgmt lookahead split (commit dcc60c3) correctly separated the
patterns so that `vlan N mgmt` and `vlan N <members>` match different
conf_overwrite entries. But the filter that applies the overwrite still
used `item.startsWith(matchStr + " ")` with matchStr = "vlan N", which
also matches "vlan N mgmt" — so the management entry was removed whenever
the VLAN's membership definition was re-saved.
Example: with both `vlan 44 management 2t 4t 5 6t` and `vlan 44 mgmt`
in the config, changing the membership dropped `vlan 44 mgmt` entirely.
Added a `!item.endsWith(" mgmt")` guard so management entries survive the
filter. No reordering is needed: `vlan N mgmt` only sets the global
management_vlan variable (cmd_parser.c) and does not depend on the VLAN
table entry existing, so its position in the config is irrelevant.
While testing #246, I noticd that SFP did not light-up while forcing
2.5gbit link. This is because RJ45 and SFP share the same LED-settings.
But RJ45 has two leds-settings.
Solution is to add settings for SFP for both managed and unmanaged
variant.
A commonly used SFP+ form-factor XGS-PON ONT (WAS-110) reports 0x63 at
power on and then switches to 0x64 after booting up.
0x63 -> 9.9gbps
0x64 -> 10gbps
These are outside of the previous 0x66-0x69 range which prevented the
link from ever being brought up.
I recently brought a "Ztyuav Z-QWYT0402", the insides looked identical to the
existing supported "Hisource Hi-K0402WS". Both of them have the
"PCB-K0402-V3.0" silkscreen.
I flashed the vanilla image and it seems to work great.
I changed the documentation to be more inclusive of other devices (including
adding a picture of mine). I suspect more devices might fall into this
"PCB-K0402-V3.0" bucket, for example the "YuanLey YS25-0402" with
the vlan switch also looks suspiciously identical from the outside.
I also added some details I noticed while flashing mine:
teardown, flash padding, how the selector switch actually works.
- itoa16_html: add comment that the function is sufficient for VLAN
IDs (<=4094); generalization not needed.
- send_vlanlist: replace post-write bounds check with a pre-write
guard using worst-case entry size (138 bytes + 1 for closing
bracket). Old comment claimed ~45 bytes per entry, which only
held for short names. With a 117-char name (the actual bound from
CMD_BUF_SIZE) entries can reach 138 bytes, and the post-check
would not have prevented an overflow.
- Document the 0x02 check in sfr_data[0] as the VLAN table entry
valid flag.
feelfree69
HL Yi
René van Dorst
Lynn-Becky
Erdnusschokolade
logicog
logicog
bennydiamond
TylerDurden-23
feelfree69
Taiga Ogawa
kekopop
Matt Merhar
Alexandru M Stan