Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Aug 2015 17:28:03 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-ports-bugs@FreeBSD.org
Subject:   [Bug 202247] x11/i3status: Incorrect Ethernet status after addition of SIOCGIFXMEDIA
Message-ID:  <bug-202247-13@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202247

            Bug ID: 202247
           Summary: x11/i3status: Incorrect Ethernet status after addition
                    of SIOCGIFXMEDIA
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: bapt@FreeBSD.org
          Reporter: jhb@FreeBSD.org
             Flags: maintainer-feedback?(bapt@FreeBSD.org)
                CC:
          Assignee: bapt@FreeBSD.org

Created attachment 159773
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=159773&action=edit
i3status_eth.patch

A few months back, the media status word for Ethernet was adjusted to use
several high bits to extend the subtype field.  Ever since this, i3status has
reported a media status string of "10GBase-KX4" when my laptop's Ethernet was
unplugged.

The root bug is that the loop looking for a matching subtype uses the IFM
macros against the subtype's word.  This is incorrect.  The description tables
only contain a single field in the raw word.  (Note that the corresponding code
in ifconfig only applies the IFM macros to the value from ifm_active.) 
Previously this bug didn't matter as IFM_SUBTYPE() against the values in the
table was a no-op.  However, with the extended types in the table, the
IFM_SUBTYPE() chopped off the upper bits.  This is why the first extended type
(10GBase-KX4) matched a status of 0 when the interface is down.

Note that I also removed the IFM_TYPE check as it was bogus.  The entries in
the table only have the subtype, so the IFM_TYPE is always clear.  This was why
IFM_TYPE_MATCH in the original source had to be hacked to permit 0 which at
that point meant it was always true and a no-op.

While here, I fixed a few other things:

1) added support for fetching extended media types
2) return an unknown status if the ioctl fails instead of garbage
3) return an unknown status if the type is not Ethernet
4) explicitly handle no carrier instead of falling through to returning "?"

This should probably go upstream as well if possible.

(I just have the patch for the port, I did not bump portrevision)

-- 
You are receiving this mail because:
You are the assignee for the bug.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-202247-13>