I’ve made a few mentions about VLANs in the recent past as it’s something that I find quite useful along with virtual APs with managing an ever-increasingly-complex home network. But as some more “basic” edge equipment may not be able to tag/untag packets to participate in VLANs, while others can’t really be trusted to maintain a fixed VLAN tag setting and avoid VLAN hopping , it actually makes sense to enforce the VLAN tagging as a function of the network infrastructure instead of configuring it at the edge.
Traditionally, this would be quite an expensive proposition, as smart-switches were traditionally the realm of business networking with choices mostly from big-name vendors costing several hundred dollars at the least. One could always jury-rig their own from a Linux box with a few NICs or an old router supported by DD-WRT/OpenWRT/etc or invest in some rather cost-efficient Mikrotik gear but this is still somewhat overkill.
Luckily, this under-served market segment has seen several vendors enter – providing “smart” switches which aren’t much more expensive than traditional “dumb” switches while offering some of the capabilities that much more expensive models do.
In this article, I will look at the TP-Link TL-SG105E 5-Port Gigabit “Easy Smart” Switch which I managed to obtain on discount for AU$39.20 including postage. While on the outside, it shares a visual similarity with the metal-cased TL-SG105 “regular” switch, this one also offers a number of additional capabilities of which VLAN operation is one of them.
Unboxing
Unlike the cheaper plastic switches which I reviewed earlier, the Easy Smart switch seems to have an air of “premium” about it with a foiled-colour outer cardboard wrap, proclaiming a 3-year warranty which is pretty standard.
The front of the box shows the product clearly along with some of its features in icon form. Interestingly, the top right corner has a logo indicating “Business Solution”, which also suggests that this is a more “sophisticated” product.
The rear provides a blurb about the capabilities of the unit – again, with switches, it’s almost like reading the back of a shampoo bottle.
The underside has the system requirements, which seems to suggest the configuration utility only runs under Windows, but the switch can be administered through the web interface which should work on almost anything. The particular unit I have is a “Ver 3.0” unit with part number 1731500017.
The sides give more information about features, and makes it clear that the box includes the switch, a power adapter, installation guide and resource CD.
Under the cardboard outer wrap, is a plain inner flip-open cardboard box. Under the flap is the mini-CD of resources, installation guide and switch in a protective plastic bag.
For Australia, it seems a separate warranty statement is also included. The switch also has a bag of self-adhesive rubber feet included, so “some assembly is necessary”.
The included switchmode power supply is rated 9V 0.6A, as is common with most of TP-Link’s products. Unlike some of their older products, the rear of the casing does not have the brand moulded into it.
The design of the switch is so that all the Ethernet cables cone in fron the front, with link speed and activity lights integrated into each jack. A power LED is provided on the right side as well.
The rear of the unit has the barrel jack for power supply, a slot for a Kensington lock and a reset button.
The other sides are not used, except for some ventilation holes.
The underside has a label with some product information and the unique serial number/MAC of the unit. Note the outlines for the self-adhesive rubber feet which have not yet been fitted. Slots for wall-mounting screws are also provided.
Teardown
The unit has two screws holding the top lid in place. Getting in is as simple as unscrewing these and sliding the cover off.
A look at the shell shows that there are some ID numbers internally, along with protection around the wall-mounting slots to prevent screws from shorting out the PCB internally.
The main PCB looks as follows – dated Week 50 of 2017, the design features very few components. A console header (J2) can be seen near the switch chip which is a square leaded-type under a heatsink. A 25Mhz clock crystal feeds this IC, along with a 25Q16CSIG (16Mbit/2MiB) flash memory. The port magnetics are Group-Tek HST-2027DAR units dated Week 1 of 2018. The firmware was dumped, but because of the presence of unique MAC addresses, will not be made available. The majority of the data is identical to the firmware update blobs issued by TP-Link, however, the data alignment is different.
The underside has no components, only solder points for through-hole components with silkscreen over solder-mask to reduce risks of solder bridges.
Judging from the input, the only electrolytic capacitor is a “bulk” capacitor for compensating for power supply cable lengths and ensuring a local reserve of power for step changes in operational mode. As a result, it’s not likely that this capacitor will fail as it will be relatively un-stressed. It is a Samxon 470uF 25V capacitor, which feeds into a downstream switching converter that has MLCC capacitors, providing the supply for the switch chip.
Configuration and Firmware
Rather interestingly, the unit comes pre-configured with a static IP address rather than DHCP – this is quite likely to conflict with some home routers (192.168.0.1). As a result, it probably helps to run a separate direct connection to the switch at first for configuration, with a static IPv4 address.
Web Interface
When you first start, you are greeted by a login screen. Secure, right? Well, kind of …
The main screen is the System screen. This shows the basic information about the switch – you can set a name for your switch on this screen as well. The left hand panel forms the navigation between the various features available. Of note is the Save Config button on the left – while any changes on the pages can be applied and the switch will respect them, the configuration is only in RAM and is lost on a reboot until you also click on the Save Config button in the sidebar. I only realised this after getting frustrated that power-cycling a configured switch caused all the configuration to be lost – I didn’t click that button after finishing my config!
The system menu also allows you to configure the IP settings.
User Accounts allows you to change the password and username for the administrator.
The system tools sub-section allows the possibility of backing up and restoring the configuration …
… rebooting or resetting the whole system.
The first feature under Switching is Port Setting, which allows you to manually configure speed, duplex and flow control. Surprisingly, while the chip supports Flow Control, it is disabled by default.
The next feature is IGMP Snooping which allows for multicast traffic to be filtered and sent only to ports that request membership, avoiding needless “flooding” of data. This can be disabled if necessary.
The final feature in this section is LAG – no, that’s not a latency thing. It is short for “Link Aggregation Group”, basically a statically configured link teaming system. Unfortunately, on a five-port switch, there’s no real reason to use LAG, as you can only have two link-aggregated pairs and an odd-port-out.
Under the Monitoring category, the first page is port statistics which shows the status of the ports. Rather interestingly, it is noted in the manual that jumbo frames are counted as both bad and good packets – so don’t be alarmed if you see bad packets, it could just be a jumbo frame or a “fully laden” VLAN tagged frame.
Port mirroring allows you to “copy” the traffic to and from one port onto another for network diagnosis or capture. This can be rather useful in case of wanting to monitor a network without needing to run a “bridge” on a computer which can affect the performance of a network more adversely.
Cable testing allows you to detect faults and distances to faults – many modern NICs have this capability but being able to run testing remotely is a plus.
The switch seems to have its own loop prevention system – this seems to be distinct from STP, which can be enabled if desired. I tend to keep it disabled, as I’m careful with the way my network is wired up and would rather not risk potential traffic drops under heavy loads.
The main star is the VLAN capabilities, which are somewhat confusingly labelled. The first type is MTU VLAN – and that’s got nothing to do with Maximum Transmission Unit. I believe MTU in this case is “Multi Tenant Unit”, in any case, this seems to “isolate” traffic from each port from directly talking to each other. All traffic is funneled up the uplink port for an upstream router to decide which traffic should pass between these downstream ports (if any).
Port-based VLAN is more like creating several “virtual” switches on one switch – say grouping ports 1 and 2 together and 3-4-5 into another group where both groups are isolated but still plugged into the same physical unit. This is more useful if you have more ports (i.e. a larger switch) as this applies only to the one switch rather than doing a “tagged” VLAN which can define networking topologies that extend beyond a single switch.
If you’re into VLANs, then 802.11q VLAN is the type you’re after – you can define VLAN IDs and whether ports are members of these VLAN IDs in a tagged or untagged way. However, just beware that only 32 unique VLAN IDs are supported simultaneously.
This is to be used in conjunction with the 802.1Q PVID Setting Page (which looks similar, I didn’t take a screenshot of) which sets which tags are applied by the switch to packets incoming from the ports.
The QoS menu allows for basic port-based QoS which probably affects the queueing behaviour of the switch. This can be done based on the port priority or by packet priority tags.
A more powerful option is the ability to limit by bandwidth. This can act as a safety valve to prevent a single malfunctioning device from saturating the network bandwidth.
Storm control options are also provided which limit rate but only for certain types of broadcast/multicast frames.
Firmware Update
While the screenshots were made on the older firmware, I updated to the latest firmware as soon as I started to seriously use the unit. To do this, we need to access the firmware update menu which actually causes the unit to reboot into a firmware upgrade mode.
Once rebooted, then it is possible to select the upgrade file to be loaded.
Once the upgrade is started, then the file is sent to the switch.
From there, the image is written to the onboard flash.
The device is then rebooted.
The page attempts to refresh, but fails to as the restart process may take just a bit longer than the page expects. However, that is not a cause for concern – just give it a little longer and it will be back.
Simple Smart Utility
For those who don’t want to use the web interface or can’t find the switch on the network, it is possible to use the Simple Smart Utility (or its older brother, the Unmanaged Pro Utility) to discover and configure the switch through UDP network broadcast packets.
The IP Setting dialogue allows you to configure the connectivity and username/password.
Once logged in, the configuration appears slightly different but offers much the same functionality as that available via the web interface.
Security? Um … Hold My Beer.
Unfortunately, the security of this unit seems to be problematic. After setting up the unit, the first thing I noticed was that login credentials were sent in plain-text over unsecured HTTP over the network with no attempt to obfuscate the data or hash it:
Logins seem to be done based on IP-address (rather than sessions, cookies, etc) – anyone who has the same IP address from the switch’s point of view will be logged in as soon as one person is logged in. This was made apparent to me as I logged in from one browser on the PC and became magically logged in on another browser in my VM which is NAT-ed behind the same IP.
Then, I discovered that while passwords have a length limit enforced by the HTML, if you craft an equivalent request using cURL, it is possible to cause a “denial of service” by issuing an over-length login request regardless of the data which cause the switch to reboot – as long as username and logon fields exist.
curl -d "username=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxx&logon=Login" -X POST http://192.168.0.1/logon.cgi
The minimal requirement I found was the above which would cause it to reboot consistently.
The crash can be confirmed when the switch replies with the <script> portion of the HTML followed by a hang. The switch becomes unavailable for almost 30 seconds as it reboots and reconfigures. If you only configured the switch but did not click “Save Configuration”, doing this will reset your switch to factory defaults. I made this mistake initially, incorrectly believing this would reset to factory defaults allowing VLAN escape – this is not the case, it merely loses any “volatile” configuration that was not saved through using the Save Configuration option in the sidebar.
Things do get worse from here – now that we know how a switch can be DoS’ed, the next part is finding the switch itself. Because of the existence of “Simple Smart Utility” which features a routine to detect the presence of switches on the network, it was found that the switch will reveal its existence even if the broadcast is for a different VLAN or subnet and reveal its own IP address.
This may not directly allow access to the switch, but knowing that the SSU issues requests on port 29808/29809 (tq/tp) to 255.255.255.255 gives a good hint as to passively detect the presence of switches being administered. If we combine this with the knowledge that the administration is happening through broadcasts with static key encryption – it is possible that the login may be captured and reused later to take over a switch as broadcast traffic is disseminated throughout the whole broadcast layer 2 domain.
This is rather regrettable, as the “standard” workarounds (e.g. setting an isolated VLAN, setting a static IP in a different subnet) won’t stop the switch from being discovered and attacked.
The Solution?
I tried contacting TP-Link through their security disclosure system but received absolutely no reply after two-and-a-half months, with no new firmware released. However, it seems an unlikely mitigation was found through my experimentation.
By exploiting the login overflow bug, I found that making the login a little longer stopped the switch from rebooting but instead would hard-crash the 8051, causing the unit to stop responding to web interface requests or broadcast discovery requests. The switch continues to pass data retaining the configuration it had prior to the crash.
curl -d "username=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx&logon=Login" -X POST http://192.168.0.1/log on.cgi
By crashing the remote administration abilities, it becomes impossible to remotely reconfigure the unit without power cycling, however, it protects the unit against such attacks. Not an ideal result, but better than leaving a few glaring holes open on the network. Lets face it – how often are you going to need to reconfigure the VLANs on the switch, given that doing so requires it to reboot and breaks connectivity for a short period?
Note that increasing the length of the request beyond a certain level actually is handled correctly by the switch and does not result in crashing its internal CPU – so hence it’s a “range” of lengths causing reboots, a “range” of lengths causing crashes and a “range” of lengths handled correctly with no side effects.
Conclusion
In truth, it seems that the switch chips employed even in basic “dumb” switches are relatively capable of performing some of the features normally reserved for smart-switches. It is through exploiting these features, which are normally “fixed” in configuration by the inbuilt EEPROM, that low-cost semi-smart switches are realised.
The TP-Link TL-SG105E uses the onboard 8051 of the Realtek RTL8367 switch chip to allow configuration of these features through a web-interface and a broadcast-based tool, allowing users to access features such as VLANs, rate limiting, QoS, IGMP Snooping and port mirroring at “budget” price not much more than that of a regular “dumb” switch. The best part is that the functionality generally works as expected, although the documentation is poor and the interface does present some confusing information at times.
However, it seems that the limitation of this approach lie in the limited onboard processing and storage capabilities of the switch chip, which results in a clunky firmware that has very strange security issues in its design including the use of fixed-key encryption as determined by another security researcher, broadcast-based messaging that allows anyone on the network or any VLAN to detect the presence of the switch, plain-text passwords over the network when logging in, the ability for crafted requests to cause it to spontaneously reboot denying service temporarily to downstream users or even lock up the remote management access permanently.
While I have contacted them about this, they have not responded nor issued any new firmware within the two-and-a-half month period since I notified them through their website’s security disclosure contact form. This is an unfortunate situation, but not unexpected given their response to the disclosure made by another security researcher.
Because of the peculiarities of the switch and its behaviour, I’d have to say that it is hard to give a clean recommendation – the unit can perform the tasks it claims to do, but it can also be the target of denial of service which would interrupt users connected downstream of the switch on a semi-continuous basis. However, I found that by crashing the remote management also meant the switch became immune from network-side attack but loses the ability to be remotely administered until power cycled. So it can be used safely and the attack window can be reduced provided the remote administration ability is “crashed” as soon as practical after the switch comes online, but this loses the ability for convenient re-configuration of the network without power cycling of the switch. As a result, I don’t think I’ll be buying any more of these myself.
A note on flow control, and why you shouldn’t be surprised it’s disabled by default:
The primary purpose of flow control is to support high throughput applications, such as iSCSI, using protocols that are highly loss sensitive. Both sides of a link have to be configured, and to be effective it must be enabled on every link along the path. This is why flow control is usually disabled by default.
Flow control disables other buffer queuing schemes, so if you’re using QoS, then you can’t use flow control. Flow control can also cause head of line blocking across ports and queues, so it’s not useful in most general purpose IP networks.
Here’s how flow control works; when the priority 0 buffer is full, the switch sends a pause frame to the transmitter on the other side of the link, causin the TX switch to block all higher priority traffic until the receiving switch says its ok to resume. If the TX switch isn’t doesn’t have flow control enabled, the receiver’s buffers, which are full, will be overrun and drop packets. Similarly, a single downlink port on a switch that is congested can cause all uplink traffic being sent to that switch to be blocked.
Draft IEEE 802.1Qau specification for congestion notification is adding support for per-priority pause to mitigate the head-of-line blocking for QoS across priority queues.
So the best practice is, unless you really know what you’re doing, don’t use flow control.
Thanks for your in-depth explanation. Indeed, I was aware of how flow control worked, however, not as much in regards to its side-effects.
It’s interesting to see that many dumb-switches seem to advertise support for it, which makes me suspect that the defaulted EEPROM configuration on them enables the logic for flow control (i.e. the switch will intercept packets to the reserved multicast address to pause/resume transmission). I suppose this causes no harm if the connected peers do not have it enabled/do not emit pause frames.
So to see it defaulted to disabled may indeed be a sensible choice in the case of a “business” class device that it claims to be – in the pursuit of maximising performance. I suppose if devices are of different speeds, at least in the half-duplex case, backpressure through artificial collisions could still be used. In the case of full duplex, I suspect the receiving NIC would probably just drop the packet instead, relying on higher level protocols to compensate through retransmissions. I suppose with the increase in computing power we have today, this is a rarer and rarer situation – although I do note that the reverse case of compensating with large packet buffer queues is also not a solution due to bufferbloat affecting latencies/round trip times and perhaps even compounding the situation through not dropping packets or marking with ECN when it really should be.
– Gough
Gough,
In reality, Ethernet flow control is hardly used anymore. It has so few applications, and breaks TCP/IP flow control, so it’s best abandoned. Here’s a useful still-relevant write-up:
http://virtualthreads.blogspot.com/2006/02/beware-ethernet-flow-control.html
I always found this practice of having default IP addresses enabled and in such commonly used subnets laughable until I had a Netgear NAS on a business network that would default to 192.168.0.1 during boot, probably due to the bootloader, and conflict with the firewall. Can tell you I not laughing much then. Also, wouldn’t trust these lower end devices to keep their sh*t together after you change and save the new IP address. Seen some lose it due to power spikes and even randomly – am looking at you, D-Link dgs-1100-08.
While I understand the consequences of DoS’ing the switch, I don’t think it’s much of a concern for their intended audience, I mean, the reboot DoS can be of concern, but it’s trivially detectable with a sniffer if the attacker insists on taking it down again after reboot.
I see this switch intended to SOHOffices where the switch price matters and people are looking to ease upon network expenses. Kind of a middle-aged brother. Sadly enough I have plenty of such penny-wise clients.
Bought one of these to make my home lan fully 802.11Q compatible and setup a public wifi network for my neighbors alongside my private/home LAN, I’d be much more concerned were there RCE exploits (akin to Cisco’s RV320) than the lack of https support since we will not be connecting onto it after the first day when we set it up very frequently. (i.e. never)
the first curl command does not reboot the switch with v4.0 firmware!
the other still works.
I bought this switch to make a router from a PC which has only one NIC.
This is my first managed switch so I bought it before I discovered that its web-GUI always accessible on each port and each VLAN.
After I discovered that I can’t disable admin GUI on uplink I began to search on the internet for additional info.
I was worried about security, I am not accustomed to expose web-gui to the internet at all, much less web-gui that was built two years ago.
My router has version V5 and it does not reboot after the first curl command but web-gui stops working if your second curl command is applied.
I’m afraid that insistent hacker can find vulnerabilities in web-server itself and force it to execute some commands without proper credentials.
Than he could change vlan-ids and get access to my LAN.
I should have bought some used gigabit router, flash it with OpenWRT and use it as a switch. It would be much secure.
Now I’m considering to cover this device’s uplink with transparent firewall made from 100M OpenWRT router…
Big thanks for the article!
Isn’t your switch behind your router/firewall anyway?
He probably wanted to do a “router on a stick” configuration. In such a case both the WAN, LAN, and router are connected to the same switch. The switch passes internet traffic to the router’s single interface, the router does it’s routing magic and tags it with a VLAN, the switch then routes the tagged packet into the LAN.
The benefit is that you can have a router with a single NIC serving multiple VLANs. The drawback is that you are now sharing bandwith through this one single NIC.
Mind to share what kind of processor you found?
Latest firmware for the TL-SG108PE V2 20211021 prevents crashing the remote management interface but still sends login credentials in plain-text over unsecured HTTP. Don’t know if interface is still accessable on all vlans.