Skip to contentSkip to conversation

Socket filter access to hatype

PATCH In review Paul LeoNerd Evans 2 participants 2 messages Apr 21, 2010 – Apr 22, 2010

Subsystems (5)
Networking Network drivers BPF BPF core +1 more subsystems
lore
Share & tools
lore

Paul LeoNerd Evans

author
#0 lore raw

PATCH 1/1 Socket filter access to hatype

When capturing packets on a PF_PACKET/SOCK_RAW socket bound to all interfaces, there doesn't appear to be a way for the filter program to actually find out the underlying hardware type the packet was captured on, such as is reported by the sll_hatype field of the struct sockaddr_ll when the packet is sent up to userland.

Unless I've managed to miss a trick somewhere, this would seem to put a fairly fundamental blocker on actually being able to filter in such packets. Granted there's the SKF_OFF_NET area to inspect at the e.g. IPv4 level, but this makes it impossible to do anything on e.g. the Ethernet level.

See below for a patch to add an SKF_AD_HATYPE field, up among the other special access fields around SKF_AD_OFF.

include/linux/filter.h +2 -1
diff -ur linux-2.6.33.2.orig/include/linux/filter.h linux-2.6.33.2/include/linux/filter.h
@@ -123,7 +123,8 @@
 #define SKF_AD_NLATTR_NEST	16
 #define SKF_AD_MARK 	20
 #define SKF_AD_QUEUE	24
-#define SKF_AD_MAX	28
+#define SKF_AD_HATYPE	28
+#define SKF_AD_MAX	32
 #define SKF_NET_OFF   (-0x100000)
 #define SKF_LL_OFF    (-0x200000)
net/core/filter.c +3 -0
diff -ur linux-2.6.33.2.orig/net/core/filter.c linux-2.6.33.2/net/core/filter.c
@@ -309,6 +309,9 @@
 		case SKF_AD_QUEUE:
 			A = skb->queue_mapping;
 			continue;
+		case SKF_AD_HATYPE:
+			A = skb->dev->type;
+			continue;
 		case SKF_AD_NLATTR: {
 			struct nlattr *nla;
Signature · 5 lines
Paul "LeoNerd" Evans

[email protected]
ICQ# 4135350       |  Registered Linux# 179460
http://www.leonerd.org.uk/
maintainer
#1 lore raw

From: Paul LeoNerd Evans <[email protected]>
Date: Wed, 21 Apr 2010 18:25:46 +0100

Quoted 6 lines

When capturing packets on a PF_PACKET/SOCK_RAW socket bound to all interfaces, there doesn't appear to be a way for the filter program to actually find out the underlying hardware type the packet was captured on, such as is reported by the sll_hatype field of the struct sockaddr_ll when the packet is sent up to userland.

Quoted 8 lines

Unless I've managed to miss a trick somewhere, this would seem to put a fairly fundamental blocker on actually being able to filter in such packets. Granted there's the SKF_OFF_NET area to inspect at the e.g. IPv4 level, but this makes it impossible to do anything on e.g. the Ethernet level.

See below for a patch to add an SKF_AD_HATYPE field, up among the other special access fields around SKF_AD_OFF.

This looks fine but you need to submit your patch properly, including proper "Signed-off-by: " tags etc. see Documentation/SubmittingPatches for details.

Please make a complete fresh new submission, and don't try to shortcut this by just replying and adding the Signed-off-by: or anything like that.

Thanks.