[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170508062725.GA1930@gwshan>
Date: Mon, 8 May 2017 16:27:25 +1000
From: Gavin Shan <gwshan@...ux.vnet.ibm.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Gavin Shan <gwshan@...ux.vnet.ibm.com>, netdev@...r.kernel.org,
joe@...ches.com, kubakici@...pl, f.fainelli@...il.com,
davem@...emloft.net
Subject: Re: [PATCH v4 net-next 08/10] net/ncsi: Support NCSI packet
generation
On Mon, May 08, 2017 at 02:56:32AM +0200, Andrew Lunn wrote:
>> I need to dig how libpcap receives packets. It's appreciated if you
>> can give some hints about that. However, I don't see the benefit to
>> receive packets by libpcap, could you claim?
>
>The base interface should already be doing it for you. Try it! Run
>tcpdump or wireshark and you should see the NCSI packets going
>out/coming in. Look for the ethertype. Neither tcpdump or wireshark
>appear to have dissectors for NCSI, but it should be simple to
>write. I've written them before, and it is easy.
>
>Doing it in userspace will give you a much nice environment to work
>in. Wireshark can link the response to the request, do a much more
>detailed decode than what you want to do in kernel space, and in
>general it is safer. Wrongly decoding and printing protocols in kernel
>space can lead to a remote kernel vulnerability. Getting it wrong in
>user space 'just' allows a remote hack of a user account.
>
Andrew, thanks a lot for the hints. Yeah, I think it's implemented based
on AF_PACKET + ETH_P_ALL. NCSI packets has been included.
The output from (libpcap and debugfs) will be different, but I assume it's
not a problem. libpcap usually outputs all Tx/Rx NCSI packets while debugfs
file outputs received NCSI response packets that correspond to the NCSI command
packets sent via the debugfs interface.
In next respin, I'll move the Rx path to libpcap while the Tx is left in
the debugfs interace.
Cheers,
Gavin
Powered by blists - more mailing lists