Re: Ensuring predictable MAC address for bond interface
On Wed, 2014-10-08 at 07:54 +0200, Thomas Haller wrote: > On Tue, 2014-10-07 at 20:25 -0700, Ed Swierk wrote: > > 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. > > > I think that the concept "order of how slaves are attached to bond > master" does not mean anything for NetworkManager, hence there is no > ~first~ slave. > > (of course, whenever you attach slaves to a bond, one of those will be > the first. But that is random in case of autoconnect and nothing that > you can configure or that NM anticipates). > > > Is it possible to set the mac address when creating the bond? If yes, we > could add a configuration option similar to > NM_SETTING_BRIDGE_MAC_ADDRESS. Yeah, the kernel allows that, and we should add this option to bonds like we did for bridges, as you suggest. > We could make NM_SETTING_BOND_MAC_ADDRESS be a hex string, or > alternatively, an interface name -- so we would look at the interfaces > and take it's MAC address. That gets complicated though, since if the slave that you specify doesn't exist, you cannot set up the bond. I'd rather handle that in editors, like we do for the MAC Address boxes of other interface types with a dropdown suggesting interfaces you can choose. But we should do this either way. Dan > Thomas > > > > > > > > > > > On Tue, Oct 7, 2014 at 7:34 AM, Dan Williams 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
Re: [MM PATCH] port-serial: fix forced closing after b28230411
On Wed, 2014-10-08 at 00:29 +0200, Aleksander Morgado wrote:
> On Tue, Oct 7, 2014 at 11:06 PM, Dan Williams 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.
Pretty sure I did that already...
Dan
> > ---
> > 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
Re: Ad-Hoc network creation took too long, failing activation
On Wed, 2014-10-08 at 00:10 +0200, poma wrote: > Starting Network Manager... > NetworkManager (version 0.9.10.0-5.git20140704.fc21) is starting... > WEXT support is enabled > WiFi hardware radio set enabled > Loaded device plugin: > /usr/lib/NetworkManager/libnm-device-plugin-wifi.so > WiFi enabled by radio killswitch; enabled by state file > Networking is enabled by state file > Started Network Manager. > (ra0): driver does not support SSID scans (scan_capa 0x00). > (ra0): using WEXT for WiFi device control > (ra0): new 802.11 WiFi device (driver: 'usb' ifindex: 5) > (ra0): exported as /org/freedesktop/NetworkManager/Devices/4 > (ra0): device state change: unmanaged -> unavailable (reason > 'managed') [10 20 2] > (ra0): preparing device > (ra0): error 100 getting card mode > [1412709645.317223] [platform/wifi/wifi-utils-wext.c:160] > wifi_wext_set_mode(): (ra0): error setting mode 2 Ugh, looks like you're using WEXT, which is historically quite problematic because different drivers expected different sequences of WEXT requests. Any driver that uses WEXT and is not upstream is automatically suspect, unfortunately... > wpa_supplicant started > (ra0) supports 1 scan SSIDs > (ra0): supplicant interface state: starting -> ready > (ra0): device state change: unavailable -> disconnected (reason > 'supplicant-available') [20 30 42] > (ra0): supplicant interface state: ready -> disconnected > (ra0) supports 1 scan SSIDs > startup complete > (ra0): supplicant interface state: disconnected -> inactive > ... > (ra0): disconnecting for new activation request. > (ra0): device state change: activated -> deactivating (reason 'none') > [100 110 0] > NetworkManager state is now DISCONNECTING > (ra0): device state change: deactivating -> disconnected (reason > 'none') [110 30 0] > (ra0): deactivating device (reason 'none') [0] > (ra0): canceled DHCP transaction, DHCP client pid 1144 > NetworkManager state is now DISCONNECTED > Activation (ra0) starting connection 'bla' > Activation (ra0) Stage 1 of 5 (Device Prepare) scheduled... > Connection disconnected (reason -3) > (ra0): supplicant interface state: completed -> disconnected > Activation (ra0) Stage 1 of 5 (Device Prepare) started... > (ra0): device state change: disconnected -> prepare (reason 'none') > [30 40 0] > NetworkManager state is now CONNECTING > Activation (ra0) Stage 2 of 5 (Device Configure) scheduled... > Activation (ra0) Stage 1 of 5 (Device Prepare) complete. > Activation (ra0) Stage 2 of 5 (Device Configure) starting... > (ra0): device state change: prepare -> config (reason 'none') [40 50 0] > Activation (ra0/wireless): connection 'bla' has security, and secrets > exist. No new secrets needed. > Config: added 'ssid' value 'bla' > Config: added 'mode' value '1' > Config: added 'frequency' value '2412' > Config: added 'key_mgmt' value 'NONE' > Config: added 'auth_alg' value 'OPEN' > Config: added 'wep_key0' value '' > Config: added 'wep_tx_keyidx' value '0' > Activation (ra0) Stage 2 of 5 (Device Configure) complete. > Config: set interface ap_scan to 2 > (ra0): supplicant interface state: disconnected -> associating > Activation (ra0/wireless): Ad-Hoc network creation took too long, > failing activation. The driver did not emit the SIOCGIWAP event, indicating that it had successfully completed Ad-Hoc AP setup. This is a driver bug. > (ra0): device state change: config -> failed (reason > 'supplicant-timeout') [50 120 11] > NetworkManager state is now DISCONNECTED > Activation (ra0) failed for connection 'bla' > Connection disconnected (reason -3) > (ra0): supplicant interface state: associating -> disconnected > (ra0): device state change: failed -> disconnected (reason 'none') > [120 30 0] > (ra0): deactivating device (reason 'none') [0] > (ra0): error 100 getting card mode > [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? NM supports AP mode if wpa_supplicant supports it on the device, but given the information you've provided here, the driver looks very fragile and I wouldn't expect it to work. WPA2 may be possible, but again the driver is quite suspect. The driver is just bad, I'm afraid... Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Ensuring predictable MAC address for bond interface
On Tue, Oct 7, 2014 at 10:54 PM, Thomas Haller wrote: > I think that the concept "order of how slaves are attached to bond > master" does not mean anything for NetworkManager, hence there is no > ~first~ slave. > > (of course, whenever you attach slaves to a bond, one of those will be > the first. But that is random in case of autoconnect and nothing that > you can configure or that NM anticipates). > > > Is it possible to set the mac address when creating the bond? If yes, we > could add a configuration option similar to > NM_SETTING_BRIDGE_MAC_ADDRESS. > > We could make NM_SETTING_BOND_MAC_ADDRESS be a hex string, or > alternatively, an interface name -- so we would look at the interfaces > and take it's MAC address. > > Yes, I like this approach much better: let the user specify the MAC address for the bond, use that address when creating the bond, and be done with it. Then the carrier state, the order of enslaving devices, etc. are all irrelevant. --Ed ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Ad-Hoc network creation took too long, failing activation
On 08.10.2014 20:31, Dan Williams wrote: > On Wed, 2014-10-08 at 00:10 +0200, poma wrote: >> Starting Network Manager... >> NetworkManager (version 0.9.10.0-5.git20140704.fc21) is starting... >> WEXT support is enabled >> WiFi hardware radio set enabled >> Loaded device plugin: >> /usr/lib/NetworkManager/libnm-device-plugin-wifi.so >> WiFi enabled by radio killswitch; enabled by state file >> Networking is enabled by state file >> Started Network Manager. >> (ra0): driver does not support SSID scans (scan_capa 0x00). >> (ra0): using WEXT for WiFi device control >> (ra0): new 802.11 WiFi device (driver: 'usb' ifindex: 5) >> (ra0): exported as /org/freedesktop/NetworkManager/Devices/4 >> (ra0): device state change: unmanaged -> unavailable (reason >> 'managed') [10 20 2] >> (ra0): preparing device >> (ra0): error 100 getting card mode >> [1412709645.317223] [platform/wifi/wifi-utils-wext.c:160] >> wifi_wext_set_mode(): (ra0): error setting mode 2 > > Ugh, looks like you're using WEXT, which is historically quite > problematic because different drivers expected different sequences of > WEXT requests. Any driver that uses WEXT and is not upstream is > automatically suspect, unfortunately... > >> wpa_supplicant started >> (ra0) supports 1 scan SSIDs >> (ra0): supplicant interface state: starting -> ready >> (ra0): device state change: unavailable -> disconnected (reason >> 'supplicant-available') [20 30 42] >> (ra0): supplicant interface state: ready -> disconnected >> (ra0) supports 1 scan SSIDs >> startup complete >> (ra0): supplicant interface state: disconnected -> inactive >> ... >> (ra0): disconnecting for new activation request. >> (ra0): device state change: activated -> deactivating (reason 'none') >> [100 110 0] >> NetworkManager state is now DISCONNECTING >> (ra0): device state change: deactivating -> disconnected (reason >> 'none') [110 30 0] >> (ra0): deactivating device (reason 'none') [0] >> (ra0): canceled DHCP transaction, DHCP client pid 1144 >> NetworkManager state is now DISCONNECTED >> Activation (ra0) starting connection 'bla' >> Activation (ra0) Stage 1 of 5 (Device Prepare) scheduled... >> Connection disconnected (reason -3) >> (ra0): supplicant interface state: completed -> disconnected >> Activation (ra0) Stage 1 of 5 (Device Prepare) started... >> (ra0): device state change: disconnected -> prepare (reason 'none') >> [30 40 0] >> NetworkManager state is now CONNECTING >> Activation (ra0) Stage 2 of 5 (Device Configure) scheduled... >> Activation (ra0) Stage 1 of 5 (Device Prepare) complete. >> Activation (ra0) Stage 2 of 5 (Device Configure) starting... >> (ra0): device state change: prepare -> config (reason 'none') [40 50 >> 0] >> Activation (ra0/wireless): connection 'bla' has security, and secrets >> exist. No new secrets needed. >> Config: added 'ssid' value 'bla' >> Config: added 'mode' value '1' >> Config: added 'frequency' value '2412' >> Config: added 'key_mgmt' value 'NONE' >> Config: added 'auth_alg' value 'OPEN' >> Config: added 'wep_key0' value '' >> Config: added 'wep_tx_keyidx' value '0' >> Activation (ra0) Stage 2 of 5 (Device Configure) complete. >> Config: set interface ap_scan to 2 >> (ra0): supplicant interface state: disconnected -> associating >> Activation (ra0/wireless): Ad-Hoc network creation took too long, >> failing activation. > > The driver did not emit the SIOCGIWAP event, indicating that it had > successfully completed Ad-Hoc AP setup. This is a driver bug. > >> (ra0): device state change: config -> failed (reason >> 'supplicant-timeout') [50 120 11] >> NetworkManager state is now DISCONNECTED >> Activation (ra0) failed for connection 'bla' >> Connection disconnected (reason -3) >> (ra0): supplicant interface state: associating -> disconnected >> (ra0): device state change: failed -> disconnected (reason 'none') >> [120 30 0] >> (ra0): deactivating device (reason 'none') [0] >> (ra0): error 100 getting card mode >> [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? > > NM supports AP mode if wpa_supplicant supports it on the device, but > given the information you've provided here, the driver looks very > fragile and I wouldn't expect it to work. WPA2 may be possible, but > again the driver is quite suspect. > > The driver is just bad, I'm afraid... > > Dan > Thanks, whether the same(Ad-Hoc/IBSS & WEXT == unsupported) applies to this module also - dmesg: usb 2-3: new high-speed USB device number 3 using ehci-pci usb 2-3: New USB device found, idVendor=0bda, idProduct=8171 usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 2-3: Product: RTL8188S WLAN Adapter usb 2-3: Manufacturer: Manufacturer Realtek usb 2-3: SerialNumber: 00e04c01 r8712u: module is from the staging directory, the quality is u
