search for: packet_host

Displaying 18 results from an estimated 18 matches for "packet_host".

2009 Nov 24
4
[Bridge] [PATCHv2 0/4] macvlan: add vepa and bridge mode
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
2009 Nov 24
4
[Bridge] [PATCHv2 0/4] macvlan: add vepa and bridge mode
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
2009 Nov 24
4
[Bridge] [PATCHv2 0/4] macvlan: add vepa and bridge mode
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
2009 Nov 26
5
[Bridge] [PATCHv3 0/4] macvlan: add vepa and bridge mode
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
2009 Nov 26
5
[Bridge] [PATCHv3 0/4] macvlan: add vepa and bridge mode
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
2009 Nov 26
5
[Bridge] [PATCHv3 0/4] macvlan: add vepa and bridge mode
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
2007 Apr 18
1
[Bridge] A question about modify bridge source
...tif_start_queue(&br->dev); ethdev = dev_get_by_name("eth0"); ethdev->br_port = (struct net_bridge_port *)br; dev_set_promiscuity(ethdev,1); dev_hold(ethdev); return br; } static void Bridge_passup(struct sk_buff *skb) { skb->dev = &brg->dev; skb->pkt_type = PACKET_HOST; skb_push(skb,ETH_HLEN); skb->protocol = eth_type_trans(skb,&brg->dev); netif_rx(skb); return; } void Bridge_dev_setup(struct net_device *dev) { unsigned char dd[6] = {0x12,0x12,0x12,0x12,0x12,0x12}; memcpy(dev->dev_addr,dd,ETH_ALEN); dev->do_ioctl = NULL; dev->get_stats...
2009 Nov 17
11
[Bridge] [PATCH 0/3] macvlan: add vepa and bridge mode
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
2009 Nov 17
11
[Bridge] [PATCH 0/3] macvlan: add vepa and bridge mode
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
2009 Nov 17
11
[Bridge] [PATCH 0/3] macvlan: add vepa and bridge mode
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
2007 Apr 18
4
[Bridge] [PATCH/RFC] Let {ip, arp}tables "see" bridged VLAN tagged {I, AR}P packets
...h_vlan_encapsulated_proto == __constant_htons(ETH_P_ARP)) + /* We need these fake structures to make netfilter happy -- * lots of places assume that skb->dst != NULL, which isn't * all that unreasonable. @@ -135,8 +147,13 @@ static int br_nf_pre_routing_finish_brid skb->pkt_type = PACKET_HOST; skb->nf_bridge->mask |= BRNF_PKT_TYPE; } + skb->nf_bridge->mask ^= BRNF_NF_BRIDGE_PREROUTING; skb->dev = bridge_parent(skb->dev); + if (skb->protocol == __constant_htons(ETH_P_8021Q)) { + skb_pull(skb, VLAN_HLEN); + skb->nh.raw += VLAN_HLEN; + } skb->dst-&gt...
2010 Jan 27
9
[Bridge] [PATCH 0/3 v3] macvtap driver
This is the third version of the macvtap device driver, following another major restructuring and a lot of bug fixes: * Change macvtap to be based around a struct sock * macvtap: fix initialization * return 0 to netlink * don't use rcu for q->file and q->vlan pointers * macvtap: checkpatch.pl fixes * macvtap: fix tun IFF flags * Use a struct socket to make tx flow control work * disable
2010 Jan 27
9
[Bridge] [PATCH 0/3 v3] macvtap driver
This is the third version of the macvtap device driver, following another major restructuring and a lot of bug fixes: * Change macvtap to be based around a struct sock * macvtap: fix initialization * return 0 to netlink * don't use rcu for q->file and q->vlan pointers * macvtap: checkpatch.pl fixes * macvtap: fix tun IFF flags * Use a struct socket to make tx flow control work * disable
2010 Jan 27
9
[Bridge] [PATCH 0/3 v3] macvtap driver
This is the third version of the macvtap device driver, following another major restructuring and a lot of bug fixes: * Change macvtap to be based around a struct sock * macvtap: fix initialization * return 0 to netlink * don't use rcu for q->file and q->vlan pointers * macvtap: checkpatch.pl fixes * macvtap: fix tun IFF flags * Use a struct socket to make tx flow control work * disable
2009 Dec 03
3
[RFC 0/2] macvtap, second try
I did not get this ready for the merge window, but people asked what the status of this is so I'm posting it now to solicit feedback. The first patch just adds some hooks into macvlan.c and is less invasive than the previous version. That part should be fine and I'd like this to get merged into macvlan for 2.6.33 if people agree that the approach is right. The second patch adds the
2009 Dec 03
3
[RFC 0/2] macvtap, second try
I did not get this ready for the merge window, but people asked what the status of this is so I'm posting it now to solicit feedback. The first patch just adds some hooks into macvlan.c and is less invasive than the previous version. That part should be fine and I'd like this to get merged into macvlan for 2.6.33 if people agree that the approach is right. The second patch adds the
2009 Dec 03
3
[RFC 0/2] macvtap, second try
I did not get this ready for the merge window, but people asked what the status of this is so I'm posting it now to solicit feedback. The first patch just adds some hooks into macvlan.c and is less invasive than the previous version. That part should be fine and I'd like this to get merged into macvlan for 2.6.33 if people agree that the approach is right. The second patch adds the
2011 Jan 12
72
PCI passthrough issue
Hello, I''m facing a strange issue with network card PCI passthrough on my openwrt test domU. - With network PCI passthrough, DNS lookup failed for some domains (exemple, google.com) but not for other (free.fr my ISP, or my domain jbfavre.org). I can ping an IP address without any problem. - Starting domU as a "normal" (ie without PCI passthrough), no problem. As far as I can