Re: Ensuring predictable MAC address for bond interface

2014-10-07 Thread Dan Williams 
On Mon, 2014-10-06 at 12:51 -0700, Ed Swierk wrote:
 I'm using NetworkManager on a server with two wired Ethernet interfaces
 (eth0 and eth1) configured as slaves of a bond in active-backup mode. I'd
 like the bond interface to always be assigned eth0's MAC address.
 
 This is easy with old-school static network configuration like ifupdown:
 just make eth0 the first slave of the bond interface, and Linux will copy
 eth0's MAC address to the bond.
 
 When NetworkManager starts up and reads system-interface config files, it
 creates the bond interface right away, but doesn't add a slave until it
 notices that the slave's link is up (i.e. carrier is 1). And of course the
 link state depends on lots of things, like whether a cable is plugged in
 and the state of the switch or host at the other end. Thus whether eth0 or
 eth1 gets enslaved to the bond first is unpredictable, meaning the bond
 interface's MAC address is unpredictable. This is troublesome in some
 environments, such as ones where a DHCP server assigns IP addresses based
 on the MAC address of the client.

Does setting the primary bond option when in active-backup mode to
eth0 make things better?  In nm-connection-editor it'll be in the page
for Bond options, in nmtui it'll be in about the same place, and in
nmcli you'd do:

nmcli con mod Bond1 +bond.options primary=eth0

and then re-activate the connection.  Let me know if that does/doesn't
help.  (note; this may only work with 0.9.10+)

Dan

 NetworkManager already treats a bond slave interface differently when its
 link goes down, leaving it in DISCONNECTED state rather than switching it
 to UNAVAILABLE. So there's precedent for having a bond interface with one
 or more link-down slave interfaces. I think the easiest way to achieve a
 stable MAC address is to extend that behavior to the startup case: as soon
 as NetworkManager sees an interface that's configured as a bond slave, it
 should move it from UNAVAILABLE to DISCONNECTED. That way the first
 configured slave interface, rather than the first one with link up, is
 enslaved to the bond.
 
 I couldn't figure out a way to configure this in NetworkManager 0.9.8.10,
 nor in mainline code. As a proof of concept, I hacked
 nm_device_state_changed() in src/nm-device.c: in the second switch(state),
 UNAVAILABLE case, I force the transition to DISCONNECTED for eth0 and eth1.
 This works as I'd hoped: both interfaces are enslaved right away, with eth0
 always first.
 
 I didn't see any easy way to implement this behavior cleanly, though. This
 new behavior should apply only to bond slave interfaces. At the point where
 nm_device_state_changed() is called, there's not yet a corresponding
 connection for eth0 or eth1, so I can't check whether the interface is
 configured as a bond slave. I thought I'd ask for advice before spending
 more time on this.
 
 Any help would be appreciated!
 
 --Ed
 ___
 networkmanager-list mailing list
 networkmanager-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/networkmanager-list


___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Link MTU option ignored in IPv6 router advertisements

2014-10-07 Thread Chuck Anderson 
Thanks, bug filed:

https://bugzilla.gnome.org/show_bug.cgi?id=738104

On Fri, Oct 03, 2014 at 12:01:38PM -0500, Dan Williams wrote:
 On Fri, 2014-10-03 at 11:36 -0400, Chuck Anderson wrote:
  I'm not sure if this is a kernel thing or a NetworkManager thing.  Did
  something change in how IPv6 router advertisements are handled by
  NetworkManager in Fedora 20?
 
 I think it's a NetworkManager thing.  We'll fix it.
 
 Dan
 
  On my Fedora 20 system, the Link MTU option recevied from IPv6 router
  advertisements is not being applied to the interface configuration:
  
  kernel-3.16.2-200.fc20.x86_64
  NetworkManager-0.9.9.0-44.git20131003.fc20.x86_64
  
  cat /proc/sys/net/ipv6/conf/wlp2s0/mtu 
  1500
  
  On my Fedora 19 system, this is working:
  
  kernel-3.14.18-100.fc19.x86_64
  NetworkManager-0.9.8.8-2.fc19.x86_64
  
  cat /proc/sys/net/ipv6/conf/p4p1/mtu
  1480
  
  In both cases, the RA has the Link MTU option:
  
  sudo rdisc6 -1 wlp2s0
  Soliciting ff02::2 (ff02::2) on wlp2s0...
  
  Hop limit :   64 (  0x40)
  Stateful address conf.:   No
  Stateful other conf.  :   No
  Mobile home agent :   No
  Router preference :   medium
  Neighbor discovery proxy  :   No
  Router lifetime   :  300 (0x012c) seconds
  Reachable time:  unspecified (0x)
  Retransmit time   :  unspecified (0x)
   Prefix   : 2001:::1::1/64
On-link :  Yes
Autonomous address conf.:  Yes
Valid time  :  300 (0x012c) seconds
Pref. time  :  300 (0x012c) seconds
   MTU  : 1480 bytes (valid)
   Source link-layer address: 68:7F:74:xx:xx:xx
   from fe80::6a7f:74ff:fexx:
  
  I need this option because my IPv6 router uses a HE.net tunnel which
  adds 20 bytes of overhead for the 6in4 encapsulation, and many sites
  break PMTUD which causes those sites to hang.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

[MM PATCH] port-serial: fix forced closing after b28230411

2014-10-07 Thread Dan Williams 
b28230411 moved up the self-priv-forced_close = TRUE, which
caused mm_port_serial_close() to just return without actually
closing the port and cleaning up.

Also, cancel the reopen separately from closing the port since
the two operations are actually independent of each other.
---
 src/mm-port-serial.c | 43 +++
 1 file changed, 23 insertions(+), 20 deletions(-)

diff --git a/src/mm-port-serial.c b/src/mm-port-serial.c
index 9b74900..3af1b8e 100644
--- a/src/mm-port-serial.c
+++ b/src/mm-port-serial.c
@@ -1270,33 +1270,31 @@ mm_port_serial_is_open (MMPortSerial *self)
 {
 g_return_val_if_fail (self != NULL, FALSE);
 g_return_val_if_fail (MM_IS_PORT_SERIAL (self), FALSE);
 
 return !!self-priv-open_count;
 }
 
-void
-mm_port_serial_close (MMPortSerial *self)
+static void
+_close_internal (MMPortSerial *self, gboolean force)
 {
 const char *device;
 int i;
 
 g_return_if_fail (MM_IS_PORT_SERIAL (self));
 
-/* If we forced closing the port, open_count will be 0 already.
- * Just return without issuing any warning */
-if (self-priv-forced_close)
-return;
-
-g_return_if_fail (self-priv-open_count  0);
+if (force)
+self-priv-open_count = 0;
+else {
+g_return_if_fail (self-priv-open_count  0);
+self-priv-open_count--;
+}
 
 device = mm_port_get_device (MM_PORT (self));
 
-self-priv-open_count--;
-
 mm_dbg ((%s) device open count is %d (close), device, 
self-priv-open_count);
 
 if (self-priv-open_count  0)
 return;
 
 if (self-priv-connected_id) {
 g_signal_handler_disconnect (self, self-priv-connected_id);
@@ -1398,43 +1396,48 @@ mm_port_serial_close (MMPortSerial *self)
   self-priv-cancellable_id);
 self-priv-cancellable_id = 0;
 }
 
 g_clear_object (self-priv-cancellable);
 }
 
+void
+mm_port_serial_close (MMPortSerial *self)
+{
+g_return_if_fail (MM_IS_PORT_SERIAL (self));
+
+if (!self-priv-forced_close)
+_close_internal (self, FALSE);
+}
+
 static void
 port_serial_close_force (MMPortSerial *self)
 {
-g_return_if_fail (self != NULL);
 g_return_if_fail (MM_IS_PORT_SERIAL (self));
 
 /* If already forced to close, return */
 if (self-priv-forced_close)
 return;
 
 mm_dbg ((%s) forced to close port, mm_port_get_device (MM_PORT (self)));
 
 /* Mark as having forced the close, so that we don't warn about incorrect
  * open counts */
 self-priv-forced_close = TRUE;
 
-/* If already closed, done */
-if (!self-priv-open_count  !self-priv-reopen_ctx)
-return;
-
 /* Cancel port reopening if one is running */
 port_serial_reopen_cancel (self);
 
-/* Force the port to close */
-self-priv-open_count = 1;
-mm_port_serial_close (self);
+/* If already closed, done */
+if (self-priv-open_count  0) {
+_close_internal (self, TRUE);
 
-/* Notify about the forced close status */
-g_signal_emit (self, signals[FORCED_CLOSE], 0);
+/* Notify about the forced close status */
+g_signal_emit (self, signals[FORCED_CLOSE], 0);
+}
 }
 
 /*/
 /* Reopen */
 
 typedef struct {
 MMPortSerial *self;
-- 
1.9.3


___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Ad-Hoc network creation took too long, failing activation

2014-10-07 Thread poma 

Starting Network Manager...
info NetworkManager (version 0.9.10.0-5.git20140704.fc21) is starting...
info WEXT support is enabled
info WiFi hardware radio set enabled
info Loaded device plugin: /usr/lib/NetworkManager/libnm-device-plugin-wifi.so
info WiFi enabled by radio killswitch; enabled by state file
info Networking is enabled by state file
Started Network Manager.
info (ra0): driver does not support SSID scans (scan_capa 0x00).
info (ra0): using WEXT for WiFi device control
info (ra0): new 802.11 WiFi device (driver: 'usb' ifindex: 5)
info (ra0): exported as /org/freedesktop/NetworkManager/Devices/4
info (ra0): device state change: unmanaged - unavailable (reason 'managed') 
[10 20 2]
info (ra0): preparing device
warn (ra0): error 100 getting card mode
error [1412709645.317223] [platform/wifi/wifi-utils-wext.c:160] 
wifi_wext_set_mode(): (ra0): error setting mode 2
info wpa_supplicant started
info (ra0) supports 1 scan SSIDs
info (ra0): supplicant interface state: starting - ready
info (ra0): device state change: unavailable - disconnected (reason 
'supplicant-available') [20 30 42]
info (ra0): supplicant interface state: ready - disconnected
info (ra0) supports 1 scan SSIDs
info startup complete
info (ra0): supplicant interface state: disconnected - inactive
...
info (ra0): disconnecting for new activation request.
info (ra0): device state change: activated - deactivating (reason 'none') 
[100 110 0]
info NetworkManager state is now DISCONNECTING
info (ra0): device state change: deactivating - disconnected (reason 'none') 
[110 30 0]
info (ra0): deactivating device (reason 'none') [0]
info (ra0): canceled DHCP transaction, DHCP client pid 1144
info NetworkManager state is now DISCONNECTED
info Activation (ra0) starting connection 'bla'
info Activation (ra0) Stage 1 of 5 (Device Prepare) scheduled...
warn Connection disconnected (reason -3)
info (ra0): supplicant interface state: completed - disconnected
info Activation (ra0) Stage 1 of 5 (Device Prepare) started...
info (ra0): device state change: disconnected - prepare (reason 'none') [30 
40 0]
info NetworkManager state is now CONNECTING
info Activation (ra0) Stage 2 of 5 (Device Configure) scheduled...
info Activation (ra0) Stage 1 of 5 (Device Prepare) complete.
info Activation (ra0) Stage 2 of 5 (Device Configure) starting...
info (ra0): device state change: prepare - config (reason 'none') [40 50 0]
info Activation (ra0/wireless): connection 'bla' has security, and secrets 
exist.  No new secrets needed.
info Config: added 'ssid' value 'bla'
info Config: added 'mode' value '1'
info Config: added 'frequency' value '2412'
info Config: added 'key_mgmt' value 'NONE'
info Config: added 'auth_alg' value 'OPEN'
info Config: added 'wep_key0' value 'omitted'
info Config: added 'wep_tx_keyidx' value '0'
info Activation (ra0) Stage 2 of 5 (Device Configure) complete.
info Config: set interface ap_scan to 2
info (ra0): supplicant interface state: disconnected - associating
warn Activation (ra0/wireless): Ad-Hoc network creation took too long, 
failing activation.
info (ra0): device state change: config - failed (reason 
'supplicant-timeout') [50 120 11]
info NetworkManager state is now DISCONNECTED
warn Activation (ra0) failed for connection 'bla'
warn Connection disconnected (reason -3)
info (ra0): supplicant interface state: associating - disconnected
info (ra0): device state change: failed - disconnected (reason 'none') [120 
30 0]
info (ra0): deactivating device (reason 'none') [0]
warn (ra0): error 100 getting card mode
error [1412717534.522258] [platform/wifi/wifi-utils-wext.c:160] 
wifi_wext_set_mode(): (ra0): error setting mode 2


IBSS works via Wicd although not reliable.
BTW AP/WPA2, is it possible at all?


poma





___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [MM PATCH] port-serial: fix forced closing after b28230411

2014-10-07 Thread Aleksander Morgado 
On Tue, Oct 7, 2014 at 11:06 PM, Dan Williams d...@redhat.com wrote:
 b28230411 moved up the self-priv-forced_close = TRUE, which
 caused mm_port_serial_close() to just return without actually
 closing the port and cleaning up.

 Also, cancel the reopen separately from closing the port since
 the two operations are actually independent of each other.

Looks good to me; I'd get it also in the mm-1-4 branch as well.

 ---
  src/mm-port-serial.c | 43 +++
  1 file changed, 23 insertions(+), 20 deletions(-)

 diff --git a/src/mm-port-serial.c b/src/mm-port-serial.c
 index 9b74900..3af1b8e 100644
 --- a/src/mm-port-serial.c
 +++ b/src/mm-port-serial.c
 @@ -1270,33 +1270,31 @@ mm_port_serial_is_open (MMPortSerial *self)
  {
  g_return_val_if_fail (self != NULL, FALSE);
  g_return_val_if_fail (MM_IS_PORT_SERIAL (self), FALSE);

  return !!self-priv-open_count;
  }

 -void
 -mm_port_serial_close (MMPortSerial *self)
 +static void
 +_close_internal (MMPortSerial *self, gboolean force)
  {
  const char *device;
  int i;

  g_return_if_fail (MM_IS_PORT_SERIAL (self));

 -/* If we forced closing the port, open_count will be 0 already.
 - * Just return without issuing any warning */
 -if (self-priv-forced_close)
 -return;
 -
 -g_return_if_fail (self-priv-open_count  0);
 +if (force)
 +self-priv-open_count = 0;
 +else {
 +g_return_if_fail (self-priv-open_count  0);
 +self-priv-open_count--;
 +}

  device = mm_port_get_device (MM_PORT (self));

 -self-priv-open_count--;
 -
  mm_dbg ((%s) device open count is %d (close), device, 
 self-priv-open_count);

  if (self-priv-open_count  0)
  return;

  if (self-priv-connected_id) {
  g_signal_handler_disconnect (self, self-priv-connected_id);
 @@ -1398,43 +1396,48 @@ mm_port_serial_close (MMPortSerial *self)
self-priv-cancellable_id);
  self-priv-cancellable_id = 0;
  }

  g_clear_object (self-priv-cancellable);
  }

 +void
 +mm_port_serial_close (MMPortSerial *self)
 +{
 +g_return_if_fail (MM_IS_PORT_SERIAL (self));
 +
 +if (!self-priv-forced_close)
 +_close_internal (self, FALSE);
 +}
 +
  static void
  port_serial_close_force (MMPortSerial *self)
  {
 -g_return_if_fail (self != NULL);
  g_return_if_fail (MM_IS_PORT_SERIAL (self));

  /* If already forced to close, return */
  if (self-priv-forced_close)
  return;

  mm_dbg ((%s) forced to close port, mm_port_get_device (MM_PORT 
 (self)));

  /* Mark as having forced the close, so that we don't warn about incorrect
   * open counts */
  self-priv-forced_close = TRUE;

 -/* If already closed, done */
 -if (!self-priv-open_count  !self-priv-reopen_ctx)
 -return;
 -
  /* Cancel port reopening if one is running */
  port_serial_reopen_cancel (self);

 -/* Force the port to close */
 -self-priv-open_count = 1;
 -mm_port_serial_close (self);
 +/* If already closed, done */
 +if (self-priv-open_count  0) {
 +_close_internal (self, TRUE);

 -/* Notify about the forced close status */
 -g_signal_emit (self, signals[FORCED_CLOSE], 0);
 +/* Notify about the forced close status */
 +g_signal_emit (self, signals[FORCED_CLOSE], 0);
 +}
  }

  
 /*/
  /* Reopen */

  typedef struct {
  MMPortSerial *self;
 --
 1.9.3





-- 
Aleksander
https://aleksander.es
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Ensuring predictable MAC address for bond interface

2014-10-07 Thread Ed Swierk 
For these experiments I upgraded to NetworkManager 0.9.10.0.

I tried setting primary=eth0 in the bond options. This option has an effect
in only one case: if I start with only eth1 plugged in (i.e. carrier up),
and then plug in eth0, the bond driver will switch the active slave from
eth1 to eth0 (whereas normally it leaves eth1 active, switching to eth0
only when link drops on eth1). But this has no effect on the MAC address of
the bond device--either way, the bond device gets eth1's MAC address and
keeps it, since eth1 was the first enslaved device.

I also experimented with setting ignore-carrier=eth0,eth1 in the main
section of NetworkManager.conf, in the hope of tricking the
nm_device_state_changed() logic into transitioning the slave devices to
DISCONNECTED and enslaving them regardless of their carrier state. This
works, sort of: now NetworkManager starts up, creates the bond device, and
enslaves eth0 and eth1, whether or not they are plugged in. The bond device
gets eth0's MAC address. It's still pretty easy to mess things up, for
example by bringing down the bond device (via nmcli conn down) and then
bringing up eth1.

I'm getting the sense that I'm fighting a losing battle against a
fundamental aspect of NetworkManager, which is to react dynamically to link
events, and only secondarily try to guarantee a certain configuration. I'm
going to try systemd-networkd next, and see if it's a better fit for my
application.

--Ed


On Tue, Oct 7, 2014 at 7:34 AM, Dan Williams d...@redhat.com wrote:

 On Mon, 2014-10-06 at 12:51 -0700, Ed Swierk wrote:
  I'm using NetworkManager on a server with two wired Ethernet interfaces
  (eth0 and eth1) configured as slaves of a bond in active-backup mode. I'd
  like the bond interface to always be assigned eth0's MAC address.
 
  This is easy with old-school static network configuration like ifupdown:
  just make eth0 the first slave of the bond interface, and Linux will copy
  eth0's MAC address to the bond.
 
  When NetworkManager starts up and reads system-interface config files, it
  creates the bond interface right away, but doesn't add a slave until it
  notices that the slave's link is up (i.e. carrier is 1). And of course
 the
  link state depends on lots of things, like whether a cable is plugged in
  and the state of the switch or host at the other end. Thus whether eth0
 or
  eth1 gets enslaved to the bond first is unpredictable, meaning the bond
  interface's MAC address is unpredictable. This is troublesome in some
  environments, such as ones where a DHCP server assigns IP addresses based
  on the MAC address of the client.

 Does setting the primary bond option when in active-backup mode to
 eth0 make things better?  In nm-connection-editor it'll be in the page
 for Bond options, in nmtui it'll be in about the same place, and in
 nmcli you'd do:

 nmcli con mod Bond1 +bond.options primary=eth0

 and then re-activate the connection.  Let me know if that does/doesn't
 help.  (note; this may only work with 0.9.10+)

 Dan

  NetworkManager already treats a bond slave interface differently when its
  link goes down, leaving it in DISCONNECTED state rather than switching it
  to UNAVAILABLE. So there's precedent for having a bond interface with one
  or more link-down slave interfaces. I think the easiest way to achieve a
  stable MAC address is to extend that behavior to the startup case: as
 soon
  as NetworkManager sees an interface that's configured as a bond slave, it
  should move it from UNAVAILABLE to DISCONNECTED. That way the first
  configured slave interface, rather than the first one with link up, is
  enslaved to the bond.
 
  I couldn't figure out a way to configure this in NetworkManager 0.9.8.10,
  nor in mainline code. As a proof of concept, I hacked
  nm_device_state_changed() in src/nm-device.c: in the second
 switch(state),
  UNAVAILABLE case, I force the transition to DISCONNECTED for eth0 and
 eth1.
  This works as I'd hoped: both interfaces are enslaved right away, with
 eth0
  always first.
 
  I didn't see any easy way to implement this behavior cleanly, though.
 This
  new behavior should apply only to bond slave interfaces. At the point
 where
  nm_device_state_changed() is called, there's not yet a corresponding
  connection for eth0 or eth1, so I can't check whether the interface is
  configured as a bond slave. I thought I'd ask for advice before spending
  more time on this.
 
  Any help would be appreciated!
 
  --Ed
  ___
  networkmanager-list mailing list
  networkmanager-list@gnome.org
  https://mail.gnome.org/mailman/listinfo/networkmanager-list



___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list