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->...
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