I also recently checked out different 10G SFP+ switches and found several $100ish on AliExpress, which could be a nice device. Most are re-branded and basically the same thing. On my short-list was:
At the end I got a Mikrotik though, as OpenWRT support is not available yet and the existing WebGUI seemed a bit lacking, as I heard about a few shortcomings (seems to be firmware related, e.g. you can't seem to mix 2.5G and 10G SFP+)
I too got a 2nd hand Mikrotik (crs305-1g-4s+in) until 10Gb devices are in better shape but I'd still like to look at OpenWRT options. Their web UI is giving me flashbacks to Win95 and Netscape Navigator, whilst the terminal UI is another one of those "we want our own identity so our CLI is totally different to everyone else" projects. But it works.
I guess I am waiting to see if there is a solid design in the 10s of different 10G switches that flooded the market from Hasivo, Horaco etc in recent months.
It would be nice to be able to replace the management interface with OpenWrt at some point, if feasible. I don't expect them to release anymore updates and the firmware definitely has some quirks, although it has been stable.
I currently use the Hasivo one I mentioned in my post for both a 2.5 Gb link with PoE+ to my AP and also both the SFP+ ports for 10 Gb (one with a DAC to my router and one with a fiber transceiver connecting to my desktop). In other words, I guess my answer to your question would be "both".
I think the ones I mentioned should cover most of what's available using the RTL93xx that are also fairly affordable.
@kusmi There is no standard for 2.5 Gb SFP+ as far as I'm aware. There are transceivers that can rate limit down to that speed (normally using pause frames), but 2.5 and 5 Gb are both solely BASE-T speeds since copper cables are where adding them made any sense. I think there are also devices that can somewhat handle it natively, but it shouldn't be expected for SFP+ in general.
Is there any support for cable diagnostics for switches in OpenWRT? RTL838x in particular. Or does that chipset not support cable diags (I didn't check my GS1900-24e before reflashig...)?
@dorozyoka did you ever manage to flash the F3 revision? And did it work?
Seems there are indeed different firmware versions between the F and F3 revisions:
D-Links firmware distribution seems kind of a mess, but when looking at their presumable AU department the firmwares are interchangeable? And I found some release notes.
I tried to update the firmware over the WebUI, but as the wiki mentions it is probably expecting an encrypted firmware:
The OEM firmware does have this feature, accessible from the webinterface for e.g. D-Link, only from the management shell for ZyXEL. The diagnostics are rather crude, though.
OpenWrt does not have this feature so far, it's probably possible, but someone has to do the necessary kernel level development (and much more).
GS1900-24# show cable-diag interfaces all
Port | Speed | Local pair | Pair length | Pair status
--------+--------+------------+-------------+---------------
1 | auto | Pair A | 18.00 | Normal
Pair B | 18.00 | Normal
Pair C | 18.00 | Normal
Pair D | 18.00 | Normal
2 | auto | Pair A | 0.82 | Open
Pair B | 0.82 | Open
Pair C | 0.78 | Open
Pair D | 0.77 | Open
[…]
6 | auto | Pair A | 8.00 | Normal
Pair B | 8.00 | Normal
Pair C | 8.00 | Normal
Pair D | 8.00 | Normal
[…]
(no, I cannot say anything about the distance units (https://github.com/sre/rust-gs1900/blob/master/src/lib.rs would suggest cm, but that doesn't correspond to the measurements at all, feet would be more realistic, but who would use that) there, but port 1 would really be 5m, port 2 unconnected and port 6 under 1m).
Thanks for showing the OEM firmware stuff. Even just knowing the connected/open/short status for each pair is often very useful. Sigh, maybe one day...
Looks like we have the RTCT register for maple? (I guess it has built in rtl8218 right?)
RTL8306 says RTCT can also do cable length. (Same with rtl8366?, rtl8370 is no ) So maybe even as per above rtl8218 or other phy's can do it too? It's not mentioned in rtl8218/rtl8380 datasheet?
Found an API for rtl8367 on github haha. Will need to do more looking when I have time. But IMO given a proper portable ethernet TDR is like <100AUD. Or just having another switch in the rack purely for TDR purposes it's not a priority. But another cool thing to look into.
I'm thinking that the rtl8218 is on the mdio bus so worst case one can hook up a cheap logic analyser to the pins and do some sniffing on a factory firmware?
edit: what's called RTCT on R8169 just says high impedance detection. So this may not be as generic as one would like in terms of what realtek has under the same name.
edit2:
gs1900-24 I looked on wiki and it's also RTL8218B PHY's? So that gives some good confirmation. I'll have to check as all my (Openwrt capable) switches are H3C/3com/HPE things and will have to have a look at what they have in terms of cable diagnostics.
edit3:
If anyone can find me a phy which actually has a public datasheet regarding cable diagnostics that would be great. 88E1545 public datasheet conveniently doesn't document page 7 in the mdio register map hahaha =P edit4: Microsemi phy's (which is also microchip =P) appear to have register documentation.
/* Function Name:
* rtk_diag_rtctEnable_set
* Description:
* Start Realtek Cable Tester for ports.
* Input:
* unit - unit id
* pPortmask - the ports for RTCT test
* Output:
* None
* Return:
* RT_ERR_OK
* RT_ERR_FAILED
* RT_ERR_UNIT_ID - invalid unit id
* RT_ERR_NOT_INIT - The module is not initial
* RT_ERR_NULL_POINTER - input parameter may be null pointer
* Applicable:
* 8328, 8389, 8390, 8380
* Note:
* When RTCT starts, the port won't transmit and receive normal traffic.
*/
/* Function Name:
* rtk_diag_portRtctResult_get
* Description:
* Get test result of Realtek Cable Tester.
* Input:
* unit - unit id
* port - the port for retriving RTCT test result
* Output:
* pRtctResult - RTCT result
* Return:
* RT_ERR_OK
* RT_ERR_FAILED
* RT_ERR_UNIT_ID - invalid unit id
* RT_ERR_NOT_INIT - The module is not initial
* RT_ERR_PORT_ID - invalid port id
* RT_ERR_PHY_RTCT_NOT_FINISH - RTCT not finish. Need to wait a while.
* RT_ERR_TIMEOUT - RTCT test timeout in this port.
* RT_ERR_NULL_POINTER - input parameter may be null pointer
* Applicable:
* 8328, 8389, 8390, 8380
* Note:
* (1) If linkType is PORT_SPEED_1000M, test result will be stored in ge_result.
* If linkType is PORT_SPEED_10M or PORT_SPEED_100M, test result will be stored in fe_result.
* (2) The unit of cable lenght is meter.
*/
Awesome thanks for the reminder! I completely forgot about that.
edit: ooh just saw that there was an sx220 tarball. Now I want to have another look at SG220 support haha.
edit2:
So it's in phy_8218b.c under sdk/src/hal/phy/. I'm having a read.
Cool so basically the one i'm reading (from the sx220 source drop) if link is up go get the length from the EEE register.
Else go by channel and do more probing to get cable length by RTCT?
Then you check the status bits to see if it's short, open, mismatch short, mismatch open and then line driver (which I assume means line driver status but IDK?)
But yeah I guess someone who wants to play around with the mdio registers could get it working. I was reading that phytool or mdio-tools would be the way to start?
edit2:
Ok so ethtool looks like it has cable test support? Or there were patches at some point? I'm still reading.
@Timeless Yes, I flashed OpenWRT version 23.05.4 in mid September on the DGS 1210 10MP F3. I used the TFTP method, as described in the wiki (which needed soldering a UART header before).
A few days later, I successfully upgraded to OpenWRT version 23.05.5 through the web interface.
I tested the SFP ports, which work with the cages from 10Gtek (I use the 1 GBit RJ-45 Transceiver modules).
However, PoE does not work. The daemon logs following message:
daemon.warn realtek-poe: Invalid port status packet (port=97)
To be honest, I didn't made further research to that PoE topic, because I didn't need it currently. I figured that I need to configure something, but didn't felt educated enough to stick into it. So thanks for pointing out, that the PoE controller of the DGS-1210-10MP F3 isn't supported currently.