Paths

Table of Contentst

Diffusion FreeBSD src repository bceec3d80a3c

e1000: Try auto-negotiation for fixed 100 or 10 configuration
Concern Raisedbceec3d80a3c
Actions

Description

e1000: Try auto-negotiation for fixed 100 or 10 configuration

This is a retread of https://reviews.freebsd.org/D34449 which I think
will fix the issue for the remote side not supporting autoneg. We now
attempt an autoneg, and if that fails fall back to the current code
that forces the link speed/duplex.

The original intent of this patch is to inform the remote switch of
duplex settings when we (the client) are specifying a fixed 10 or 100
speed. Otherwise it may get the duplex setting wrong.

The tricky case is when the remote (switch) side is fixing its
speed AND duplex while disabling autoneg and we (client) need to do
the same, which still seems to be common enough at some ISPs.

Original commit message follows:
Currently if an e1000 interface is set to a fixed media configuration,
for gigabit, it will participate in auto-negotiation as required by
IEEE 802.3-2018 Clause 37. However, if set to fixed media configuration
for 100 or 10, it does NOT participate in auto-negotiation.

By my reading of Clauses 28 and 37, while auto-negotiation is optional
for 100 and 10, it is not prohibited and is, in fact, "highly
recommended".

This patch enables auto-negotiation for fixed 100 and 10 media
configuration, in a similar manner to that already performed for 1000.
I.e., the patch enables advertising of just the manually configured
settings with the goal of allowing the remote end to match the manually
configured settings if it has them available.

To be clear, this patch does NOT allow an em(4) interface that has been
manually configured with specific media settings to respond to
auto-negotiation by then configuring different parameters to those that
were manually configured. The intent of this patch is to fully comply
with the requirements of Clause 37, but for 100 and 10.

The need for this has arisen on an em(4) link where the other end is
under a different administrative control and is set to full
auto-negotiation. Due to the cable length GigE is not working well. It
is desired to set the em(4) end to "media 100baseTX mediatype
full-duplex" which does work when both ends are configured that way.
Currently, because em(4) does not participate in autoneg for this
setting, the remote defaults to half-duplex - i.e., there's a duplex
mismatch and things don't work. With this patch, em(4) would inform the
remote that it has only 100baseTX full, the remote would match that and
it will work.

Tested by: Natalino Picone <natalino.picone@nozominetworks.com>
Tested by: Franco Fichtner <franco@opnsense.org>
Tested by: J.R. Oldroyd <fbsd@opal.com> (previous version)
Sponsored by: Nozomi Networks
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D47336

Details

Auditors

jeroen.steinvoorte_mep-info.com

Provenance

Kevin Bowling <kbowling@FreeBSD.org>

Authored on Nov 23 2024, 12:27 PM

Differential Revision

D47336: e1000: particpate in auto-negotiation for fixed 100b or 10b configuration

Parents

rGb4ede68c21c6: find: Correct ls(1) equivalent command for -ls primary

Branches

Unknown

Tags

Unknown

Event Timeline

Kevin Bowling <kbowling@FreeBSD.org> committed rGbceec3d80a3c: e1000: Try auto-negotiation for fixed 100 or 10 configuration (authored by Kevin Bowling <kbowling@FreeBSD.org>).Nov 24 2024, 12:18 AM

Kevin Bowling <kbowling@FreeBSD.org> added an edge: D47336: e1000: particpate in auto-negotiation for fixed 100b or 10b configuration.Nov 24 2024, 12:23 AM

Kevin Bowling <kbowling@FreeBSD.org> mentioned this in rG645c45e297c0: e1000: Try auto-negotiation for fixed 100 or 10 configuration.Nov 27 2024, 4:16 AM

Kevin Bowling <kbowling@FreeBSD.org> mentioned this in rG87a1f9e8df1e: e1000: Try auto-negotiation for fixed 100 or 10 configuration.

Is this also tested with a device connected to a network switch that is set to 100 Mbit Full Duplex without auto negotiation?

And then verified that the the device and network switch are communication Full Duplex?

Since i recently updated my opnsense firewall i am encountering a lot of collisions on the WAN configuration.
I noticed that even though it is configured to Fixed 100Mbit full duplex, it does auto negotiation and falls back to 100 Mbit half duplex, as the ISP has auto negotiation switched off.
For 10 and 100 Mbit connections auto negotiation is disabled when it is set to fixed 10/100 half/full duplex.
All network equipment behaves this way. This is the second time i am forced to take action changing network equipment which is caused by a dodgy network cable.

In D47336#1079637, @fbsd_opal.com wrote:

Glad to see this is back under consideration. It will be useful for cases where it is needed.
When D34449 was reverted, we puled a new CAT6 cable where we had had this problem and therefore eliminated our need for this patch.
I am actually at the location in question at the moment, for a few days. I will try to set up a test of this revised patch this weekend.

I now have a network switch which does auto negotiation to the fire wall and is configured to 100Mbit full duplex to the ISP switch.

Can this please be reverted.

This commit now has outstanding concerns.Tue, Apr 1, 2:37 PM

In rGbceec3d80a3caf9249e24247fb937674bf5b46b5#723018, @jeroen.steinvoorte_mep-info.com wrote:

I noticed that even though it is configured to Fixed 100Mbit full duplex, it does auto negotiation and falls back to 100 Mbit half duplex, as the ISP has auto negotiation switched off.

If you're using 1000 LX/SX/Y, 100TX or 10T the auto-neg code advertises only one setting (what you set); there is no possibility of it "falling back" to half duplex if full duplex is what was set.
For 100FC or 10FL the code does not do any negotiation.

In rGbceec3d80a3caf9249e24247fb937674bf5b46b5#723276, @fbsd_opal.com wrote:

In rGbceec3d80a3caf9249e24247fb937674bf5b46b5#723018, @jeroen.steinvoorte_mep-info.com wrote:

I noticed that even though it is configured to Fixed 100Mbit full duplex, it does auto negotiation and falls back to 100 Mbit half duplex, as the ISP has auto negotiation switched off.

If you're using 1000 LX/SX/Y, 100TX or 10T the auto-neg code advertises only one setting (what you set); there is no possibility of it "falling back" to half duplex if full duplex is what was set.
For 100FC or 10FL the code does not do any negotiation.

The interface i am using is just a standard RJ-45 interface capable of doing 1Gbit, but it is configured to 100Mbit Full Duplex.
The ISP has its Cisco switch configured to 100Mbit Full Duplex, with no auto negotiation enabled.

But when I run ifconfig in the firewall i get the information below for the WAN interface.

igb1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
      description: WAN (wan)
      options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>
      ether xx:xx:xx:xx:xx:xx
      inet xx.xxx.xx.xxx netmask 0xfffffffc broadcast xx.xxx.xx.xxx
      inet6 xxxx::xxxx:xxxx:xxxx:xxxx%igb1 prefixlen 64 scopeid 0x2
      media: Ethernet 100baseTX <full-duplex> (100baseTX <half-duplex>)
      status: active
      nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

Note the line media: Ethernet 100baseTX <full-duplex> (100baseTX <half-duplex>)
I also have a lot of collisions on the interface statistics.

When I plug the same port with the same settings an a port that has auto negotiation enabled it comes back with below.

igb1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
      description: WAN (wan)
      options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>
      ether xx:xx:xx:xx:xx:xx
      inet xx.xxx.xx.xx netmask 0xfffffffc broadcast xx.xxx.xx.xxx
      inet6 xxxx::xxxx:xxxx:xxxx:xxxx%igb1 prefixlen 64 scopeid 0x2
      media: Ethernet 100baseTX <full-duplex>
      status: active
      nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

Note the line media: Ethernet 100baseTX <full-duplex>

And the collisions are gone.

So from my perspective, auto negotiation is enabled and falls back to half-duplex (as designed for network hubs).
But in this case auto negotiation must be disabled on both sides and just set the interface to 100Mbit Full-duplex.
That is not possible anymore.

@jeroen.steinvoorte_mep-info.com can you please get me the Cisco config for a port? I did test on a 2960X. Depending on what I see with that I will either fix or revert.

I have setup a test case at home where I have the same firewall as in the office and have a couple of ports to spare. In the office i am interrupting operations.
I have connected a laptop to a cisco switch which is connected to the firewall running opnsense. I have configured the firewall to 100 Mbit Full duplex.
The Cisco switch is also configured to 100 Mbit Full duplex.

!
interface gi1
!
interface gi2
  speed 100
  duplex full
!

When i plug the cable in gi2 i get collisions at the firewall and ifconfig in the firewall shows me half-duplex as mention in the earlier posts.
When i plug the cable in gi1 i get no collisions at the firewall and ifconfig in the firewall shows me full-duplex as mentioned in the erlier posts.

The Cisco switch used is an SF220-48. I have done the same test in the office with a TP link TL-SG105E and a netgear GS105E.
I cannot get a copy of the configuration of the ISP. But they told me that they limit our bandwidth to 100Mbit by setting the port to speed 100 and dupex full. The behavior with the switches i have tested is identical to the switch of the ISP.

Oh I forgot to mention. When making config changes in the network equipment. Disconnect and reconnect the network cable. Otherwise the firewall remembers what was negotiated and may give a false idea that it works.

Configuring two interfaces on a switch and move the cable between them is much easier.

Any update on this matter? What can I do to help?

In rGbceec3d80a3caf9249e24247fb937674bf5b46b5#728134, @jeroen.steinvoorte_mep-info.com wrote:

Any update on this matter? What can I do to help?

If you have time, take a look at the commit in question and see if you can find out what might be going wrong logically to the best of your ability.

Also can you share you exact hw string like dev.igb.0.%desc or whatever device it is. I have a fear/suspicion there is some NIC hardware dependency in the NICs link state machine so it might not be purely a driver issue. Which means it becomes a choice of who to make happy. But I haven't had time to sit down and test this on some of my many my hardware combinations yet.. so there is also a chance I just didn't test correctly with the link resets you mentioned. It may be a few weeks with my current workload.

In rGbceec3d80a3caf9249e24247fb937674bf5b46b5#728222, @kbowling wrote:

In rGbceec3d80a3caf9249e24247fb937674bf5b46b5#728134, @jeroen.steinvoorte_mep-info.com wrote:

Any update on this matter? What can I do to help?

If you have time, take a look at the commit in question and see if you can find out what might be going wrong logically to the best of your ability.

Also can you share you exact hw string like dev.igb.0.%desc or whatever device it is. I have a fear/suspicion there is some NIC hardware dependency in the NICs link state machine so it might not be purely a driver issue. Which means it becomes a choice of who to make happy. But I haven't had time to sit down and test this on some of my many my hardware combinations yet.. so there is also a chance I just didn't test correctly with the link resets you mentioned. It may be a few weeks with my current workload.

Sorry my paste got truncate with the request, I want to see sysctl dev.igb.1.%desc

I have checked it for all interfaces. Below the result.

root@router:/home/[user] # sysctl dev.igb.1.%desc
dev.igb.1.%desc: Intel(R) I211 (Copper)
root@router:/home/[user] # sysctl dev.igb.0.%desc
dev.igb.0.%desc: Intel(R) I211 (Copper)
root@router:/home/[user] # sysctl dev.igb.2.%desc
dev.igb.2.%desc: Intel(R) I211 (Copper)
root@router:/home/[user] # sysctl dev.igb.3.%desc
dev.igb.3.%desc: Intel(R) I211 (Copper)
root@router:/home/[user] # sysctl dev.igb.4.%desc
dev.igb.4.%desc: Intel(R) I211 (Copper)
root@router:/home/[user] # sysctl dev.igb.5.%desc
dev.igb.5.%desc: Intel(R) I211 (Copper)