netdev - Re: Network protocol (IP,IPv6,...) and TC actions (ACT

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:	Sat, 17 Apr 2010 01:10:50 +0200
From:	Grégoire Baron <baronchon@...m.org>
To:	netdev@...r.kernel.org
Cc:	Jan Ceuleers <jan.ceuleers@...puter.org>
Subject: Re: Network protocol (IP,IPv6,...) and TC actions (ACT_CSUM)

Thanks Jan, for the suggestion.

Hi,

I will re-explain my situation.

I started to write a new TC action (ACT_CSUM) in order to be able to
force, specially when ACT_PEDIT is used, the update of common checksums:
 * the IPv4 header checksum,
 * the ICMP/IGMP and ICMPv6 checksums,
 * the TCP/UDP checkusms,
 * and why not, more ...

Also, the idea is to support directly IPv4 and IPv6.
The best user interface (via iproute2/tc) could to not ask the final
user to assume a specific network protocol, but let the action
discover it.

With this aim, I would like to know if someone could confirm me the
struct sk_buff .protocol member is the good candidate to discover if I
have an IPv4, an IPv6 packet or any other network protocol, in the skb
got by the TC action code (supporting INGRESS and EGRESS).

Indeed, this struct sk_buff member could contain something like
ETH_P_8021Q, which isn't a network protocol Id ...

I think this kind of content isn't seen by the TC actions, which work
at the network level (even if their filter protocol flag accepts all).
If someone could confirm, thanks in advance.

By the same way, I've wondered if the struct sk_buff .len member could
be used to avoid to "discover" the network packet length in the TC
action code, especially in the case of IPv6 packets (and jumbogram ;-).
But, I think not, because it could be not the case in INGRESS TC action
execution, in my point of view, because the packet wasn't delivered to
the network protocol yet. Is my analysis right?

Thanks again for your help.

Best Regards,

Grégoire Baron

On Tue, Apr 13, 2010 at 07:31:07PM +0200, Jan Ceuleers wrote:
> Grégoire Baron wrote:
> > As this .protocol member seems to be used at different moments when a
> > packet is received, forwared or sent, and could contain something like
> > ETH_P_8021Q which isn't a network protocol Id, can we say the struct
> > sk_buff .protocol member is guaranteed to contain a network protocol Id
> > in the struct sb_buff used in the TC action executions ?
> 
> Grégoire,
> 
> I suggest that you ask your question on the netdev mailing list (netdev@...r.kernel.org).
> 
> Cheers, Jan
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html