netdev - Re: IPA monitor (Final RFC)

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] [day] [month] [year] [list]

Date:   Wed, 2 Feb 2022 20:05:04 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Alex Elder <elder@...aro.org>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        Network Development <netdev@...r.kernel.org>,
        "bjorn.andersson@...aro.org" <bjorn.andersson@...aro.org>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: IPA monitor (Final RFC)

> From what I can tell, CRC errors are not indicated in the status
> header.  The status seems to be more oriented toward "this is
> the processing that the IPA hardware performed on this packet."
> Including "it entered IPA on this 'port' and matched this
> filter rule and got routed out this other 'port'."  But to be
> honest my focus has been more on providing the feature than
> what exactly those bits represent...

My experience of using interfaces like this, it is sometimes CRC
problems you are trying to track down. So it would be nice if the
behaviour around CRCs was documented, to know if packets with bad CRC
get dropped, or are part of the stream etc. It probably does not make
much difference to the actual API design.

> > Do you look at various libpcap-ng implementations? Since this is
> > debugfs you are not defining a stable ABI, you can change it any time
> > you want and break userspace. But maybe there could be small changes
> > in the API which make it easier to feed to wireshark via libpcap.
> 
> I considered that.  That was really the interface I was envisioning
> at first.  Those things don't really align perfectly with the
> information that's made available here though.  This is more like
> "what is the hardware doing to each packet" (so we can maybe
> understand behavior, or identify a bug).  Rather than "what is
> the content of packets flowing through?"  It might be useful
> to use the powerful capabilities of things like wireshark for
> analysis, but I kind of concluded the purpose of exposing this
> information is a little different.

I've had good experiences with writing dissectors for wireshark.  I
think you should be able to decode the extra headers, and then pass
the IP packet onto the standard dissectors. And having multiple frames
in one message should also not be a big issue. So i would not discard
the idea of writing into some sort of pcap file and feeding it to
wireshark.

    Andrew