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.
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.
While the current implementation works for what it is actually used, it
is broken when trying to do larger transfers.
The length field in the control register has a size of 4 bits. In every
transfer, length+1 bytes are read. Thus, each transfer is limited to a
maximum of 16 bytes. Add a check for the length, and write the correct
value to the register.
Also update the loop in "sfp_send_data" to properly increment the output
register. Remove the unused special case for a length of 128 bytes.
When device has no LOS pin and module has no extended status, the
RX LOS value will not be shown. When both are present, the equality
check is performed. When only one is present, the present value
will be shown.
json from the switch, will still contain the field, but can be
null for when pin is not available.
The state of the SFP module is being already send in status.json,
but was not parsed via Web UI. When debuging SFP LOS/Signal detection
it is usefull to see what module is reporting back.
Extended the SFP mouse-over information with:
- RX LOS as reported in 0x02 bit of register 238
- External TX Disabled from 0x80 bit of register 238
- TX fault from 0x04 of the same register
- The last state of RX LOS pin (available also when there is no 0x40
option on the module)
This should help identify missing/incorrect setup of TX disabled pin.
I noticed that entering some vlan config, clicking "Update/Create", then
clicking "Get Configuration" resulted in Tagged/Untagged/PVID displaying
completely wrong data. It looks like the parisng in fetchVLAN() in
vlan.js was just completely disconnected from the layout of the
registers read by vlan_get() in rtl837x_port.c. Who knows how that
happened.
1. Fix fetchVLAN() member/untag parsing: the old code read bits [9:0]
as untagged and bits [10:19] as tagged, but the VLAN table register
layout is members in [9:0] and untag in [19:10]. Now correctly
derives tagged (member && !untag) and untagged (member && untag).
2. Add PVID to vlan.json response: PVID is stored per-port in separate
PVID registers (RTL837x_PVID_BASE_REG), not in the VLAN table entry.
The old code nonsensically tried to read it from bits [20:29] of the
VLAN table. Add port_pvid_get() and build a pvid bitmask in
send_vlan() so the JS can parse it correctly.
3. Remove auto-PVID logic from setC(): setC() is called by fetchVLAN()
while it's loading existing config, and so this logic mangled the
display of the existing config. Also, it doesn't make sense to
auto-set the PVID for tagged members (PVID relates to untagged
ingress.)
We use the SoC's UUID to generate a fixed MAC for a particular
switch device. The MAC generated uses a Realtek prefix and then
is followed by 3 bytes genertaed from the first 3 bytes of the
UUID xored with the last byte in order to prevent being able
to deduce the UUID from the public MAC.
logicog
René van Dorst
logicog
UAb5eSMn
orbisai0security
feelfree69
feelfree69
Jan Hoffmann
diijkstra
Mark H. Spatz
chriz
TylerDurden-23