1. While loop scanning VLAN name terminated only on ' ', not '\0'.
When the name is the last token in cmd_buffer, the loop reads past
the buffer into adjacent XRAM.
2. Entering 'vlan' without arguments causes parse_vlan() to read
cmd_words_b[1] which points to undefined memory, causing atoi_short()
to interpret residual bytes from previous commands as a VLAN ID.
Bug found and fix proposed by logicog during review of PR #232.
Co-Authored-By: logicog <logicog@users.noreply.github.com>
Adds CLI reference for the previously undocumented vlan <id> mgmt
command, including the disable case (vlan 0 mgmt), default state,
and a lockout warning.
Fixes#235
Previously, renaming a VLAN or deleting and recreating it with a
different name did not update the displayed name. The vlan_names[]
array is an append-only buffer where vlan_name() returns the first
matching entry, so stale entries kept winning.
This commit adds vlan_name_remove(), which locates an entry by
VLAN ID and removes it via array compaction. The function is called
in two places:
- parse_vlan() in cmd_parser.c, before appending a new name entry,
to remove any pre-existing entry for the same VLAN ID
- vlan_delete() in rtl837x_port.c, to clean up the name when a
VLAN is removed
The implementation reuses the existing vlan_name() lookup, scans for
the trailing space of the matched entry, then shifts remaining bytes
left. Locals are declared as static __xdata to avoid the SDCC
overlay segment limit on banked functions.
Tested on KeepLiNK KP-9000-6XH-X:
- vlan 99 AAA p1u; vlan 99 BBB -> name updated to BBB
- vlan 99 d; vlan 99 CCC p1u -> name correctly CCC, not stale AAA
Note: This fix addresses the runtime XMEM state. Persistence of
renamed VLAN names across reboot requires the user to download and
re-upload /config, as is the existing pattern for all configuration
changes in this firmware.
When checking for a new root, a root_bridge with the same priority as STP_I will never be adopted as cmpMAC always returns 0.
This PR fixes this bug by changing the comparison of MACs to what was intended
With content_type = "application/x-www-form-urlencoded", "+" means space.
This case was not handled.
Also refactor the code to make a loop to process the hex digits.
- machine.c/h: add MACHINE_FNS1200P with verified GPIO assignments for
both SFP ports, LED SET0 (amber 2.5G / green 1G-100M-10M) and SET1
(SFP all-speeds), led_mux from original firmware register dump, and
machine_custom_init() enabling LED_GLB_IO_EN bit 6
- doc/devices/FNS-1200P.md: device overview, port layout, serial
console (S1 three through-holes = UART0 115200 8N1 3.3V),
LED and SFP GPIO tables
- doc/devices/photos/FNS-1200P/: chassis front panel and PCB top photos
- doc/supported_devices.md: add FNS-1200P to the list
GPIO assignments and LED register values were cross-checked between
live GPIO observation (RTLPlayground gpio command) and an original
firmware register dump.
* Revise compiling section and add cautionary notes
Updated compiling instructions and added warnings about flashing procedures.
* Refactor caution messages in README.md
Updated caution messages to use new formatting for emphasis.
* Revise caution and reminder notes in README
Updated caution and reminder sections for clarity and consistency.
* Fix typos in README regarding firmware update
Corrected typo errors in the README.
* Add image for advanced settings
Add advanced_seetings.png
* Add advanced settings configuration details to README
Added advanced settings section with configuration instructions.
* Fix image source in README for advanced settings
Corrected the image source filename for advanced settings.
* Revise IP and port command descriptions in README
Updated command descriptions in README for clarity.
* Revise README.md for clarity and updated instructions
Updated sections in README.md for clarity and accuracy, including compiling requirements, installation instructions, and cautionary notes.
* Revise README for clarity and emphasis
Updated formatting and emphasized important notes in the README.
* Correct image file name and compilation output in README
Updated README to reflect changes in image file names and compilation output.
Chrome sends upload requests using POST with multipart/form-data
content type in multiple packets for the header part of the form-data.
Introduce a TSTATE_MULTIPART for the httpd server states that denotes
that so far only a part of the multipart header has been transmitted.
Once the full header has been transmitted, we change to TSTATE_POST
as for Firefox which sends all the multipart header in one piece.
The main further change required then is to make sure that the parsing
of the initial part of the multipart request is only parsed once and initially
to distinguish between configuration and firmware uploads.