Are my smart bulbs broken ?

E_B

Hello all …

I recently bought three LocalBytes Tasmota smart bulbs which all worked perfectly. I also flashed a Sonoff RF bridge with Tasmota, which worked perfectly, all on the same 192.168.1.0/24 network.

A couple of days ago I mapped my network using nmap (amongst other tools) and I ended up with a full “map”. I experimented further with more aggressive nmap and with other tools and somehow it knocked the 3 smart bulbs and the Sonoff bridge off my network such that they were no longer visible on the LAN.

Each bulb is generating its own WLAN AP which I can log onto with a tablet just like I did to configure them back in April when they arrived, but when I open the web page at 192.168.4.1 I am told

“the web page at http://192.168.4.1 could not be loaded because net:: ERR_EMPTY_RESPONSE”

In each case I can ping them from my tablet at 192.168.4.1 and I can see via a port scan that the only port, port 80, is open. Switching the bulbs on/off 6 times hasn’t seemed to reset them.

The fact that the Sonoff RF bridge (which I flashed with Tasmota myself) has also vanished from my WLAN which immediately suggests there is a problem affecting Tasmota but nothing to do with hardware or firmware failures.

I re-flashed the Sonoff bridge - easy to try - and that fixed the problem for the bridge!

What should I do to resurrect the bulbs, do you think? In other words, before I undertake the difficult task of dismantling and trying to re-flash the bulbs, does anyone know if I can somehow “brute force” my way in?

archie

Hi EB,

That is unexpected. Did you run any scripts with your nmap scans? A simple port scan shouldn’t have caused lasting damage - certainly not anything a reboot wouldn’t fix. Although, a number of the built in nmap scripts are considered “not safe”, and they may well have caused damage.

For reference, I have run a number of port scans over my ESPHome plugs and bulbs and have never had an issue.

E_B

I didn’t run any scripts; the most “aggressive” I got was along the lines of $ nmap -sS -sV -F -T4 -p- so I am not sure why it’s gone wrong. I’ve had some good advice via email this morning from LocalBytes’ Rebecca which I’ll also try (power down the router, power down the three bulbs, switch the router on, wait half an hour and switch the bulbs on) …just in case there’s a corrupted arp cache I suppose. I’m waiting for an opportunity to try just that but I expect I will end up having to desolder them and get to the programming pins which are unpopulated test pads on the back of the ESP8285 PCB:

archie

Hi,

Thanks for your response. I would first like to point out that the LB devices are not designed to be user-repairable. It is your device, and you can do with it what you like, but please don’t mess with electronics unless you know what you’re doing.

With that out of the way, I would point out that the -sV flag in nmap will cause nmap to run version enumeration scripts.

My gut tells me one of these probably resulted in a request to tasmota’s reset endpoints, as happened here: https://github.com/arendst/Tasmota/issues/6709

E_B

That’s a useful URL - thanks.It’s clear that nmap caused the problem we suspected.

I have been experimenting (to no avail, as yet) with a variety of GET and POST commands which appear to work in some cases (Restart%201) but not others (Status). The bulb clearly isn’t entirely dead, just badly injured!