Correct way to disable link autoneg

[Mads]

A user of our sbRIO-based system is hooking his device to a link interface that does not support autoneg *AND* is running at 100 Mbit/s Full duplex. This will produce a duplex mismatch problem as the sbRIO NIC is always using autoneg...(in NI MAX we can only change the preferred mode/ability flag). The NIC on the sbRIO detects the speed (although I am not sure how stable that detection is expected to be(?)), but will as expected default to half duplex, not full.

So, we want to disable autoneg on the sbRIO, and fix it to 100 Mbit/Full.

I have seemingly succeeded in doing so by adding the highlighted line to the ifplugd.script:

The question is, is this the/a correct way to do it on Linux RT, and/or is there a better/simpler way to do it?

Setting it as an environmental (Ethtool_opt) variable in sysconfig seems to be another Linux-way to go, but I do not find where to apply that on Linux RT.

Mads

[Taggart]

I'm no Linux expert but editing a config file seems rather Linuxy.  I'm sure there are other ways to do it. Environment variables also seem rather linuxy.

[GatorChomp]

I don't have a Linux RT sbRIO on hand but I think you should be able to change the Link Speed in MAX if you expand More settings for the adapter. From a cRIO:

I think you can also edit some of those settings with the nirtcfg utility (e.g., see the hostname section here). 

[Mads]

The NI MAX interface only sets the "preferred" link speed, which in effect (as tested using ethtool) translates to autoneg ON, but with the ability flag set to the chosen mode. It is still in autoneg ON mode though, so if the other interface does not support autoneg I expect that it will default to Half duplex, with the speed possibly correct due to the ability to detect speed (but not duplex-settings). -Or, if the speed detection fails (not sure how robust it is), 10 Half.

I do not think there is a graphical way availble to disable autoneg, just as there is no way as far as I know to graphically announce support for a specific combination of modes (in other words to say that you "prefer" 10 Full *or* 100 Half for example), to do that I think we are required to do it in a "Linuxy" way using scripts...Like this:

/usr/sbin/ethtool -s eth0 advertise 0x0F

Where 0x0F is an exaple code which means support for all comboes of 10/100 - but no 1000 Mbitps.

[Mads]

"I'm no Linux expert but editing a config file seems rather Linuxy.  I'm sure there are other ways to do it. Environment variables also seem rather linuxy.

[Mads]

It seems to me that the answer to the original question here is NO. Adding the ethtool command to the ifplugd.script will not work in all scenarios.

The reason I say that is that adding the ethtool command to the ifplugd script seems to work fine *only* on bootup, but not on down/up (if the interface in question is unplugged/down and then plugged/taken up again it will no longer detect a link (which it should as it was able to detect it on bootup, and looking at the config through ethtool shows that it should match the link).

So something is going wrong here when the script is invoked a second time / on down-up. 

Is there anyone who knows a way to turn autoneg off and fix the link speed and duplex settings in a way that will work consistently?

PS. As mentioned earlier I do not think just setting the preferred link setup through MAX is sufficient as it only affects the advertised mode. Having tested this now with a pairing with a device that is fixed to 100 Full e.g. I found that I was correct in that assumption; autoneg will still interfere then and cause a duplex mismatch and in some cases also a speed mismatch due to fallback to 10.

[Mads]

I have to correct myself again here as the loss of link depends on the time the physical link is down. If the physical link is kept disconnected for a sufficiently long period the proposed ifplugd.script edit works after all.

It is only when the physical link is disconnected and then reconnected within a couple of seconds that the solution causes the link to remain in a link not detected state. So it is not ideal, as short loss of contact can cause the link to remain down, but at least it will go back up then if the link is physically down for a sufficiently long time.

[GatorChomp]

Prefacing this with the fact that Linux networking is not something I'm super familiar with.

You're correct, MAX just sets the preference and doesn't disable autonegotiating. I did some poking around in online forums on the topic, and there are a number of stack overflow posts which simply say you shouldn't disable autoneg but that's not exactly helpful here.

For your case, my best guess is that you need to cover the "error" case for ifplug and not just the "up" and "down" cases. That might be why the script works when unplugged for a sufficiently long time but not for short unplugs. Another option appears to be to configure ifplugd to treat errors as link-down/no link situations through the available flags for the command.

Again, I am just speculating here and I am by no means an expert on this topic.

[Mads]

GatorChomp wrote:

"For your case, my best guess is that you need to cover the "error" case for ifplug and not just the "up" and "down" cases. That might be why the script works when unplugged for a sufficiently long time but not for short unplugs. Another option appears to be to configure ifplugd to treat errors as link-down/no link situations through the available flags for the command.

Again, I am just speculating here and I am by no means an expert on this topic."

Sounds like a good lead.🤔

I am absolutely unfamiliar with Linux myself. There is for example already, by default, an -f (?) argument in ifplugd.config which I assume is the one setting errors to be treated as up/down...Or more correctly, it is stated as -fI, not -f. I cannot find an -fI argument described, nor is the -f argument supposed to have a parameter as far as I can see, unlike -u for example which has a time in seconds...If this is something else than the -f argument I could add that I guess...I am not sure what I would put in an error case if needed though (and I am assuming that would go into the ifplugd.script by adding an error) entry...but again, this is all "Greek" or rather "text" to a graphical guy like me 😁)

[Taggart]

if it is a standard linux command -fl is the same as -f and -l .  The parameter probably goes with the -l flag.