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

[Amin Azez <azez@ufomechanic.net>]

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