# [S] VLAN<-bridge->ethernet not working, strange mac addr.

## hexa

Hi there,

i had to set up a bridge betwen normal ethernet and VLAN(802.1q i think). I have no problem setting it up but the Gentoo powered Router/FW/Bridge decided it will change MAC Addresses to something strange when bridgind these two networks together so i think there probably is a bug in gentoo-sources and vanilla-sources kernels.

I'll try to stay brief. This is my test environment:

A: Notebook OSX (192.168.25.10/24)   MAC: 0:d:93:32:62:0

                      \/

B: PC Linux 2.6.15.1vanilla-sources (br0(eth1,vlan3)/192.168.25.100/24)  MAC(br0): 0:8:c7:d:d5:59

                      \/

C: PC Linux 2.6gentoo-sources (vlan3/192.168.25.11/24)  MAC(vlan3): 0:1:2:95:db:12

If I ping from host B i can reach both A and B no problems, from A i can reach B just fine and from C I can reach B also. Now here is the interesting bit:

When i try to reach (e.g. ping) from A to C i get a response from C but it comes from and is destined to some XY MAC address so A doesn't recognize the response. Here is what tcpdump shows on host A:

ho-2:~ root# tcpdump -i en0 -n -e

#arp who has for B = O.K.

16:35:56.288636 00:0d:93:32:62:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 192.168.25.100 tell 192.168.25.10

#arp is at for B = O.K.

16:35:56.288853 00:08:c7:0d:d5:59 > 00:0d:93:32:62:00, ethertype ARP (0x0806), length 68: arp reply 192.168.25.100 is-at 00:08:c7:0d:d5:59

#ping A -> B = O.K.

16:35:56.288880 00:0d:93:32:62:00 > 00:08:c7:0d:d5:59, ethertype IPv4 (0x0800), length 98: IP 192.168.25.10 > 192.168.25.100: icmp 64: echo request seq 0

16:35:56.289423 00:08:c7:0d:d5:59 > 00:0d:93:32:62:00, ethertype IPv4 (0x0800), length 102: IP 192.168.25.100 > 192.168.25.10: icmp 64: echo reply seq 0

#arp who has for C = O.K.

16:36:28.993116 00:0d:93:32:62:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 192.168.25.11 tell 192.168.25.10

#arp reply from C thru B to A

#WTF??? look at the source and dest addresses, 

#they don't even match ARP reply from inside the same packet!

16:36:28.993592 db:12:81:00:00:03 > 62:00:00:01:02:95, ethertype ARP (0x0806), length 68: arp reply 192.168.25.11 is-at 00:01:02:95:db:12

You can clearly see that ARP reply is O.K, but the ethernet address (MAC) from which it's comming from and to which it's destined are just off, eg. repy to A's arp-who-has request comes from strange MAC and more strangely it's destined for another strange non/existent MAC addr. (to 62:00:00:01:02:95 instead to 00:0d:93:32:62:00). If i take a closer look it looks like it's made of parts from hosts A and C MAC addresses. A bug? It works the same (e.g. wrong  :Wink:  if i run vanilla-sources or gentoo-sources on host B.

You can try and reproduce this problem and i'm sure you will, but if i don't get a solution soon i guess i'll just go and have to install BSD (damn!!) to make it work. I hope some one will do that and contact kernel developers  :Wink:  BTW bridging betwen normal ethernets works just fine  :Wink: 

Here is just a little snippet from my net config on how i set up nets on B:

--

#cause we set it on bridge:

config_eth1=( "null" )

#cause we set it on bridge or vlan:

config_eth2=( "null" )

# Specify the VLAN numbers for the interface like so

# Please ensure your VLAN IDs are NOT zero-padded

vlans_eth2="3 25"

#format of vlan if name

vconfig_eth2=( "set_name_type VLAN_PLUS_VID_NO_PAD" )

#ethernet headers 1=go around ethX

vconfig_vlan3=( "set_flag 1" )

vconfig_vlan25=( "set_flag 1" )

#other options like this

#vconfig_vlan1=( "set_flag 1" "set_egress_map 2 6" )

# Configure the interface as usual

#3 = 25/24

#config_vlan3=( "192.168.25.100 netmask 255.255.255.0 brd 192.168.25.255" )

config_vlan3=( "null")

#25 = 74/24

config_vlan25=( "192.168.74.13 netmask 255.255.255.0 brd 192.168.74.255" )

#config_vlan25=( "null" )

# Bridging (802.1d)

# To add ports to bridge br0

bridge_br0="eth1 vlan3"

# You need to configure the ports to null values so dhcp does not get started

#config_ethX=( "null" )

#config_vlanX=( "null" )

# Finally give the bridge an address - dhcp or a static IP

config_br0=( "192.168.25.100/24" )

depend_br0() {

       need net.eth2 net.eth1

}

# Below is an example of configuring the bridge

# Consult "man brctl" for more details

#brctl_br0=( "setfd 0" "sethello 0" "stp off" )

brctl_br0=( "stp off" )

--

Something more simpler is on host C.Last edited by hexa on Sat Mar 11, 2006 11:59 am; edited 1 time in total

----------

## widan

```
16:36:28.993592 db:12:81:00:00:03 > 62:00:00:01:02:95, ethertype ARP (0x0806), ...
```

The beginning of the mangled frame looks like this:

 *Quote:*   

> 62 00 00 01 02 95 db 12 81 00 00 03 08 06 ...

 

There is the end of the destination MAC, the source MAC, but shifted 4 bytes, and a VLAN tag (ethertype 0x8100 for 802.1q tagging, and VID is set to 3, which matches the fact you're using VLAN 3). But B should have removed the tag...

Assuming VLAN packets are de-tagged by moving the MAC addresses 4 bytes forward (which makes more sense than moving the rest of the packet 4 bytes backwards) and adding 4 to the pointer indicating the start address of the packet in memory, that would mean that the mangled frame had the pointer incremented, but the start of the header was not copied... weird.

----------

## hexa

I want to notify Stephen Hemminger (<shemmingerATosdl.org>) since he is the developer of bridging code so i signed up on his mailing list bridge@lists.osdl.org, but i still haven't beed approved yet. If they don't I'll just mail directly to him.

----------

## widan

Maybe you could try this (from the man page of vconfig) and see if it packets are received normally with it:

```
set_flag [vlan-device] 0 | 1

       When  1,  ethernet  header  reorders  are turned on. Dumping the

       device will appear as a common ethernet  device  without  vlans.

       When  0 (default)  however,  ethernet  headers are not reordered,

       which results in vlan tagged packets when  dumping  the  device.

       Usually the default gives no problems, but some packet filtering

       programs might have problems with it.
```

What it does is that:

```
/* Lifted from Gleb's VLAN code... */

memmove(skb->data - ETH_HLEN,

        skb->data - VLAN_ETH_HLEN, 12);

skb->mac.raw += VLAN_HLEN;
```

It actually moves the 12 bytes of the MAC addresses to overwrite the tag, rather than just updating the pointer to the payload. Maybe it will help. You set it like that (the man page is wrong about the syntax, but the help text in vconfig is right):

```
vconfig set_flag vlan3 1 1
```

The first "1" is the flag number (REORDER_HDR), and the second "1" is the value (enable or disable).

----------

## hexa

I'll try and do that when i set up the environment again.

I'll let you know if it works, althou i doubt it since i'm setting this on vlan3 and i think the problem is that vlan tag exists when a packet leaves for normal ethernet on eth1 (part of br0).

We'll see  :Wink:  Tanx for help!

----------

## hexa

Widan you are the man!

Your sudgestion worked! Thank you very mutch for pointing that documentation bug out.

----------

## [Lx]-=Mystify=-

I don't f.......... believe it....

the documentation bug is known for 2 years and not fixed yet...

I had the same problem, spend a lot of time troubleshooting it. I found the reason, and now discover that it's already known...

who can I contact on that???

----------

## hexa

Believe it my friend.  :Smile: 

Seems not lot's of people do bridging between VAN and LAN.

You can probably contact kernel developers.  :Smile: 

----------

