After creating and clearing VLAN groups, the switch no longer functions properly; even as an unmanaged switch. Port 3 and port 4 LEDs are constantly solid, regardless of a connection through the ports.
Hello,
Could you expand on what VLAN groups you created? I.e. list the commands you used.
Do you have any packet captures on devices on the ports you can also send?
You mention port 3/4 activity and link LEDs are set on (and I presume not blinking). What colour did they change to?
Thanks,
Aaron
Here are the commands we used:
- vlan add port 1 vid 1
- vlan add port 2 vid 1
- vlan add port 3 vid 2
- vlan add port 4 vid 2
and then after creating the ports, we cleared them:
- vlan clear
We can’t seem to get traffic for packet captures on any of the ports. The third port is solid red and the fourth port is solid green.
Apologies if I was unclear but I mean packet captures on both the requesting and replying devices on two ports within the same VLAN group (i.e. ports 1/2 or 3/4) rather than just on the receiving device. For example, you can conduct an ICMP ping test between two devices (one on port 1 and the other one port 2) and use a program like Wireshark to capture packets. Sharing them here will give more insight.
Are you using VLAN-aware network interfaces on the host devices connected to the switch? Because the way you’ve set up the VLAN groups is essentially each port as a single VLAN trunk port, which will require packets to embed a VLAN tag in the frame otherwise it will be dropped on ingress by default. Without knowing the specifics of your host devices’ distros I can’t explain how to do that but here’s an example on ArchLinux distro if that helps.
Regarding the LED activity/link lights, I’ll need to attempt to replicate that on my test device. Do you have more information regarding the PHY settings of the devices you are connecting to the switch (i.e. 10/100/1000mbps, full/half duplex, auto-negotiation advertisement, etc)?
The ICMP ping test was unsuccessful between all four ports. Is there a way to fully reset the switch?
For the PHY settings, nothing was changed in the CLI. For both port 3 and port 4, the devices should be using auto-negotiation.
In this case, you can do vlan clear and then perform a power cycle to reset the board. Note the docs listing what vlan clear does.
Is the issue you’re having that when you perform vlan clear along with a power reset, the board is bricked and can’t even operate as a managed switch?
Are you still able to access the CLI prompt after power cycling? If so, what does vlan show output after boot up?
Did you get a chance to look at the VLAN interfaces documentation? I suggested packet captures because they would allow you to confirm whether the VLAN tag was present in the packet.
Regarding the activity/link LEDs, I expect them to be the same color and show the same behavior if the link partners auto-negotiate to the same speed. What you are seeing appears to be different. Please give me a few days to set that up and test it in my lab to see if I can replicate the same result.
On another note, you look like you want to set up access VLAN ports here but are setting up single VLAN trunk ports. If you need an access port for untagged traffic, you will need to edit the commands to
vlan add port 1 vid 1 pvid untagged
vlan add port 2 vid 1 pvid untagged
vlan add port 3 vid 2 pvid untagged
vlan add port 4 vid 2 pvid untagged
Note the documentation has quick snippets for this you can use for reference when creating access or trunk ports.
1 Like
For clarification, after changing the VLAN settings initially, we are now unable to access the CLI to perform any type of command. We also cannot get any packet captures because there is no communication between the ports. The switch does not function as unmanaged, let alone managed. We have tried flashing the switch again, but it still hasn’t solved our issue
Some questions for you:
When you do VLAN clear, then power cycle the board, what activity do you see on the ports?
What devices are you connecting the switch to?
You mention that after you made these VLAN settings, the switch now no longer functions in unmanaged or managed mode.
In other words, you don’t see a CLI come up, and neither do the ports come up. Let’s break this down. Can you please flash the board with a blank firmware. This will clear the switch of any firmware. What activity do you see on the ports after doing this?
Finally, has anything changed in your hardware setup between changing the VLAN configuration on the CLI?
Forgive me, I know you said the CLI doesn’t come up now, please disregard my first question.
Please reflash the board with blank firmware, and we’ll debug from a known point of reference (no firmware, unmanaged mode).
Currently, the switch is not connected to any devices through the ports. Initially, port 3 was connected to an unmanaged switch that was connected to two sensors, port 4 was connected to a computer, port 1 was connected to an ADC, and port 2 was connected to another computer
When you say blank firmware, do you mean the bootloader and app binary from the documentation? We have tried this, and the board still has the same issues with LEDs and lack of port communication.
The hardware set up has not changed, other than the fact that we disconnected devices from the ports while trying to troubleshoot the issues
Thanks for the information.
What we’re trying to understand is whether the firmware has somehow corrupted operation of the switch. We haven’t seen anything like that before, but what I’d like us to do is revert the switch back to the state where it has no firmware running on it.
This isn’t using the bootloader app. This is literally using the SWD port on the board, and flashing a blank binary onto it. This would remove any settings you have made and restore the system to a purely unmanaged mode.
To do this, follow the same steps you used to flash the manager software in the first place, using the SWD port and the 6 pin connector. You can use STM32 Cube Programmer and simply flash a blank firmware file.
Once you’ve done this, let’s see how the switch behaves and we can debug from there.
When we try to flash the black binary file, we get the following error:
Can we press the full chip erase instead?
Yes, you can do a full chip erase, it will achieve the same thing
We did the full chip erase and the red light no longer illuminates on start-up; however, the LEDs for port 3 and port 4 are lit up with the same colors as previously stated. There is still no communication between ports on the switch.
Here is what it looks like:
Ok. The lights are on, so that means the links are up. Do the port LEDs flash when connected? If so, do they flash together? (If they flash together, that means both devices can see each other on the network)
Let’s now debug what you’re connecting to.
Firstly, please try connecting two simple devices to two ports on UbiSwitch. For example, two PCs on each port. We want to confirm that the basic switch operation is working. With those two PCs connected, check that the Ethernet interfaces on each PC come up.
Also, can you remind me what is connected to each port? Were they previously able to communicate and are no longer able to?
What happens when those two devices are connected together directly?
Sorry for the confusion, but the ports that we are plugged into are not ports 3 and 4. It seems that regardless of the connections to the ports, only port 3 and 4 have LEDs that are lit up and solid.
We have a sensor connected to port 7, and a computer connected to port 8.
Did you see this behaviour before you flashed the module?
Also, can you tell me the voltage you are powering the board at, and the current?