search for: skb_share_check

...03-02-25 15:23:09.000000000 >+0100 >+++ linux-2.4/net/8021q/vlan_dev.c 2003-10-07 16:01:29.000000000 +0200 >@@ -75,7 +75,12 @@ > static inline struct sk_buff *vlan_check_reorder_header(struct sk_buff >*skb) > { > if (VLAN_DEV_INFO(skb->dev)->flags & 1) { >- skb = skb_share_check(skb, GFP_ATOMIC); >+ if (skb_shared(skb) || skb_cloned(skb)) { >+ struct sk_buff *nskb; >+ nskb = skb_copy(skb, GFP_ATOMIC); >+ kfree_skb(skb); >+ skb = nskb; >+ } > if (skb) { > /* Lifted from Gleb's VLAN code... */ > memmove(skb->data - ETH_HLEN...

...finish, 1); @@ -220,13 +247,20 @@ static unsigned int br_nf_pre_routing(un { struct iphdr *iph; __u32 len; - struct sk_buff *skb; + struct sk_buff *skb = *pskb; struct nf_bridge_info *nf_bridge; - if ((*pskb)->protocol != __constant_htons(ETH_P_IP)) - return NF_ACCEPT; - - if ((skb = skb_share_check(*pskb, GFP_ATOMIC)) == NULL) + if (skb->protocol != __constant_htons(ETH_P_IP)) { + struct vlan_ethhdr *hdr = (struct vlan_ethhdr *) + ((*pskb)->mac.ethernet); + + if (!IS_VLAN_IP) + return NF_ACCEPT; + if ((skb = skb_share_check(*pskb, GFP_ATOMIC)) == NULL) + goto out; + skb_pu...

>-----Original Message----- >From: Ben Greear [mailto:greearb@candelatech.com] >Sent: Monday, October 06, 2003 10:24 PM >To: Bart De Schuymer >Cc: netdev@oss.sgi.com; vlan@wanfear.com; bridge >Subject: [VLAN] Re: [PATCH/RFC] Let {ip,arp}tables "see" bridged VLAN >tagged{I,AR}P packets > > >Bart De Schuymer wrote: >> - add some code in

This is based on an earlier patch from Eric Biederman adding forwarding between macvlans. I extended his approach to allow the administrator to choose the mode for each macvlan, and to implement a functional VEPA between macvlan. Still missing from this is support for communication between the lower device that the macvlans are based on. This would be extremely useful but as others have found out

This is based on an earlier patch from Eric Biederman adding forwarding between macvlans. I extended his approach to allow the administrator to choose the mode for each macvlan, and to implement a functional VEPA between macvlan. Still missing from this is support for communication between the lower device that the macvlans are based on. This would be extremely useful but as others have found out

This is based on an earlier patch from Eric Biederman adding forwarding between macvlans. I extended his approach to allow the administrator to choose the mode for each macvlan, and to implement a functional VEPA between macvlan. Still missing from this is support for communication between the lower device that the macvlans are based on. This would be extremely useful but as others have found out

Second version, all feedback so far addressed, thanks for the help and interest! The patch to iproute2 has not changed, so I'm not including it this time. Patch 4/4 (the netlink interface) is basically unchanged as well but included for completeness. The other changes have moved forward a bit, to the point where I find them a lot cleaner and am more confident in the code being ready for

Second version, all feedback so far addressed, thanks for the help and interest! The patch to iproute2 has not changed, so I'm not including it this time. Patch 4/4 (the netlink interface) is basically unchanged as well but included for completeness. The other changes have moved forward a bit, to the point where I find them a lot cleaner and am more confident in the code being ready for

Second version, all feedback so far addressed, thanks for the help and interest! The patch to iproute2 has not changed, so I'm not including it this time. Patch 4/4 (the netlink interface) is basically unchanged as well but included for completeness. The other changes have moved forward a bit, to the point where I find them a lot cleaner and am more confident in the code being ready for

Not many changes this time, just integrated a bug fix and all the coding style feedback from Eric Dumazet and Patrick McHardy. I'll keep the patch for network namespaces on the tx path out of this series for now, because the discussion is still ongoing and it addresses an unrelated issue. --- Version 2 description: The patch to iproute2 has not changed, so I'm not including it this

Not many changes this time, just integrated a bug fix and all the coding style feedback from Eric Dumazet and Patrick McHardy. I'll keep the patch for network namespaces on the tx path out of this series for now, because the discussion is still ongoing and it addresses an unrelated issue. --- Version 2 description: The patch to iproute2 has not changed, so I'm not including it this

Not many changes this time, just integrated a bug fix and all the coding style feedback from Eric Dumazet and Patrick McHardy. I'll keep the patch for network namespaces on the tx path out of this series for now, because the discussion is still ongoing and it addresses an unrelated issue. --- Version 2 description: The patch to iproute2 has not changed, so I'm not including it this

Dear Sir, I was trying to install bridge as we are installing scps gateway in our testbed.This requires us to install the bridge. Our Linux version is 2.4.18 ~3 and we are using redhat 7.2 Please let me know which is the bridge I should install and how to configure it. Before configuring the bridge what I should check in my configuration. Thanks for your time, Sincerely Rama ===== I hear

This series of patches provides an ability to add VLANs to the bridge ports. This is similar to what can be found in most switches. The bridge port may have any number of VLANs added to it including vlan 0 priority tagged traffic. When vlans are added to the port, only traffic tagged with particular vlan will forwarded over this port. Additionally, vlan ids are added to FDB entries and become