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]
Message-ID: <8e65d057-a39c-6b83-b650-922ba9e86051@gmail.com>
Date:   Wed, 14 Jun 2017 18:03:27 +0200
From:   Jan Grashöfer <jan.grashoefer@...il.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     netdev@...r.kernel.org, aeppert@...il.com
Subject: Re: Receiving raw packets (incl. VLAN tags) on raw sockets

On 14/06/17 16:41, Eric W. Biederman wrote:
> That does not work.  That is is just the software fallback for when
> the device driver does not have a special case the processing
> vlan tagged packets.
> 
> There was a major inconsistency that for a long time the hardware
> network drivers were stripping tags and the software ones were not.
> 
> The code you are playing with is the fix for the rare slow path
> that does not happen to strip the tags.  Disabling the rare slow path
> might temporarily solve your symptoms but it will be much more painful
> when you are entrenched in your ways and discover that high performance
> hardware behaves differently than your software device.

Thanks for your reply! Actually, I was referring to COTS hardware that 
incorporates offloading features. But, when it comes to (security) 
monitoring, offloading is usually disabled [1,2] to process the packets 
as seen on the wire. Thus the "slow path" would be the default path for 
most monitoring applications. That is, what makes this situation kind of 
weird. After turning off the NIC's VLAN offloading, it took me some time 
to realize that now the kernel strips off VLAN tags. If someone decides 
that VLAN offloading is not needed, I think the kernel should not 
enforce it.

Jan

[1] 
https://redmine.openinfosecfoundation.org/projects/suricata/wiki/File_Extraction#NIC-offloading
[2] 
https://www.bro.org/documentation/faq.html#capture-loss-without-dropped-packets

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ