Review, Teardown: Alcatroz Airmouse Duo2 Wireless Mouse

Being increasingly reliant on mobile devices to get some level of work done, I had a sudden need for another Bluetooth-capable mouse. While the Logitech M337 continues to serve me well with its rather unusual colour scheme, I was looking for something perhaps a bit more affordable – it just seems rather silly that after all these years, a Bluetooth mouse is still something that is sold for $37 or even more!

While the common solution for this was to just “go to eBay” and order from overseas, the addition of GST on low value items has dampened the appeal somewhat, along with a tide of sellers who claim to have shipped items that never turn up. Add to that the uncertainty of quality and description accuracy – it’s a reason why I’ve really curtailed my eBay spend. This led me to discovering that one of my local retailers stocks a Bluetooth-capable mouse for just $10, the Alcatroz Airmouse Duo2, so I decided to grab one to see whether it was any good.


Alcatroz is not a brand that is commonly heard of in Australia and it seems only one of my local stores carries its products. It’s always on the cheaper end of the market, which is often where a lot of less pleasant items tend to live, but I wasn’t quite going to condemn it before I had given it a go. It seems that this company is part of Leapfrog distribution which is a Singaporean company which is responsible for several other brands (such as Armageddon, SonicGear and Audiobox).

The Airmouse Duo2 comes in a blue box with hang-tab. It is available in black and white colour, and claims to have 2.4Ghz Wireless (with matching “nano” USB receiver) and Bluetooth 4.0 dual-support. It uses 2xAAA batteries which come included (a nice touch) with a claimed 100 hour usage battery life. The unit is capable of 1200dpi, is Made in China and is backed by a 2-year warranty.

Inside the box is a multilingual instruction leaflet, the mouse inside some protective foam bag and a pair of alkaline AAA batteries.

The mouse itself has a rather familiar shape, although is a little flatter than some others I have used. The lower plastic is matte in finish, whereas the top section is gloss.

The mouse is branded with some grey printing on the top. The scroll wheel itself has a wide rubber surface, and like the buttons, is also slightly stiff, refusing to “coast”.

The underside has the relevant model information and QC labels, but also is where the battery compartment and USB receiver are.

The design of the battery compartment is somewhat poor, with the two batteries sitting staggered with no release-aids.

The supplied nano receiver is rather anonymous looking and like most miniature USB devices, has a small PCB hiding within the connector shell.

Once connected, the device appears with a VID of 248A and PID of 8367. This suggests the device might be manufactured by Maxxter, although this is no smoking gun.


Curious to find out what powers the unit, I decided to take it apart almost immediately. To do this, two rubber feet need to be removed revealing two small Philips head screws that need to be removed. Afterwards, the case halves separate.

Et Voila! That’s one wireless mouse. Rather surprisingly, the battery leads are connected by a connector to the main PCB – many manufacturers save a few cents by omitting this as most units would never be repaired if they failed.

Taking a closer look at the PCB, we see the silkscreen marking of FJP-B+2.4G-WK6 FTM10 V1.1 dated 18th October 2017, making this a rather recent product. It seems that the PCB was configured so that you could have a DPI button as well as back/forward buttons, but these were not fitted. The wireless antenna is a PCB trace that is on the left-side of the PCB nearest the index finger when holding the mouse. Two different types of switches seem to be used – Huano (white) for the left and right click button and ZDN (? green) for the scroll-click.

Surprisingly, or rather not, the whole operation of the mouse falls down to one integrated SoC from Telink – the TLSR8261 which seems to be optimised for smart remote control applications. The IC is clocked from a 12Mhz crystal.

The underside is pretty much bare, except for the through-hole solder joints which is rather expected. Still, not bad for $10.

User Opinion

On the whole, a mouse is fairly easy to set up and use with this one being no exception. Putting the batteries in the mouse, it sprang to life practically immediately with the USB receiver being plug and play. However, if you want to use Bluetooth, you need to hold down both mouse buttons until a green LED comes on, and then release.

This activates the Bluetooth mode, allowing it to be found or connected to via Bluetooth Low Energy. This can be seen with the resulting scan from a BLE analyser application.

Because it is a BLE device, it cannot be connected to older Bluetooth Classic (i.e. 3.0 or earlier) devices, requiring Bluetooth 4.0 “Smart” or Low-Energy capabilities at a minimum. This is catered for in most modern devices made in the past few years, otherwise you can revert to using the USB receiver.

The mouse can be toggled between operation in 2.4Ghz mode or Bluetooth Low Energy mode by repeating the “hold-both-mouse-buttons” routine, allowing for controlling two devices from the one mouse. However, the routine can get tiring as it is not as convenient as pressing a single button.

I found the body of the mouse to be a bit short, the plastic to be rather “hard edged” and the stiffness of the switches to make it less comfortable than the Logitech mouse. But it was still a lot better than being without a mouse and acceptable for the price. The 1200dpi resolution is fairly normal, and is sufficient for most office/productivity scenarios on smaller/single screens (e.g. a laptop).

The lack of a power switch was somewhat disappointing. While the mouse does have some aggressive energy saving strategies, it is easily accidentally awoken in transit by a click or scroll which wastes energy and also does not avoid waste from quiescent standby consumption.


For $10, this mouse is a lot cheaper than any other retail Bluetooth-capable mouse option. The build quality feels downright average with a basic 1D scroll-wheel configuration with no additional buttons. The click switches and scroll wheel feel slightly stiff and the DPI is relatively pedestrian, but the unit is functional and quite usable. Ergonomically, it is a little “flat” for my liking, although as a “travel” mouse, this is not a bad compromise. The biggest annoyances for me are the lack of a power switch for conserving battery life and the slightly lengthy mode-change routine of holding down both mouse buttons until an LED lights up.

The biggest downside is that the mouse is (as it says on the box) a Bluetooth Low-Energy device, meaning that it cannot connect to older Bluetooth chipsets that only have Bluetooth Classic capabilities (e.g. 3.0 and earlier). You must have Bluetooth 4.0 with Low Energy capabilities (i.e. Bluetooth Smart) to be able to connect, although most recent smartphones, tablets and laptops will have this. For those that don’t, the dual-mode functionality allows you to use the USB receiver to work with the mouse as well. In fact, you can even use it between two devices, toggling the mouse mode between USB receiver and Bluetooth to swap between computers.

In all, as long as one is aware of the limitation, the mouse is actually fantastic value for money and a big saving compared to the branded alternatives. Sure, the Logitech M337 I have before is a Bluetooth Classic device which ensures wider compatibility and has an extra left/right scroll ability with nicer feeling buttons and shape, but I don’t think it’s quite worth the extra dough. As a result, it seems the Alcatroz Airmouse Duo2 is actually a pretty decent choice for those wanting a wireless mouse on the cheap.

Posted in Computing, Tablet | Tagged , , , , , , , , , | Leave a comment

Project: Words vs Numbers “Art” with an Arduino & HD44780 LCD

I’m definitely no artist – I don’t normally go on “artistic” endeavours, but I try to do practical things as any engineer would. But it’s been a while since I’ve had the time or inclination to build something … and things rarely ever go to plan. After a little building of something else, I somehow ended up building something just for the sake of it. Call it “art”.

The Inspiration Frustration Process

It was an afternoon, I had pulled out an Arduino Leonardo and an LCD Keypad Shield. I wanted to build something Wi-Fi connected, so I grabbed an ESP8266 Wi-Fi Shield as well and thought I’d be on my way. Even if the AT-command set mode wasn’t great, I was only looking to build something simple.

Getting a little ahead of myself, I had no stackable pin headers, so I decided to stuff the Wi-Fi Shield behind the LCD Keypad Shield and just solder it to the slightly-long headers it already had. That went just fine and so I tried snapping it onto the Leonardo – aside from a slight port-clearance issue, it sat “well enough”.

This was when I ran into trouble. The shield acted dead – give it all the AT+RST‘s you want, this thing was not talking no matter what baud. It wasn’t a software vs hardware UART selection switch issue either – the module just didn’t work.

But now I had a problem on my hands – getting the unit out was a nightmare.

Desperate not to “bin” the whole lot and just start fresh, I tried to desolder the shield with very little success – so many plated through-holes wicked solder to inaccessible regions where no wick or bulb could reach. The board was so big it was not practical to hot-air the whole assembly, so I resorted to snipping pins as short as possible and trying to lever the bits apart.

After tearing a few (useless) pads off the board and still resorting to a heat-gun, I managed to separate the two but not without some casualties – the LCD had taken a good dose of heat resulting in some noticeable discolouration, so I don’t know if that was still good or not.

Going into salvage mode, I was still convinced the ESP8266 Wi-Fi Shield would be of use, so I decided to try programming it directly using the ESP8266 Arduino Core and an FTDI cable. I could get a response – I could program the chip to blink an LED, but absolutely anything Wi-Fi related was not working at all. I checked the WiFi Mode was being set correctly, and even tried scripts to disable and re-enable it to no avail. My AP was also telling me that it never even saw a connection attempt.

By now, I was really majorly frustrated, so I decided to try recovering the shield as it had nice level shifters and voltage regulators on it – I loaded a Wi-Fi scan program onto it and it said no network. Suspecting something happened to the antenna connection, I checked for continuity – there was no issue. I suspected a crack in the ceramic capacitor connected to the antenna – desoldered it and shorted it out to no avail.

Now I suspected a bad ESP8266 – so I got the hot air gun out and desoldered the IC and reworked another ESP8266 from another board on. With the fine pitch and complex pad pattern, it was a big stretch but worth a try. Still no dice.

Now suspecting either an EEPROM data problem or a crystal oscillator out of tolerance, I moved both from the other “donor” module to the shield. I thought this would be a sure win – but no. Only blinks, no Wi-Fi.

By now, I was fed up. It was only a few dollars … I was prepared to let it go. Weekend project postponed until later … when the parts arrive.

But What About the LCD?

I still had a really beaten up LCD shield module that had been through many ordeals and seemed to be bin material. But then, I thought I might as well give it a go – by desoldering as much of the broken pins out and replacing just the pins necessary, I decided to give it a shot.

In order to do this, I had to write a program to write some data to the screen. I could have stuck with “Hello World”, but where’s the fun in that? It wouldn’t test the character generator much …

So I decided to embark on a project to fill the LCD with random characters as quickly as possible and continually do this.

The LCD was still alive, but with a slight bright spot on the top row. That’s quite amazing. But then, I thought it would be nice to make something less “random and confusing” – why not make something aesthetically eye-catching.

The New “Art” Project

Keeping myself occupied for the afternoon, I decided that I would take the random-character-sketch and instead do something a little less random and a little more artistic. That’s when I came up with the idea of illustrating “Words vs Numbers” on an LCD. As I had an old Arduino Mega 2560 that had a bunch of blown I/O pins due to an accident with some scrap wire and an even larger 20×4 LCD that was doing absolutely nothing for the past six years, I decided it would be nice to just cobble it together for some fun.

The new project would:

  • Put numbers in random positions on the display on a regular basis, rather than doing random characters sequentially as my LCD test did. This would create a sparkling that would look like “noise” on a background of numbers that might be somewhat reminiscent of The Matrix.
  • Write random words to random positions on the display on a regular basis. This would be taken from a list of common English words – fitting as many in as possible to increase variety.
  • Be fleeting but still readable – illustrating a battle between the two by having the random numbers “erode” the words over time, whereas words would spring up suddenly at intervals. This is sort of entropic in a way, showing the words “decaying” into the field of numbers.
  • Be powered via USB, which is no trouble for Arduinos.

All in all, nothing hard, but at least something I could get my hands on.

The Result

With some white coloured hook-up wire (as that was what I had left), a half-damaged Arduino Mega 2560 clone board, a 10kohm precision trimpot, an old LCD display and a lot of hot glue … we have this monstrosity.

What does it do? Simply, this …

An abridged version of the code is as follows:

#include <LiquidCrystal.h>

#define INT_CHAR_DEL 45
#define CHARSET_HIGH 57
#define CHARSET_LOW 48
#define ROWS 2
#define COLS 16
#define INJECTINT 24

LiquidCrystal lcd(8,9,4,5,6,7);
const char string_0[] PROGMEM = "a";
const char string_1[] PROGMEM = "abandon";
const char* const string_table[] PROGMEM = {string_0, string_1};
char buf[17];
int cyclecount=0;

void setup() {
  lcd.begin(COLS, ROWS);

void loop() {
  if (cyclecount>INJECTINT) {
    strcpy_P(buf, (char*)pgm_read_word(&(string_table[random(0,2350)])));
    for(cyclecount=0;cyclecount<strlen(buf);cyclecount++) {

This code was kept as simple as possible and was something I ended up writing within half an hour. The idea is to use LiquidCrystal library for parallel LCD interfacing, using random() to generate the necessary random values seeded by an analogRead() value from an unconnected pin. The loop sets the cursor to a random position within the LCD and writes a random character within the range (defined as numbers) to that position. It delays a fixed amount of time, and counts every loop. After a fixed number of loops, we turn on the “blink” feature so the block cursor shows (to make the word printing more obvious) and pull a random string from the string table in PROGMEM. This is written to a random position on the screen character by character (ensuring it fits into the screen), followed by a five-times-length delay to give the eye some time to identify and read the word before it is “destroyed” by further random writes. The blink feature is turned off when returning back into the random number writing loop.

Due to the difference in memory, the number of words that can be accommodated depends on the microcontroller in question and how it accesses memory. In the case of 32kB microcontrollers (e.g. 32U4, 328P), the amount of space is somewhere around 28kB-30kB depending on which particular microcontroller is used. The Leonardo, for example, has less because some of this space is necessary for the bootloader’s USB emulation. As a result, I made a “smaller” version with 2350 words from EF Australia that just fits into those.

For larger microcontrollers, such as the ATMEGA1280/256o used in the Mega boards, they have 128/256kB of memory minus some for the bootloader. Unfortunately, there is a problem with using all of this memory as pointers are 16-bit in the Arduino code, resulting in a hard 64kB limit in pointers. Exceeding this results in code that doesn’t execute properly through to assembler errors. The solution for this is to apparently use far-pointers, which don’t seem nicely supported, so I’ve capped the number of words to 6500 words instead from Google’s corpus to fit within this space limit.

The full code for both an Arduino Leonardo (or other 32kB microcontrollers) and Arduino Mega 1280/2560 (or 64kB+ microcontrollers) can be downloaded:

Porting to other microcontrollers might allow for even more words to be accommodated due to the difference in capacity and way memory accesses are handled.


It’s not something really amazing or perhaps even unique, but more a result of a lot of frustration. Borne out of some code I wrote to just test an LCD which I had tortured, I decided to extend it with the help of a few online corpuses to print random words over a sea of random numbers. But now that I’ve built it, I do like it – it seems rather visually interesting at times to just pick a word out from the “sea” of numbers before it disappears.

Posted in Electronics | Tagged , , , | 1 Comment

Not So Smart: TP-Link TL-SG105E V3.0 5-Port Gigabit Easy Smart Switch

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.


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.


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 ( 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
xxxxxxxxxxx&logon=Login" -X POST

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 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
xxxxxxxxxxxxxxxxxxxxx&logon=Login" -X POST

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.


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.

Posted in Computing, Telecommunications | Tagged , , , , , , , , | 4 Comments