SODOLA Managed Switch Web UI Issue - Home Network
What happened
Up to Date Server Network Configuration
Due to a power outage from the Power-Outage Incident, my SODOLA switch web interface hasn't been accessible. I first had this issue while setting up the switch, and then it randomly started working on its default IP 192.168.2.1. Ever since I moved into my home, my network switch continued to route traffic but I couldn't access the web interface. Typically a quick reboot would fix this, but after I set the local IP to 192.168.1.241 I lost access again.
Root cause
- A power outage (multiple outages in a short time) at the machine location site.
- My switch config wasn't saved, so it was factory-reset on power loss.
- The network switch boots in isolation mode by default, preventing ports from communicating with each other.
All details on solution are under the Solution Test
Power-Outage Details
The fix
When setting up switches, isolate network and client ports and use the same IP range as the switch's default. For full detail read this
Prevention
- Implement the
UPSplanned in my Power Redundancy Plan - Save the switch configuration after setup so the assigned static IP persists across power loss.
Tests/Debugging
Ultimately I need to invest in a better managed switch. I already nearly filled all eight ports on this switch, and it's giving me too many early issues. I need to migrate to a more stable switch.
Forcing static IP and accessing web locally
I thought forcing a static IP would fix this. I assumed the switch was factory-reset by the sudden power loss or that my router detected it as a new device and gave it a new IP.
Critical Discovery #1
Before I did this I checked my Spectrum router's UI (the Spectrum website) to find the device IP. It showed a MAC address but no assigned IP.
This wasn't the first time. When I first got the switch I had the same problem. After about half an hour of troubleshooting the switch UI randomly opened on 192.168.2.1. I don't know exactly what I changed then, so I assumed it would not recur, but it happened again within 24 hours.
Critical Discovery #2
After that, I researched solutions online. Everyone suggested disconnecting the switch from the router and connecting it directly to a client to access the web UI.
I tried several things:
- Removing the connection between the router and the switch
- Removing the WAN connection from my laptop to the router
- Directly connecting the switch to my laptop
- Disconnecting all other devices from the router except my laptop
- Changing the laptop IP from dynamic to static and trying many addresses such as
192.168.1.239and192.168.2.1, then attempting to access the web UI - Using the factory-reset pin and trying to access the web UI at the default IP (the one that worked days earlier)
Results
Still no connection to the UI. The router continued to route traffic for all my nodes, so network connectivity for clients remained.
After all these tests I've decided to plan for a new router and a new switch in the future. I knew managing my own server would be more work, and spending hours debugging a web UI isn't worth it when I need to replace this switch anyway.
Testing after some time
My switch has been connected post-factory-reset for a while, so I tried manually connecting again to see if the Spectrum router would assign it an IP. I'm hoping for luck and will try more forum research, but overall I'm unhappy with this managed switch.
Results
After some time I physically connected to the switch and tried to access the web UI again with no success. I don't know the next step yet, but I will continue debugging.
Misc/Reattempted Tests
Critical Discovery #3
After more physical tests I learned a few things. Connected through my switch were three links:
- Node 1
PROXMOXNode - Router connection
- Physical connection to my client (MacBook)
When I tested my previous methods, I noticed that with Wi‑Fi off on my laptop I could access the internet because the router was connected through the switch, so Ethernet was passing traffic. However, when I tried to access my PROXMOX node (also passed through the switch), it wouldn't connect.
I enabled Wi‑Fi on my MacBook to test whether my PROXMOX node was reachable. With Wi‑Fi enabled I gained full access to my PROXMOX node over the network.
Hypothesis
I don't fully understand what this means yet, but it points toward the root of the router issues. My working theory is the switch is passing traffic from Node 1 to the Spectrum router but not outputting traffic from the switch itself. It's a rough explanation, but it could explain why I can't access Node 1 physically but can access it through the router and the WAN when the router is connected to the switch.
Research
Isolation Mode
After researching, I learned budget managed switches like my SODOLA boot with a default setting called VLAN Mode or Isolation Mode. This setting prevents client ports from talking to each other; the only allowed communication is via an uplink. That fits my hypothesis and explains the behavior. It also confirms this feature is useful when isolating a sandbox network from a main network.
Layer 2 Communication
Earlier I noted that the Spectrum router showed only MAC addresses and no IPs for some devices. That's because devices directly plugged into a switch communicate on layer 2 using MAC addresses, which explains the missing IP information on the Spectrum router.
Critical Discovery #4
IP Assigning
This was a rookie mistake. While isolating my laptop from all other connections, I edited my IPV4.
I had assumed I was changing the switch's IP, but I was actually changing my laptop's IP on the switch. That makes sense: I mistakenly thought the MacBook interface was changing the device's IP on the switch.
I had been assigning my laptop the IP 192.168.2.1, which is the switch's default IP, causing an IP conflict on the two-device network. My next step was to factory-reset the switch again and assign my MacBook an IP inside 192.168.2.X (I'll use .10 to be safe) and test.
Results
Success
My theory was correct: the issue was my misunderstanding of TCP/IP addressing. This test resolves the case.