headers
Harald Dunkel | 4 Nov 2009 14:42
Picon
Favicon

bridge on bonding interface: DHCP replies don't get through

Hi folks,

I would like to run a bridge for kvm on a bonding interface
(4 * 1Gbit, Intel e1000e). Problem: The DHCPDISCOVER packets
sent by the guest show up on my dhcp server as expected, but
the DHCPOFFER sent as a reply doesn't reach the guest behind
the bridge.

Using tcpdump on host and guest I can see the DHCPOFFER on
the bond0 and br0 interface, but it never shows up on vnet0
or on the guest's eth0.

If I drop the bonding interface and use the host's eth2 for
the bridge instead, then there is no such problem.

Kernel on host and guest is 2.6.31.5. Below you can find more
information about my setup. I had sent this information to the
linux kvm mailing list before, but consensus was that this is
a bridging problem. See

	http://www.spinics.net/lists/kvm/msg25153.html

Would it be possible to track this problem down? Any helpful
comment would be highly appreciated.

Many thanx

Harri
====================================================================
# brctl show
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jon Lewis | 4 Nov 2009 16:00

ebtables counters bug

I posted this yesterday to the netfilter list, but I'm not sure that was 
the right list for this issue.  I seem to have [re]discovered a bug very 
similar to if not the same as
http://osdir.com/ml/linux.network.bridge.ebtables.devel/2003-06/msg00002.html

According to the mailing list archive, that bug was fixed in 2003...but 
either it wasn't, or it's been reintroduced.

I'm using ebtables-v2.0.9-1.tar.gz with CentOS 5.3
2.6.18-164.el5xen #1 SMP Thu Sep 3 04:03:03 EDT 2009 x86_64 x86_64 x86_64 
GNU/Linux

Using ebtables, I've setup a number of user-defined chains.  In the INPUT and 
FORWARD chains, I have rules to jump to these user-defined chains.

I've noticed that any change (adding or deleting a rule) to any chain (at 
least the INPUT, FORWARD, or any other user-defined one) causes the counters 
for the last user-defined chain to be reset to 0's.  Creating a new 
user-defined chain does not seem to affect counters.  Deleting that new 
user-defined chain does reset the counters in the last 
remaining user-defined chain.

I just verified the same behavior on a RHEL 5.4 system running
2.6.18-164.2.1.el5 #1 SMP Mon Sep 21 04:37:42 EDT 2009 x86_64 x86_64 x86_64 
GNU/Linux
with

Name        : ebtables                     Relocations: (not relocatable)
Version     : 2.0.8.2                           Vendor: Dag Apt Repository, 
http://dag.wieers.com/apt/
(Continue reading)

Permalink | Reply | 3 comments |
headers
Bart De Schuymer | 4 Nov 2009 22:48
Picon

Re: ebtables counters bug

Hi Jon,

Thanks for the report. I've fixed the bug in cvs. A new release will 
follow later.

cheers,
Bart

Jon Lewis schreef:
> I posted this yesterday to the netfilter list, but I'm not sure that was 
> the right list for this issue.  I seem to have [re]discovered a bug very 
> similar to if not the same as
> http://osdir.com/ml/linux.network.bridge.ebtables.devel/2003-06/msg00002.html
>
> According to the mailing list archive, that bug was fixed in 2003...but 
> either it wasn't, or it's been reintroduced.
>
> I'm using ebtables-v2.0.9-1.tar.gz with CentOS 5.3
> 2.6.18-164.el5xen #1 SMP Thu Sep 3 04:03:03 EDT 2009 x86_64 x86_64 x86_64 
> GNU/Linux
>
> Using ebtables, I've setup a number of user-defined chains.  In the INPUT and 
> FORWARD chains, I have rules to jump to these user-defined chains.
>
> I've noticed that any change (adding or deleting a rule) to any chain (at 
> least the INPUT, FORWARD, or any other user-defined one) causes the counters 
> for the last user-defined chain to be reset to 0's.  Creating a new 
> user-defined chain does not seem to affect counters.  Deleting that new 
> user-defined chain does reset the counters in the last 
> remaining user-defined chain.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jon Lewis | 4 Nov 2009 22:58

Re: ebtables counters bug

Cool.  I was going to check out a copy from cvs, but the instructions at
http://ebtables.sourceforge.net/downloads/cvs.html
seem to be out of date, and anonymous access to 
cvs.sourceforge.net:/cvsroot/ebtables is denied.

$ cvs -d:pserver:anonymous <at> cvs.sourceforge.net:/cvsroot/ebtables login
Logging in to :pserver:anonymous <at> cvs.sourceforge.net:2401/cvsroot/ebtables
CVS password:
cvs [login aborted]: connect to [cvs.sourceforge.net]:2401 failed: 
Connection refused

On Wed, 4 Nov 2009, Bart De Schuymer wrote:

> Hi Jon,
>
> Thanks for the report. I've fixed the bug in cvs. A new release will follow 
> later.
>
> cheers,
> Bart
>
> Jon Lewis schreef:
>> I posted this yesterday to the netfilter list, but I'm not sure that was 
>> the right list for this issue.  I seem to have [re]discovered a bug very 
>> similar to if not the same as
>> http://osdir.com/ml/linux.network.bridge.ebtables.devel/2003-06/msg00002.html
>> 
>> According to the mailing list archive, that bug was fixed in 2003...but 
>> either it wasn't, or it's been reintroduced.
>>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jon Lewis | 5 Nov 2009 06:34

Re: ebtables counters bug

On Wed, 4 Nov 2009, Jon Lewis wrote:

> Cool.  I was going to check out a copy from cvs, but the instructions at
> http://ebtables.sourceforge.net/downloads/cvs.html
> seem to be out of date, and anonymous access to 
> cvs.sourceforge.net:/cvsroot/ebtables is denied.
>
> $ cvs -d:pserver:anonymous <at> cvs.sourceforge.net:/cvsroot/ebtables login
> Logging in to :pserver:anonymous <at> cvs.sourceforge.net:2401/cvsroot/ebtables
> CVS password:
> cvs [login aborted]: connect to [cvs.sourceforge.net]:2401 failed: Connection 
> refused

I tried a little harder and figured out the cvs issue.  The instructions 
on the sourceforce web page are outdated.  The cvs server should be 
ebtables.cvs.sourceforge.net.

I just rebuilt ebtables with your patch to communication.c and it seems to 
solve the problem.  Thanks.

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Permalink | Reply | 0 comments |
headers
Jasper Spaans | 10 Nov 2009 16:57

[PATCH] Add upstream debian patches

Hello list,

Debian has had these patches by Santiago Garcia Mantinan for ages [0][1],
and they have not been applied yet.  We're trying to run a 32-bit brctl on a
64-bit system, and got bitten by this.  Can you apply the patches below so
other distributions can also benefit from this?

Thanks,
Jasper

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496491
[1] https://lists.linux-foundation.org/pipermail/bridge/2008-August/006011.html
---
 brctl/brctl.c               |    2 +-
 doc/FAQ                     |    2 +-
 doc/FIREWALL                |    5 ++---
 libbridge/libbridge_devif.c |    2 +-
 4 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/brctl/brctl.c b/brctl/brctl.c
index 454b8dd..79f07b2 100644
--- a/brctl/brctl.c
+++ b/brctl/brctl.c
 <at>  <at>  -69,7 +69,7  <at>  <at>  int main(int argc, char *const* argv)
 	argc -= optind;
 	argv += optind;
 	if ((cmd = command_lookup(*argv)) == NULL) {
-		fprintf(stderr, "never heard of command [%s]\n", argv[1]);
+		fprintf(stderr, "never heard of command [%s]\n", argv[0]);
 		goto help;
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Ames | 10 Nov 2009 19:02
Favicon

Net wiki import to the LF drupal site

Networking working group,

I have an example of the import of the Networking wiki into the LF 
drupal environment:

https://corp-dev.linuxfoundation.org/collaborate/workgroups/networking

Members who join have edit rights to all the pages similar to a wiki.

I have installed a LaTex interpreter so the math capability works with a 
small change you use <tex> rather than <math> tags.

We will put in all the apache redirects so there will be no dead links.

Let me know if there are any changes you need before the import into 
production. And then I will import into the production site on Thursday, 
November 12th if I don't hear anything back.

--
David Ames
Permalink | Reply | 0 comments |
headers
Patrick McHardy | 11 Nov 2009 16:29
Favicon

Re: [PATCH 2/4] macvlan: allow in-kernel modules to create and manage macvlan devices

Patrick Mullaney wrote:
> The macvlan driver didn't allow for creation/deletion of devices
> by other in-kernel modules. This patch provides common routines
> for both in-kernel and netlink based management. This patch
> also enables macvlan device support for gro for lower level
> devices that support gro.

> -static void macvlan_transfer_operstate(struct net_device *dev)
> +void macvlan_transfer_operstate(struct net_device *dev)
>  {
>  	struct macvlan_dev *vlan = netdev_priv(dev);
>  	const struct net_device *lowerdev = vlan->lowerdev;
>  <at>  <at>  -458,6 +458,7  <at>  <at>  static void macvlan_transfer_operstate(struct net_device *dev)
>  			netif_carrier_off(dev);
>  	}
>  }
> +EXPORT_SYMBOL_GPL(macvlan_transfer_operstate);

I think this function could be moved to net/core/dev.c or
net/core/link_watch.c. The VLAN code has an identical copy.

> -int macvlan_newlink(struct net_device *dev,
> -		    struct nlattr *tb[], struct nlattr *data[])
> +int macvlan_link_lowerdev(struct net_device *dev,
> +						  struct net_device *lowerdev)

Please indent this more cleanly.

>  {
>  	struct macvlan_dev *vlan = netdev_priv(dev);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrick McHardy | 11 Nov 2009 16:36
Favicon

Re: [PATCH 4/4] venet-macvlan: add new driver to connect a venet to a macvlan netdevice

Patrick Mullaney wrote:
> This driver implements a macvlan device as a venet device that can
> be connected to vbus. Since it is a macvlan device, it provides
> a more direct path to the underlying adapter by avoiding the
> bridge.

> --- /dev/null
> +++ b/kernel/vbus/devices/venet/macvlan.c
> ...
> +struct venetmacv {
> +	struct macvlan_dev mdev;
> +	unsigned char ll_ifname[IFNAMSIZ];
> +	struct venetdev dev;
> +	const struct net_device_ops *macvlan_netdev_ops;
> +};

macvlan might destroy the device below you when the underlying
device is unregistered. You need to handle this by releasing
the venetmacv device. Check out the NETDEV_UNREGISTER case in
macvlan_device_event().
Permalink | Reply | 0 comments |
headers
Patrick Mullaney | 10 Nov 2009 23:27
Picon
Favicon

[PATCH 0/4] vbus: venet macvlan support

(Applies to alacrityvm.git/master:34534534)

This patchset implements a vbus venet device with a
macvlan backend.

These patches allow an alacrityvm guest to send and receive
directly over a macvlan, avoiding the bridge entirely.
This driver inherits all of the benefits of the work done
to date on vbus/venet driver(SAR offloading, zero-copy
in the guest->host path, configurable tx-complete mitigation,
interrupt coalescing at the vbus level).  Some of the work to
re-factor and share the common code between venet-tap and
venet-macvlan was done prior because it should be generally
useful to anyone wanting to implement a venet type of device.

Once the driver is built and installed, you may use it
just like you would a venet-tap device. In order to
instantiate a venet-macvlan, there are just two differences
from the procedure to instantiating a venet-tap. In order
to create the venet-macvlan device, just:

echo venet-macvlan > /config/vbus/devices/≤device-name>/type

and

echo "lower-devicename" > /sys/vbus/devices/≤device-name>/ll_ifname

where lower-devicename is something like eth0, eth1, eth2 etc.

The second step associates the lower-devicename, usually
(Continue reading)

Permalink | Reply | 0 comments |

Gmane