On Mon, Apr 28, 2008 at 01:57:54PM -0700, Stephen Hemminger wrote:
I looked at this, and thought about cleaning it up and putting in
next release but right now can't see how it could work with
vlan accelerated hardware.
¿Did you see my last mail? I made the cleaning up you suggested and
Your patch doesn't work if hardware does vlan acceleration. Vlan
acceleration
strips the tag off so skb-data points to actual contents and tag is passed
up to vlan_receive_skb out of band. By the time the bridge sees the packet
the
actual tag is gone.
Yes, I know. However, AFAIK
I've been trying to get something like that to work for over a year now.
It mostly works, only the bridge will stop forwarding some arp replies
coming in from a non-vlan interface to the trunk. Bridge sees the
replies but they never make it onto the wire. If this was an STP (it's
not
be useful.
Regards,
Jaime.
---
Subject: [PATCH] Add vlan id to bridge forward database
This makes forwarding table aware of 802.1Q vlan ids and stores
id with MACs in the table. Up to two vlan tags are handled.
It solves problems when having same MAC on diffent pairs
(vlan, port). Current
On Mon, Mar 17, 2008 at 11:35:37AM -0700, Stephen Hemminger wrote:
Minor stuff:
1. Please use shorter variable names, rather than:
unsigned short vlan_first_id;
I would choose:
u16 vlan1;
Done.
2. You probably can use skb-protocol rather than having to
On Mon, 28 Jan 2008 16:39:14 +0100
Jaime Medrano [EMAIL PROTECTED] wrote:
I'm resending this mail since I got no answer.
Is there any major problem in this?
Stephen Hemminger wrote:
What about the nested vlan case?
Below is a new patch that handles the double-tagging case. I'm not
?
This is a user/kernel ABI change. Does it break old tools?
New patch gets rid of the unused field but it still doesn't break old tools.
Anyway, the user part is not really needed. I just think it could be useful.
Regards,
Jaime.
---
Subject: [PATCH] Add vlan id to bridge forward database
