On Wed, Mar 30, 2011 at 11:48:49AM +0200, Daniel Lezcano wrote:
> Ok, I hope it's fixed now.
Well, there is no sign of package loss on tcp during few simple tests,
but udp packages, which length is 4096 are still broken, making DNS
unusable. Small packages, SOA requests, for example, are working j
On Wed, Mar 30, 2011 at 11:48:49AM +0200, Daniel Lezcano wrote:
> Thanks for reporting.
Thanks. I'll test it as soon as it will be in mainline release (we've already
migrated all affected installations to physical device usage).
pgpFypAOZxZ4O.pgp
Description: PGP signature
--
On Fri, Mar 18, 2011 at 12:26:32PM +0300, Vladimir Laskov wrote:
> # lxc-execute --name vm1 /bin/bash
> lxc-execute: failed to create veth1-vethAmmjfi : File exists
> lxc-execute: failed to create netdev
> lxc-execute: failed to create the network
> lxc-execute: failed to spawn 'vm1'
> lxc-execute
On Thu, Feb 24, 2011 at 11:20:09AM +0100, Daniel Lezcano wrote:
> I saw you were using the command 'nc6', do you use netcat with ipv6 ?
Well, yes and no. I've tried both ipv4 and ipv6 and my notebook has no
ipv6 address assigned, so most terrible connection was though ipv4 =).
At another server t
On Mon, Feb 21, 2011 at 05:07:31PM +0100, Daniel Lezcano wrote:
> I Cc'ed the netdev mailing list and Patrick in case my analysis is wrong
> or incomplete.
I'm confirming, that this happens only when macvlan's are onto dummy net
device. In case of some physical interface under macvlan there is no
On Mon, Feb 21, 2011 at 05:07:31PM +0100, Daniel Lezcano wrote:
> IMO, the checksum is not needed for the virtual macvlan devices, hence
Well, maybe then I've made a horrible mistake of asking the wrong
question. It's not a bad checksums that are wondering me, but very poor
network traffic perform
Greetings, Daniel.
On Mon, Feb 21, 2011 at 04:20:59PM +0100, Daniel Lezcano wrote:
2.6.37 kernel with gentoo linux patches (doesn't affect any low-system
stuff, AFAIK).
lxc-0.7.2 is used.
Reproducable on two different machines.
I'm using tcpdump -vvv for bad checksum detection. This also affects
Just what is told in subject: on macvlan ports there is a huge ammount
of invalid checksums, even on packets from one container to another on
same macvlan physical device.
We are using macvlan bridge mode on dummy0 device. Any ideas why this
could be happening?
pgp4oH2WLbzwN.pgp
Description: PGP