skb->mac.raw, when is does it point to ethhdr

skb->mac.raw, when is does it point to ethhdr

[Amin Azez]

I've been treating skb->mac.raw as a pointer to ethhdr and stealing mac 
addresses when conntrack's are created.

So the question comes up, how do we tell when skb->mac.raw is pointing 
to an ethernet frame header and when it is pointing to something else?

I found a case even in ethernet only systems where if traffic is sent to 
a non-existant host then some associated skb have skb->mac.raw not NULL 
but also point to something else, or at least something quite bogus, for 
my to copy mac address memcpy was tying to copy sizeof(ethhdr) from 
fbdb1200, or sometimes from such addresses as 003ba300, which indictaes 
sometimes it is not even a valid pointer to anywhere. I got:

Unable to handle kernel paging request at virtual address fbdb1200

So I need to find out how to tell when skb->mac.raw points to a valid 
ethhdr struct.

The clue must be in sk_buff somewhere.

net_device, a likely candidate seems too opaque, with nothing to 
indicate device type, or link layer header struct type.

I guess I could look for skb->mac_len to be the same as ethernet maclen, 
but thats a cheat.

Thats about all I can find.

Any ideas?

Amin

Re: skb->mac.raw, when is does it point to ethhdr

[YOSHIFUJI Hideaki / 吉藤英明]

In article <d4r2n4$o39$1@sea.gmane.org> (at Thu, 28 Apr 2005 17:29:35 +0100), Amin Azez <azez@ufomechanic.net> says:

> I've been treating skb->mac.raw as a pointer to ethhdr and stealing mac 
> addresses when conntrack's are created.
> 
> So the question comes up, how do we tell when skb->mac.raw is pointing 
> to an ethernet frame header and when it is pointing to something else?

Basically, the hardware header (ether frame) is resolved / appended
in the ip_finish_output2() (for IPv4) or ip6_output_finish() (for IPv6),
after POST_ROUTING.
Thus, in the POST_ROUTING (or before the POST_ROUTING),
hardware header (ether frame) is not available (in most cases).

--yoshfuji

Re: skb->mac.raw, when is does it point to ethhdr

[Amin Azez]

YOSHIFUJI Hideaki / 吉藤英明 wrote:

>In article <d4r2n4$o39$1@sea.gmane.org> (at Thu, 28 Apr 2005 17:29:35 +0100), Amin Azez <azez@ufomechanic.net> says:
>  
>
>>I've been treating skb->mac.raw as a pointer to ethhdr and stealing mac 
>>addresses when conntrack's are created.
>>
>>So the question comes up, how do we tell when skb->mac.raw is pointing 
>>to an ethernet frame header and when it is pointing to something else?
>>    
>>
>Basically, the hardware header (ether frame) is resolved / appended
>in the ip_finish_output2() (for IPv4) or ip6_output_finish() (for IPv6),
>after POST_ROUTING.
>Thus, in the POST_ROUTING (or before the POST_ROUTING),
>hardware header (ether frame) is not available (in most cases).
>  
>
Thanks, for this, but the question is more complex.
conntrack only gets to inspect packets in PREROUTING and OUTPUT phases.
In this problem case the packet was originating from the local machine 
and so as you pointed out the mac info won't be setup until POSTROUTING.

Generally I am only interesting in collecting mac addresses in PREROUTING.
I suppose I need to know which phase of netfilter triggered the 
conntrack that triggered me. Until then I have stolen the ancient 
bridging check which makes sure that skb->mac.raw points to somewhere 
within skb, so I can tell it is at least a valid pointer.

Is there anyway to tell if skb>mac.raw it points to an ethernet mac 
address, or an X25 linklayer address, or appletalk, etc?
Having a valid pointer is one thing, but knowing what it points to is 
another.

Thanks

Amin

Re: skb->mac.raw, when is does it point to ethhdr

[Henrik Nordstrom]

On Thu, 28 Apr 2005, Amin Azez wrote:

> So the question comes up, how do we tell when skb->mac.raw is pointing to an 
> ethernet frame header and when it is pointing to something else?

IIRC You need to look at the link type of the device the packet came from.

Regards
Henrik

wow, why does everything presume ethernet? Re: skb->mac.raw, when is does it point to ethhdr

[Amin Azez]

Henrik Nordstrom wrote:

> On Thu, 28 Apr 2005, Amin Azez wrote:
>
>> So the question comes up, how do we tell when skb->mac.raw is 
>> pointing to an ethernet frame header and when it is pointing to 
>> something else?
>
> IIRC You need to look at the link type of the device the packet came 
> from.

I was trying to do that but when I looked again after your hint I found 
it, thanks.

I notice most netfilter stuff that uses mac.raw seems to presume an 
ethernet link layer.

e.g.
net/ipv4/netfilter/ipt_mac.c - although it takes "in" and "out" devices 
as parameters it presumes ethernet:
static int
match(const struct sk_buff *skb,
const struct net_device *in,
const struct net_device *out,
const void *matchinfo,
int offset,
int *hotdrop)
{
const struct ipt_mac_info *info = matchinfo;

/* Is mac pointer valid? */
return (skb->mac.raw >= skb->head
&& (skb->mac.raw + ETH_HLEN) <= skb->data
/* If so, compare... */
&& ((memcmp(eth_hdr(skb)->h_source, info->srcaddr, ETH_ALEN)
== 0) ^ info->invert));
}

in net/bridge/br_stp_bpdu.c, br_send_bpdu has:
memcpy(skb->mac.raw, bridge_ula, ETH_ALEN);
memcpy(skb->mac.raw+ETH_ALEN, dev->dev_addr, ETH_ALEN);

are only ethernet bridges supported? I guess so... even the bluetooth 
stuff presumes ETH_ALEN
All I can say is "wow"


I was planning to do things "properly" and use skb->input_dev (or do I 
need skb->dev or skb->realdev?)

skb->input_dev->type
will refer (strangely to) one of the ARP types in linux/if_arp.h with me 
being interested in ARPHRD_ETHER among others.

Mac address length will be
skb->input_dev->addr_len

However, to get at a source mac address is still uncertain, maybe I need 
to dispatch to a different routine or different offsets based on 
input_dev->type ?
There doesn't seem to be a standard way to access mac addresses from 
link layer packets (arp stuff must know how to) which perhaps is why I 
can't find one, and everyone is doing what I did at first and presuming 
ethernet.

For ethernet, skb->mac.raw points to:
struct ethhdr {
unsigned char h_dest[ETH_ALEN]; /* destination eth addr */
unsigned char h_source[ETH_ALEN]; /* source ether addr */
unsigned short h_proto; /* packet type ID field */
} __attribute__((packed));

and the source address is had from 
(skb->mac.raw)+(skb->input_dev->addr_len), but does it follow that the 
same rules work for token ring or other network types. For ethernet it 
comes straight from the headers.

Does anyone know without looking how "ifconfig" works out how to format 
the mac address? (Not that it will help me work out what the source mac 
address is for a given skb, but I'm looking for how to generate a 
standard textual representation based on dev->addr_len and skb->mac.raw).

Amin

Re: wow, why does everything presume ethernet? Re: skb->mac.raw, when is does it point to ethhdr

[Henrik Nordstrom]

On Fri, 29 Apr 2005, Amin Azez wrote:

> However, to get at a source mac address is still uncertain, maybe I need to 
> dispatch to a different routine or different offsets based on input_dev->type 
> ?

You need to know each and every link layer you need to support.

The link layer part of the packet isn't supposed to be accessed outside of 
the link layer, so this isn't made easy.

> Does anyone know without looking how "ifconfig" works out how to format the 
> mac address?

If I am not wrong it simply hexdumps it with : between the octets. Length 
is known. But there may be special cases for some link layers.. see the 
source to make be sure. iproute just hext dumps it with :.

Regards
Henrik

Re: wow, why does everything presume ethernet? Re: skb->mac.raw, when is does it point to ethhdr

[Amin Azez]

Henrik Nordstrom wrote:

> On Fri, 29 Apr 2005, Amin Azez wrote:
>
>> However, to get at a source mac address is still uncertain, maybe I 
>> need to dispatch to a different routine or different offsets based on 
>> input_dev->type ?
>
> You need to know each and every link layer you need to support.
> The link layer part of the packet isn't supposed to be accessed 
> outside of the link layer, so this isn't made easy.
>
>> Does anyone know without looking how "ifconfig" works out how to 
>> format the mac address?
>
> If I am not wrong it simply hexdumps it with : between the octets. 
> Length is known. But there may be special cases for some link layers.. 
> see the source to make be sure. iproute just hext dumps it with :.

Hmm. You can guess what's coming next. MAC addresses are important in 
many filtering or logging scenarios. We've already gone past the point 
where we should have been using some formal method to extract the link 
layer addresses from the link layer header. I'm suggesting we introduce 
such a method in a way that it can be trivially added to each link layer 
once the information is available and where it is obvious for a link 
layer where that information is not available.

1) My first idea is extra fields in the device structure net_device. 
There are so few instances of this structure allocated I think we can 
afford the usage.
These will indicate the offset within the raw link layer packet header 
of the source and dest mac addresses. Together with net_device->addr_len 
this makes it simple and inexpensive to extract mac addresses as 
required. A value of -1 would indicate that these values are not 
available for a given network device.
This would be unsuitable if the mac addresses do not have fixed length 
or do not sit at the same header offset each time.

2) The link-layer code would fill in two pointers to the mac addresses 
in similar manner to sk_buff->mac.raw . If the mac length is not fixed 
then two slots must also exist to hold the length of each mac address. 
It may be cheap for most transports to fill in these two pointers, but 
as a per-packet operation it should perhaps only be enabled if netfilter 
is activated in the kernel configuration?

3) The final idea which I hope we don't need is to provide a callback 
address in net_device that may be applied to an sk_buff to extract out 
the mac addresses. This moves all expense to the instants that the mac 
addresses are needed, but makes the operations more expensive.

My suggestion is to take the first idea and move to the second (and 
<sob> third) if required.

Because the net_device is available from the skb, the functionality can 
be encapsulated in a macro or inline function in such a way as to 
survive any rework of the implementation. Perhaps these 6 functions:
get_src_mac_address(skb);
get_src_mac_address_len(skb);
copy_src_mac_address(dst,skb);
get_dst_mac_address(skb);
get_dst_mac_address_len(skb);
copy_dst_mac_address(dst,skb);

Amin