New Shake. When we plug the Shake into our Aruba switches the ethernet jack on the shake won’t even light up. Same results plugging it into a Fortigate. Taking it home and putting it on a home router it lights up and works. Back to our college network and having the same results. I manage this network and firewall so it’s on an open test environment.
Any idea what could be going on?
Thanks
Random guess: Something to do with auto speed selection?
Try fixing the port on your switch @ 100Mbps and see if that helps.
Well slap my arse and call me Sally. It didn’t cross my mind that the shake would be a fixed 100Mb port that doesn’t like to negotiate. That worked, thank you.
I have been caught too many times by auto-negotiation problems (not just with R-Pi).
Symptoms just sounded TOO familiar.
Thank you @PhilipPeake for the tip on auto-negotiation.
I ran into this problem last week after deciding to relocate S0CBB from my second floor home office to the garage concrete slab. I was also going to power it via POE. In testing the POE I ran into the same problem that @mmacpuguy encountered and was scratching my head. Then this post arrived.
I have several POE ethernet switches throughout my property, but only one was a managed switch, a Ubiquiti US-8-60W. I nailed up a port on that switch to 100M and successfully connected the RS4D.
This brings up a question. Why does this occur only on the RS? Of course the RPI 4 does not have this problem, but I have many RPI 3B and RPI 3B+ running on POE both with hats and directly with splitters and have never encountered this problem before. All those Pi are running the pure Rasbian OS. Does RS’s tinkering with Rasbian create this issue?
Thank you again for enlightening me to this problem.
I don’t really know. The OS is not pure Raspbian (which, IMHO may be a good thing!).
If I had to guess, it would be that auto-negotiation in home devices is much more restricted, just cycling through 100BaseT and 1000BaseT until it obtains a lock.
Commercial equipment often covers a broader range 10Mbps - 10Mbps.
Cheap interfaces just may not even detect that there is any signal at the extremes.
I first became “sensitized” to this problem a long time ago, with people having throughput problems.
Typically, it was Sun Microsystems servers and Cisco switches - neither particularly cheap pieces of equipment, but both having out-of-box auto-negotiate.
Usually, the problem was obvious if you just looked at the interface state - you would often find that they had negotiated full-duplex, but with 100BaseT in one direction and 10BaseT in the other…
After a few of those, any sort of comms issue - that is where I start looking.
Hi all:
This is a HW, not a SW limitation.
4 Ethernet wires used :: Max velocity is 100 Mbit/s
8 Ethernet wires used :: Max velocity is 1000 Mbit/s
RS ships all indoor Shakes (the ones with the clear plastic home enclosure) with 1000 Mbit/s configured cables and all outdoor Shakes (IP67) with 100 Mbit/s connections. This will change in the future as 1000 Mbit/s technologies become more common.
Saludos,
I know it supports those speeds, but the problem here is auto-negotiation.
Many professional switches support a wide range of speeds, and also support (who knows why, these days) different speeds for each side of a bi-directional link (as well as uni-directional links).
They seem to get things wrong and fail with a lot of consumer kit. Does the R-PI support/respond to 10BaseT? To attempts to do things like 10BaseT up, 100BaseT (or 1000BaseT) down? These things do, and they probe for it.
All I know is that I have, over the years, resolved a lot of networking/connectivity problems by turning auto-negotiation off when dealing with “professional” switches - consumer kit pretty much always seems to work ok.