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:   Wed, 26 Sep 2018 20:47:34 +0000
From:   Chris Preimesberger <chrisp@...nsition.com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     "linville@...driver.com" <linville@...driver.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: bug: 'ethtool -m' reports spurious alarm & warning threshold
 values for QSFP28 transceivers

Hello Andrew,

Thank you for the quick response!!
Apologies in advance for my use of outlook and top-posting, etc...

I've run the raw option and the hex option, and pasted the results below.
Since the raw option printed strange characters on the CLI, I re-ran it,
Sending the output to a file (raw.txt) and attached that file as well.

Pasted from Ubuntu CLI:

tech1@D7:~$ 
tech1@D7:~$ 
tech1@D7:~$ 
tech1@D7:~$ 
tech1@D7:~$ sudo ethtool -m enp1s0 raw on
.UU$��pA`?�@�G.#
                 �.v..��.�.@TRANSITION      ��TNQSFP100GCWDM4 1AfX%.F?.?�TN02000301      180919  
    h�.I��_��'.��Ri=.`��Zntech1@D7:~$ 
tech1@D7:~$ 
tech1@D7:~$ 
tech1@D7:~$ 
tech1@D7:~$ sudo ethtool -m enp1s0 hex on
Offset		Values
------		------
0x0000:		11 00 00 0f 00 00 00 00 00 55 55 00 00 00 00 00 
0x0010:		00 00 00 00 00 00 24 e2 00 00 81 68 00 00 00 00 
0x0020:		00 00 00 00 00 00 00 00 00 00 41 60 3f e0 40 e0 
0x0030:		47 00 1f 10 0e 1e 0b f7 12 76 00 00 00 00 00 00 
0x0040:		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x0050:		00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 
0x0060:		00 00 00 00 00 00 00 00 00 00 1f 00 00 00 00 00 
0x0070:		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x0080:		11 fc 07 80 00 00 00 00 00 00 00 03 ff 00 02 00 
0x0090:		00 00 00 40 54 52 41 4e 53 49 54 49 4f 4e 20 20 
0x00a0:		20 20 20 20 00 00 c0 f2 54 4e 51 53 46 50 31 30 
0x00b0:		30 47 43 57 44 4d 34 20 31 41 66 58 25 1c 46 3f 
0x00c0:		06 00 3f d6 54 4e 30 32 30 30 30 33 30 31 20 20 
0x00d0:		20 20 20 20 31 38 30 39 31 39 20 20 0c 00 68 f3 
0x00e0:		00 00 02 49 80 a0 5f 1f de c9 27 16 f8 ae 52 69 
0x00f0:		3d 02 60 00 00 00 00 00 00 00 00 00 83 f4 5a 6e 
tech1@D7:~$ 
tech1@D7:~$ 






Chris Preimesberger | Test & Validation Engineer
Transition Networks, Inc.

chrisp@...nsition.com
direct: +1.952.996.1509 | fax: +1.952.941.2322 | www.transition.com


-----Original Message-----
From: Andrew Lunn [mailto:andrew@...n.ch] 
Sent: Wednesday, September 26, 2018 2:45 PM
To: Chris Preimesberger
Cc: linville@...driver.com; netdev@...r.kernel.org
Subject: Re: bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers

On Wed, Sep 26, 2018 at 07:29:23PM +0000, Chris Preimesberger wrote:
> Hello,
> 
> I'm re-sending in plain text per the auto-reply from a spam filter.

Yep. no html obfustication accepted here. Please ASCII only please :-)

Please can you also wrap your lines at about 75 characters.

>  I have attached some text files this time, which explain the situation below, in case the below email's font & formatting is now too messed up for easy comprehension.

> Bug #1.  Ethtool's reporting of the installed transceiver's alarm and warning thresholds will differ, depending on whether or not ethtool is piped to another command.  Example commands are below, with their respective differing output values highlighted:

Could you dump the raw values. That will make it easier for us to
reproduce this issue, assuming it is ethtool, and not the kernel
driver.

Thanks
	Andrew


View attachment "raw.txt" of type "text/plain" (256 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ