[Touch-packages] [Bug 1774132] Re: [Bionic]udev stop notifying when network interface added

[Talat Batheesh]

** Attachment added: "dmesg"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1774132/+attachment/5146405/+files/dmesgub18.04.log

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1774132

Title:
  [Bionic]udev stop notifying when network interface added

Status in systemd package in Ubuntu:
  New

Bug description:
  Expected:

  After a network driver restart, the network interfaces are deleted and
  added again, the udev should notify that new interface was added. then
  the interface service should be started accordingly.

  Actual:
  Udev doesn't notify about that new interface is added and the interface 
service doesn't start.

  More details:

  We see this issue when using Mellanox OFED package.
  Mellanox OFED add a service per network device and add udev rule to start 
this service when the interface added.
  After driver restart ("/etc/init.d/openibd restart") the network devices 
doesn't loaded, since udev doesn't notify.

  The system should run from udev rules, since once the driver creates
  an interface, there should be a udev event saying a new interface is
  added, then this script will be ran by udev (the OS).

  " /bin/systemctl --no-block start mlnx_interface_mgr@ib0.service "

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

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

[Touch-packages] [Bug 1774132] Re: [Bionic]udev stop notifying when network interface added

[Talat Batheesh]

Thank you Dima, 
Added requested files.

yours,
Talat

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1774132

Title:
  [Bionic]udev stop notifying when network interface added

Status in systemd package in Ubuntu:
  New

Bug description:
  Expected:

  After a network driver restart, the network interfaces are deleted and
  added again, the udev should notify that new interface was added. then
  the interface service should be started accordingly.

  Actual:
  Udev doesn't notify about that new interface is added and the interface 
service doesn't start.

  More details:

  We see this issue when using Mellanox OFED package.
  Mellanox OFED add a service per network device and add udev rule to start 
this service when the interface added.
  After driver restart ("/etc/init.d/openibd restart") the network devices 
doesn't loaded, since udev doesn't notify.

  The system should run from udev rules, since once the driver creates
  an interface, there should be a udev event saying a new interface is
  added, then this script will be ran by udev (the OS).

  " /bin/systemctl --no-block start mlnx_interface_mgr@ib0.service "

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

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

[Touch-packages] [Bug 1774132] Re: [Bionic]udev stop notifying when network interface added

[Talat Batheesh]

** Attachment added: "udevadm"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1774132/+attachment/5146404/+files/udevadm18.04.log

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1774132

Title:
  [Bionic]udev stop notifying when network interface added

Status in systemd package in Ubuntu:
  New

Bug description:
  Expected:

  After a network driver restart, the network interfaces are deleted and
  added again, the udev should notify that new interface was added. then
  the interface service should be started accordingly.

  Actual:
  Udev doesn't notify about that new interface is added and the interface 
service doesn't start.

  More details:

  We see this issue when using Mellanox OFED package.
  Mellanox OFED add a service per network device and add udev rule to start 
this service when the interface added.
  After driver restart ("/etc/init.d/openibd restart") the network devices 
doesn't loaded, since udev doesn't notify.

  The system should run from udev rules, since once the driver creates
  an interface, there should be a udev event saying a new interface is
  added, then this script will be ran by udev (the OS).

  " /bin/systemctl --no-block start mlnx_interface_mgr@ib0.service "

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

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

[Touch-packages] [Bug 1774132] [NEW] [Bionic]udev stop notifying when network interface added

[Talat Batheesh]

Public bug reported:

Expected:

After a network driver restart, the network interfaces are deleted and
added again, the udev should notify that new interface was added. then
the interface service should be started accordingly.

Actual:
Udev doesn't notify about that new interface is added and the interface service 
doesn't start.

More details:

We see this issue when using Mellanox OFED package.
Mellanox OFED add a service per network device and add udev rule to start this 
service when the interface added.
After driver restart ("/etc/init.d/openibd restart") the network devices 
doesn't loaded, since udev doesn't notify.

The system should run from udev rules, since once the driver creates an
interface, there should be a udev event saying a new interface is added,
then this script will be ran by udev (the OS).

" /bin/systemctl --no-block start mlnx_interface_mgr@ib0.service "

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1774132

Title:
  [Bionic]udev stop notifying when network interface added

Status in systemd package in Ubuntu:
  New

Bug description:
  Expected:

  After a network driver restart, the network interfaces are deleted and
  added again, the udev should notify that new interface was added. then
  the interface service should be started accordingly.

  Actual:
  Udev doesn't notify about that new interface is added and the interface 
service doesn't start.

  More details:

  We see this issue when using Mellanox OFED package.
  Mellanox OFED add a service per network device and add udev rule to start 
this service when the interface added.
  After driver restart ("/etc/init.d/openibd restart") the network devices 
doesn't loaded, since udev doesn't notify.

  The system should run from udev rules, since once the driver creates
  an interface, there should be a udev event saying a new interface is
  added, then this script will be ran by udev (the OS).

  " /bin/systemctl --no-block start mlnx_interface_mgr@ib0.service "

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

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

[Touch-packages] [Bug 1719302] Re: Please include mlx4 and mlx5 InfiniBand modules

[Talat Batheesh]

Hi Luke, 
Any update with this bug?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1719302

Title:
  Please include mlx4 and mlx5 InfiniBand modules

Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in initramfs-tools package in Debian:
  New

Bug description:
  Mellanox ConnectX architecture is:  mlx4_core is the lower level PCI
  driver which register on the PCI id, and protocol specific drivers are
  depended on it: mlx4_en - for Ethernet and mlx4_ib for Infiniband. NIC
  could have multiple ports which can change their type dynamically. We
  use the request_module() call to load the relevant protocol driver
  when needed: on loading time or at port type change event.

  The mlx4_core and mlx5_core modules are included in the initrd, but
  not mlx4_ib and mlx5_ib. Thus the request_module() call will not find
  these modules and fail load them. The mlx*_ib module loading will not
  be retried.

  Therefore also include mlx4_ib and mlx5_ib in the initrd to make
  autoloading them work. A patch is attached to the related Debian bug
  report.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1719302/+subscriptions

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

[Touch-packages] [Bug 1715319] [NEW] [IPV6] DHCP client gets 128 subnet mask instead of any other that defined

[Talat Batheesh]

Public bug reported:

After configuring DHCP server (with and without RADVD), the client gets
ipv6 address in range that was defined, or preserved. But the subnetmask
of the address is 128 no matter what was the definition.

Steps to reproduce

1.Install packages:
#apt-get install -y *dhcp*
#apt-get install radvd

2.Define DHCP and RADVD files:

#vim /etc/dhcp/dhcpd6.conf
authoritative;
default-lease-time 600;
max-lease-time 7200;
log-facility local7;
subnet6 ::/64 {
option dhcp6.name-servers ::;
range6 ::1 ::100;
}

#vim /etc/radvd.conf
interface enp5s0f0
{
AdvSendAdvert on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
prefix ::/64 {
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
};


3.
# sysctl net.ipv6.conf.ens3.forwarding
net.ipv6.conf.ens3.forwarding = 1

4.Create empty server data base file and bring up DHCP server:
#echo "" >  /tmp/dhcp6.lease
# dhcpd -6 -cf /etc/dhcp/dhcpd6.conf -lf /tmp/dhcpd6.leases enp5s0f0

5.Define client interface in /etc/network/interfaces file:
#vim  /etc/network/interfaces
auto enp6s0f0
iface enp6s0f0 inet6 dhcp

6.Start client and check the ip:
#ifdown 
#ifup
#ifconfig enp6s0f0

** Affects: isc-dhcp (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1715319

Title:
  [IPV6] DHCP client gets 128 subnet mask instead of any other that
  defined

Status in isc-dhcp package in Ubuntu:
  New

Bug description:
  After configuring DHCP server (with and without RADVD), the client
  gets ipv6 address in range that was defined, or preserved. But the
  subnetmask of the address is 128 no matter what was the definition.

  Steps to reproduce

  1.Install packages:
  #apt-get install -y *dhcp*
  #apt-get install radvd

  2.Define DHCP and RADVD files:

  #vim /etc/dhcp/dhcpd6.conf
  authoritative;
  default-lease-time 600;
  max-lease-time 7200;
  log-facility local7;
  subnet6 ::/64 {
  option dhcp6.name-servers ::;
  range6 ::1 ::100;
  }

  #vim /etc/radvd.conf
  interface enp5s0f0
  {
  AdvSendAdvert on;
  MinRtrAdvInterval 3;
  MaxRtrAdvInterval 10;
  prefix ::/64 {
  AdvOnLink on;
  AdvAutonomous on;
  AdvRouterAddr on;
  };
  };

  
  3.
  # sysctl net.ipv6.conf.ens3.forwarding
  net.ipv6.conf.ens3.forwarding = 1

  4.Create empty server data base file and bring up DHCP server:
  #echo "" >  /tmp/dhcp6.lease
  # dhcpd -6 -cf /etc/dhcp/dhcpd6.conf -lf /tmp/dhcpd6.leases enp5s0f0

  5.Define client interface in /etc/network/interfaces file:
  #vim  /etc/network/interfaces
  auto enp6s0f0
  iface enp6s0f0 inet6 dhcp

  6.Start client and check the ip:
  #ifdown 
  #ifup
  #ifconfig enp6s0f0

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1715319/+subscriptions

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

[Touch-packages] [Bug 1693503] Re: Remove mlx4.conf

[Talat Batheesh]

ok, could you please just change the name of the file ? 
I will do a tests next week to figure if mlx4_core request the modules mlx_en 
when the link type is ETh, then we don't need this file at all.

thanks
Talat

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to kmod in Ubuntu.
https://bugs.launchpad.net/bugs/1693503

Title:
  Remove mlx4.conf

Status in kmod package in Ubuntu:
  Confirmed

Bug description:
  Hi,

  we are working on debianizing rdma-core package, it will contain a
  rdma service that manage the mlx4.conf file, so the conf file
  “/etc/modprobe.d/mlx4.conf” (that comes with “kmod” package) is not
  needed anymore, and must be removed.

  This conf file conflicts with “/lib/modprobe.d/libmlx4.conf” that will
  come with “rdma-core” package, and prevents running a script
  (/sbin/mlx4-setup.sh) that configures ConnectX-3 devices port types
  (IB vs. ETH).

  
  thanks
  Talat

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

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

[Touch-packages] [Bug 1693503] [NEW] Remove mlx4.conf

[Talat Batheesh]

Public bug reported:

Hi,

we are working on debianizing rdma-core package, it will contain a rdma
service that manage the mlx4.conf file, so the conf file
“/etc/modprobe.d/mlx4.conf” (that comes with “kmod” package) is not
needed anymore, and must be removed.

This conf file conflicts with “/lib/modprobe.d/libmlx4.conf” that will
come with “rdma-core” package, and prevents running a script
(/sbin/mlx4-setup.sh) that configures ConnectX-3 devices port types (IB
vs. ETH).


thanks
Talat

** Affects: kmod (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to kmod in Ubuntu.
https://bugs.launchpad.net/bugs/1693503

Title:
  Remove mlx4.conf

Status in kmod package in Ubuntu:
  New

Bug description:
  Hi,

  we are working on debianizing rdma-core package, it will contain a
  rdma service that manage the mlx4.conf file, so the conf file
  “/etc/modprobe.d/mlx4.conf” (that comes with “kmod” package) is not
  needed anymore, and must be removed.

  This conf file conflicts with “/lib/modprobe.d/libmlx4.conf” that will
  come with “rdma-core” package, and prevents running a script
  (/sbin/mlx4-setup.sh) that configures ConnectX-3 devices port types
  (IB vs. ETH).

  
  thanks
  Talat

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

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

[Touch-packages] [Bug 1681344] [NEW] Ping interface to its IP failed using -I option

[Talat Batheesh]

Public bug reported:

Scenario:

$ifconfig
ens3: flags=4163  mtu 1500
inet 10.141.20.8  netmask 255.255.0.0  broadcast 10.141.255.255
inet6 fe80::250:56ff:fe8d:1408  prefixlen 64  scopeid 0x20
ether 00:50:56:8d:14:08  txqueuelen 1000  (Ethernet)
RX packets 152370  bytes 15937926 (15.9 MB)
RX errors 3  dropped 0  overruns 0  frame 3
TX packets 4092  bytes 470882 (470.8 KB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ens8: flags=4163  mtu 1500
inet 11.141.20.8  netmask 255.255.0.0  broadcast 11.141.255.255
inet6 fe80::268a:7ff:fe1e:d572  prefixlen 64  scopeid 0x20
ether 24:8a:07:1e:d5:72  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 29  bytes 2280 (2.2 KB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10
loop  txqueuelen 1000  (Local Loopback)
RX packets 200  bytes 16052 (16.0 KB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 200  bytes 16052 (16.0 KB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

$ping -c 10 -I ens8 11.141.20.8
PING 11.141.20.8 (11.141.20.8) from 11.141.20.8 ens8: 56(84) bytes of data.
^C
--- 11.141.20.8 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2050ms

$ping -c 10 -I ens3 10.141.20.8
PING 10.141.20.8 (10.141.20.8) from 10.141.20.8 ens3: 56(84) bytes of data.
^C
--- 10.141.20.8 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9200ms

Tested with driver mlx4 / mlx5 / e1000


iputils version 
iputils-ping3:20161105-1ubuntu2


Thanks,
Talat

** Affects: iputils (Ubuntu)
 Importance: Undecided
 Status: New

** Description changed:

  Scenario:
  
- $ifconfig 
+ $ifconfig
  ens3: flags=4163  mtu 1500
- inet 10.141.20.8  netmask 255.255.0.0  broadcast 10.141.255.255
- inet6 fe80::250:56ff:fe8d:1408  prefixlen 64  scopeid 0x20
- ether 00:50:56:8d:14:08  txqueuelen 1000  (Ethernet)
- RX packets 152370  bytes 15937926 (15.9 MB)
- RX errors 3  dropped 0  overruns 0  frame 3
- TX packets 4092  bytes 470882 (470.8 KB)
- TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
+ inet 10.141.20.8  netmask 255.255.0.0  broadcast 10.141.255.255
+ inet6 fe80::250:56ff:fe8d:1408  prefixlen 64  scopeid 0x20
+ ether 00:50:56:8d:14:08  txqueuelen 1000  (Ethernet)
+ RX packets 152370  bytes 15937926 (15.9 MB)
+ RX errors 3  dropped 0  overruns 0  frame 3
+ TX packets 4092  bytes 470882 (470.8 KB)
+ TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
  
  ens8: flags=4163  mtu 1500
- inet 11.141.20.8  netmask 255.255.0.0  broadcast 11.141.255.255
- inet6 fe80::268a:7ff:fe1e:d572  prefixlen 64  scopeid 0x20
- ether 24:8a:07:1e:d5:72  txqueuelen 1000  (Ethernet)
- RX packets 0  bytes 0 (0.0 B)
- RX errors 0  dropped 0  overruns 0  frame 0
- TX packets 29  bytes 2280 (2.2 KB)
- TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
+ inet 11.141.20.8  netmask 255.255.0.0  broadcast 11.141.255.255
+ inet6 fe80::268a:7ff:fe1e:d572  prefixlen 64  scopeid 0x20
+ ether 24:8a:07:1e:d5:72  txqueuelen 1000  (Ethernet)
+ RX packets 0  bytes 0 (0.0 B)
+ RX errors 0  dropped 0  overruns 0  frame 0
+ TX packets 29  bytes 2280 (2.2 KB)
+ TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
  
  lo: flags=73  mtu 65536
- inet 127.0.0.1  netmask 255.0.0.0
- inet6 ::1  prefixlen 128  scopeid 0x10
- loop  txqueuelen 1000  (Local Loopback)
- RX packets 200  bytes 16052 (16.0 KB)
- RX errors 0  dropped 0  overruns 0  frame 0
- TX packets 200  bytes 16052 (16.0 KB)
- TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
+ inet 127.0.0.1  netmask 255.0.0.0
+ inet6 ::1  prefixlen 128  scopeid 0x10
+ loop  txqueuelen 1000  (Local Loopback)
+ RX packets 200  bytes 16052 (16.0 KB)
+ RX errors 0  dropped 0  overruns 0  frame 0
+ TX packets 200  bytes 16052 (16.0 KB)
+ TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
  
- $ping -c 10 -I ens8 11.141.20.8 
+ $ping -c 10 -I ens8 11.141.20.8
  PING 11.141.20.8 (11.141.20.8) from 11.141.20.8 ens8: 56(84) bytes of data.
  ^C
  --- 11.141.20.8 ping statistics ---
  3 packets transmitted, 0 received, 100% packet loss, time 2050ms
  
- $ping -c 10 -I ens3 10.141.20.8 
+ $ping -c 10 -I ens3 10.141.20.8
  PING 10.141.20.8 (10.141.20.8) from 10.141.20.8 ens3: 56(84) bytes of data.
  ^C
  --- 10.141.20.8 ping statistics ---
  10 packets transmitted, 0 received, 100% 

[Touch-packages] [Bug 1672144] Re: ifup service of network device stay active after driver stop

[Talat Batheesh]

This bug reproduced with tg3 , mlx4, mlx5 and bonding modules and i
beleve that this issue reproduce on each interface that has ifup
service.

simple reproduce 
1. interfaces is up after reboot or ifup.
2. modprobe -r 
#network interfaces closed and removed
3.systemctl status ifup@.service
# service is up although the network interface doesn't exist.

This issue not reproduced with kernel 4.9.
when we moved to kernel 4.10 we see this issue.


thanks
Talat

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1672144

Title:
  ifup service of network device stay active after driver stop

Status in systemd package in Ubuntu:
  New

Bug description:
  The network device systemd service stay active after unload the module of 
this network device, that call close port (ndo_stop).
  once we try to load the NIC driver again, it try to start the ifup service of 
his NICs and due to the service is already up, so it fail and we didn't see the 
interface with the static configuration =.
  below simple reproduce with the Mellanox ConnectX4 device (driver name 
mlx5_core).

  Also we see this issue with Azure system, Ubuntu 17.04 guest over
  Hyper-v, the  VF failed to start after re-enable SR-IOV from VM's
  vNIC.

  
  For now we have a Work Around that to add a udev rule,
   echo DRIVERS==\"*mlx*\", SUBSYSTEM==\"net\", 
ACTION==\"add\",RUN+=\"/sbin/ifup --force $env{INTERFACE}\" > 
/lib/udev/rules.d/100-up.rules
  Example:
  #:/lib/udev/rules.d# cat 100-up.rules
  DRIVERS=="*mlx*", SUBSYSTEM=="net", ACTION=="add",RUN+="/sbin/ifup --force 
$env{INTERFACE}" 

  ***
  * More info and reproduce *
  ***
  # ifdown ens1f0
  RTNETLINK answers: Cannot assign requested address
  # ifup ens1f0 
  # ifconfig ens1f0 
  ens1f0: flags=4163  mtu 1500
  inet 123.12.23.1  netmask 255.255.0.0  broadcast 123.12.255.255
  inet6 fe80::268a:7ff:fea1:fbdc  prefixlen 64  scopeid 0x20
  ether 24:8a:07:a1:fb:dc  txqueuelen 1000  (Ethernet)
  RX packets 0  bytes 0 (0.0 B)   
  RX errors 0  dropped 0  overruns 0  frame 0 
  TX packets 17  bytes 1392 (1.3 KB)  
  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0  

  # ethtool -i ens1f0 |grep driv
  driver: mlx5_core
  # systemctl status ifup@ens1f 
  ifup@ens1f0.service  ifup@ens1f1.service

  # systemctl status ifup@ens1f0.service 
  * ifup@ens1f0.service - ifup for ens1f0  
 Loaded: loaded (/lib/systemd/system/ifup@.service; static; vendor preset: 
enabled)
 Active: active (exited) since Sun 2017-03-12 09:40:04 IST; 2h 26min ago
   
   Main PID: 1608 (code=exited, status=0/SUCCESS)   
   
 CGroup: /system.slice/ifup@ens1f0.service  
   

  Mar 12 09:40:04 qa-h-vrt-039 systemd[1]: Started ifup for ens1f0.
  Mar 12 09:40:04 qa-h-vrt-039 sh[1608]: ifup: interface ens1f0 already 
configured
  root@qa-h-vrt-039:/tmp# modprobe -rv mlx5_ib 
  rmmod mlx5_ib
  rmmod mlx5_core  

  # modprobe -rv mlx5_core

  # ifconfig -a |grep ens1f0

  # lsmod |grep mlx5

  # systemctl status ifup@ens1f0.service
  * ifup@ens1f0.service - ifup for ens1f0 
 Loaded: loaded (/lib/systemd/system/ifup@.service; static; vendor preset: 
enabled)
 Active: active (exited) since Sun 2017-03-12 09:40:04 IST; 2h 27min ago
   Main PID: 1608 (code=exited, status=0/SUCCESS)
 CGroup: /system.slice/ifup@ens1f0.service

  Mar 12 09:40:04 qa-h-vrt-039 systemd[1]: Started ifup for ens1f0.
  Mar 12 09:40:04 qa-h-vrt-039 sh[1608]: ifup: interface ens1f0 already 
configured

  # modprobe mlx5_core

  # ifconfig ens1f0
  ens1f0: flags=4098  mtu 1500
  ether 24:8a:07:a1:fb:dc  txqueuelen 1000  (Ethernet)
  RX packets 0  bytes 0 (0.0 B)
  RX errors 0  dropped 0  overruns 0  frame 0
  TX packets 0  bytes 0 (0.0 B)
  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

  
  # cat /etc/network/interfaces
  # This file describes the network interfaces available on your system
  # and how to activate them. For more information, see interfaces(5).

  
  # The loopback network interface
  auto lo
  iface lo inet loopback

  # The primary network interface
  auto eno1
  iface eno1 inet dhcp

  #ens1f0
  auto ens1f0
  iface ens1f0 inet static
  address 123.12.23.1
  netmask 255.255.0.0
  mtu 1500

  
  *
  * Another repto and investigate *
  *
  once interface is created the system starts a service that is responsible for 
activating it (basically runs ifup).
  so, at first shot everything wo

[Touch-packages] [Bug 1672144] Re: ifup service of network device stay active after driver stop

[Talat Batheesh]

network interface ifup.
# ifup 

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1672144

Title:
  ifup service of network device stay active after driver stop

Status in systemd package in Ubuntu:
  New

Bug description:
  The network device systemd service stay active after unload the module of 
this network device, that call close port (ndo_stop).
  once we try to load the NIC driver again, it try to start the ifup service of 
his NICs and due to the service is already up, so it fail and we didn't see the 
interface with the static configuration =.
  below simple reproduce with the Mellanox ConnectX4 device (driver name 
mlx5_core).

  Also we see this issue with Azure system, Ubuntu 17.04 guest over
  Hyper-v, the  VF failed to start after re-enable SR-IOV from VM's
  vNIC.

  
  For now we have a Work Around that to add a udev rule,
   echo DRIVERS==\"*mlx*\", SUBSYSTEM==\"net\", 
ACTION==\"add\",RUN+=\"/sbin/ifup --force $env{INTERFACE}\" > 
/lib/udev/rules.d/100-up.rules
  Example:
  #:/lib/udev/rules.d# cat 100-up.rules
  DRIVERS=="*mlx*", SUBSYSTEM=="net", ACTION=="add",RUN+="/sbin/ifup --force 
$env{INTERFACE}" 

  ***
  * More info and reproduce *
  ***
  # ifdown ens1f0
  RTNETLINK answers: Cannot assign requested address
  # ifup ens1f0 
  # ifconfig ens1f0 
  ens1f0: flags=4163  mtu 1500
  inet 123.12.23.1  netmask 255.255.0.0  broadcast 123.12.255.255
  inet6 fe80::268a:7ff:fea1:fbdc  prefixlen 64  scopeid 0x20
  ether 24:8a:07:a1:fb:dc  txqueuelen 1000  (Ethernet)
  RX packets 0  bytes 0 (0.0 B)   
  RX errors 0  dropped 0  overruns 0  frame 0 
  TX packets 17  bytes 1392 (1.3 KB)  
  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0  

  # ethtool -i ens1f0 |grep driv
  driver: mlx5_core
  # systemctl status ifup@ens1f 
  ifup@ens1f0.service  ifup@ens1f1.service

  # systemctl status ifup@ens1f0.service 
  * ifup@ens1f0.service - ifup for ens1f0  
 Loaded: loaded (/lib/systemd/system/ifup@.service; static; vendor preset: 
enabled)
 Active: active (exited) since Sun 2017-03-12 09:40:04 IST; 2h 26min ago
   
   Main PID: 1608 (code=exited, status=0/SUCCESS)   
   
 CGroup: /system.slice/ifup@ens1f0.service  
   

  Mar 12 09:40:04 qa-h-vrt-039 systemd[1]: Started ifup for ens1f0.
  Mar 12 09:40:04 qa-h-vrt-039 sh[1608]: ifup: interface ens1f0 already 
configured
  root@qa-h-vrt-039:/tmp# modprobe -rv mlx5_ib 
  rmmod mlx5_ib
  rmmod mlx5_core  

  # modprobe -rv mlx5_core

  # ifconfig -a |grep ens1f0

  # lsmod |grep mlx5

  # systemctl status ifup@ens1f0.service
  * ifup@ens1f0.service - ifup for ens1f0 
 Loaded: loaded (/lib/systemd/system/ifup@.service; static; vendor preset: 
enabled)
 Active: active (exited) since Sun 2017-03-12 09:40:04 IST; 2h 27min ago
   Main PID: 1608 (code=exited, status=0/SUCCESS)
 CGroup: /system.slice/ifup@ens1f0.service

  Mar 12 09:40:04 qa-h-vrt-039 systemd[1]: Started ifup for ens1f0.
  Mar 12 09:40:04 qa-h-vrt-039 sh[1608]: ifup: interface ens1f0 already 
configured

  # modprobe mlx5_core

  # ifconfig ens1f0
  ens1f0: flags=4098  mtu 1500
  ether 24:8a:07:a1:fb:dc  txqueuelen 1000  (Ethernet)
  RX packets 0  bytes 0 (0.0 B)
  RX errors 0  dropped 0  overruns 0  frame 0
  TX packets 0  bytes 0 (0.0 B)
  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

  
  # cat /etc/network/interfaces
  # This file describes the network interfaces available on your system
  # and how to activate them. For more information, see interfaces(5).

  
  # The loopback network interface
  auto lo
  iface lo inet loopback

  # The primary network interface
  auto eno1
  iface eno1 inet dhcp

  #ens1f0
  auto ens1f0
  iface ens1f0 inet static
  address 123.12.23.1
  netmask 255.255.0.0
  mtu 1500

  
  *
  * Another repto and investigate *
  *
  once interface is created the system starts a service that is responsible for 
activating it (basically runs ifup).
  so, at first shot everything works.
  at the second driver reload:
  Good flow (on good setup 4.9.0-rc5+):
  1. driver is unloaded and the interface’s “ifup” service is shutdown:
  Feb 23 00:54:09 reg-l-vrt-206-006 kernel: [6.790189] mlx4_en: 
enP43508p0s2: Close port called
  Feb 23 00:54:09 reg-l-vrt-206-006 kernel: [6.868484] hv_netvsc 
a2be13bb-7244-44ff-a31a-dea8d58a79da eth1: VF down: enP43508p0s2
  Feb 23 00:54:09 reg-l-vrt-206-006 kernel: 

[Touch-packages] [Bug 1673491] Re: [Zesty] libnl3 Segmentation fault in sriov environments

[Talat Batheesh]

Thank you ,
The update is passed and libnl updated to libnl-3-200:amd64 (3.2.29-0ubuntu2).

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libnl3 in Ubuntu.
https://bugs.launchpad.net/bugs/1673491

Title:
  [Zesty] libnl3 Segmentation fault in sriov environments

Status in libnl3 package in Ubuntu:
  Fix Released
Status in libvirt package in Ubuntu:
  New

Bug description:
  in Ubuntu 17.04 we can't open a virt-manager, we see sefault

  This issue happen when we update from kernel 4.10.0-9-generic to
  4.10.0-11-generic

  root@:~# /usr/sbin/libvirtd
  Segmentation fault (core dumped)   

  root@:~# gdb /usr/sbin/libvirtd ./core 
  GNU gdb (Ubuntu 7.12.50.20170314-0ubuntu1) 7.12.50.20170314-git
  Copyright (C) 2017 Free Software Foundation, Inc.  
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.   
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"   
  and "show warranty" for details. 
  This GDB was configured as "x86_64-linux-gnu".   
  Type "show configuration" for configuration details. 
  For bug reporting instructions, please see:  
  . 
  Find the GDB manual and other documentation resources online at: 
  .
  For help, type "help".   
  Type "apropos word" to search for commands related to "word"...  
  Reading symbols from /usr/sbin/libvirtd...(no debugging symbols found)...done.
  [New LWP 4232]
  [New LWP 4216]
  [New LWP 4219]
  [New LWP 4218]
  [New LWP 4231]
  [New LWP 4215]
  [New LWP 4220]
  [New LWP 4224]
  [New LWP 4221]
  [New LWP 4223]
  [New LWP 4222]
  [New LWP 4217]
  [New LWP 4225]
  [New LWP 4227]
  [New LWP 4230]
  [New LWP 4229]
  [New LWP 4228]
  [Thread debugging using libthread_db enabled] 
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  Core was generated by `/usr/sbin/libvirtd'.   
  Program terminated with signal SIGSEGV, Segmentation fault.   
  #0  0x7f97fa93367f in rtnl_link_sriov_parse_vflist () from 
/usr/lib/x86_64-linux-gnu/libnl-route-3.so.200
  [Current thread is 1 (Thread 0x7f97dff94700 (LWP 4232))]  
   
  (gdb) where   
   
  #0  0x7f97fa93367f in rtnl_link_sriov_parse_vflist () from 
/usr/lib/x86_64-linux-gnu/libnl-route-3.so.200
  #1  0x7f97fa927fad in ?? () from 
/usr/lib/x86_64-linux-gnu/libnl-route-3.so.200  
  #2  0x7f980bfb76c3 in nl_cache_parse () from 
/lib/x86_64-linux-gnu/libnl-3.so.200
  #3  0x7f980bfb770b in ?? () from /lib/x86_64-linux-gnu/libnl-3.so.200 
   
  #4  0x7f980bfbdc1c in nl_recvmsgs_report () from 
/lib/x86_64-linux-gnu/libnl-3.so.200
  #5  0x7f980bfbe049 in nl_recvmsgs () from 
/lib/x86_64-linux-gnu/libnl-3.so.200   
  #6  0x7f980bfb6aab in ?? () from /lib/x86_64-linux-gnu/libnl-3.so.200 
   
  #7  0x7f980bfb763d in nl_cache_pickup () from 
/lib/x86_64-linux-gnu/libnl-3.so.200   
  #8  0x7f980bfb7871 in nl_cache_refill () from 
/lib/x86_64-linux-gnu/libnl-3.so.200   
  #9  0x7f97fa926975 in r

[Touch-packages] [Bug 1672144] Re: ifup service of network device stay active after driver stop

[Talat Batheesh]

No, not equal

:~# systemctl cat sys-subsystem-net-devices-ens1f0.device
No files found for sys-subsystem-net-devices-ens1f0.device.

:~# ifup ens1f0
ifup: interface ens1f0 already configured


:~# systemctl cat ifup@ens1f0.service
# /lib/systemd/system/ifup@.service
[Unit]
Description=ifup for %I
After=local-fs.target network-pre.target apparmor.service systemd-sysctl.service
Before=network.target shutdown.target network-online.target
Conflicts=shutdown.target
BindsTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device
DefaultDependencies=no
IgnoreOnIsolate=yes

[Service]
# avoid stopping on shutdown via stopping system-ifup.slice
Slice=system.slice
ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifup --allow=auto %I; \
if ifquery %I >/dev/null; then ifquery --state %I >/dev/null; fi'
ExecStop=/sbin/ifdown %I
RemainAfterExit=true
TimeoutStartSec=5min

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1672144

Title:
  ifup service of network device stay active after driver stop

Status in systemd package in Ubuntu:
  New

Bug description:
  The network device systemd service stay active after unload the module of 
this network device, that call close port (ndo_stop).
  once we try to load the NIC driver again, it try to start the ifup service of 
his NICs and due to the service is already up, so it fail and we didn't see the 
interface with the static configuration =.
  below simple reproduce with the Mellanox ConnectX4 device (driver name 
mlx5_core).

  Also we see this issue with Azure system, Ubuntu 17.04 guest over
  Hyper-v, the  VF failed to start after re-enable SR-IOV from VM's
  vNIC.

  
  For now we have a Work Around that to add a udev rule,
   echo DRIVERS==\"*mlx*\", SUBSYSTEM==\"net\", 
ACTION==\"add\",RUN+=\"/sbin/ifup --force $env{INTERFACE}\" > 
/lib/udev/rules.d/100-up.rules
  Example:
  #:/lib/udev/rules.d# cat 100-up.rules
  DRIVERS=="*mlx*", SUBSYSTEM=="net", ACTION=="add",RUN+="/sbin/ifup --force 
$env{INTERFACE}" 

  ***
  * More info and reproduce *
  ***
  # ifdown ens1f0
  RTNETLINK answers: Cannot assign requested address
  # ifup ens1f0 
  # ifconfig ens1f0 
  ens1f0: flags=4163  mtu 1500
  inet 123.12.23.1  netmask 255.255.0.0  broadcast 123.12.255.255
  inet6 fe80::268a:7ff:fea1:fbdc  prefixlen 64  scopeid 0x20
  ether 24:8a:07:a1:fb:dc  txqueuelen 1000  (Ethernet)
  RX packets 0  bytes 0 (0.0 B)   
  RX errors 0  dropped 0  overruns 0  frame 0 
  TX packets 17  bytes 1392 (1.3 KB)  
  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0  

  # ethtool -i ens1f0 |grep driv
  driver: mlx5_core
  # systemctl status ifup@ens1f 
  ifup@ens1f0.service  ifup@ens1f1.service

  # systemctl status ifup@ens1f0.service 
  * ifup@ens1f0.service - ifup for ens1f0  
 Loaded: loaded (/lib/systemd/system/ifup@.service; static; vendor preset: 
enabled)
 Active: active (exited) since Sun 2017-03-12 09:40:04 IST; 2h 26min ago
   
   Main PID: 1608 (code=exited, status=0/SUCCESS)   
   
 CGroup: /system.slice/ifup@ens1f0.service  
   

  Mar 12 09:40:04 qa-h-vrt-039 systemd[1]: Started ifup for ens1f0.
  Mar 12 09:40:04 qa-h-vrt-039 sh[1608]: ifup: interface ens1f0 already 
configured
  root@qa-h-vrt-039:/tmp# modprobe -rv mlx5_ib 
  rmmod mlx5_ib
  rmmod mlx5_core  

  # modprobe -rv mlx5_core

  # ifconfig -a |grep ens1f0

  # lsmod |grep mlx5

  # systemctl status ifup@ens1f0.service
  * ifup@ens1f0.service - ifup for ens1f0 
 Loaded: loaded (/lib/systemd/system/ifup@.service; static; vendor preset: 
enabled)
 Active: active (exited) since Sun 2017-03-12 09:40:04 IST; 2h 27min ago
   Main PID: 1608 (code=exited, status=0/SUCCESS)
 CGroup: /system.slice/ifup@ens1f0.service

  Mar 12 09:40:04 qa-h-vrt-039 systemd[1]: Started ifup for ens1f0.
  Mar 12 09:40:04 qa-h-vrt-039 sh[1608]: ifup: interface ens1f0 already 
configured

  # modprobe mlx5_core

  # ifconfig ens1f0
  ens1f0: flags=4098  mtu 1500
  ether 24:8a:07:a1:fb:dc  txqueuelen 1000  (Ethernet)
  RX packets 0  bytes 0 (0.0 B)
  RX errors 0  dropped 0  overruns 0  frame 0
  TX packets 0  bytes 0 (0.0 B)
  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

  
  # cat /etc/network/interfaces
  # This file describes the network interfaces available on your system
  # and how to activate them. For more information, see interfaces(5).

  
  # The loopback network interface
  auto lo
  iface lo inet loopback

  # T

[Touch-packages] [Bug 1673491] Re: [Zesty] libnl3 Segmentation fault in sriov environments

[Talat Batheesh]

Thank you, 
The fix is working, i validate it with machine that has sriov environment.
Dimitri, could you please add this fixes to the zesty release ? 

Thanks, 
Talat

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libnl3 in Ubuntu.
https://bugs.launchpad.net/bugs/1673491

Title:
  [Zesty] libnl3 Segmentation fault in sriov environments

Status in libnl3 package in Ubuntu:
  New
Status in libvirt package in Ubuntu:
  New

Bug description:
  in Ubuntu 17.04 we can't open a virt-manager, we see sefault

  This issue happen when we update from kernel 4.10.0-9-generic to
  4.10.0-11-generic

  root@:~# /usr/sbin/libvirtd
  Segmentation fault (core dumped)   

  root@:~# gdb /usr/sbin/libvirtd ./core 
  GNU gdb (Ubuntu 7.12.50.20170314-0ubuntu1) 7.12.50.20170314-git
  Copyright (C) 2017 Free Software Foundation, Inc.  
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.   
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"   
  and "show warranty" for details. 
  This GDB was configured as "x86_64-linux-gnu".   
  Type "show configuration" for configuration details. 
  For bug reporting instructions, please see:  
  . 
  Find the GDB manual and other documentation resources online at: 
  .
  For help, type "help".   
  Type "apropos word" to search for commands related to "word"...  
  Reading symbols from /usr/sbin/libvirtd...(no debugging symbols found)...done.
  [New LWP 4232]
  [New LWP 4216]
  [New LWP 4219]
  [New LWP 4218]
  [New LWP 4231]
  [New LWP 4215]
  [New LWP 4220]
  [New LWP 4224]
  [New LWP 4221]
  [New LWP 4223]
  [New LWP 4222]
  [New LWP 4217]
  [New LWP 4225]
  [New LWP 4227]
  [New LWP 4230]
  [New LWP 4229]
  [New LWP 4228]
  [Thread debugging using libthread_db enabled] 
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  Core was generated by `/usr/sbin/libvirtd'.   
  Program terminated with signal SIGSEGV, Segmentation fault.   
  #0  0x7f97fa93367f in rtnl_link_sriov_parse_vflist () from 
/usr/lib/x86_64-linux-gnu/libnl-route-3.so.200
  [Current thread is 1 (Thread 0x7f97dff94700 (LWP 4232))]  
   
  (gdb) where   
   
  #0  0x7f97fa93367f in rtnl_link_sriov_parse_vflist () from 
/usr/lib/x86_64-linux-gnu/libnl-route-3.so.200
  #1  0x7f97fa927fad in ?? () from 
/usr/lib/x86_64-linux-gnu/libnl-route-3.so.200  
  #2  0x7f980bfb76c3 in nl_cache_parse () from 
/lib/x86_64-linux-gnu/libnl-3.so.200
  #3  0x7f980bfb770b in ?? () from /lib/x86_64-linux-gnu/libnl-3.so.200 
   
  #4  0x7f980bfbdc1c in nl_recvmsgs_report () from 
/lib/x86_64-linux-gnu/libnl-3.so.200
  #5  0x7f980bfbe049 in nl_recvmsgs () from 
/lib/x86_64-linux-gnu/libnl-3.so.200   
  #6  0x7f980bfb6aab in ?? () from /lib/x86_64-linux-gnu/libnl-3.so.200 
   
  #7  0x7f980bfb763d in nl_cache_pickup () from 
/lib/x86_64-linux-gnu/libnl-3.so.200   
  #8  0x7f980bfb7871 in nl_cache_refill () from 
/lib/x86_64-linux-gnu

[Touch-packages] [Bug 1673491] Re: [Zesty] libvirtd Segmentation fault after running virt-manager

[Talat Batheesh]

Hi,

Thanks for taking a look at the bug and taking the time to help improve the 
package.
This issue is a show stopper for our products, I would appreciate it if you 
would prepare a package with the fix that we can test and verify the fix.

Thanks,
Talat

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libnl3 in Ubuntu.
https://bugs.launchpad.net/bugs/1673491

Title:
  [Zesty] libvirtd  Segmentation fault after running virt-manager

Status in libnl3 package in Ubuntu:
  New
Status in libvirt package in Ubuntu:
  New

Bug description:
  in Ubuntu 17.04 we can't open a virt-manager, we see sefault

  This issue happen when we update from kernel 4.10.0-9-generic to
  4.10.0-11-generic

  root@:~# /usr/sbin/libvirtd
  Segmentation fault (core dumped)   

  root@:~# gdb /usr/sbin/libvirtd ./core 
  GNU gdb (Ubuntu 7.12.50.20170314-0ubuntu1) 7.12.50.20170314-git
  Copyright (C) 2017 Free Software Foundation, Inc.  
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.   
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"   
  and "show warranty" for details. 
  This GDB was configured as "x86_64-linux-gnu".   
  Type "show configuration" for configuration details. 
  For bug reporting instructions, please see:  
  . 
  Find the GDB manual and other documentation resources online at: 
  .
  For help, type "help".   
  Type "apropos word" to search for commands related to "word"...  
  Reading symbols from /usr/sbin/libvirtd...(no debugging symbols found)...done.
  [New LWP 4232]
  [New LWP 4216]
  [New LWP 4219]
  [New LWP 4218]
  [New LWP 4231]
  [New LWP 4215]
  [New LWP 4220]
  [New LWP 4224]
  [New LWP 4221]
  [New LWP 4223]
  [New LWP 4222]
  [New LWP 4217]
  [New LWP 4225]
  [New LWP 4227]
  [New LWP 4230]
  [New LWP 4229]
  [New LWP 4228]
  [Thread debugging using libthread_db enabled] 
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  Core was generated by `/usr/sbin/libvirtd'.   
  Program terminated with signal SIGSEGV, Segmentation fault.   
  #0  0x7f97fa93367f in rtnl_link_sriov_parse_vflist () from 
/usr/lib/x86_64-linux-gnu/libnl-route-3.so.200
  [Current thread is 1 (Thread 0x7f97dff94700 (LWP 4232))]  
   
  (gdb) where   
   
  #0  0x7f97fa93367f in rtnl_link_sriov_parse_vflist () from 
/usr/lib/x86_64-linux-gnu/libnl-route-3.so.200
  #1  0x7f97fa927fad in ?? () from 
/usr/lib/x86_64-linux-gnu/libnl-route-3.so.200  
  #2  0x7f980bfb76c3 in nl_cache_parse () from 
/lib/x86_64-linux-gnu/libnl-3.so.200
  #3  0x7f980bfb770b in ?? () from /lib/x86_64-linux-gnu/libnl-3.so.200 
   
  #4  0x7f980bfbdc1c in nl_recvmsgs_report () from 
/lib/x86_64-linux-gnu/libnl-3.so.200
  #5  0x7f980bfbe049 in nl_recvmsgs () from 
/lib/x86_64-linux-gnu/libnl-3.so.200   
  #6  0x7f980bfb6aab in ?? () from /lib/x86_64-linux-gnu/libnl-3.so.200 
   
  #7  0x7f980bfb763d in nl_cache_pickup () from 
/lib/x86_64-linux-gnu/libnl-3.so.200 

[Touch-packages] [Bug 1672144] [NEW] ifup service of network device stay active after driver stop

[Talat Batheesh]

Public bug reported:

The network device systemd service stay active after unload the module of this 
network device, that call close port (ndo_stop).
once we try to load the NIC driver again, it try to start the ifup service of 
his NICs and due to the service is already up, so it fail and we didn't see the 
interface with the static configuration =.
below simple reproduce with the Mellanox ConnectX4 device (driver name 
mlx5_core).

Also we see this issue with Azure system, Ubuntu 17.04 guest over
Hyper-v, the  VF failed to start after re-enable SR-IOV from VM's vNIC.


For now we have a Work Around that to add a udev rule,
 echo DRIVERS==\"*mlx*\", SUBSYSTEM==\"net\", 
ACTION==\"add\",RUN+=\"/sbin/ifup --force $env{INTERFACE}\" > 
/lib/udev/rules.d/100-up.rules
Example:
#:/lib/udev/rules.d# cat 100-up.rules
DRIVERS=="*mlx*", SUBSYSTEM=="net", ACTION=="add",RUN+="/sbin/ifup --force 
$env{INTERFACE}" 

***
* More info and reproduce *
***
# ifdown ens1f0
RTNETLINK answers: Cannot assign requested address
# ifup ens1f0 
# ifconfig ens1f0 
ens1f0: flags=4163  mtu 1500
inet 123.12.23.1  netmask 255.255.0.0  broadcast 123.12.255.255
inet6 fe80::268a:7ff:fea1:fbdc  prefixlen 64  scopeid 0x20
ether 24:8a:07:a1:fb:dc  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)   
RX errors 0  dropped 0  overruns 0  frame 0 
TX packets 17  bytes 1392 (1.3 KB)  
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0  

# ethtool -i ens1f0 |grep driv
driver: mlx5_core
# systemctl status ifup@ens1f 
ifup@ens1f0.service  ifup@ens1f1.service

# systemctl status ifup@ens1f0.service 
* ifup@ens1f0.service - ifup for ens1f0  
   Loaded: loaded (/lib/systemd/system/ifup@.service; static; vendor preset: 
enabled)
   Active: active (exited) since Sun 2017-03-12 09:40:04 IST; 2h 26min ago  
 
 Main PID: 1608 (code=exited, status=0/SUCCESS) 
 
   CGroup: /system.slice/ifup@ens1f0.service
 

Mar 12 09:40:04 qa-h-vrt-039 systemd[1]: Started ifup for ens1f0.
Mar 12 09:40:04 qa-h-vrt-039 sh[1608]: ifup: interface ens1f0 already configured
root@qa-h-vrt-039:/tmp# modprobe -rv mlx5_ib 
rmmod mlx5_ib
rmmod mlx5_core  

# modprobe -rv mlx5_core

# ifconfig -a |grep ens1f0

# lsmod |grep mlx5

# systemctl status ifup@ens1f0.service
* ifup@ens1f0.service - ifup for ens1f0 
   Loaded: loaded (/lib/systemd/system/ifup@.service; static; vendor preset: 
enabled)
   Active: active (exited) since Sun 2017-03-12 09:40:04 IST; 2h 27min ago
 Main PID: 1608 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/ifup@ens1f0.service

Mar 12 09:40:04 qa-h-vrt-039 systemd[1]: Started ifup for ens1f0.
Mar 12 09:40:04 qa-h-vrt-039 sh[1608]: ifup: interface ens1f0 already configured

# modprobe mlx5_core

# ifconfig ens1f0
ens1f0: flags=4098  mtu 1500
ether 24:8a:07:a1:fb:dc  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).


# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eno1
iface eno1 inet dhcp

#ens1f0
auto ens1f0
iface ens1f0 inet static
address 123.12.23.1
netmask 255.255.0.0
mtu 1500


*
* Another repto and investigate *
*
once interface is created the system starts a service that is responsible for 
activating it (basically runs ifup).
so, at first shot everything works.
at the second driver reload:
Good flow (on good setup 4.9.0-rc5+):
1. driver is unloaded and the interface’s “ifup” service is shutdown:
Feb 23 00:54:09 reg-l-vrt-206-006 kernel: [6.790189] mlx4_en: enP43508p0s2: 
Close port called
Feb 23 00:54:09 reg-l-vrt-206-006 kernel: [6.868484] hv_netvsc 
a2be13bb-7244-44ff-a31a-dea8d58a79da eth1: VF down: enP43508p0s2
Feb 23 00:54:09 reg-l-vrt-206-006 kernel: [6.868487] hv_netvsc 
a2be13bb-7244-44ff-a31a-dea8d58a79da eth1: Data path switched from VF: 
enP43508p0s2
Feb 23 00:54:09 reg-l-vrt-206-006 kernel: [6.869575] hv_netvsc 
a2be13bb-7244-44ff-a31a-dea8d58a79da eth1: VF unregistering: enP43508p0s2
Feb 23 00:54:09 reg-l-vrt-206-006 systemd1: Stopping ifup for enP43508p0s2...
Feb 23 00:54:09 reg-l-vrt-206-006 ifdown47196: Cannot find device 
"enP43508p0s2" 
Feb 23 00:54:09 reg-l-vrt-206-006 ifdown47196: Cannot find device 
"enP43508p0s2" 
Feb 23 0

[Touch-packages] [Bug 1669317] Re: iproute2: range error adding rules from tc

[Talat Batheesh]

This Bug invalid due to iproute 4.9.0 doesn't support Matching Arp.


** Changed in: iproute2 (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1669317

Title:
  iproute2: range error adding rules from tc

Status in iproute2 package in Ubuntu:
  Invalid

Bug description:
  Trying to add a rule from tc resulted in an ERANGE error

  example:
  # tc filter add dev ens5f0_0 protocol ip parent : flower skip_hw dst_mac 
e4:11:22:11:4a:51 src_mac e4:11:22:11:4a:50 ip_proto tcp src_ip 1.1.1.1 dst_ip 
2.2.2.2 action drop 

   
  RTNETLINK answers: Numerical result out of range   

  iproute2 is the newest version (4.9.0-1ubuntu1).

  The fix is already upstream.
  Attached fix.

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

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

[Touch-packages] [Bug 1669317] Re: iproute2: range error adding rules from tc

[Talat Batheesh]

** Patch added: "tc fix"
   
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1669317/+attachment/4829659/+files/0001-tc-flower-Fix-parsing-ip-address.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1669317

Title:
  iproute2: range error adding rules from tc

Status in iproute2 package in Ubuntu:
  New

Bug description:
  Trying to add a rule from tc resulted in an ERANGE error

  example:
  # tc filter add dev ens5f0_0 protocol ip parent : flower skip_hw dst_mac 
e4:11:22:11:4a:51 src_mac e4:11:22:11:4a:50 ip_proto tcp src_ip 1.1.1.1 dst_ip 
2.2.2.2 action drop 

   
  RTNETLINK answers: Numerical result out of range   

  iproute2 is the newest version (4.9.0-1ubuntu1).

  The fix is already upstream.
  Attached fix.

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

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

[Touch-packages] [Bug 1669317] [NEW] iproute2: range error adding rules from tc

[Talat Batheesh]

Public bug reported:

Trying to add a rule from tc resulted in an ERANGE error

example:
# tc filter add dev ens5f0_0 protocol ip parent : flower skip_hw dst_mac 
e4:11:22:11:4a:51 src_mac e4:11:22:11:4a:50 ip_proto tcp src_ip 1.1.1.1 dst_ip 
2.2.2.2 action drop 

   
RTNETLINK answers: Numerical result out of range   

iproute2 is the newest version (4.9.0-1ubuntu1).

The fix is already upstream.
Attached fix.

** Affects: iproute2 (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1669317

Title:
  iproute2: range error adding rules from tc

Status in iproute2 package in Ubuntu:
  New

Bug description:
  Trying to add a rule from tc resulted in an ERANGE error

  example:
  # tc filter add dev ens5f0_0 protocol ip parent : flower skip_hw dst_mac 
e4:11:22:11:4a:51 src_mac e4:11:22:11:4a:50 ip_proto tcp src_ip 1.1.1.1 dst_ip 
2.2.2.2 action drop 

   
  RTNETLINK answers: Numerical result out of range   

  iproute2 is the newest version (4.9.0-1ubuntu1).

  The fix is already upstream.
  Attached fix.

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

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

[Touch-packages] [Bug 1638256] [NEW] ifup fail when use MTU small than 68

[Talat Batheesh]

Public bug reported:

ifup failed when we set a static MTU small than 68, and when we change the 
static configuration and try to run ifdown and then ifup, the interface still 
with the old MTU and both of ifup and ifdown command fail.
when we change the MTU manually by ip tool and then change it in the 
/etc/network/interfaces to be 1500 the interface get back to work.

root:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 16.10
Release:16.10
Codename:   yakkety
root:~# uname -r
4.8.0-26-generic


scenario: 
set the MTU static to 67 

root:~# ifdown ens2
root:~# ifup ens2
root:~# ifdown ens2
RTNETLINK answers: No such device
root:~# ifup ens2
RTNETLINK answers: No buffer space available
Failed to bring up ens2.
root:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

auto ens2
iface ens2 inet static
address 21.3.5.16
mtu 67

## change MTU static to 1500 
root:~# vim /etc/network/interfaces
root:~# ifdown ens2
ifdown: interface ens2 not configured
root:~# ifup ens2
RTNETLINK answers: No buffer space available
Failed to bring up ens2.

root:~# ip link set ens2 mtu 1500
root:~# ifup ens2

** Affects: ifupdown (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1638256

Title:
  ifup fail when use MTU small than 68

Status in ifupdown package in Ubuntu:
  New

Bug description:
  ifup failed when we set a static MTU small than 68, and when we change the 
static configuration and try to run ifdown and then ifup, the interface still 
with the old MTU and both of ifup and ifdown command fail.
  when we change the MTU manually by ip tool and then change it in the 
/etc/network/interfaces to be 1500 the interface get back to work.

  root:~# lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu 16.10
  Release:16.10
  Codename:   yakkety
  root:~# uname -r
  4.8.0-26-generic

  
  scenario: 
  set the MTU static to 67 

  root:~# ifdown ens2
  root:~# ifup ens2
  root:~# ifdown ens2
  RTNETLINK answers: No such device
  root:~# ifup ens2
  RTNETLINK answers: No buffer space available
  Failed to bring up ens2.
  root:~# cat /etc/network/interfaces
  # This file describes the network interfaces available on your system
  # and how to activate them. For more information, see interfaces(5).

  auto ens2
  iface ens2 inet static
  address 21.3.5.16
  mtu 67

  ## change MTU static to 1500 
  root:~# vim /etc/network/interfaces
  root:~# ifdown ens2
  ifdown: interface ens2 not configured
  root:~# ifup ens2
  RTNETLINK answers: No buffer space available
  Failed to bring up ens2.

  root:~# ip link set ens2 mtu 1500
  root:~# ifup ens2

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

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

[Touch-packages] [Bug 1115710] Re: Mellanox mlx4_en network driver is not automatically loaded

[Talat Batheesh]

Hi,

This Fix is for old releases that doesn't include mlx4_en in their initramfs.
Now, that the initrd include the mlx4_en, so no need to creating a mlx4.conf 
file with softdep mlx4_core post: mlx4_en
After removing this file we see that mlx4_en loaded after boot due to mlx4_core 
request a module according to the port type -

drivers/net/ethernet/mellanox/mlx4/main.c
static void mlx4_request_modules(struct mlx4_dev *dev)
{
int port;
int has_ib_port = false;
int has_eth_port = false;
#define EN_DRV_NAME "mlx4_en"
#define IB_DRV_NAME "mlx4_ib"

for (port = 1; port <= dev->caps.num_ports; port++) {
if (dev->caps.port_type[port] == MLX4_PORT_TYPE_IB)
has_ib_port = true;
else if (dev->caps.port_type[port] == MLX4_PORT_TYPE_ETH)
has_eth_port = true;
}

if (has_eth_port)
request_module_nowait(EN_DRV_NAME);
if (has_ib_port || (dev->caps.flags & MLX4_DEV_CAP_FLAG_IBOE))
request_module_nowait(IB_DRV_NAME);
}


We are debianize rdma-utils package that create a file 
/etc/modpobe.d/mlx4.conf, according to Debian policy  package shouldn't modify 
files installed by another package in any way, it's forbidden.
in addition the rdma service create the same file name and add the following 
install mlx4_core /sbin/modprobe --ignore-install mlx4_core && (if [ -f 
/usr/libexec/mlx4-setup.sh -a -f /etc/rdma/mlx4.conf ]; then 
/usr/libexec/mlx4-setup.sh < /etc/rdma/mlx4.conf; fi; /sbin/modprobe mlx4_en; 
/sbin/modprobe mlx4_ib)
this should load the diver with the requested port type configuration.

could you please revert this fix?

Thanks,
Talat

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to kmod in Ubuntu.
https://bugs.launchpad.net/bugs/1115710

Title:
  Mellanox mlx4_en network driver is not automatically loaded

Status in MAAS:
  Invalid
Status in kmod package in Ubuntu:
  Fix Released
Status in module-init-tools package in Ubuntu:
  Invalid
Status in module-init-tools source package in Precise:
  Triaged
Status in module-init-tools source package in Quantal:
  Won't Fix
Status in kmod source package in Raring:
  Fix Released

Bug description:
  The Mellanox Ethernet card module is not being loaded in the ephemeral
  images, which causes enlisting/commissioning to fail to boot the root
  image from ISCSI, given that the interface is not loaded.

  Related bugs:
   * bug 1015339: installer initrd missing kernel modules for Mellanox ConnectX 
HCA Ethernet

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1115710/+subscriptions

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Talat Batheesh]

Hi Rafael,
Thank you for the great job.
The Broadcast flag is working, the packet drop was in the switch.
We will ask our costumer to install this PPA, will update later.

Thank you,
Talat

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1529815

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  In Progress
Status in isc-dhcp source package in Trusty:
  In Progress
Status in isc-dhcp source package in Wily:
  In Progress
Status in isc-dhcp source package in Xenial:
  In Progress

Bug description:
  
  DHCP client is sending discover with Unicast type request for the offer, in 
this configuration of IB to ETH through a relay we need the type to be 
broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  
  DHCP CLIENT (IPoIB) 
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Talat Batheesh]

The DHCP Relay issue still has not been resolved.
The issue was DHCP Offer packets that being sent from the DHCP server are not 
reaching the client.

Setup:
DHCP Client: IB SideUbuntu OS with ConnectX3 FW ver 2.35.5000, Mellanox 
OFED 3.2-1.0.1
DHCP Server: ETH Side   Win2012  R2 with ConnectX3 FW ver 2.35.5000, WinOF 5.10 
   
SX GW, MLNX_OS ver 3.4.3002 


Looking at the traffic capture I can see packets are coming from the Windows 
server towards the switch, but never leaving it.
Please refer to the following traffic capture files attached to the case:
Ibdump_dhcp – capture of ib0
Dhcp.pcap – port mirroring of the ETH port connected to the Windows
Dhcp_win2012 - wireshark capture of the windows dhcp server 

Setup details is mentioned &  marked above.


Setup:
IB Side: DHCP Client  Ubunutu 14.04,   OFED 3.2-1.0.1.1,  CX3 2.35.5000 
(10.7.55.193)
ETH Side: DHCP Server Win2012 R2, WinOF 5.10,CX3 2.35.5000 
(10.7.55.190)
SX1036  GW:   MLNX_OS ver 3.4.3002

Before installing the PPA
DHCP client sends discover, DHCP server send offer, however the packet never 
reach the client, bootp flag is Unicast


** Attachment added: "dhcpcase files"
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+attachment/4597819/+files/dhcpcase.rar

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1529815

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  In Progress
Status in isc-dhcp source package in Trusty:
  In Progress
Status in isc-dhcp source package in Wily:
  In Progress
Status in isc-dhcp source package in Xenial:
  In Progress

Bug description:
  
  DHCP client is sending discover with Unicast type request for the offer, in 
this configuration of IB to ETH through a relay we need the type to be 
broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  
  DHCP CLIENT (IPoIB) 
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Talat Batheesh]

This is pacp for other vendor

** Attachment added: "rhel_discover.pcap"
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+attachment/4541720/+files/rhel_discover.pcap

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1529815

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  New

Bug description:
  
  DHCP client is sending discover with Unicast type request for the offer, in 
this configuration of IB to ETH through a relay we need the type to be 
broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  
  DHCP CLIENT (IPoIB) 
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1529815] [NEW] InfiniBand DHCP flow with PRA and DHCP relay not working

[Talat Batheesh]

Public bug reported:


DHCP client is sending discover with Unicast type request for the offer, in 
this configuration of IB to ETH through a relay we need the type to be 
broadcast.

The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
this issue exist even when we use always-broadcast statement in configuration 
file.

in other vendors we see that discover request type is broadcast.
attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.


DHCP CLIENT (IPoIB) 
Ubuntu 14.04  kernel 3.13.0-74
Mellanox OFED 3.1-1.0.3 or inbox driver
isc-dhcp-client  4.2.4-7ubuntu12.3

** Affects: isc-dhcp (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: trusty

** Attachment added: "Ubuntu pcap file"
   
https://bugs.launchpad.net/bugs/1529815/+attachment/4541675/+files/ubuntu_inbox.pcap

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1529815

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  New

Bug description:
  
  DHCP client is sending discover with Unicast type request for the offer, in 
this configuration of IB to ETH through a relay we need the type to be 
broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  
  DHCP CLIENT (IPoIB) 
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1312419] Re: nl_cache_refill; rtnl_neigh_get fail to find neighbors in cache

[Talat Batheesh]

Hi Rafael,

After updating libibverbs and libmlx4 (upstream version) from the
openfabrics, the issue solved.

git clone git://git.kernel.org/pub/scm/libs/infiniband/libibverbs.git libibverbs
git clone git://git.openfabrics.org/~yishaih/libmlx4.git

# apt-get install libnl-3-dev libnl-route-3-dev

we must to update the libibverbs abd libmlx4 to updated version.

Yours,
Talat

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libnl3 in Ubuntu.
https://bugs.launchpad.net/bugs/1312419

Title:
  nl_cache_refill; rtnl_neigh_get fail to find neighbors in cache

Status in libnl3 package in Ubuntu:
  In Progress

Bug description:
  Retrieving information about configured neighbors fail 
  my application is running the following procedure:

  neigh = NULL;
  cache = rtnl_neigh_alloc_cache(sk);
  while(NULL == neigh){
  nl_cache_refill(sk, chache);
  neigh = rtnl_neigh_get(cache, ifindex, dst_addr);
  }

  with libnl3 3.2.21-1 this loop will never end, even when adding a static arp 
entry.
  However, with libnl-3.2.24 the neighbor lookup succeed.

  additional general info:
  $ lsb_release -rd
  Description:Ubuntu 14.04 LTS
  Release:14.04
  $ uname -r
  3.13.0-24-generic
  $ apt-cache policy libnl-genl-3-200 libnl-route-3-200
  libnl-genl-3-200:
Installed: 3.2.21-1
Candidate: 3.2.21-1
Version table:
   *** 3.2.21-1 0
  500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
  100 /var/lib/dpkg/status
  libnl-route-3-200:
Installed: 3.2.21-1
Candidate: 3.2.21-1
Version table:
   *** 3.2.21-1 0
  500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
  100 /var/lib/dpkg/status

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

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

[Touch-packages] [Bug 1312419] Re: nl_cache_refill; rtnl_neigh_get fail to find neighbors in cache

[Talat Batheesh]

Hi Rafael,

 Unfortunately, after installing the PPA, the udaddy test still fail on Ubuntu 
14.04.3 LTS.
Tested with ConnectX3-pro.


root # udaddy -b 1.1.1.1
udaddy: starting server
receiving data transfers

^C
root# uname -r
3.13.0-68-generic
root# cat /etc/issue
Ubuntu 14.04.3 LTS \n \l


Client side 
# udaddy  -s 1.1.1.1 -b 1.1.1.2
udaddy: starting client
udaddy: connecting
udaddy: failure creating address handle
test complete
return status -1

As a reference, may we need to add the following patches that mentioned in Bug 
#1364442 
“
Ubuntu is missing some code to make this work. The issue is that libmlx4 and 
libibverbs is missing the code for RoCE UD neighboor code.
Here I found the series of patches needed:
For libmlx4:
[PATCH libmlx4 V4 0/2] Add RoCE IP based addressing support for UD QPs
[PATCH libmlx4 V4 1/2] Add ibv_query_port caching support
[PATCH libmlx4 V4 2/2] Add RoCE IP based addressing support for UD QPs
For libibverbs:
[PATCH libibverbs V5 0/2] Use neighbour lookup for RoCE UD QPs Eth L2 resolution
[PATCH libibverbs V5 1/2] Add ibv_port_cap_flags
[PATCH libibverbs V5 2/2] Use neighbour lookup for RoCE UD QPs Eth L2 resolution
”

Yours,
Talat

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libnl3 in Ubuntu.
https://bugs.launchpad.net/bugs/1312419

Title:
  nl_cache_refill; rtnl_neigh_get fail to find neighbors in cache

Status in libnl3 package in Ubuntu:
  In Progress

Bug description:
  Retrieving information about configured neighbors fail 
  my application is running the following procedure:

  neigh = NULL;
  cache = rtnl_neigh_alloc_cache(sk);
  while(NULL == neigh){
  nl_cache_refill(sk, chache);
  neigh = rtnl_neigh_get(cache, ifindex, dst_addr);
  }

  with libnl3 3.2.21-1 this loop will never end, even when adding a static arp 
entry.
  However, with libnl-3.2.24 the neighbor lookup succeed.

  additional general info:
  $ lsb_release -rd
  Description:Ubuntu 14.04 LTS
  Release:14.04
  $ uname -r
  3.13.0-24-generic
  $ apt-cache policy libnl-genl-3-200 libnl-route-3-200
  libnl-genl-3-200:
Installed: 3.2.21-1
Candidate: 3.2.21-1
Version table:
   *** 3.2.21-1 0
  500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
  100 /var/lib/dpkg/status
  libnl-route-3-200:
Installed: 3.2.21-1
Candidate: 3.2.21-1
Version table:
   *** 3.2.21-1 0
  500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
  100 /var/lib/dpkg/status

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

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