[Kernel-packages] [Bug 1715812] Re: Neighbour confirmation broken, breaks ARP cache aging

2017-11-02 Thread Daniel Axtens 
** Changed in: linux (Ubuntu)
   Status: Confirmed => 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/1715812

Title:
  Neighbour confirmation broken, breaks ARP cache aging

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Released
Status in linux source package in Zesty:
  Fix Released

Bug description:
  [SRU Justification]

  [Impact]
  A host can lose access to another host whose MAC address changes if they have 
active connections to other hosts that share a route. The ARP cache does not 
time out as expected - instead the old MAC address is continuously reconfirmed.

  [Fix]
  Apply series [1], which changes the algorithm for neighbour confirmation.
  That is, from upstream:
  51ce8bd4d17a net: pending_confirm is not used anymore 
  0dec879f636f net: use dst_confirm_neigh for UDP, RAW, ICMP, L2TP 
  63fca65d0863 net: add confirm_neigh method to dst_ops 
  c3a2e8370534 tcp: replace dst_confirm with sk_dst_confirm 
  c86a773c7802 sctp: add dst_pending_confirm flag 
  4ff0620354f2 net: add dst_pending_confirm flag to skbuff 
  9b8805a32559 sock: add sk_dst_pending_confirm flag 

  [Test case]
  Create 3 real or virtual systems, all hooked up to a switch.
  One system needs an active-backup bond with fail_over_mac=1 num_grat_arp=0.

  Put all the systems in the same subnet, e.g. 192.168.200.0/24

  Call the system with the bond A, and the other two systems B and C.

  On B, run in 3 shells:
   - netperf -t TCP_RR to C
   - ping -f A
   - watch 'ip -s neigh show 192.168.200.0/24'

  On A, cause the bond to fail over.

  Observe that:

   - without the patches, B intermittently fails to notice the change in
  A's MAC address. This presents as the ping failing and not recovering,
  and the arp table showing the old mac address never timing out and
  never being replace with a new mac address.

   - with the patches, the arp cache times out and B sends another mac
  probe and detects A's new address.

  It helps to use taskset to put ping and netperf on the same CPU, or
  use single-CPU vms.

  See [2] for more details.

  [References]
  [2] Original report: 
https://www.mail-archive.com/netdev@vger.kernel.org/msg138762.html
  [1]: https://www.spinics.net/lists/linux-rdma/msg45907.html

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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1715812] Re: Neighbour confirmation broken, breaks ARP cache aging

2017-10-10 Thread Launchpad Bug Tracker 
This bug was fixed in the package linux - 4.4.0-97.120

---
linux (4.4.0-97.120) xenial; urgency=low

  * linux: 4.4.0-97.120 -proposed tracker (LP: #1718149)

  * blk-mq: possible deadlock on CPU hot(un)plug (LP: #1670634)
- [Config] s390x -- disable CONFIG_{DM, SCSI}_MQ_DEFAULT

  * Xenial update to 4.4.87 stable release (LP: #1715678)
- irqchip: mips-gic: SYNC after enabling GIC region
- i2c: ismt: Don't duplicate the receive length for block reads
- i2c: ismt: Return EMSGSIZE for block reads with bogus length
- ceph: fix readpage from fscache
- cpumask: fix spurious cpumask_of_node() on non-NUMA multi-node configs
- cpuset: Fix incorrect memory_pressure control file mapping
- alpha: uapi: Add support for __SANE_USERSPACE_TYPES__
- CIFS: remove endian related sparse warning
- wl1251: add a missing spin_lock_init()
- xfrm: policy: check policy direction value
- drm/ttm: Fix accounting error when fail to get pages for pool
- kvm: arm/arm64: Fix race in resetting stage2 PGD
- kvm: arm/arm64: Force reading uncached stage2 PGD
- epoll: fix race between ep_poll_callback(POLLFREE) and 
ep_free()/ep_remove()
- crypto: algif_skcipher - only call put_page on referenced and used pages
- Linux 4.4.87

  * Xenial update to 4.4.86 stable release (LP: #1715430)
- scsi: isci: avoid array subscript warning
- ALSA: au88x0: Fix zero clear of stream->resources
- btrfs: remove duplicate const specifier
- i2c: jz4780: drop superfluous init
- gcov: add support for gcc version >= 6
- gcov: support GCC 7.1
- lightnvm: initialize ppa_addr in dev_to_generic_addr()
- p54: memset(0) whole array
- lpfc: Fix Device discovery failures during switch reboot test.
- arm64: mm: abort uaccess retries upon fatal signal
- x86/io: Add "memory" clobber to insb/insw/insl/outsb/outsw/outsl
- arm64: fpsimd: Prevent registers leaking across exec
- scsi: sg: protect accesses to 'reserved' page array
- scsi: sg: reset 'res_in_use' after unlinking reserved array
- drm/i915: fix compiler warning in drivers/gpu/drm/i915/intel_uncore.c
- Linux 4.4.86

  * Xenial update to 4.4.85 stable release (LP: #1714298)
- af_key: do not use GFP_KERNEL in atomic contexts
- dccp: purge write queue in dccp_destroy_sock()
- dccp: defer ccid_hc_tx_delete() at dismantle time
- ipv4: fix NULL dereference in free_fib_info_rcu()
- net_sched/sfq: update hierarchical backlog when drop packet
- ipv4: better IP_MAX_MTU enforcement
- sctp: fully initialize the IPv6 address in sctp_v6_to_addr()
- tipc: fix use-after-free
- ipv6: reset fn->rr_ptr when replacing route
- ipv6: repair fib6 tree in failure case
- tcp: when rearming RTO, if RTO time is in past then fire RTO ASAP
- irda: do not leak initialized list.dev to userspace
- net: sched: fix NULL pointer dereference when action calls some targets
- net_sched: fix order of queue length updates in qdisc_replace()
- mei: me: add broxton pci device ids
- mei: me: add lewisburg device ids
- Input: trackpoint - add new trackpoint firmware ID
- Input: elan_i2c - add ELAN0602 ACPI ID to support Lenovo Yoga310
- ALSA: core: Fix unexpected error at replacing user TLV
- ALSA: hda - Add stereo mic quirk for Lenovo G50-70 (17aa:3978)
- ARCv2: PAE40: Explicitly set MSB counterpart of SLC region ops addresses
- i2c: designware: Fix system suspend
- drm: Release driver tracking before making the object available again
- drm/atomic: If the atomic check fails, return its value first
- drm: rcar-du: lvds: Fix PLL frequency-related configuration
- drm: rcar-du: lvds: Rename PLLEN bit to PLLON
- drm: rcar-du: Fix crash in encoder failure error path
- drm: rcar-du: Fix display timing controller parameter
- drm: rcar-du: Fix H/V sync signal polarity configuration
- tracing: Fix freeing of filter in create_filter() when set_str is false
- cifs: Fix df output for users with quota limits
- cifs: return ENAMETOOLONG for overlong names in cifs_open()/cifs_lookup()
- nfsd: Limit end of page list when decoding NFSv4 WRITE
- perf/core: Fix group {cpu,task} validation
- Bluetooth: hidp: fix possible might sleep error in hidp_session_thread
- Bluetooth: cmtp: fix possible might sleep error in cmtp_session
- Bluetooth: bnep: fix possible might sleep error in bnep_session
- binder: use group leader instead of open thread
- binder: Use wake up hint for synchronous transactions.
- ANDROID: binder: fix proc->tsk check.
- iio: imu: adis16480: Fix acceleration scale factor for adis16480
- iio: hid-sensor-trigger: Fix the race with user space powering up sensors
- staging: rtl8188eu: add RNX-N150NUB support
- ASoC: simple-card: don't fail if sysclk setting is not supported
- ASoC: rsnd: disable SRC.out only when stop timing
- ASoC: rsnd: avoid

[Kernel-packages] [Bug 1715812] Re: Neighbour confirmation broken, breaks ARP cache aging

2017-10-10 Thread Launchpad Bug Tracker 
This bug was fixed in the package linux - 4.10.0-37.41

---
linux (4.10.0-37.41) zesty; urgency=low

  * CVE-2017-1000255
- SAUCE: powerpc/64s: Use emergency stack for kernel TM Bad Thing program
  checks
- SAUCE: powerpc/tm: Fix illegal TM state in signal handler

linux (4.10.0-36.40) zesty; urgency=low

  * linux: 4.10.0-36.40 -proposed tracker (LP: #1718143)

  * Neighbour confirmation broken, breaks ARP cache aging (LP: #1715812)
- sock: add sk_dst_pending_confirm flag
- net: add dst_pending_confirm flag to skbuff
- sctp: add dst_pending_confirm flag
- tcp: replace dst_confirm with sk_dst_confirm
- net: add confirm_neigh method to dst_ops
- net: use dst_confirm_neigh for UDP, RAW, ICMP, L2TP
- net: pending_confirm is not used anymore

  * SRIOV: warning if unload VFs (LP: #1715073)
- PCI: Lock each enable/disable num_vfs operation in sysfs
- PCI: Disable VF decoding before pcibios_sriov_disable() updates resources

  * Kernel has troule recognizing Corsair Strafe RGB keyboard (LP: #1678477)
- usb: quirks: add delay init quirk for Corsair Strafe RGB keyboard

  * CVE-2017-14106
- tcp: initialize rcv_mss to TCP_MIN_MSS instead of 0

  * [CIFS] Fix maximum SMB2 header size (LP: #1713884)
- CIFS: Fix maximum SMB2 header size

  * Middle button of trackpoint doesn't work (LP: #1715271)
- Input: trackpoint - assume 3 buttons when buttons detection fails

  * Drop GPL from of_node_to_nid() export to match other arches (LP: #1709179)
- powerpc: Drop GPL from of_node_to_nid() export to match other arches

  * vhost guest network randomly drops under stress (kvm) (LP: #1711251)
- Revert "vhost: cache used event for better performance"

  * arm64 arch_timer fixes (LP: #1713821)
- Revert "UBUNTU: SAUCE: arm64: arch_timer: Enable CNTVCT_EL0 trap if
  workaround is enabled"
- arm64: arch_timer: Enable CNTVCT_EL0 trap if workaround is enabled
- clocksource/arm_arch_timer: Fix arch_timer_mem_find_best_frame()
- clocksource/drivers/arm_arch_timer: Fix read and iounmap of incorrect
  variable
- clocksource/drivers/arm_arch_timer: Fix mem frame loop initialization
- clocksource/drivers/arm_arch_timer: Avoid infinite recursion when ftrace 
is
  enabled

  * Touchpad not detected (LP: #1708852)
- Input: elan_i2c - add ELAN0608 to the ACPI table

 -- Thadeu Lima de Souza Cascardo   Fri, 06 Oct
2017 16:45:48 -0300

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

** CVE added: https://cve.mitre.org/cgi-
bin/cvename.cgi?name=2017-1000255

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-14106

-- 
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/1715812

Title:
  Neighbour confirmation broken, breaks ARP cache aging

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Zesty:
  Fix Released

Bug description:
  [SRU Justification]

  [Impact]
  A host can lose access to another host whose MAC address changes if they have 
active connections to other hosts that share a route. The ARP cache does not 
time out as expected - instead the old MAC address is continuously reconfirmed.

  [Fix]
  Apply series [1], which changes the algorithm for neighbour confirmation.
  That is, from upstream:
  51ce8bd4d17a net: pending_confirm is not used anymore 
  0dec879f636f net: use dst_confirm_neigh for UDP, RAW, ICMP, L2TP 
  63fca65d0863 net: add confirm_neigh method to dst_ops 
  c3a2e8370534 tcp: replace dst_confirm with sk_dst_confirm 
  c86a773c7802 sctp: add dst_pending_confirm flag 
  4ff0620354f2 net: add dst_pending_confirm flag to skbuff 
  9b8805a32559 sock: add sk_dst_pending_confirm flag 

  [Test case]
  Create 3 real or virtual systems, all hooked up to a switch.
  One system needs an active-backup bond with fail_over_mac=1 num_grat_arp=0.

  Put all the systems in the same subnet, e.g. 192.168.200.0/24

  Call the system with the bond A, and the other two systems B and C.

  On B, run in 3 shells:
   - netperf -t TCP_RR to C
   - ping -f A
   - watch 'ip -s neigh show 192.168.200.0/24'

  On A, cause the bond to fail over.

  Observe that:

   - without the patches, B intermittently fails to notice the change in
  A's MAC address. This presents as the ping failing and not recovering,
  and the arp table showing the old mac address never timing out and
  never being replace with a new mac address.

   - with the patches, the arp cache times out and B sends another mac
  probe and detects A's new address.

  It helps to use taskset to put ping and netperf on the same CPU, or
  use single-CPU vms.

  See [2] for more details.

  [References]
  [2] Original report: 
https://www.mail-archive.com/netdev@vger.kernel.org/msg138762.html
  [1]:

[Kernel-packages] [Bug 1715812] Re: Neighbour confirmation broken, breaks ARP cache aging

2017-09-27 Thread Daniel Axtens 
Verified on Xenial and Zesty.

** Tags removed: verification-needed-zesty
** Tags added: verification-done-zesty

-- 
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/1715812

Title:
  Neighbour confirmation broken, breaks ARP cache aging

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Zesty:
  Fix Committed

Bug description:
  [SRU Justification]

  [Impact]
  A host can lose access to another host whose MAC address changes if they have 
active connections to other hosts that share a route. The ARP cache does not 
time out as expected - instead the old MAC address is continuously reconfirmed.

  [Fix]
  Apply series [1], which changes the algorithm for neighbour confirmation.
  That is, from upstream:
  51ce8bd4d17a net: pending_confirm is not used anymore 
  0dec879f636f net: use dst_confirm_neigh for UDP, RAW, ICMP, L2TP 
  63fca65d0863 net: add confirm_neigh method to dst_ops 
  c3a2e8370534 tcp: replace dst_confirm with sk_dst_confirm 
  c86a773c7802 sctp: add dst_pending_confirm flag 
  4ff0620354f2 net: add dst_pending_confirm flag to skbuff 
  9b8805a32559 sock: add sk_dst_pending_confirm flag 

  [Test case]
  Create 3 real or virtual systems, all hooked up to a switch.
  One system needs an active-backup bond with fail_over_mac=1 num_grat_arp=0.

  Put all the systems in the same subnet, e.g. 192.168.200.0/24

  Call the system with the bond A, and the other two systems B and C.

  On B, run in 3 shells:
   - netperf -t TCP_RR to C
   - ping -f A
   - watch 'ip -s neigh show 192.168.200.0/24'

  On A, cause the bond to fail over.

  Observe that:

   - without the patches, B intermittently fails to notice the change in
  A's MAC address. This presents as the ping failing and not recovering,
  and the arp table showing the old mac address never timing out and
  never being replace with a new mac address.

   - with the patches, the arp cache times out and B sends another mac
  probe and detects A's new address.

  It helps to use taskset to put ping and netperf on the same CPU, or
  use single-CPU vms.

  See [2] for more details.

  [References]
  [2] Original report: 
https://www.mail-archive.com/netdev@vger.kernel.org/msg138762.html
  [1]: https://www.spinics.net/lists/linux-rdma/msg45907.html

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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1715812] Re: Neighbour confirmation broken, breaks ARP cache aging

2017-09-27 Thread Fabio Bardella 
** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial

-- 
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/1715812

Title:
  Neighbour confirmation broken, breaks ARP cache aging

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Zesty:
  Fix Committed

Bug description:
  [SRU Justification]

  [Impact]
  A host can lose access to another host whose MAC address changes if they have 
active connections to other hosts that share a route. The ARP cache does not 
time out as expected - instead the old MAC address is continuously reconfirmed.

  [Fix]
  Apply series [1], which changes the algorithm for neighbour confirmation.
  That is, from upstream:
  51ce8bd4d17a net: pending_confirm is not used anymore 
  0dec879f636f net: use dst_confirm_neigh for UDP, RAW, ICMP, L2TP 
  63fca65d0863 net: add confirm_neigh method to dst_ops 
  c3a2e8370534 tcp: replace dst_confirm with sk_dst_confirm 
  c86a773c7802 sctp: add dst_pending_confirm flag 
  4ff0620354f2 net: add dst_pending_confirm flag to skbuff 
  9b8805a32559 sock: add sk_dst_pending_confirm flag 

  [Test case]
  Create 3 real or virtual systems, all hooked up to a switch.
  One system needs an active-backup bond with fail_over_mac=1 num_grat_arp=0.

  Put all the systems in the same subnet, e.g. 192.168.200.0/24

  Call the system with the bond A, and the other two systems B and C.

  On B, run in 3 shells:
   - netperf -t TCP_RR to C
   - ping -f A
   - watch 'ip -s neigh show 192.168.200.0/24'

  On A, cause the bond to fail over.

  Observe that:

   - without the patches, B intermittently fails to notice the change in
  A's MAC address. This presents as the ping failing and not recovering,
  and the arp table showing the old mac address never timing out and
  never being replace with a new mac address.

   - with the patches, the arp cache times out and B sends another mac
  probe and detects A's new address.

  It helps to use taskset to put ping and netperf on the same CPU, or
  use single-CPU vms.

  See [2] for more details.

  [References]
  [2] Original report: 
https://www.mail-archive.com/netdev@vger.kernel.org/msg138762.html
  [1]: https://www.spinics.net/lists/linux-rdma/msg45907.html

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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1715812] Re: Neighbour confirmation broken, breaks ARP cache aging

2017-09-25 Thread Kleber Sacilotto de Souza 
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'. If the problem still exists,
change the tag 'verification-needed-xenial' to 'verification-failed-
xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

** Tags added: verification-needed-zesty

-- 
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/1715812

Title:
  Neighbour confirmation broken, breaks ARP cache aging

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Zesty:
  Fix Committed

Bug description:
  [SRU Justification]

  [Impact]
  A host can lose access to another host whose MAC address changes if they have 
active connections to other hosts that share a route. The ARP cache does not 
time out as expected - instead the old MAC address is continuously reconfirmed.

  [Fix]
  Apply series [1], which changes the algorithm for neighbour confirmation.
  That is, from upstream:
  51ce8bd4d17a net: pending_confirm is not used anymore 
  0dec879f636f net: use dst_confirm_neigh for UDP, RAW, ICMP, L2TP 
  63fca65d0863 net: add confirm_neigh method to dst_ops 
  c3a2e8370534 tcp: replace dst_confirm with sk_dst_confirm 
  c86a773c7802 sctp: add dst_pending_confirm flag 
  4ff0620354f2 net: add dst_pending_confirm flag to skbuff 
  9b8805a32559 sock: add sk_dst_pending_confirm flag 

  [Test case]
  Create 3 real or virtual systems, all hooked up to a switch.
  One system needs an active-backup bond with fail_over_mac=1 num_grat_arp=0.

  Put all the systems in the same subnet, e.g. 192.168.200.0/24

  Call the system with the bond A, and the other two systems B and C.

  On B, run in 3 shells:
   - netperf -t TCP_RR to C
   - ping -f A
   - watch 'ip -s neigh show 192.168.200.0/24'

  On A, cause the bond to fail over.

  Observe that:

   - without the patches, B intermittently fails to notice the change in
  A's MAC address. This presents as the ping failing and not recovering,
  and the arp table showing the old mac address never timing out and
  never being replace with a new mac address.

   - with the patches, the arp cache times out and B sends another mac
  probe and detects A's new address.

  It helps to use taskset to put ping and netperf on the same CPU, or
  use single-CPU vms.

  See [2] for more details.

  [References]
  [2] Original report: 
https://www.mail-archive.com/netdev@vger.kernel.org/msg138762.html
  [1]: https://www.spinics.net/lists/linux-rdma/msg45907.html

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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1715812] Re: Neighbour confirmation broken, breaks ARP cache aging

2017-09-25 Thread Kleber Sacilotto de Souza 
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
zesty' to 'verification-done-zesty'. If the problem still exists, change
the tag 'verification-needed-zesty' to 'verification-failed-zesty'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!

-- 
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/1715812

Title:
  Neighbour confirmation broken, breaks ARP cache aging

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Zesty:
  Fix Committed

Bug description:
  [SRU Justification]

  [Impact]
  A host can lose access to another host whose MAC address changes if they have 
active connections to other hosts that share a route. The ARP cache does not 
time out as expected - instead the old MAC address is continuously reconfirmed.

  [Fix]
  Apply series [1], which changes the algorithm for neighbour confirmation.
  That is, from upstream:
  51ce8bd4d17a net: pending_confirm is not used anymore 
  0dec879f636f net: use dst_confirm_neigh for UDP, RAW, ICMP, L2TP 
  63fca65d0863 net: add confirm_neigh method to dst_ops 
  c3a2e8370534 tcp: replace dst_confirm with sk_dst_confirm 
  c86a773c7802 sctp: add dst_pending_confirm flag 
  4ff0620354f2 net: add dst_pending_confirm flag to skbuff 
  9b8805a32559 sock: add sk_dst_pending_confirm flag 

  [Test case]
  Create 3 real or virtual systems, all hooked up to a switch.
  One system needs an active-backup bond with fail_over_mac=1 num_grat_arp=0.

  Put all the systems in the same subnet, e.g. 192.168.200.0/24

  Call the system with the bond A, and the other two systems B and C.

  On B, run in 3 shells:
   - netperf -t TCP_RR to C
   - ping -f A
   - watch 'ip -s neigh show 192.168.200.0/24'

  On A, cause the bond to fail over.

  Observe that:

   - without the patches, B intermittently fails to notice the change in
  A's MAC address. This presents as the ping failing and not recovering,
  and the arp table showing the old mac address never timing out and
  never being replace with a new mac address.

   - with the patches, the arp cache times out and B sends another mac
  probe and detects A's new address.

  It helps to use taskset to put ping and netperf on the same CPU, or
  use single-CPU vms.

  See [2] for more details.

  [References]
  [2] Original report: 
https://www.mail-archive.com/netdev@vger.kernel.org/msg138762.html
  [1]: https://www.spinics.net/lists/linux-rdma/msg45907.html

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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1715812] Re: Neighbour confirmation broken, breaks ARP cache aging

2017-09-15 Thread Stefan Bader 
** Changed in: linux (Ubuntu Zesty)
   Status: New => Fix Committed

** Changed in: linux (Ubuntu Xenial)
   Status: New => Fix Committed

-- 
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/1715812

Title:
  Neighbour confirmation broken, breaks ARP cache aging

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Zesty:
  Fix Committed

Bug description:
  [SRU Justification]

  [Impact]
  A host can lose access to another host whose MAC address changes if they have 
active connections to other hosts that share a route. The ARP cache does not 
time out as expected - instead the old MAC address is continuously reconfirmed.

  [Fix]
  Apply series [1], which changes the algorithm for neighbour confirmation.
  That is, from upstream:
  51ce8bd4d17a net: pending_confirm is not used anymore 
  0dec879f636f net: use dst_confirm_neigh for UDP, RAW, ICMP, L2TP 
  63fca65d0863 net: add confirm_neigh method to dst_ops 
  c3a2e8370534 tcp: replace dst_confirm with sk_dst_confirm 
  c86a773c7802 sctp: add dst_pending_confirm flag 
  4ff0620354f2 net: add dst_pending_confirm flag to skbuff 
  9b8805a32559 sock: add sk_dst_pending_confirm flag 

  [Test case]
  Create 3 real or virtual systems, all hooked up to a switch.
  One system needs an active-backup bond with fail_over_mac=1 num_grat_arp=0.

  Put all the systems in the same subnet, e.g. 192.168.200.0/24

  Call the system with the bond A, and the other two systems B and C.

  On B, run in 3 shells:
   - netperf -t TCP_RR to C
   - ping -f A
   - watch 'ip -s neigh show 192.168.200.0/24'

  On A, cause the bond to fail over.

  Observe that:

   - without the patches, B intermittently fails to notice the change in
  A's MAC address. This presents as the ping failing and not recovering,
  and the arp table showing the old mac address never timing out and
  never being replace with a new mac address.

   - with the patches, the arp cache times out and B sends another mac
  probe and detects A's new address.

  It helps to use taskset to put ping and netperf on the same CPU, or
  use single-CPU vms.

  See [2] for more details.

  [References]
  [2] Original report: 
https://www.mail-archive.com/netdev@vger.kernel.org/msg138762.html
  [1]: https://www.spinics.net/lists/linux-rdma/msg45907.html

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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1715812] Re: Neighbour confirmation broken, breaks ARP cache aging

2017-09-15 Thread Stefan Bader 
** Also affects: linux (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Zesty)
   Importance: Undecided
   Status: New

-- 
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/1715812

Title:
  Neighbour confirmation broken, breaks ARP cache aging

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Xenial:
  New
Status in linux source package in Zesty:
  New

Bug description:
  [SRU Justification]

  [Impact]
  A host can lose access to another host whose MAC address changes if they have 
active connections to other hosts that share a route. The ARP cache does not 
time out as expected - instead the old MAC address is continuously reconfirmed.

  [Fix]
  Apply series [1], which changes the algorithm for neighbour confirmation.
  That is, from upstream:
  51ce8bd4d17a net: pending_confirm is not used anymore 
  0dec879f636f net: use dst_confirm_neigh for UDP, RAW, ICMP, L2TP 
  63fca65d0863 net: add confirm_neigh method to dst_ops 
  c3a2e8370534 tcp: replace dst_confirm with sk_dst_confirm 
  c86a773c7802 sctp: add dst_pending_confirm flag 
  4ff0620354f2 net: add dst_pending_confirm flag to skbuff 
  9b8805a32559 sock: add sk_dst_pending_confirm flag 

  [Test case]
  Create 3 real or virtual systems, all hooked up to a switch.
  One system needs an active-backup bond with fail_over_mac=1 num_grat_arp=0.

  Put all the systems in the same subnet, e.g. 192.168.200.0/24

  Call the system with the bond A, and the other two systems B and C.

  On B, run in 3 shells:
   - netperf -t TCP_RR to C
   - ping -f A
   - watch 'ip -s neigh show 192.168.200.0/24'

  On A, cause the bond to fail over.

  Observe that:

   - without the patches, B intermittently fails to notice the change in
  A's MAC address. This presents as the ping failing and not recovering,
  and the arp table showing the old mac address never timing out and
  never being replace with a new mac address.

   - with the patches, the arp cache times out and B sends another mac
  probe and detects A's new address.

  It helps to use taskset to put ping and netperf on the same CPU, or
  use single-CPU vms.

  See [2] for more details.

  [References]
  [2] Original report: 
https://www.mail-archive.com/netdev@vger.kernel.org/msg138762.html
  [1]: https://www.spinics.net/lists/linux-rdma/msg45907.html

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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp