kernel-packages team mailing list archive

[Launchpad Bug Tracker <1284535@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package linux - 3.13.0-14.34

---------------
linux (3.13.0-14.34) trusty; urgency=low

  [ Tim Gardner ]

  * Release Tracking Bug
    - LP: #1285851

  [ Andy Whitcroft ]

  * [Config] d-i -- add hyperv_keyboard to serial-modules udeb
    - LP: #1285434

  [ Hannes Frederic Sowa ]

  * SAUCE: ipv6: honor IPV6_PKTINFO with v4 mapped addresses on sendmsg
    - LP: #1284535

  [ Jason Wang ]

  * SAUCE: x86, hyperv: bypass the timer_irq_works() check
    - LP: #1282693

  [ Paolo Pisati ]

  * [Config] disable FB_OMAP2, DRM_OMAP=m

  [ Upstream Kernel Changes ]

  * ipv6: make IPV6_RECVPKTINFO work for ipv4 datagrams
    - LP: #1284535
  * mei: remove flash_work_queue
  * mei: drop redundant list_del_init
  * mei: cleanup mei_irq_read_handler
  * mei: enable marking internal commands
  * mei: me: set dma mask using DMA mapping API
  * Documentation/misc-devices/mei/mei-amt-version.c: remove unneeded call
    of mei_deinit()
  * mei: do not run reset flow from the interrupt thread
  * mei: nfc: mei_nfc_free has to be called under lock
  * mei: fix syntax in comments and debug output
  * mei: revamp mei reset state machine
  * mei: limit the number of consecutive resets
  * mei: set client's read_cb to NULL when flow control fails
 -- Tim Gardner <tim.gardner@xxxxxxxxxxxxx>   Wed, 26 Feb 2014 08:43:20 -0500

** Changed in: linux (Ubuntu Trusty)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1284535

Title:
  Make IPV6_[RECV]PKTINFO work for IPv4-mapped addresses

Status in “linux” package in Ubuntu:
  Fix Released
Status in “linux” source package in Trusty:
  Fix Released

Bug description:
  Currently, the Linux kernel doesn't provide IPV6_RECVPKTINFO ancillary
  data on datagrams coming in from IPv4-mapped clients (e.g.,
  ::ffff:192.0.2.1) on INET6 sockets in the default dual personality
  mode, nor does it honour IPV6_PKTINFO when sending datagrams on such a
  socket to an IPv4-mapped destination.

  This means that an UDP application that requires a server to respond
  with the same address as it was contacted on cannot reliably work for
  IPv4 clients, because 1) the server has no way of knowing which
  address it was contacted on, and even if it did, 2) the kernel would
  ignore requests to use a specific source address.

  For a real-life manifestation of this problem, see this OpenVPN bug
  report: https://community.openvpn.net/openvpn/ticket/306

  This has recently been fixed in the net-next upstream tree with the
  following commits (the first one of which made the 3.14 merge window,
  the second one will be in 3.15):

  https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=4b261c75a99f29c93a0b6babfc180cdf566bd654
  https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=c8e6ad0829a723a74cd2fea9996a3392d2579a18

  Enabling IPv6 is getting increasingly important in these days, but at
  the same time maintaining backwards compatibility with IPv4-only
  clients is also essential. I'm therefore requesting a backport of the
  above two commits to the Ubuntu LTS kernel images so that it becomes
  possible to use OpenVPN (and any other software packages) in dual-
  stack mode.

  Tore

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1284535/+subscriptions