White Rabbit Switch - Software issueshttps://ohwr.org/project/wr-switch-sw/issues2024-03-27T16:00:44Zhttps://ohwr.org/project/wr-switch-sw/issues/310Servo not resetted when desynchronized due to upstream problems2024-03-27T16:00:44ZMaciej LipinskiServo not resetted when desynchronized due to upstream problemsWhen upstream switch looses connection, the switch connected to it will go out of TRACK_PHASE and then eventually resynchronized... in such case the servo is not re-initialized (e.g. updated counter not set to zero)
to be investigated whether this is good, it seems this behvior changed between 6.0 and 6.1v7.1Adam WujekAdam Wujekhttps://ohwr.org/project/wr-switch-sw/issues/309Grandmaster ID and steps removed updated before slave in TRACK_PHASE2024-03-27T15:58:54ZMaciej LipinskiGrandmaster ID and steps removed updated before slave in TRACK_PHASEon BC, the propagated downstream value of grandmaster ID and stepsRemoved is updated (GM ID from BC's own ID to GM's ID) before the BC/WRS is in TRACK_PHASE on the slave port. As a consequence, the downstream devices have a false impression that the time is traceable and good before it is.v7.1Adam WujekAdam Wujekhttps://ohwr.org/project/wr-switch-sw/issues/307add possibility to advertise as PTP v2.0 in PTP messages2024-03-19T14:01:11ZAdam Wujekadd possibility to advertise as PTP v2.0 in PTP messagesSome PTP equipment does not work with WRS/WR node if it uses PTP v2.1 in the PTP header (which is BTW against the IEEE1588 standard). Make an option in dot-config, that make PPSi to advertise as PTP v2.0 in PTP messages.
https://ohwr.org/project/ppsi/issues/53v7.0https://ohwr.org/project/wr-switch-sw/issues/305Remove -F parameter from wrs_version2024-03-19T14:01:11ZAdam WujekRemove -F parameter from wrs_versionUse -f to get the FPGA type and use tool `wrs_status_led` to handle LEDs.
Remove from `wrs_version` the code to drive status LEDs.v7.0https://ohwr.org/project/wr-switch-sw/issues/304wrong behaviour of BMCA with redundant links (PASSIVE)2024-03-19T14:01:11ZAdam Wujekwrong behaviour of BMCA with redundant links (PASSIVE)When there are redundant links, in master WRS link shall be in master mode while it goes to passive.
Related to https://ohwr.org/project/ppsi/issues/52v7.0https://ohwr.org/project/wr-switch-sw/issues/303WRS v6.1 => Clk2 output feeds local oscillator in Grand Master mode2024-02-16T16:15:57ZPeter JansweijerWRS v6.1 => Clk2 output feeds local oscillator in Grand Master modeThis [issue](https://forums.ohwr.org/t/wr-switch-firmware-v6-1-release/849052/4) affects v6.1 only (v6.01 and v5.0.1 are fine). It is verified on a second switch WRS-3/18 which makes it unlikely that there is a hardware issue.https://ohwr.org/project/wr-switch-sw/issues/302Documentation: sagniac effect2024-03-06T22:31:44ZMaciej LipinskiDocumentation: sagniac effectmention sagniac effect and that it can be accounted for using the constantAsymmetry data setv7.0Maciej LipinskiMaciej Lipinskihttps://ohwr.org/project/wr-switch-sw/issues/301switch reboot/shotdown2024-02-08T10:41:29ZMaciej Lipinskiswitch reboot/shotdownit seems that after issuing the "reboot" command, the VLAN config might be cleared to create a moment of wrong configuration which can be dangerious.
Ensure that during the reboot/shotdow, now strange VLAN config is madev7.0Adam WujekAdam Wujekhttps://ohwr.org/project/wr-switch-sw/issues/300'ifconfig' shows incorrect number of bytes2023-12-20T10:50:20ZDietrich Beck'ifconfig' shows incorrect number of bytesOn some of our switches, 'ifconfig' yields an incorrect number of bytes. Example:
```
wrs#ifconfig wri1; sleep 10; ifconfig wri1
wri1 Link encap:Ethernet HWaddr 64:FB:81:2F:FE:F2
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1132857827 errors:0 dropped:74204937 overruns:0 frame:0
TX packets:34700825 errors:0 dropped:0 overruns:0 carrier:1
collisions:0 txqueuelen:1000
RX bytes:1319987352 (1.2 GiB) TX bytes:2581308252 (2.4 GiB)
wri1 Link encap:Ethernet HWaddr 64:FB:81:2F:FE:F2
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1132878970 errors:0 dropped:74204987 overruns:0 frame:0
TX packets:34700848 errors:0 dropped:0 overruns:0 carrier:1
collisions:0 txqueuelen:1000
RX bytes:1319991108 (1.2 GiB) TX bytes:2581309952 (2.4 GiB)
```
Within 10 seconds, there are 21143 RX packets. This number makes sense, as our 'Data Master' is sending Ethernet frames with timing messages at a rate slightly above 2 kHz. Plus some extra frames for PTP, LLDP ...
The frames size with timing message is typically 102 bytes (without interframe gap). Thus, one would expect around 2.1E6 RX bytes.
However, the number of RX bytes within the same time is only 3756 bytes (only about 0.2 bytes per packet) which does not make sense to me.
It seems that such a behavior only shows up at WRS that see higher traffic rates like shown in the above example.https://ohwr.org/project/wr-switch-sw/issues/299MAC aging2024-03-06T22:59:03ZEnkhbold OchirsurenMAC agingWR switches keep the learnt MAC addresses beyond the aging time (default is 300 seconds).
It was observed during the address caching capacity and learning rate tests of RFC 2889 benchmarking using the Xenabay traffic analyzer. If 'aging time' is chosen as address reset condition, then test is failed (even at the relative low frame rate of 20 frame/s). In this case, the RTU table keeps many dynamic entries, which have aging value of '0'. This behavior is observed in all software versions including v4.2, v5.0.1 v6.0 and v6.1.
Attempts to remove them manually with 'rtu_stat remove all <port> 1' also failed (trials done only on v6.1).
Example of 'rtu_stat' output (and this is special/rare case with duplicate entries) is given below:
```
MAC Dst.ports FID Type Age [s]
----------------------------------------------------------------------------------
...
02:f4:bc:00:05:00 2 0 DYNAMIC (hash 138:2) 359
02:f4:bc:00:05:00 2 0 DYNAMIC (hash 138:2) 0
02:f4:bc:00:05:01 2 0 DYNAMIC (hash 119:2) 359
02:f4:bc:00:05:01 2 0 DYNAMIC (hash 119:2) 0
02:f4:bc:00:05:02 2 0 DYNAMIC (hash 17a:2) 359
02:f4:bc:00:05:02 2 0 DYNAMIC (hash 17a:2) 0
```
As example of how MAC aging affects the RFC 2889 tests, the results of the address caching capacity test are attached (software = v6.1, frame size = 512 bytes, learning rate = 20 frame/s):
- xena2889-report-20231023-194401.pdf: test failed, "aging time = 350 seconds' is chosen for the address learning reset condition. Here, switch starts to forward test packets (100, 1074) properly, no flooding. At iteration with the critical number of packets (1561) it floods, and then it remains to flood in all further iterations with lowering number of the test packets (1317, 1195, ..., 1075, 1074). Test is failed, because the switch floods even with the same number of packets (1074), with which no flooding has happened in previous iteration.
- xena2889-report-20231023-195822.pdf: same test, but passed, "switching test ports" is chosen for the reset condition. In this setup, test runs as expected: switch forwards the test packets (100, 1074, #1561, 1317, 1439) properly in all iterations except those with critical/high number of packets (1561).
[xena2889-report-20231023-194401.pdf](/uploads/440043e33930c3d6d68b428543b9290e/xena2889-report-20231023-194401.pdf)
[xena2889-report-20231023-195822.pdf](/uploads/5b0638b1fbe175199eb5905bb5029e47/xena2889-report-20231023-195822.pdf)https://ohwr.org/project/wr-switch-sw/issues/298unable to establish link between two WRS2024-03-06T23:00:31ZAdam Wujekunable to establish link between two WRSUnable to establish link between two WRS:
* after 863 restarts (WRS v6.0.1)
* after 28
* after 381
* 5 errors out of 4153
Probably restart of HAL does help. Unplug/plug fiber/SFP does not help.https://ohwr.org/project/wr-switch-sw/issues/297Pll does not lock (with 60 seconds timeout)2024-01-31T22:56:57ZAdam WujekPll does not lock (with 60 seconds timeout)It can happen sometimes that the PLL does not lock. This issue will collect the restart statistics from different tests. The tests were done with 60 seconds timeout. If the timeout is set to 15seconds (default), In practice such timeout will not happen.
* 2 errors out of 863
* 2 errors out of 4153v7.0https://ohwr.org/project/wr-switch-sw/issues/296logMinDelayReqInterval is not updated with the value from the received relay_...2024-01-31T22:28:05ZAdam WujeklogMinDelayReqInterval is not updated with the value from the received relay_response framesee https://ohwr.org/project/ppsi/issues/49v7.0https://ohwr.org/project/wr-switch-sw/issues/295support configuration of multiple NTP servers in dot-config2023-09-20T10:18:50ZAdam Wujeksupport configuration of multiple NTP servers in dot-configSupport configuration of multiple NTP servers in dot-confighttps://ohwr.org/project/wr-switch-sw/issues/294in PPSI (HA) replace "Coherency" to "Coherent" in configuration options2024-01-31T22:28:08ZAdam Wujekin PPSI (HA) replace "Coherency" to "Coherent" in configuration optionsIt looks like IEEE1588-2019 is wrong, since in the Table I.1 "PTP attribute values for options" it mentions about:
* L1SyncBasicPortDS.txCoherencyIsRequired
* L1SyncBasicPortDS.rxCoherencyIsRequired
* L1SyncBasicPortDS.congruencyIsRequired
But such are not members of L1SyncBasicPortDS data set. They should be replaced with (Coherency -> Coherent and congruency -> congruent):
* L1SyncBasicPortDS.txCoherentIsRequired
* L1SyncBasicPortDS.rxCoherentIsRequired
* L1SyncBasicPortDS.congruentIsRequired
Related to https://ohwr.org/project/ppsi/issues/47v7.0https://ohwr.org/project/wr-switch-sw/issues/293wrsw_vlan does not show MAC addresses2023-09-01T23:12:30ZMaciej Lipinskiwrsw_vlan does not show MAC addressesThere seems to be bug introduced in v6.1. When using
`wrsw_vlans --plist`
the MAC addresses are not displayed
![image](/uploads/d74b17ccb2ed59cbd2d0c1600fbe6019/image.png)
This works well no WR switches with v6.0.1:
![image](/uploads/ec5ce209a4368cdb4710494d414dee31/image.png)v6.1.1Adam WujekAdam Wujekhttps://ohwr.org/project/wr-switch-sw/issues/291in menuconfig move CONFIG_READ_SFP_DIAG_ENABLE out of Developer options2024-03-19T14:01:11ZAdam Wujekin menuconfig move CONFIG_READ_SFP_DIAG_ENABLE out of Developer optionsReading SFP diagnostics is production ready, so move it out of Developer options.v7.0https://ohwr.org/project/wr-switch-sw/issues/289Introduce "stickiness" of errors/warnings in SNMP2024-01-31T22:28:48ZMaciej LipinskiIntroduce "stickiness" of errors/warnings in SNMPCurrently, if an error or warning occurs for a short time (some seconds), our monitoring tool (Grafana) will not notice. It is proposed to introduce a config parameter which would allow to prolong appearance of errors/warnings (possibly separate config for each level). This would be useful, for example, in the context of delock warning (#215) that now occurs only during one SNMP read after the delock cnt is increased.v7.0Adam WujekAdam Wujekhttps://ohwr.org/project/wr-switch-sw/issues/288delock on GM not reported in syslog2024-01-31T22:28:53ZMaciej Lipinskidelock on GM not reported in syslogIt seems that the delock event is not always captured in the syslog, see attached [syslog](/uploads/e1fec0e8948b1b074e6697a0784dbe74/syslog)v7.0Adam WujekAdam Wujekhttps://ohwr.org/project/wr-switch-sw/issues/287'wr_mon -e' for GM produces empty/blank outout2024-01-31T22:28:57ZMaciej Lipinski'wr_mon -e' for GM produces empty/blank outoutWhen 'wr_mon -e is executed on a WRS that is a GM, it produces empty lines. It should either
- provide info relevant for GM, or
- info that it gives no info for GMv7.0Adam WujekAdam Wujek