Re: Howto change port used for 3g modem?
Dan, FYI, The Fedora-14 ModemManager package is only 0.4.4git20100720.f14. When we get the Alcatel X220 problems fixed, can you update the packages in both Fedora 14 & 15 which is due to release later this month? How do I tell when you have updated git for me to test? Thanks, Perazim Ok, so it really is an X220. There's a plugin for that already, the "x22x" plugin, which was added on Wed Sep 22 2010. I think what's going on here though is that the Longcheer plugin (which supports the Alcatel X030s and X060s) needs to be more careful about what modems it tries to grab. I'll fix that up in git, and then I'd expect your device to be handled by the "x22x" plugin. Dan O email é um dos seus instrumentos de trabalho? http://www.portugalmail.net/profissional ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: Release of NetworkManager 0.8.999 (0.9-rc2)
On 05/05/2011 06:33 PM, Dan Williams wrote: >> Any plans on fixing that in F15 you can't change interface settings when >> the interface is not connected/plugged in. This is rather annoying ;-) > > That's actually a gnome-control-center bug, not really a NetworkManager > bug. And I'm pretty sure there's a bug on bugzilla.gnome.org for that > already. That bug will get fixed, but that component is part of the > GNOME desktop instead of NM. > ok thanks! >> Also, any plans on bug 694758? > > Yeah, need more info from Jiri here. > just responded in the bug :-) grtz -- Ferry Huberts ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Extra symbols returned by check-exports when building 0.8.4 on Lucid.
On Wed, 2011-05-04 at 09:57 -0400, Mathieu Trudel-Lapierre wrote:
> Hi,
>
> As discussed on IRC; I'm finding some extra symbols when I try to
> build 0.8.4 on Lucid. I suspect these are due to the older kernel and
> older GCC, but I admit I haven't really dug into the exact cause so
> much.
>
> The extra symbols are returned by the objdump -t "$so" | grep
> "[.]hidden.*" command run in tools/check-exports.sh:
>
> 00040ff4 l O *ABS* .hidden _GLOBAL_OFFSET_TABLE_
> 00041380 l O .data .hidden __dso_handle
> 000406e8 l O .dtors .hidden __DTOR_END__
> fbe4 l F .text .hidden __i686.get_pc_thunk.cx
> 0002f980 l F .text 0014 .hidden __stack_chk_fail_local
> b1e7 l F .text .hidden __i686.get_pc_thunk.bx
> 00040e60 l O *ABS* .hidden _DYNAMIC
>
> This was returned by the same objdump command and grep on i386. The
> symbols on amd64 are similar, with a slight difference:
>
> ../tools/check-exports.sh ./.libs/libnm-util.so ./libnm-util.ver
> ./.libs/libnm-util.so: checking exported symbols against ./libnm-util.ver
> --- ./libnm-util.ver 2011-05-04 13:34:48.0 +
> +++ - 2011-05-04 13:37:42.782033236 +
> @@ -1,5 +1,10 @@
> {
> global:
> + _DYNAMIC;
> + _GLOBAL_OFFSET_TABLE_;
> + __DTOR_END__;
> + __dso_handle;
> + atexit;
> nm_connection_add_setting;
> nm_connection_clear_secrets;
> nm_connection_compare;
>
> I suspect atexit also comes from the hidden symbols, but I haven't
> been able to verify this yet (time to build a x86_64 VM).
>
> Is there any way to properly exclude them so tests succeed?
Yeah, done and pushed. If you want a less-invasive version than the one
I pushed (though my patches do expose some previously hidden, but
should-have-been exported symbols which was the point of
check-exports.sh in the first place...) then you can simply kill the
second objdump+grep of get_symbols() in check-exports.sh.
Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: bluetooth DUN silently discarding "invalid" APNs
On Thu, 2011-05-05 at 17:54 +0100, Marc Herbert wrote: > >> You should simply just stay clear of this whole mess and not validate > >> anything. This would add two new and incredibly great features: > >> > >> - Restore an error message in case of a typo (as opposed to silently > >> discarding user input) > >> - Support APNs with unusual characters. > >> > >> Two new features by merely deleting some code, how great value is that? > > > > The code was put into NM in the first place to ensure that characters > > like spaces and such that certainly *aren't* allowed in APNs weren't > > used. The validation is still necessary, but I think the core problem > > we should fix is ensuring that you can't type invalid characters into > > the box and you can't type an invalid APN length. Then we should extend > > the allowed characters. We certainly shouldn't remove the checks > > completely, since there *are* actually restrictions on the APN contents > > and length. > > Besides the "hostname" legacy, please tell where do these "certainly > not allowed" characters come from. My Nokia phone lets me input any > character crap in the APN field without even a warning. Then I just > get the same "Connection failed, check your settings" error message > than for any other "valid" typo (reminder: Nokia and Ericsson > designed and implemented GSM, UMTS & LTE practically alone). wvdial > lets me enter the same crap. So why is NetworkManager implementing > this? Too much spare time? Because certain characters are not allowed, and the length is restricted, and just because you have devices that might for some reason allow this, there are devices that certainly don't, and these characters are not valid at all anyway. So to avoid unexpected errors *before* the connect attempt, we should be filtering them out. We don't allow spaces in IP addresses, so why should we allow in APNs where they are also invalid? It's basic input validation. Yes, we'll allow _. But no, we're not going to allow ȫ. Why? Because the standards disallow that. APNs are not a freeform byte-string type. Nor should we treat them as such. The original reason that the validation code was added was specifically for spaces. These cause some modems to puke, not to mention that causing the connect attempt to fail because there's a space in the APN or something like that is completely unhelpful, when we know that these characters are invalid. Dan > But once again, the core problem is not abusive validation. The core > problem is silently discarding user input with a misleading > "configuration completed" message. This needs an quick fix that cannot > wait the redesign of a better user interface. And surprise, there is a > really obvious quick fix: just behave like Nokia. > > ___ > 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: bluetooth DUN silently discarding "invalid" APNs
>> You should simply just stay clear of this whole mess and not validate >> anything. This would add two new and incredibly great features: >> >> - Restore an error message in case of a typo (as opposed to silently >> discarding user input) >> - Support APNs with unusual characters. >> >> Two new features by merely deleting some code, how great value is that? > > The code was put into NM in the first place to ensure that characters > like spaces and such that certainly *aren't* allowed in APNs weren't > used. The validation is still necessary, but I think the core problem > we should fix is ensuring that you can't type invalid characters into > the box and you can't type an invalid APN length. Then we should extend > the allowed characters. We certainly shouldn't remove the checks > completely, since there *are* actually restrictions on the APN contents > and length. Besides the "hostname" legacy, please tell where do these "certainly not allowed" characters come from. My Nokia phone lets me input any character crap in the APN field without even a warning. Then I just get the same "Connection failed, check your settings" error message than for any other "valid" typo (reminder: Nokia and Ericsson designed and implemented GSM, UMTS & LTE practically alone). wvdial lets me enter the same crap. So why is NetworkManager implementing this? Too much spare time? But once again, the core problem is not abusive validation. The core problem is silently discarding user input with a misleading "configuration completed" message. This needs an quick fix that cannot wait the redesign of a better user interface. And surprise, there is a really obvious quick fix: just behave like Nokia. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ModemManager: Letting plugins manage RS232 modems
On Thu, 2011-05-05 at 16:54 +0200, Aleksander Morgado wrote: > Hi all, > > (sorry for the long email) > > ModemManager plugins need several steps to know whether they can handle > a given connected modem. The flow is usually something like this: > > (1) Check vendor ID (and sometimes also product ID), with one of > the following methods: > (1.a) Use vendor/product IDs reported by udev (obtained > from the USB interface) > (1.b) Check for a specific envvar set in the udev device > (e.g. ID_MM_ERICSSON_MBM). The vendor/product > relationship w.r.t the envvar is moved to the udev rules > file. > > (2) Check interface subsystem type (some plugins only support > "tty"s, for example) > > (3) Check modem capabilities, to see if they are GSM or CDMA. > (3.1) If capabilities already cached, just check them. > (3.2) If capabilities not already cached, launch port > probing: > (3.2.1) Probe capabilities. If any of the > following commands succeeds and we parse a valid > reply, the remaining ones are skipped. > (3.2.1.1) AT+GCAP (3 times). If all 3 > get timed out, check if port is QCDM. > (3.2.1.2) ATI > (3.2.1.3) AT+CPIN? > (3.2.1.4) AT+CGMM > (3.2.2) Notify the probe end and let the plugin > check the capabilities in the signal handler. > > All plugins, except for the generic one, will do the vendor ID check to > see if they can support the connected modem. Unfortunately, both (1.a) > and (1.b) methods to check vendor ID depend on the values reported by > udev, and sometimes they do not correspond with the real modem > vendor/product IDs: > * For modems connected via an adapter (bluetooth, RS232<->USB, ...), > usually the adapter's vendor/product ID are reported by udev. > * For modems connected to a RS232 port, there's no vendor/product ID > reported by udev. > * Probably some other situations I can't think of... > > So how can we let plugins know if they can handle these devices? > > We could extend the port probing so that in addition to the > capabilities, we also try to query vendor and model via AT commands. > This would be done as a new step just after probing capabilities (3.2.1) > and before notifying the probe end (3.2.2): > > (3.2.1) Probe capabilities (...) > (3.2.2) Probe vendor ID. If any of the following commands > succeeds and we parse a valid reply, the remaining ones are > skipped. If all the commands fail, product probing is also > skipped. > (3.2.2.1) AT+CGMI > (3.2.2.2) AT+GMI > (3.2.2.3) ATI > (3.2.3) Probe product ID. If any of the following commands > succeeds and we parse a valid reply, the remaining ones are > skipped. > (3.2.3.1) AT+CGMM > (3.2.3.2) AT+GMM > (3.2.3.3) ATI > (3.2.4) Notify the probe end and let the plugin check the > capabilities/vendor/product in the signal handler. > > This would allow plugins that expect (for example) RS232 modems, to do > an additional check on the vendor ID (and/or product ID) string reported > by the modem itself. These additional AT commands during probing would > be sent only if we got a successful capabilities query (so not tried if > the port is a QCDM one for example); and the replies could be cached in > the AT port handler, so at the end it shouldn't affect much the time > needed to setup the modem (as these commands are usually afterwards > issued when querying card info). This solution should be enough for both > RS232 modems connected directly to a RS232 port and for modems connected > to the PC via an adapter. > > An implementation of this can be checked at the following commit: > https://gitorious.org/lanedo/modemmanager/commit/b06faebb748a18c5428afc8aa7a71b95d79a5fbe > > And an example of how it can be used here: > https://gitorious.org/lanedo/modemmanager/commit/62ba095c26528eaa519598124b3494829bedf501 > > Some other ideas I thought about: > (a) During whitelisting the RS232 port in udev, include an envvar like > ID_MM_MY_PLUGIN, so that the plugin can the look for it and if found, > assume it can handle the modem. But this doesn't work for RS232 modems > connected via a USB adapter; and also it would be very plugin-specific. > (b) Add a custom init command in the specific plugin during port > probing, which checks vendor ID and compare it there. I don't dislike > this solution that much, but it ends up being very plugin-specific, not > a general solution. I like it. I now see what you w
Re: ANN: Release of NetworkManager 0.8.999 (0.9-rc2)
On Thu, 2011-05-05 at 12:59 +0200, Ferry Huberts wrote: > On 05/05/2011 01:00 AM, Dan Williams wrote: > > Hi, > > > > I've tagged and uploaded 0.8.999 which has quite a few fixes from the > > last release, including: > > > > Great! > > Dan, > > Any plans on fixing that in F15 you can't change interface settings when > the interface is not connected/plugged in. This is rather annoying ;-) That's actually a gnome-control-center bug, not really a NetworkManager bug. And I'm pretty sure there's a bug on bugzilla.gnome.org for that already. That bug will get fixed, but that component is part of the GNOME desktop instead of NM. > Also, any plans on bug 694758? Yeah, need more info from Jiri here. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: bluetooth DUN silently discarding "invalid" APNs
On Thu, 2011-05-05 at 09:28 +0100, Marc Herbert wrote: > Le 04/05/2011 21:02, Dan Williams a écrit : > > > APNs are defined by GSM 03.03 section 14.9 which says: > > > > http://www.3gpp.org/ftp/Specs/html-info/0303.htm > > > = > > The syntax of the APN shall follow the Name Syntax defined in RFC 2181 > > [14] and RFC 1035 [15]. The APN consists of one or more labels. Each > > label is coded as one octet length field followed by that number of > > octets coded as 8 bit ASCII characters. Following RFC 1035 [15] the > > labels should consist only of the alphabetic characters (A-Z and a-z), > > digits (0-9) and the dash (-). The case of alphabetic characters is not > > significant. The APN is not terminated by a length byte of zero. > > = > > > > It is funny how GSM 03.03 makes the usual misinterpretation of (the > admittedly confusing) DNS RFC1035, while in the same paragraph quoting > RFC2181 which explicitly rectifies this misinterpretation (in section > 11). > > DNS does not put any restrictions on label characters. This > restriction came from "hostname". > > > But the specification does use the word "should", which implies that > > APNs may deviate from the suggestion. > > I suspect resolving the APN through DNS is not even mandatory. Some > networks could use alternative ways to select the GGSN. > > > Many APNs already use '.' (which the specification does not suggest) > > That is because '.' is the usual way to separate DNS labels in text > form (not on the wire). The '.' is not part of any label. > > > and perhaps we should allow "_" too. > > You should simply just stay clear of this whole mess and not validate > anything. This would add two new and incredibly great features: > > - Restore an error message in case of a typo (as opposed to silently > discarding user input) > - Support APNs with unusual characters. > > Two new features by merely deleting some code, how great value is that? The code was put into NM in the first place to ensure that characters like spaces and such that certainly *aren't* allowed in APNs weren't used. The validation is still necessary, but I think the core problem we should fix is ensuring that you can't type invalid characters into the box and you can't type an invalid APN length. Then we should extend the allowed characters. We certainly shouldn't remove the checks completely, since there *are* actually restrictions on the APN contents and length. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
ModemManager: Letting plugins manage RS232 modems
Hi all, (sorry for the long email) ModemManager plugins need several steps to know whether they can handle a given connected modem. The flow is usually something like this: (1) Check vendor ID (and sometimes also product ID), with one of the following methods: (1.a) Use vendor/product IDs reported by udev (obtained from the USB interface) (1.b) Check for a specific envvar set in the udev device (e.g. ID_MM_ERICSSON_MBM). The vendor/product relationship w.r.t the envvar is moved to the udev rules file. (2) Check interface subsystem type (some plugins only support "tty"s, for example) (3) Check modem capabilities, to see if they are GSM or CDMA. (3.1) If capabilities already cached, just check them. (3.2) If capabilities not already cached, launch port probing: (3.2.1) Probe capabilities. If any of the following commands succeeds and we parse a valid reply, the remaining ones are skipped. (3.2.1.1) AT+GCAP (3 times). If all 3 get timed out, check if port is QCDM. (3.2.1.2) ATI (3.2.1.3) AT+CPIN? (3.2.1.4) AT+CGMM (3.2.2) Notify the probe end and let the plugin check the capabilities in the signal handler. All plugins, except for the generic one, will do the vendor ID check to see if they can support the connected modem. Unfortunately, both (1.a) and (1.b) methods to check vendor ID depend on the values reported by udev, and sometimes they do not correspond with the real modem vendor/product IDs: * For modems connected via an adapter (bluetooth, RS232<->USB, ...), usually the adapter's vendor/product ID are reported by udev. * For modems connected to a RS232 port, there's no vendor/product ID reported by udev. * Probably some other situations I can't think of... So how can we let plugins know if they can handle these devices? We could extend the port probing so that in addition to the capabilities, we also try to query vendor and model via AT commands. This would be done as a new step just after probing capabilities (3.2.1) and before notifying the probe end (3.2.2): (3.2.1) Probe capabilities (...) (3.2.2) Probe vendor ID. If any of the following commands succeeds and we parse a valid reply, the remaining ones are skipped. If all the commands fail, product probing is also skipped. (3.2.2.1) AT+CGMI (3.2.2.2) AT+GMI (3.2.2.3) ATI (3.2.3) Probe product ID. If any of the following commands succeeds and we parse a valid reply, the remaining ones are skipped. (3.2.3.1) AT+CGMM (3.2.3.2) AT+GMM (3.2.3.3) ATI (3.2.4) Notify the probe end and let the plugin check the capabilities/vendor/product in the signal handler. This would allow plugins that expect (for example) RS232 modems, to do an additional check on the vendor ID (and/or product ID) string reported by the modem itself. These additional AT commands during probing would be sent only if we got a successful capabilities query (so not tried if the port is a QCDM one for example); and the replies could be cached in the AT port handler, so at the end it shouldn't affect much the time needed to setup the modem (as these commands are usually afterwards issued when querying card info). This solution should be enough for both RS232 modems connected directly to a RS232 port and for modems connected to the PC via an adapter. An implementation of this can be checked at the following commit: https://gitorious.org/lanedo/modemmanager/commit/b06faebb748a18c5428afc8aa7a71b95d79a5fbe And an example of how it can be used here: https://gitorious.org/lanedo/modemmanager/commit/62ba095c26528eaa519598124b3494829bedf501 Some other ideas I thought about: (a) During whitelisting the RS232 port in udev, include an envvar like ID_MM_MY_PLUGIN, so that the plugin can the look for it and if found, assume it can handle the modem. But this doesn't work for RS232 modems connected via a USB adapter; and also it would be very plugin-specific. (b) Add a custom init command in the specific plugin during port probing, which checks vendor ID and compare it there. I don't dislike this solution that much, but it ends up being very plugin-specific, not a general solution. Comments? -- Aleksander ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: Release of NetworkManager 0.8.999 (0.9-rc2)
On 05/05/2011 01:00 AM, Dan Williams wrote: > Hi, > > I've tagged and uploaded 0.8.999 which has quite a few fixes from the > last release, including: > Great! Dan, Any plans on fixing that in F15 you can't change interface settings when the interface is not connected/plugged in. This is rather annoying ;-) Also, any plans on bug 694758? grtz -- Ferry Huberts ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: bluetooth DUN silently discarding "invalid" APNs
Le 04/05/2011 21:02, Dan Williams a écrit : > APNs are defined by GSM 03.03 section 14.9 which says: > > http://www.3gpp.org/ftp/Specs/html-info/0303.htm > = > The syntax of the APN shall follow the Name Syntax defined in RFC 2181 > [14] and RFC 1035 [15]. The APN consists of one or more labels. Each > label is coded as one octet length field followed by that number of > octets coded as 8 bit ASCII characters. Following RFC 1035 [15] the > labels should consist only of the alphabetic characters (A-Z and a-z), > digits (0-9) and the dash (-). The case of alphabetic characters is not > significant. The APN is not terminated by a length byte of zero. > = > It is funny how GSM 03.03 makes the usual misinterpretation of (the admittedly confusing) DNS RFC1035, while in the same paragraph quoting RFC2181 which explicitly rectifies this misinterpretation (in section 11). DNS does not put any restrictions on label characters. This restriction came from "hostname". > But the specification does use the word "should", which implies that > APNs may deviate from the suggestion. I suspect resolving the APN through DNS is not even mandatory. Some networks could use alternative ways to select the GGSN. > Many APNs already use '.' (which the specification does not suggest) That is because '.' is the usual way to separate DNS labels in text form (not on the wire). The '.' is not part of any label. > and perhaps we should allow "_" too. You should simply just stay clear of this whole mess and not validate anything. This would add two new and incredibly great features: - Restore an error message in case of a typo (as opposed to silently discarding user input) - Support APNs with unusual characters. Two new features by merely deleting some code, how great value is that? Cheers, Marc ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: bluetooth DUN silently discarding "invalid" APNs
Le 04/05/2011 21:02, Dan Williams a écrit : > On Tue, 2011-05-03 at 12:33 +0100, Marc Herbert wrote: >> Hi, >> >> I wasted a number of hours when trying to tether using >> bluetooth... it seems any APN containing an underscore "_" causes the >> DUN configuration entered into the gnome bluetooth wizard to be >> *SILENTLY* discarded. > > APNs are defined by GSM 03.03 section 14.9 which says: Dan, You did not address at all the most important issue: whether the validation is good or not, it should not SILENTLY discard user input. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
