With ethtool-5.8-5.el8.x86_64
ethtool-5.8-5.el8.x86_64
$ ethtool --json -I -a eth0 ethtool: bad command line argument(s) For more information run ethtool -h $ echo $? 1
With ethtool-5.13-1.hs.el8
ethtool-5.13-1.hs.el8
$ ethtool --json -I -a eth0 Pause parameters for eth0: Autonegotiate: off RX: on TX: on $ echo $? 0
Note that the output is not JSON in both cases, but with the new version it actually returns success instead of failure.
Problem is in do_gpause, which is the ioctl fallback in case the netlink interface doesn't work.
do_gpause
https://git.kernel.org/pub/scm/network/ethtool/ethtool.git/tree/ethtool.c?h=v5.13&id=8b8cb55d5625218e1142c7ac3a6b2e902ab1b63b#n1835
Unlike the netlink version nl_gpause, which ends up calling pause_reply_cb, the ioctl fallback wasn't updated to be able to output JSON:
nl_gpause
pause_reply_cb
https://git.kernel.org/pub/scm/network/ethtool/ethtool.git/tree/netlink/pause.c?h=v5.13&id=8b8cb55d5625218e1142c7ac3a6b2e902ab1b63b#n165
In our environment, it looks like we only get up to cmd 10 (ETHTOOL_MSG_WOL_SET), while on my Fedora laptop I seem to get all the way to cmd 28 (ETHTOOL_MSG_TUNNEL_INFO_GET). Not sure why that part is happening (not sure if related to the dependency libmnl, major version is the same), but that should explain why it thinks ETHTOOL_MSG_PAUSE_GET is not available and falls back to ioctl in that case.
The problem exists upstream, I can try to write a patch for there too (but don't wait for me, feel free to report/fix upstream if you'd like.)
Patch series to fix this: https://lore.kernel.org/netdev/20210813171938.1127891-1-kuba@kernel.org/T/
The fix was merged upstream and will be available in the next ethtool release (likely in a couple of weeks)
Fixed in ethtool-5.14-1.hs.el8
ethtool-5.14-1.hs.el8
Metadata Update from @dcavalca: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Metadata Update from @ngompa: - Issue tagged with: c8s
Login to comment on this ticket.