On Mon, 2011-08-08 at 22:11 +0100, Dick Middleton wrote:
> Package: linux-2.6
> Version: 2.6.39-3
> Severity: normal
> File: tg3
>
>
> There's 2 problems here really. I suspect they're related.
>
> 1) bridging using tg3 interface and adding a tap to it causes the mac
> address to change from the real mac to the pseudo mac of the tap
> interface.
> If tap is removed from the bridge the mac reverts. This confuses arp
> and dhcp no end!
Nevertheless, this is the intended behaviour. The MAC address of the
bridge is the lowest MAC address of all its member devices, unless an
address has been manually assigned to it, e.g.:
ip link set dev br0 address 12:34:56:78:9a:bc
(All MAC addresses with 2, 6, a or e as the second digit are available
for local assignment.)
[...]
> The second problem concerns the vlan attached to this interface.
> Normally one would attach the vlan to the real interface eth0.
> However if you do this doesn't pass traffic.
[...]
You cannot use both a VLAN sub-device and a bridge attached to the same
device. This used to work for devices with VLAN tag extraction offload,
as the network stack would check for VLAN sub-devices before bridge
membership when processing received packets; but for other devices it
would check for bridge membership first. But this was not intentional,
and now the network stack always checks for bridge membership first.
I realise this behaviour is not ideal. The kernel ought to refuse to
attach both a VLAN sub-device and a bridge at the same time. It should
also support an unmatched-VLAN sub-device, so you can attach *that* to a
bridge and achieve the result you had before.
If you want to discuss the behaviour and argue for a change, write to
the bridge mailing list <bridge@lists.linux-foundation.org>.
Ben.
Attachment:
signature.asc
Description: This is a digitally signed message part