*) improved SwOS web interface accessibility;
- replaced <a> elements with <button>;
- increased spacing between checkboxes;
- added meaningful descriptions (aria-label) for checkboxes;
- fixed button order when navigating using Tab key;
- made all elements accessible using keyboard;
- improved readability using screen reader software;
What’s new in v2.19:
*) css610pi: updated PoE firmware;
*) css610pi: added LLDP power management support;
*) fixed incorrect forwarding of reserved multicast;
*) fixed FDB flush on link down;
*) gpen21/ftc21: improved SFP compatibility with other devices;
*) removed horizontal scrollbar in GUI;
Feature Request:
Fix Syntax errors in host table
Add switch port numbers above or below the switch port check boxes for vlan assignments.
Cable test function
The issue might depend on Hosts table size, and not occur on small networks. It’s 100% reproducible for me on a live network with a few hundreds of devices, tested with different web browsers (Firefox, Chromium, Safari). I have contacted MT support #[SUP-161444] and they reproduced it too, a few months ago. And really, I dream about a similar device but RouterOS based with CRS3xx-like features (netpower 16P was close, if only PoE-out ports could be used as PoE-in as well - which is doable by adding a diode per port, long time ago I did this myself adding reverse-PoE to OmniTikUPA).
I suppose the idea is if you need reverse PoE you use netPower 15FR (CRS318-1Fi-15Fr-2S-OUT) that is much cheaper, and if you need PoE out you should use netPower 16P with PSU capable of providing enough power for all your PoE devices…
Netpower 15FR unfortunately has only 100Mbps copper ports (including the single PoE-out port, serious bottleneck if used for 60GHz radio uplink). Possible workaround: take power from the 100Mb PoE-out port and data from S-RJ01 copper SFP module, combine them in external gigabit PoE injector. I have done this once, but it’s ugly. And it’s still max 90Mbps real speed for each customer, too little to compete against FTTH. Netpower 16P with small hardware mod would be much better. OK if it only works at 48V PoE-in due to power constraints (too high current in the wires at 24V).
Hello, that’s me again. Guess what… in 2.20 still seeing syntax errors in Hosts table. Same in Chromium/Edge/Firefox. But there is something new - “NOTE: first 128 of all hosts are displayed” - it’s the first time I see this sometimes appear in addition to syntax errors. Also, it’s different on Safari (iPhone, iOS 16.7.11) - 2.18 had syntax errors too, while 2.20 shows the note about first 128 hosts and I haven’t seen syntax errors yet. Yes, web GUI programming is hard, and you really need to test many different browsers/platforms.
Could someone please open the browser’s developer tools while on Host table and check the Network tab to see what responses you get for “!dhost.b”
Alternatively, you can run the following curl command (make sure to replace the password and IP address with your own):
# on linux
curl --digest -u admin:password $'http://192.168.88.1/\u0021dhost.b'
# on windows
curl --digest -u admin:password http://192.168.88.1/!dhost.b
It seems !dhost.b is incomplete (truncated at some point before the closing bracket, the same point even if reloaded a few times) on some client OS but not others. Web browsers on a Win10 desktop and old MacBook (macOS High Sierra) have the issue, so does curl on that old macOS. However, web browser on iPhone (older one but not too old - 8 Plus with latest updates which means iOS 16.7.11) and curl on Linux have no problem.The same machines (both Win10 desktop and old MacBook) can open many other web pages just fine (I use both regularly), just not the Hosts tab in SwOS Lite. I’m on a trip and don’t have a Linux machine with me right now, when I’m back at home in about a week I can try a Linux desktop (Debian on RPi 400). It seems it could be some kind of TCP/IP stack incompatibility triggered when connecting from Win10 or old macOS (don’t both share similar BSD-derived network stack?) but not Linux or iOS (more modern network stacks) to SwOS Lite.
EDIT - I’ve just looked with Wireshark and it looks really weird. Lots of TCP retransmissions, seems each packet is blindly sent by SwOS Lite twice (to compensate for packet loss even if there is none?), and in the last two packets (with otherwise same headers, sequence number etc.) the data differs. First one is full of data and not terminated as if there was more to expect, second one has the same data at the beginning but terminated with closing bracket and padded with spaces to the same length. As if there was some kind of race condition, data being sent from a shared buffer while it is also being updated, so it changes (including table size!) between retransmissions. Re-inventing TCP (“simple algorithm”) may not be as simple as it seems, I’ve heard of no other embedded devices except MT doing this, they generally do it properly with a default route etc.
Are the devices really so low on resources they couldn’t have a proper (minimal but reasonably RFC compliant) TCP/IP stack? If that is the case, it may make sense to replace the web GUI with external utility (possibly part of Winbox) that manages the device with SNMP (simpler UDP based protocol). At least for already existing hardware that can’t dual-boot RouterOS - in other cases better simply use RouterOS.