Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Switch port speed and duplex settings

31 views
Skip to first unread message

fca...@gmail.com

unread,
Sep 8, 2012, 6:49:11 PM9/8/12
to
Hi,

Is there any way that I can detect a swtich port's speed and duplex settings via Wireshark? Failing that, does any one know of a utility that I could use?

Thanx,
Ed

Char Jackson

unread,
Sep 8, 2012, 11:44:36 PM9/8/12
to
On Sat, 8 Sep 2012 15:49:11 -0700 (PDT), fca...@gmail.com wrote:

>Hi,
>
>Is there any way that I can detect a swtich port's speed and duplex settings via Wireshark? Failing that, does any one know of a utility that I could use?

Starting with the easiest, if you have physical access to the switch
you may be able to observe its front panel status LEDs. Failing that,
if it's a managed switch you may be able to log into it and view the
status of each port. If it's unmanaged, you can check its spec sheet
or check the port status of the devices connected to it.

Just tossing out ideas...

geertjandegroot

unread,
Sep 9, 2012, 11:29:55 AM9/9/12
to
> Is there any way that I can detect a swtich port's speed
> and duplex settings via Wireshark?
> Failing that, does any one know of a utility that I could use?

You did not tell your platform and the answer differs a great deal
between them.

To start: wireshark typically does not have access to the MII-bus,
which is where these things are managed.

With most BSD variants (including OSX), ifconfig helps:
$ ifconfig re0
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
...
address: xx:xx:xx:xx:xx:xx
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet xx.xx.xx.xx netmask 0xffffff80 broadcast xx.xx.xx.xx
inet6 2001:xx:xx:xx::xx prefixlen 64

$ ifconfig -m re0
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: xx:xx:xx:xx:xx:xx
media: Ethernet autoselect (100baseTX full-duplex)
status: active
supported Ethernet media:
media none
media 10baseT
media 10baseT mediaopt full-duplex
media 100baseTX
media 100baseTX mediaopt full-duplex
media 1000baseT
media 1000baseT mediaopt full-duplex
media autoselect
...

On Linux, there are several mechanisms and I'm not aware of a generic
mechanism. Check 'miitool'.

I do not know details on Windows, sorry.

Geert Jan

Rick Jones

unread,
Sep 11, 2012, 5:26:29 PM9/11/12
to
If you are running wireshark on a station connected to the switch
port, chances are quite good that the station's speed and duplex match
that of the switch port. In fact, if you see anything at all, it
means the speeds match. The switch port could have a different duplex
setting than the station though. Something from the mists of time,
check the bit about signs of a duplex mis-match:

How 100Base-T Autoneg is supposed to work:

When both sides of the link are set to autoneg, they will "negotiate"
the duplex setting and select full-duplex if both sides can do
full-duplex.

If one side is hardcoded and not using autoneg, the autoneg process
will "fail" and the side trying to autoneg is required by spec to use
half-duplex mode.

If one side is using half-duplex, and the other is using full-duplex,
sorrow and woe is the usual result.

So, the following table shows what will happen given various settings
on each side:

Auto Half Full

Auto Happiness Lucky Sorrow

Half Lucky Happiness Sorrow

Full Sorrow Sorrow Happiness

Happiness means that there is a good shot of everything going well.
Lucky means that things will likely go well, but not because you did
anything correctly :) Sorrow means that there _will_ be a duplex
mis-match.

When there is a duplex mismatch, on the side running half-duplex you
will see various errors and probably a number of _LATE_ collisions
("normal" collisions don't count here). On the side running
full-duplex you will see things like FCS errors. Note that those
errors are not necessarily conclusive, they are simply indicators.

Further, it is important to keep in mind that a "clean" ping (or the
like - eg "linkloop" or default netperf TCP_RR) test result is
inconclusive here - a duplex mismatch causes lost traffic _only_ when
both sides of the link try to speak at the same time. A typical ping
test, being synchronous, one at a time request/response, never tries
to have both sides talking at the same time.

Finally, when/if you migrate to 1000Base-T, everything has to be set
to auto-neg anyway.

Leaving the boilerplate behind... If the speed is 1 GbE, 99 times out
of ten the duplex will be full - while the GbE specs allowed for
half-duplex operation at 1 GbE speed, I don't know of any kit that
shipped which actually did that.

Even if you aren't on a station connected to the switch port, if the
wireshark trace shows data flowing through the switch port above
100Base-T speeds, you can reasonably assume the switch port was
full-duplex and operating at 1 GbE speed. If the data is shown
flowing at > 1 GbE then you can probably assume 10GbE.

There are some exceptions though - certian GbE kit could operate at
2.5 GbE, though I'm not sure if it ever did so outside of an HP Blade
environment? Speaking of an HP Blade environment, it would be I/O
modules rather than switches, but the "flex NICs" there can be
configured to run in any multiple of 100 Mbit/s.

rick jones
--
The computing industry isn't as much a game of "Follow The Leader" as
it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
- Rick Jones
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
0 new messages