Hi.
I am a bit new to ethtool, kernel drivers and all the surrounding aspects.
I also recognize that my use case is of low priority and a bit niche,
but any response would be greatly appreciated.
I'm modifying an existing Intel driver, and I'm looking for a way to
integrate/add another ethtool hook to force call `netif_carrier_on`.
There's plenty of hooks/listeners (not clear as to what you call
these) between the Intel driver and ethtool via C API's today that
allows for ethtool to control the driver. Many of which are for speed,
autonegotiation etc. But I don't see any flags/functions to force a
carrier state to up.
This would be very useful for many reasons, primarily on fiber optic
setups where you are developing hardware such as switches, routers and
even developing network cards. Or if you've got a passive device such
as IDS or something similar that passively monitors network traffic
and can't/shouldn't send out link requests.
There are commercial products with modified drivers that support this,
but since the Intel hardware in this case seems to support it - just
that there's no way controlling it with the tools that exist today. I
would therefore request a feature for consideration to ethtool that
can force carrier states up/down.
A intuitive option I think would be:
ethtool --change carrier on
Assuming that drivers follow suit and allow this. But a first step
would be for the tools to support it in the API so drivers have
something to call/listen for. In the meantime, I can probably
integrate a private flag and go that route, but that feels hacky and
won't foster driver developers to follow suit. My goal is to empower
more open source alternatives to otherwise expensive commercials
solutions.
Best wishes,
Anton Hvornum
On Tue, 9 Feb 2021 18:35:54 +0100
Anton Hvornum [off-list ref] wrote:
Hi.
I am a bit new to ethtool, kernel drivers and all the surrounding aspects.
I also recognize that my use case is of low priority and a bit niche,
but any response would be greatly appreciated.
I'm modifying an existing Intel driver, and I'm looking for a way to
integrate/add another ethtool hook to force call `netif_carrier_on`.
There's plenty of hooks/listeners (not clear as to what you call
these) between the Intel driver and ethtool via C API's today that
allows for ethtool to control the driver. Many of which are for speed,
autonegotiation etc. But I don't see any flags/functions to force a
carrier state to up.
This would be very useful for many reasons, primarily on fiber optic
setups where you are developing hardware such as switches, routers and
even developing network cards. Or if you've got a passive device such
as IDS or something similar that passively monitors network traffic
and can't/shouldn't send out link requests.
There are commercial products with modified drivers that support this,
but since the Intel hardware in this case seems to support it - just
that there's no way controlling it with the tools that exist today. I
would therefore request a feature for consideration to ethtool that
can force carrier states up/down.
A intuitive option I think would be:
ethtool --change carrier on
Assuming that drivers follow suit and allow this. But a first step
would be for the tools to support it in the API so drivers have
something to call/listen for. In the meantime, I can probably
integrate a private flag and go that route, but that feels hacky and
won't foster driver developers to follow suit. My goal is to empower
more open source alternatives to otherwise expensive commercials
solutions.
Best wishes,
Anton Hvornum
Normally, carrier just reflects the state of what the hardware is
reporting. Why not set admin down which tells the NIC to take
the device offline, and that drops the fiber link.
Or maybe what you want is already there.
Try writing to /sys/class/net/ethX/carrier which forces a carrier change?
On 10.02.2021 01:32, Stephen Hemminger wrote:
On Tue, 9 Feb 2021 18:35:54 +0100
Anton Hvornum [off-list ref] wrote:
quoted
Hi.
I am a bit new to ethtool, kernel drivers and all the surrounding aspects.
I also recognize that my use case is of low priority and a bit niche,
but any response would be greatly appreciated.
I'm modifying an existing Intel driver, and I'm looking for a way to
integrate/add another ethtool hook to force call `netif_carrier_on`.
There's plenty of hooks/listeners (not clear as to what you call
these) between the Intel driver and ethtool via C API's today that
allows for ethtool to control the driver. Many of which are for speed,
autonegotiation etc. But I don't see any flags/functions to force a
carrier state to up.
This would be very useful for many reasons, primarily on fiber optic
setups where you are developing hardware such as switches, routers and
even developing network cards. Or if you've got a passive device such
as IDS or something similar that passively monitors network traffic
and can't/shouldn't send out link requests.
There are commercial products with modified drivers that support this,
but since the Intel hardware in this case seems to support it - just
that there's no way controlling it with the tools that exist today. I
would therefore request a feature for consideration to ethtool that
can force carrier states up/down.
A intuitive option I think would be:
ethtool --change carrier on
Assuming that drivers follow suit and allow this. But a first step
would be for the tools to support it in the API so drivers have
something to call/listen for. In the meantime, I can probably
integrate a private flag and go that route, but that feels hacky and
won't foster driver developers to follow suit. My goal is to empower
more open source alternatives to otherwise expensive commercials
solutions.
Best wishes,
Anton Hvornum
Normally, carrier just reflects the state of what the hardware is
reporting. Why not set admin down which tells the NIC to take
the device offline, and that drops the fiber link.
Or maybe what you want is already there.
Try writing to /sys/class/net/ethX/carrier which forces a carrier change?
This attribute uses callback ndo_change_carrier in struct net_device_ops.
The kerneldoc provides further details.