Networking over unmanaged switch

24 views
Skip to first unread message

sneff-841

unread,
Jan 24, 2021, 9:16:36 PM1/24/21
to vmx-pi
I have my PC, VMXpi, and Gloworm/Limelight all on the same unmanaged switch. 

I'm starting the Gloworm and the VMXpi/Roborio at the same time, off the same power supply, when the PC is sometimes already connected.

While some of my networking issues were definitely the corrupted USB3.1 driver I finally figured out to restart/reinstall this a.m., I have a sneaking suspicion that another major contributor is device startup order. Like if my PC is already connected to the unmanaged switch, will powering up the VMX let it connect at the usual address or will it get forced onto the PC's default DHCP? If there's another RPi device (gloworm) sitting on the same network, does this effect get even worse? 

Wondering if there are any fixes that can come from the VMXpi side to make it more resilient against device startup order.... 

Thanks,
Sam 

Scott Libert

unread,
Jan 24, 2021, 9:53:02 PM1/24/21
to vmx-pi
 > device startup order
> if my PC is already connected to the unmanaged switch, will powering up the VMX let it connect at the usual address or will it get forced onto the PC's default DHCP?

The behavior is defined by the DHCP Server's configuration, and by whether each DHCP client can communicate with the DHCP Server.

There should be only one DHCP server on the subnet.  In your case, which device is the DHCP Server?  The PC, the Gloworm, the VMX-PI or the unmanaged switch?

If the DHCP server is not up and running when another DHCP client (like the PC) starts up, after a timeout period the client will fall back to an auto-assigned address (which will be on a separate network).  So the first rule is if using DHCP,  the DHCP Server should be constantly running.  Perhaps the unmanaged switch should be configured as the sole DHCP server on this network.

In the degenerate case where the DHCP server doesn't respond to any DHCP client, all clients should be on the same auto-assigned subnet.  However, it's likely that if that happens, that software (e.g., driver station) might need to be reconfigured to know the ip addresses.

Startup order can potentially impact which IP address is given to each device.  To handle cases where DHCP clients get different IP addresses assigned to them by the DHCP Server (due to their startup order) It is also possible to configure a DHCP server so that it always gives the same IP address to the same MAC address.

And if none of that is acceptable, static ip addresses can be used.

> Wondering if there are any fixes that can come from the VMXpi side to make it more resilient against device startup order.... 

Not sure what a fix might be - it's not clear to me yet what the problem is.  It'll help to know:  (a) which device is the DHCP server in your network and (b) in the case were unwanted behavior is occurring, what IP addresses are all of the devices using when the problem occurs?

Sam Neff

unread,
Jan 25, 2021, 3:04:17 PM1/25/21
to Scott Libert, vmx-pi
Thank you! That's a really clear summary of the DHCP activity, that I wasn't able to piece together myself from googling. 

I think that the VMXpi should be the DHCP server, unless I can figure out how to change settings on the unmanaged switch, but I haven't dug enough into the setup to verify that it's the only DHCP server, as you are pointing out.
At the minimum in the short term I can just connect the devices in the correct order. 

Best Regards,
Sam Neff


--
You received this message because you are subscribed to a topic in the Google Groups "vmx-pi" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vmx-pi/Ka8nlyxuy2k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vmx-pi+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vmx-pi/31d6b3fe-3908-4649-b741-dafd694099e9n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages