netdev - RE: [PATCH] 1/1 net: packet: Keep 802.1Q VLAN tag in packet on SOCK_DGRAM socket

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:	Mon, 4 Jan 2010 18:11:17 +0100
From:	Milan Dadok <milan@...ok.name>
To:	'Patrick McHardy' <kaber@...sh.net>
CC:	<uaca@...mni.uv.es>, <johann.baudy@...-log.net>,
	<linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>
Subject: RE: [PATCH] 1/1 net: packet: Keep 802.1Q VLAN tag in packet on SOCK_DGRAM socket - resend

>Patrick McHardy wrote:
>> Currently pseudo-header contains for OUTGOING packet on physical card (vlan10@...1)
>> a) HW accelarated network card  
>> protocol = ethertype IPv4 (0x0800)
>> tci = vlan number = 10
>> and data starts with 4500 0028
>> 
>> b) non HW accelerated network card 
>> protocol = ethertype 802.1Q (0x8100)
>> tci = 0
>> and data starts with 4500 0028
>> vlan tci and real protocol number (ARP,IPV4,IPV6) of data is lost 
>>
>As mentioned in the text I quoted, this is apparently what is
>intended for SOCK_DGRAM packet sockets. The accelerated case is
>inconsistent and vlan_tci should be cleared I guess.
>
>I agree that sll_protocol should reflect the network protocol
>in this case however.

There are probablly two solution SOCK_DGRAM
A. sll_protocol will have outer network protokol and packet data will have all data after that network protokol field
	(sll tci will be <>0 only with VLAN acceleration)

B. ssl_protocol will have the most inner network protokol (Ipv4, ARP, Ipv6)
	and cooked sll will have fields for restore all encapsulation protocols
	(on eth1 I need to know, if packet is send with vlan 1010 in vlan 10 or as vlan 10 in vlan 1010)

>> I have no problems with received packets, only outgoing packet have problem.
>> I think that out packet on SOCK_DGRAM sockets MUST BE in same format as in (received) packet on same interface.
>> Can we agree on this?
>
>Yes, agreed.

Now receive path is working as in solution A (if I remember correctly from my tests)
- packet data with all 802.1Q tags are send throu SOCK_DGRAM in same format as in SOCK_RAW (expect MAC header)
  (on HW vlan accel first VLAN tag is in tci field of TPACKET_V2)

Outgoing packet in SOCK_RAW is same as in receive.
Outgoing packet in SOCK_DGRAM - solution B with invalid sll_protokol

My patch is trying to change behaviour of outgoing packet in SOCK_DGRAM to same format as in received SOCK_DGRAM or SOCK_RAW

PS. There is one BIG question - how can I write kernel filter for filter explicit vlan number,
which can be used at the same time on HW vlan accelerated card (outer VLAN is in tci) and
non HW vlan accelerated card (outer VLAN is at the beggining of packet data)

Only solution I found, is to use user level filter and recreate vlan tag from sll tci in userspace before running filter.

Milan







--
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