[Expired for linux (Ubuntu) because there has been no activity for 60
days.]
** Changed in: linux (Ubuntu)
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1780103
That was too soon: correction: 18.04 does not yet fix this bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1780103
Title:
Network namespaces support for non-IP suddenly missing
To manage
A system update on 18.04 now fixes this bug. I'll check later to see if
the 16.04 line also fixes it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1780103
Title:
Network namespaces support for
This ticket is related to:
https://github.com/torvalds/linux/commit/b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba
https://github.com/torvalds/linux/commit/9aad13b087ab0a588cd68259de618f100053360e
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
It looks like the frame gets artificially enlarged by something in
between my call to send and the receiver, by 14 bytes (an ethernet
header size). The bytes 'it' uses to pad are all the same, but always
different. If I set the MTU to the correct size (that is, the ethernet
*payload* size), then
Ok. I've found a clue. It's in the MTU size. If you enlarge the
specified MTU size in my test code by 14 (fourteen - the size of an
Ethernet header), then the frames go through unhindered. It looks like
someone interpreted 'MTU' to mean: 'size of the Ethernet frame' instead
of 'size of the
The code above formulates, sends and (in a second executable) receives
ethernet frames. The network namespaces are set up to enable this. The
ethernet frames are unusual for two reasons: they are long (2156 MTU),
and they are typed as non-IP (or ARP). Also, they don't use the MAC
addresses that
The attached tar.gz contains C-files, a Makefile, and a test shell
script. It must be made (using 'make'), and run as root. This code works
on Ubuntu 16.04 kernel 4.4.0-128-generic (and prints 'success!') but
does not work on 4.4.0-130-generic or 4.4.0-131-generic.
** Attachment added: "Tar.gz
I have source code now that works on the old kernel, and doesn't on the
new one. Shall I post it (somehow - I don't know how)?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1780103
Title:
Network
I have more information on this issue. It turns out that I do two things
that are unusual: I set the MTU of the ethernet device to 2156. Then I
send a non-IP ethernet type packet with a length of 2170 bytes (2156 +
14 bytes ethernet header) using raw sockets. The raw socket receiving
it, gets a
Would it be possible for you to test the latest upstream stable kernel?
Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the
latest v4.4 stable kernel[0].
If this bug is fixed in the mainline kernel, please add the following
tag 'kernel-fixed-upstream'.
If the mainline kernel
I've run apport-collect twice on this one: the first one is with the
working (4.4.0-128-generic) kernel, the second one is with the
*non*-working kernel (4.4.0-130-generic).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
apport information
** Tags added: apport-collected xenial
** Description changed:
I run 16.04, and I keep daily track of all dist-upgrades. Yesterday (3
july 2018) there was an upgrade, and it must have been a kernel upgrade,
because my machine had rebooted (which I make it do
I can confirm that the 4.4.0-128-generic kernel does *not* have the
problem, while the 4.4.0-130-generic kernel *does*.
Op wo 4 jul. 2018 om 17:21 schreef Daniel Manrique <
daniel.manri...@canonical.com>:
> Hello,
>
> Thank you for taking the time to report this bug and helping to make
> Ubuntu
Hello,
Thank you for taking the time to report this bug and helping to make
Ubuntu better.
As diagnostic procedures, I can suggest:
You could try rebooting, hitting the key to get the grub menu (Shift,
see https://askubuntu.com/questions/16042/how-to-get-to-the-grub-menu-
at-boot-time) and
15 matches
Mail list logo
