Re: Autoconnect for mobile broadband
The modem is automatically unlocked when discovered by nm-applet. When
that happens is outside the scope of this fix, but I assume it happens
in both cases you describe.
Anders Feder
On 17-10-2011 23:48, Sascha Silbe wrote:
Excerpts from Anders Feder's message of 2011-10-17 18:50:08 +0200:
I don't see how this would prevent autoconnect if secured with a PIN?
That case would specifically be served by the other entry point:
When modem is unlocked {
If (autoconnect == true) {
Enable_and_autoconnect()
}
}
I guess I'm just missing a link here. With your proposed logic, does the
modem get unlocked automatically on NM start-up resp. when the user
plugs it in?
Sascha
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Autoconnect for mobile broadband
Excerpts from Anders Feder's message of 2011-10-17 18:50:08 +0200:
> I don't see how this would prevent autoconnect if secured with a PIN?
> That case would specifically be served by the other entry point:
>
> When modem is unlocked {
> If (autoconnect == true) {
> Enable_and_autoconnect()
> }
> }
I guess I'm just missing a link here. With your proposed logic, does the
modem get unlocked automatically on NM start-up resp. when the user
plugs it in?
Sascha
--
http://sascha.silbe.org/
http://www.infra-silbe.de/
signature.asc
Description: PGP signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Autoconnect for mobile broadband
(Typo. I meant: "a version where auto/-unlock/ has been fixed".)
On 17-10-2011 18:50, Anders Feder wrote:
I don't see how this would prevent autoconnect if secured with a PIN?
That case would specifically be served by the other entry point:
When modem is unlocked {
If (autoconnect == true) {
Enable_and_autoconnect()
}
}
Note that I am assuming a version of NM where autoconnect has been
fixed per:
http://git.gnome.org/browse/network-manager-applet/commit/?id=7d837085c467675529a4e2be90f406e1cfcd6277
Anders Feder
On 17-10-2011 14:15, Sascha Silbe wrote:
Excerpts from Anders Feder's message of 2011-10-14 20:20:55 +0200:
I see. Should I clear this change of behavior with someone if I would
like to implement it?
Also, where would the entry point be? Since the modem may or may not
need an unlock, perhaps there needs to be two:
When modem is discovered {
If (autoconnect == true) {
If (Unlock required == false)
Enable_and_autoconnect()
}
}
This would prevent automatic connect if the user secured the SIM card
against theft (or at least prevent a thief from making use of the card)
by setting a PIN. It's bad enough that NM/MM currently doesn't work
properly with my Huawei E1750 if a PIN is set (but then it's partially
my fault because I haven't spent the time yet to analyse and report the
exact failure modes). Please don't _design_ it that way.
Sascha
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Autoconnect for mobile broadband
I don't see how this would prevent autoconnect if secured with a PIN?
That case would specifically be served by the other entry point:
When modem is unlocked {
If (autoconnect == true) {
Enable_and_autoconnect()
}
}
Note that I am assuming a version of NM where autoconnect has been fixed
per:
http://git.gnome.org/browse/network-manager-applet/commit/?id=7d837085c467675529a4e2be90f406e1cfcd6277
Anders Feder
On 17-10-2011 14:15, Sascha Silbe wrote:
Excerpts from Anders Feder's message of 2011-10-14 20:20:55 +0200:
I see. Should I clear this change of behavior with someone if I would
like to implement it?
Also, where would the entry point be? Since the modem may or may not
need an unlock, perhaps there needs to be two:
When modem is discovered {
If (autoconnect == true) {
If (Unlock required == false)
Enable_and_autoconnect()
}
}
This would prevent automatic connect if the user secured the SIM card
against theft (or at least prevent a thief from making use of the card)
by setting a PIN. It's bad enough that NM/MM currently doesn't work
properly with my Huawei E1750 if a PIN is set (but then it's partially
my fault because I haven't spent the time yet to analyse and report the
exact failure modes). Please don't _design_ it that way.
Sascha
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Fix unterminated buffer after readlink() call
On Friday, 14. October 2011 17:50:14 Dan Williams wrote: > > Good catch, I missed the memset() call. > > > > And if readlink() doesn't fill the buffer, > > > > > the remaining bytes will already be set to 0 by the memset, AFAICT. > > > Are you seeing a crash here or was this from visual inspection? > > > > Pure visual inspection, I was looking for readlink() usage patterns. > > > > Still the buf[link_len] = '0'; is more explicit and we wouldn't need > > the memset() call at all. What do you think? > > I try to do the memset() calls specifically to prevent bugs caused by > forgetting to do NULL termination later on; it's kind of the shotgun > approach but these paths generally aren't performance sensitive and I > think the tradeoff of a few cycles to memset (which is a very optimized > operation these days) is worth the decreased possibility of bugs and > buffer overruns here. At least that was my thought :) Yeah, performance is not an issue here. So let's keep it like it is. Cheers, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Persistent 3G connection fails, not sure why
I maintain a persistent 3G connection on a remote device using network
manager. However, every so often, the link fails and then does not restart
itself. I managed to identify an occurrence of this in my syslog, but
honestly I'm not really sure what I'm looking at. It seems that the machine
thinks the device has been unplugged, but there's no corresponding log entry
for it actually being unplugged.
Would someone mind looking at the below syslog snip and guiding me in the
right direction?
> Oct 13 22:25:26 tracker pppd[1091]: LCP terminated by peer
> Oct 13 22:25:26 tracker pppd[1091]: Connect time 206.7 minutes.
> Oct 13 22:25:26 tracker pppd[1091]: Sent 203306 bytes, received 182777 bytes.
> Oct 13 22:25:26 tracker pppd[1091]: Modem hangup
> Oct 13 22:25:26 tracker pppd[1091]: Connection terminated.
> Oct 13 22:25:26 tracker NetworkManager[333]: (ttyUSB1): device state
> change: 8 -> 9 (reason 13)
> Oct 13 22:25:26 tracker NetworkManager[333]: Unmanaged Device found;
> state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
> Oct 13 22:25:26 tracker NetworkManager[333]: Activation (ttyUSB1)
> failed.
> Oct 13 22:25:26 tracker modem-manager[337]: (ttyUSB1) closing serial
> port...
> Oct 13 22:25:26 tracker NetworkManager[333]: (ttyUSB1): device state
> change: 9 -> 3 (reason 0)
> Oct 13 22:25:26 tracker NetworkManager[333]: (ttyUSB1): deactivating
> device (reason: 0).
> Oct 13 22:25:26 tracker kernel: [12441.840088] ata1.00: exception Emask 0x0
> SAct 0x0 SErr 0x0 action 0x6
> Oct 13 22:25:26 tracker kernel: [12441.846744] ata1.00: BMDMA stat 0x66
> Oct 13 22:25:26 tracker kernel: [12441.850446] ata1.00: failed command: WRITE
> DMA
> Oct 13 22:25:26 tracker kernel: [12441.855020] ata1.00: cmd
> ca/00:02:c4:fb:5b/00:00:00:00:00/e0 tag 0 dma 1024 out
> Oct 13 22:25:26 tracker kernel: [12441.855024] res
> 51/84:00:c4:fb:5b/00:00:00:00:00/e0 Emask 0x30 (host bus error)
> Oct 13 22:25:26 tracker kernel: [12441.870623] ata1.00: status: { DRDY ERR }
> Oct 13 22:25:26 tracker kernel: [12441.874708] ata1.00: error: { ICRC ABRT }
> Oct 13 22:25:26 tracker kernel: [12441.878820] ata1: soft resetting link
> Oct 13 22:25:26 tracker modem-manager[337]: (ttyUSB1) serial port
> closed
> Oct 13 22:25:26 tracker modem-manager[337]: Modem
> /org/freedesktop/ModemManager/Modems/0: state changed (connected ->
> disconnecting)
> Oct 13 22:25:26 tracker modem-manager[337]: Modem
> /org/freedesktop/ModemManager/Modems/0: state changed (disconnecting ->
> connected)
> Oct 13 22:25:26 tracker NetworkManager[333]: could not read ppp stats:
> No such device
> Oct 13 22:25:26 tracker pppd[1091]: Exit.
> Oct 13 22:25:26 tracker NetworkManager[333]: Unmanaged Device found;
> state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
> Oct 13 22:25:26 tracker NetworkManager[333]:SCPlugin-Ifupdown: devices
> removed (path: /sys/devices/virtual/net/ppp0, iface: ppp0)
> Oct 13 22:25:26 tracker NetworkManager[333]: disconnect failed: (32)
> The serial port is not open.
> Oct 13 22:25:27 tracker kernel: [12442.048218] ata1.00: configured for
> UDMA/100
> Oct 13 22:25:27 tracker kernel: [12442.048241] ata1: EH complete
> Oct 13 22:25:27 tracker kernel: [12442.050941] ata1.00: exception Emask 0x0
> SAct 0x0 SErr 0x0 action 0x6
> Oct 13 22:25:27 tracker kernel: [12442.057483] ata1.00: BMDMA stat 0x66
> Oct 13 22:25:27 tracker kernel: [12442.061153] ata1.00: failed command: WRITE
> DMA
> Oct 13 22:25:27 tracker kernel: [12442.065696] ata1.00: cmd
> ca/00:02:c4:fb:5b/00:00:00:00:00/e0 tag 0 dma 1024 out
> Oct 13 22:25:27 tracker kernel: [12442.065699] res
> 51/84:00:c4:fb:5b/00:00:00:00:00/e0 Emask 0x30 (host bus error)
> Oct 13 22:25:27 tracker kernel: [12442.081273] ata1.00: status: { DRDY ERR }
> Oct 13 22:25:27 tracker kernel: [12442.085366] ata1.00: error: { ICRC ABRT }
> Oct 13 22:25:27 tracker kernel: [12442.089488] ata1: soft resetting link
> Oct 13 22:25:27 tracker kernel: [12442.260206] ata1.00: configured for
> UDMA/100
> Oct 13 22:25:27 tracker kernel: [12442.260226] ata1: EH complete
> Oct 13 22:25:27 tracker kernel: [12442.268296] ata1.00: exception Emask 0x0
> SAct 0x0 SErr 0x0 action 0x6
> Oct 13 22:25:27 tracker kernel: [12442.274829] ata1.00: BMDMA stat 0x66
> Oct 13 22:25:27 tracker kernel: [12442.278480] ata1.00: failed command: WRITE
> DMA
> Oct 13 22:25:27 tracker kernel: [12442.283022] ata1.00: cmd
> ca/00:02:c4:fb:5b/00:00:00:00:00/e0 tag 0 dma 1024 out
> Oct 13 22:25:27 tracker kernel: [12442.283026] res
> 51/84:00:c4:fb:5b/00:00:00:00:00/e0 Emask 0x30 (host bus error)
> Oct 13 22:25:27 tracker kernel: [12442.298605] ata1.00: status: { DRDY ERR }
> Oct 13 22:25:27 tracker kernel: [12442.302693] ata1.00: error: { ICRC ABRT }
> Oct 13 22:25:27 tracker kernel: [12442.306763] ata1: soft resetting link
> Oct 13 22:25:27 tracker kernel: [12442.476225] ata1.00: configured for
> UDMA/100
> Oct 13 22:25:27 tracker kernel: [12442.476
Re: Autoconnect for mobile broadband
Excerpts from Anders Feder's message of 2011-10-14 20:20:55 +0200:
> I see. Should I clear this change of behavior with someone if I would
> like to implement it?
>
> Also, where would the entry point be? Since the modem may or may not
> need an unlock, perhaps there needs to be two:
>
> When modem is discovered {
> If (autoconnect == true) {
> If (Unlock required == false)
> Enable_and_autoconnect()
> }
> }
This would prevent automatic connect if the user secured the SIM card
against theft (or at least prevent a thief from making use of the card)
by setting a PIN. It's bad enough that NM/MM currently doesn't work
properly with my Huawei E1750 if a PIN is set (but then it's partially
my fault because I haven't spent the time yet to analyse and report the
exact failure modes). Please don't _design_ it that way.
Sascha
--
http://sascha.silbe.org/
http://www.infra-silbe.de/
signature.asc
Description: PGP signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 8/9] ifcfg: Ignore higher level configs for bonding slaves
On Wed, 2011-10-12 at 13:51 -0500, Dan Williams wrote:
> I'd rather enforce connection validity with verify() and warn the user
> if any IP config was found in the file in the ifcfg plugin.
> I'm not sure why we need a dummy config; we'd only need one check for
> it, and that's in stage3 when we start IP config, right? In that case
> we simply skip the IPv4 config like happens when the config is disabled.
> In the end I don't have strong feelings on this; but we should certainly
> warn in ifcfg-rh if an IPv4 config is present in the ifcfg file.
I tried to implement this and it gets ugly.
IPv6 is not a problem but IPv4 undertakes everything to not be disabled.
src/settings/plugins/ifcfg-rh/reader.c:
static NMSetting *
make_ip4_setting (shvarFile *ifcfg,
[...]
if ( !tmp_ip4 && !tmp_prefix && !tmp_netmask
&& !tmp_ip4_0 && !tmp_prefix_0 && !tmp_netmask_0
&& !tmp_ip4_1 && !tmp_prefix_1 && !tmp_netmask_1
&& !tmp_ip4_2 && !tmp_prefix_2 && !tmp_netmask_2) {
if (valid_ip6_config)
/* Nope, no IPv4 */
method = NM_SETTING_IP4_CONFIG_METHOD_DISABLED;
else
method = NM_SETTING_IP4_CONFIG_METHOD_AUTO;
Any suggestion on how to implement a no ip configuration was provided
rule in NMSettingConnection's verify()?
Also, when eth1 and eth2 are configured as bonding slaves and the ifcfg
parsing fails the interface will still be brought up automatically using
dhcp.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 8/8] api: Let MM_MODEM_MODE be a bitfield, and new PreferredMode property
> Supported and Allowed modes are modified to be bitmasks of MM_MODEM_MODE > values, > and preference of a specific mode is now given in the new PreferredMode > property and as an extra argument to the SetAllowedModes() call. > > * Supported Modes: bitmask specifying which modes are supported by the > specific > hardware. For example, a modem may only support 1G/2G/3G connections (not 4G). > > * Allowed Modes: bitmask specifying which modes, of the ones Supported by the > modem, are allowed to use. For example, a modem may support 1G/2G/3G > connections > but only 1G and 2G connections are allowed by the user as 3G involves more > expensive data rates. > > [Allowed] ⊆ [Supported] > > * Preferred Mode: specific mode which is preferred among the ones defined in > the Allowed modes bitmask. For example, a modem may allow 1G/2G/3G connections > but the user would like that if possible 2G be used, as 3G consumes too much > battery. If 2G is not possible, 3G can be used. > > [Preferred] ∈ [Allowed] After talk in IRC, decided to push this fix as it is; we can change it afterwards if needed. -- Aleksander ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
