netdev - Re: consequences of setting net_device_ops ndo_change

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 5 Aug 2018 06:43:11 -0400 (EDT)
From:   "Robert P. J. Day" <rpjday@...shcourse.ca>
To:     Andrew Lunn <andrew@...n.ch>
cc:     Linux kernel ntedev mailing list <netdev@...r.kernel.org>
Subject: Re: consequences of setting net_device_ops ndo_change_carrier()?

On Sun, 5 Aug 2018, Andrew Lunn wrote:

> On Sat, Aug 04, 2018 at 07:06:58AM -0400, Robert P. J. Day wrote:
> >
> >   i'll try to keep this (relatively) short as there may be a
> > simple answer to this, or it could just be a stupid question --
> > sort of related to previous question (thank you, florian).
> >
> >   currently messing with networking device involving FPGA and some
> > quad-port transceivers, and noticed that, when one unplugs or
> > plugs a device into one of the ports, there is no change in the
> > contents of the corresponding sysfs files
> > /sys/class/net/<ifname>/carrier (or operstate, for that matter,
> > which might be related to this as well).
>
> Hi Robert
>
> As other have pointed out, ndo_change_carrier is not what you want
> here.

  i think i see that now ... based on the really adamant comment in
netdevice.h:

"Devices that determine carrier state from physical hardware
properties (eg network cables) or protocol-dependent mechanisms (eg
USB_CDC_NOTIFY_NETWORK_CONNECTION) should NOT implement this
function."

the impression i got was that implementing that routine for a physical
device would actually cause problems, but it seems only that it would
be a strange thing to do, but wouldn't necessarily cause problems if
you chose not to take advantage of it. which brings me back to one of
my original questions -- why *would* someone implement it? as some
sort of debugging feature? in any event, i'm convinced that that's not
where the problem lies.

> You should have a PHY device of some sort. Either a traditional
> copper PHY, or an SFP module. There should be a driver for this PHY.
> This could be one of those in drivers/net/phy. Or it could be
> firmware running, running on a little microcontroller inside your
> FPGA?

  in my case, it's properly in drivers/net/phy, so at least that part
is normal. back to investigating ...

rday

--

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                  http://crashcourse.ca/dokuwiki

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================