[B.A.T.M.A.N.] encapsulated ethernet frame format

[B.A.T.M.A.N.] encapsulated ethernet frame format

[Berat]

[-- Attachment #1.1: Type: text/plain, Size: 1113 bytes --]

Hi,

I was trying to understand how batman-adv encapsulates ethernet frames.
Batman dissector of wireshark, shows an ethernet II section, then a
batman section, then again an ethernet II section. Is this
rappresentation respects the original capsulated header format? I
couldn't find a scheme that shows fields of an encapsulated header in
the documentation. So with wireshark, it tells me something like that:

-----------------------------------------------------------------------
Dst.Mac|Src.Mac|Type|Packt Type|Version|TTL|Seq.No|Dst.Mac|Src.Mac|Type
-----------------------------------------------------------------------
\___________________/\____________________________/\__________________/
   First Ethernet 	   Batman Section	     Second Ethernet
    II Section  					II Section


Why there are two times destination and source mac addresses? I want to
retrieve mac addresses of originators of packets by working on raw
packet data. But i'm a little bit confused with this scheme. Sorry if
it's a banal question, i don't have much experience with networking.
Thanks for any help.

[-- Attachment #1.2: 0x9763E522.asc --]
[-- Type: application/pgp-keys, Size: 13764 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [B.A.T.M.A.N.] encapsulated ethernet frame format

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 2170 bytes --]

Hi Berat,

yes this is expected:
 * the first Ethernet section is required for WiFi (or Ethernet) to send the 
packet on the physical link between two neighbors - this will change with 
every hop taken in the mesh
 * The batman section includes a couple of control fields and also source and 
destination (at least for unicast packets). These sources and destinations are 
for the originators, that is mesh nodes within the mesh, which may be a couple 
of hops away
 * Finally, the second Ethernet section contains source and destination of the 
devices which are actually talking to - these devices are not necessarily mesh 
nodes, but might be devices only bridge into the batman-adv mesh network. 
batman-adv takes these Ethernet frames as they are and encapsulates them by 
adding its own batman section and the per-hop first ethernet section as you 
saw.

So if you want to work on the "originator" layer, have a look at the batman 
section source/destinations.

Cheers,
    Simon

On Wednesday 22 July 2015 16:59:37 Berat wrote:
> Hi,
> 
> I was trying to understand how batman-adv encapsulates ethernet frames.
> Batman dissector of wireshark, shows an ethernet II section, then a
> batman section, then again an ethernet II section. Is this
> rappresentation respects the original capsulated header format? I
> couldn't find a scheme that shows fields of an encapsulated header in
> the documentation. So with wireshark, it tells me something like that:
> 
> -----------------------------------------------------------------------
> Dst.Mac|Src.Mac|Type|Packt Type|Version|TTL|Seq.No|Dst.Mac|Src.Mac|Type
> -----------------------------------------------------------------------
> \___________________/\____________________________/\__________________/
>    First Ethernet 	   Batman Section	     Second Ethernet
>     II Section  					II Section
> 
> 
> Why there are two times destination and source mac addresses? I want to
> retrieve mac addresses of originators of packets by working on raw
> packet data. But i'm a little bit confused with this scheme. Sorry if
> it's a banal question, i don't have much experience with networking.
> Thanks for any help.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [B.A.T.M.A.N.] encapsulated ethernet frame format

[Berat]

[-- Attachment #1.1: Type: text/plain, Size: 1402 bytes --]

Thanks a lot for the answer. (Sorry, i didn't realized that i was
replying to you instead of mailing list.) There is an ultimate point
that i would like to understand. If you can help me it would be great.

So, to see if i've got it right, i made this little simulation of the
traffic:



C1 	    C3	 	 C4
 \ 	     |		/
  N1 - N2 - N3 - N4 - N5
 / 			\
C2 			C5




Client C1 communicates with client C5, and i'm intercepting packets that
are passing through node N3 and i see a unicast packet at the moment;

the first ethernet II section has:
source mac -> mac of N2
dest. mac -> mac of N3
----------------------------
batman section has:
dest. mac -> mac of N5
//here i see source mac only for batadv_unicast_4addr packets,
//which are ARP requests. for all other packet types, including
//dns request which is a unicast packet, there is only destination
//(or originator if a broadcast packet)
----------------------------
the second ethernet II section has:
source mac -> mac of C1
dest. mac -> mac of C5


So if i got it right, i would like to deduce, if a computer that i see
by the packet that i intercept is local(connected to the antenna that
i'm intercepting) or packet is just switched/forwarded by this antenna.
But without that source mac information in batman section, it doesn't
seem possible to me. Can i deduce it without that information?


[-- Attachment #1.2: 0x9763E522.asc --]
[-- Type: application/pgp-keys, Size: 13764 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [B.A.T.M.A.N.] encapsulated ethernet frame format

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 1917 bytes --]

Hi Berat,

please see below.
On Thursday 23 July 2015 17:47:23 Berat wrote:
> Thanks a lot for the answer. (Sorry, i didn't realized that i was
> replying to you instead of mailing list.) There is an ultimate point
> that i would like to understand. If you can help me it would be great.
> 
> So, to see if i've got it right, i made this little simulation of the
> traffic:
> 
> 
> 
> C1 	    C3	 	 C4
>  \ 	     |		/
>   N1 - N2 - N3 - N4 - N5
>  / 			\
> C2 			C5
> 
> 
> 
> 
> Client C1 communicates with client C5, and i'm intercepting packets that
> are passing through node N3 and i see a unicast packet at the moment;
> 
> the first ethernet II section has:
> source mac -> mac of N2
> dest. mac -> mac of N3
> ----------------------------
> batman section has:
> dest. mac -> mac of N5
> //here i see source mac only for batadv_unicast_4addr packets,
> //which are ARP requests. for all other packet types, including
> //dns request which is a unicast packet, there is only destination
> //(or originator if a broadcast packet)

Right, only the 4addr actually shows the source.

> ----------------------------
> the second ethernet II section has:
> source mac -> mac of C1
> dest. mac -> mac of C5
> 
> 
> So if i got it right, i would like to deduce, if a computer that i see
> by the packet that i intercept is local(connected to the antenna that
> i'm intercepting) or packet is just switched/forwarded by this antenna.
> But without that source mac information in batman section, it doesn't
> seem possible to me. Can i deduce it without that information?

You could try to look at the TTL in the batman-adv header - its decremented on 
each hop, so you could find out the first one. Another way would be to check the 
second ethernet II header and see if the source in the local table - although 
there are some corner cases where this may be incorrect (e.g. when the client 
roams).

Cheers,
     Simon

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]