Bug 202247
| Summary: | x11/i3status: Incorrect Ethernet status after addition of SIOCGIFXMEDIA | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | John Baldwin <jhb> | ||||
| Component: | Individual Port(s) | Assignee: | Baptiste Daroussin <bapt> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | Flags: | bugzilla:
maintainer-feedback?
(bapt) |
||||
| Priority: | --- | ||||||
| Version: | Latest | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
Please go ahead and commit. And yes it would be great to upstream that. I am pretty sure the patch will apply ootb upstream or quite close even if we are one version behind (I have not taken time to port the newer version given it depends on libpulse) A commit references this bug: Author: jhb Date: Tue Aug 11 20:51:56 UTC 2015 New revision: 393973 URL: https://svnweb.freebsd.org/changeset/ports/393973 Log: Fix some nits with displaying Ethernet media status exposed by the recent extended Ethernet media states: - Don't apply IFM_SUBTYPE to the raw subtype in the description table. IFM_SUBTYPE() requires a fully populated word and was truncating values in the table when comparing resulting in false matches (notably "10GBase-KX4" for the no media case). - Explicitly check for IFM_ETHER. - Use SIOCGIFXMEDIA when present to obtain extended media states. - Explicitly handle "no carrier". PR: 202247 Reviewed by: bapt Changes: head/x11/i3status/Makefile head/x11/i3status/files/ head/x11/i3status/files/patch-print_eth_info.c |
Created attachment 159773 [details] 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)