IPv6 up notify support for PPP [Was: Re: Re: Implementing IPv6 in modem manager]
Hi,
since we have a device that mimics a GSM card and talks IPv6 negotiated over
PPP, I went ahead and tried to get some sort of v6 support into modem-manager.
As a first step: PPP needs a patch to notify of IPv6 coming up. See below. Is
anyone able to figure out who is taking patches for PPP? Dan do you have a
contact at PPP and can push this?
BR,
Markus
From: Markus Becker
Date: Wed, 14 Mar 2012 16:48:44 +0100
Subject: [PATCH] Support for notification of IPv6 up/down for NetworkManager.
---
pppd/ipv6cp.c | 17 +
pppd/pppd.h |8 ++--
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/pppd/ipv6cp.c b/pppd/ipv6cp.c
index 4a09c9a..cae9481 100644
--- a/pppd/ipv6cp.c
+++ b/pppd/ipv6cp.c
@@ -179,6 +179,16 @@ int no_ifaceid_neg = 0;
/* local vars */
static int ipv6cp_is_up;
+/* Hook for a plugin to know when IP protocol has come up */
+void (*ipv6_up_hook) __P((void)) = NULL;
+
+/* Hook for a plugin to know when IP protocol has come down */
+void (*ipv6_down_hook) __P((void)) = NULL;
+
+/* Notifiers for when IPCP goes up and down */
+struct notifier *ipv6_up_notifier = NULL;
+struct notifier *ipv6_down_notifier = NULL;
+
/*
* Callbacks for fsm code. (CI = Configuration Information)
*/
@@ -1282,6 +1292,10 @@ ipv6cp_up(f)
np_up(f->unit, PPP_IPV6);
ipv6cp_is_up = 1;
+notify(ipv6_up_notifier, 0);
+if (ipv6_up_hook)
+ ipv6_up_hook();
+
/*
* Execute the ipv6-up script, like this:
* /etc/ppp/ipv6-up interface tty speed local-LL remote-LL
@@ -1305,6 +1319,9 @@ ipv6cp_down(f)
{
IPV6CPDEBUG(("ipv6cp: down"));
update_link_stats(f->unit);
+notify(ipv6_down_notifier, 0);
+if (ipv6_down_hook)
+ ipv6_down_hook();
if (ipv6cp_is_up) {
ipv6cp_is_up = 0;
np_down(f->unit, PPP_IPV6);
diff --git a/pppd/pppd.h b/pppd/pppd.h
index 936cc60..2cd7914 100644
--- a/pppd/pppd.h
+++ b/pppd/pppd.h
@@ -258,8 +258,10 @@ extern struct notifier *pidchange; /* for notifications
of pid changing */
extern struct notifier *phasechange; /* for notifications of phase changes */
extern struct notifier *exitnotify; /* for notification that we're exiting */
extern struct notifier *sigreceived; /* notification of received signal */
-extern struct notifier *ip_up_notifier; /* IPCP has come up */
-extern struct notifier *ip_down_notifier; /* IPCP has gone down */
+extern struct notifier *ip_up_notifier; /* IPCP has come up */
+extern struct notifier *ip_down_notifier; /* IPCP has gone down */
+extern struct notifier *ipv6_up_notifier; /* IPV6CP has come up */
+extern struct notifier *ipv6_down_notifier; /* IPV6CP has gone down */
extern struct notifier *auth_up_notifier; /* peer has authenticated */
extern struct notifier *link_down_notifier; /* link has gone down */
extern struct notifier *fork_notifier; /* we are a new child process */
@@ -727,6 +729,8 @@ extern int (*allowed_address_hook) __P((u_int32_t addr));
extern void (*ip_up_hook) __P((void));
extern void (*ip_down_hook) __P((void));
extern void (*ip_choose_hook) __P((u_int32_t *));
+extern void (*ipv6_up_hook) __P((void));
+extern void (*ipv6_down_hook) __P((void));
extern int (*chap_check_hook) __P((void));
extern int (*chap_passwd_hook) __P((char *user, char *passwd));
--
1.7.9.1
> 2011/3/20 Guillaume Leclanche :
> > 2011/3/19 Dan Williams :
> >> On Sat, 2011-03-19 at 12:56 +0100, Guillaume Leclanche wrote:
> >>
> >> 1) detecting the available PDP context types: many many modems only
> >> support the IP type, but others will support the IPV4/V6 types as well,
> >> especially newer ones. So we'll need to add some code to the enable
> >> sequence (mm-generic-gsm.c) to request AT+CGDCONT=? and pick out the
> >> available PDP context types. There's code that already does some of
> >> this, but only for AT+CGDCONT? to get the currently defined PDP
> >> contexts, while we need to get the *possible* ones.
> >
> > Yes, here's what's returned by mine.
> >
> > AT+CGDCONT=?
> > +CGDCONT: (1-10),("IP"),,,(0-1),(0-1)
> > +CGDCONT: (1-10),("IPV6"),,,(0-1),(0-1)
> >
> > The 3rd context type will be "IPV4V6". Although it's in 3GPP standards
> > already (R8 for LTE and R9 for UMTS/GPRS), there is at the moment
> > hardware supporting it, neither modems nor operator equipment (Q2
> > 2012).
>
> Additionnaly some pointers :
>
> * 3GPP standard with introduction of IPv4v6, Release 9 :
> [2/3G] ftp://ftp.3gpp.org/Specs/2010-12/Rel-9/23_series/23060-970.zip
> [4G] ftp://ftp.3gpp.org/Specs/2010-12/Rel-9/23_series/23401-970.zip
>
> * Great IETF draft to put "IP" names on 3GPP concepts and know where
> it's going :
> http://tools.ietf.org/html/draft-korhonen-v
Automatic setup of UMTS connection
tyUSB3): password => "vodafone" [mm-generic-gsm.c:5099] simple_connect(): (ttyUSB3): allowed_mode => 0 [mm-generic-gsm.c:4988] simple_state_machine(): (ttyUSB3): simple connect state 0 [mm-generic-gsm.c:4988] simple_state_machine(): (ttyUSB3): simple connect state 2 [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): <-- '+COPS: 0,2,"26202",2OK' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): --> 'AT+COPS=3,0;+COPS?' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): <-- '+COPS: 0,0,"Vodafone.de",2OK' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): --> 'AT+CIND?' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): <-- '+CIND: 5,3,1,0,0,0,1,0OK' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): --> 'AT*CNTI=0' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): <-- '*CNTI: 0,HSDPA/HSUPAOK' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): --> 'AT+CGREG?' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): <-- '+CGREG: 2,1,"059A","025C1E2B",2OK' [mm-generic-gsm.c:2655] mm_generic_gsm_set_reg_status(): PS registration state changed: 1 [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): --> 'AT+CREG?' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): <-- '+CREG: 2,1,"059A","025C1E2B",2OK' [mm-generic-gsm.c:4988] simple_state_machine(): (ttyUSB3): simple connect state 4 [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): --> 'AT+COPS=3,2;+COPS?' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): <-- '+COPS: 0,2,"26202",2OK' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): --> 'AT+COPS=3,0;+COPS?' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): <-- '+COPS: 0,0,"Vodafone.de",2OK' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): --> 'AT+CIND?' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): <-- '+CIND: 5,3,1,0,0,0,1,0OK' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): --> 'AT*CNTI=0' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): <-- '*CNTI: 0,HSDPA/HSUPAOK' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): --> 'AT+CGDCONT?' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): <-- '+CGDCONT: 1,"IP","web.vodafone.de","0.0.0.0",0,0OK' [mm-generic-gsm.c:4988] simple_state_machine(): (ttyUSB3): simple connect state 5 [mm-modem.c:742] mm_modem_set_state(): Modem /org/freedesktop/ModemManager/Modems/1: state changed (registered -> connecting) [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): --> 'AT+CGATT=1' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): <-- 'OK' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): --> 'ATD*99***1#' [mm-at-serial-port.c:298] debug_log(): (ttyUSB3): <-- 'CONNECT 115200' [mm-port.c:181] mm_port_set_connected(): (ttyUSB3): port now connected [mm-modem.c:742] mm_modem_set_state(): Modem /org/freedesktop/ModemManager/Modems/1: state changed (connecting -> connected) [mm-generic-gsm.c:4988] simple_state_machine(): (ttyUSB3): simple connect state 6 [mm-manager.c:793] device_added(): (net/ppp0): could not get port's parent device [mm-at-serial-port.c:298] debug_log(): (ttyUSB6): --> 'AT+CREG=2' [mm-at-serial-port.c:298] debug_log(): (ttyUSB6): --> 'AT+CGREG=2' [mm-at-serial-port.c:298] debug_log(): (ttyUSB6): <-- 'ERROR' [mm-serial-parsers.c:412] mm_serial_parser_v1_parse(): Got failure code 100: Unknown error [mm-manager.c:793] device_added(): (net/tun0): could not get port's parent device [mm-at-serial-port.c:298] debug_log(): (ttyUSB6): --> 'AT+CIND?' [mm-at-serial-port.c:298] debug_log(): (ttyUSB6): --> 'AT*CNTI=0' [mm-at-serial-port.c:298] debug_log(): (ttyUSB6): --> 'AT+CIND?' [mm-at-serial-port.c:298] debug_log(): (ttyUSB6): <-- 'ERROR' [mm-serial-parsers.c:412] mm_serial_parser_v1_parse(): Got failure code 100: Unknown error [mm-at-serial-port.c:298] debug_log(): (ttyUSB6): --> 'AT*CNTI=0' | Dipl.-Ing. Markus Becker | Communication Networks | TZI - Center for Computing Technologies | University Bremen | Germany | web: http://www.comnets.uni-bremen.de/~mab/ | mailto: m...@comnets.uni-bremen.de | telephone: +49 421 218 62379 | building: NW1 room: N2260 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Sierra Wireless MC8790V
bInterfaceProtocol 1 Keyboard
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType33
bcdHID 1.11
bCountryCode0 Not supported
bNumDescriptors 1
bDescriptorType34 Report
wDescriptorLength 60
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes3
Transfer TypeInterrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface
Re: Re: how network-manager chose connection?
> On Wed, 2010-07-07 at 14:26 +0200, Pierre-Marie Coron wrote: > > Hello everybody, > > [...] > > At the moment the order can't be changed, it's a function of the > "default route" that is set, either by NM or (if you don't use NM) > normal system networking scripts. It all depends on which connection is > started, either manually by you, or automatically by NM. > > NM will autostart the last-used connection by default if it's wired or > wifi. When multiple connections are active, the ordering is wired > > wifi > 3G. Hi Dan, some time back in the times of NetworkManager in SVN, we made some modifications to NetworkManagerPolicy, so that it exposes the priority of connections/devices/device types (don't remember which one) over DBUS, so that a user (program) could change the priority and initiate an update of the routing and DNS. Are you interested in applying that to git? If yes, then I would start digging it out. > > > I want to make a proxy server who chose the connection according to > > the aviability of it or the kind of protocol witch is using. > > For exemple instant messaging don't need a big bandwidth but streaming > > yes so instant messaging could be used though 56k modem or GPRS key > > instead of using the ethernet connection. This is similar to what we did. Applications could register with some service and based on the applications the service would set the priorities inside NM. Markus > This is somewhat complicated, because it's not about which connections > are active and which aren't, but it's about IP routing which > NetworkManager doesn't really get into (other than setting the default > route). > > You can *simulate* this by adding specific routes to the servers you > want to use to the routing table. So if you know your IM server's IP > address you could: > > ip route add /32 dev > > If that IP address is stable, you can add it to the NetworkManager > connection infromation for your GPRS connetion in the connection > editor's IPv4 Routes dialog and all your IM should then go over GPRS. > You can do that with NM today. > > You can't use the kernels IP routing table for *classes* of traffic > right now, but you might be able to use the Linux firewall (iptables) to > do this for you since it's quite a flexible packet filter and does a lot > more than just firewalling. > > So the short answer is: > > - yes, you can make traffic to specific IP address or subnets use a > specific interface by adding those subnets as routes to the NM IPv4 > Routes dialog > > - it's a lot more complicated to send classes of traffic (ie, all web > traffic) out over a specific interface > > Dan > > > I already see documentation about QoS software like wondershaper but > > it is made for one connection. > > I hope my message is clear and i apologize for my poor English. > > > > Best regards > > > > PM > > ___ > > 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 | Dipl.-Ing. Markus Becker | Communication Networks | Mobile Research Center | TZI - Center for Computing Technologies | University Bremen | Germany | web: http://www.comnets.uni-bremen.de/~mab/ | mailto: m...@comnets.uni-bremen.de | telephone: +49 421 218 62379 | building: NW1 room: N2260 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
access to "ppp0" on dbus
Hi, is it somehow possible to get the ppp device of a mobile broadband connection (e.g. ppp0), which was created by a dial-in connection, over dbus? Up to now we only found the physical device name (ttyUSB0) and the Udi. Thanks, Markus | ATTENTION: NEW TELEPHONE EXTENSION! | Dipl.-Ing. Markus Becker | Communication Networks | Mobile Research Center | TZI - Center for Computing Technologies | University Bremen | Germany ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Can not build network-manager from git with debian squeeze
you need libiw-dev. markus > Hi, > > i tried to build the latest git sources and got the following error: > > ### BEGIN ### > $ ./autogen.sh > ... > ... > checking Linux Wireless Extensions >= 18... no > configure: error: wireless-tools library and development headers >= 28pre9 > not installed or not functional > ### END ### > > but: > $ dpkg -l|grep wireless-tools > ii wireless-tools30~pre9-4 Tools > for manipulating Linux Wireless Extensions > > > so wireless-tools are version 30. > > Any idea? > > Cheers, > Tom ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Wrong SVN information on web site
Hi, I just noticed that on http://projects.gnome.org/NetworkManager/ talk is still that the source code is handled in SVN although it is git for some time now. "For information on obtaining the NetworkManager source code from GNOME SVN, read the developers page" BR, Markus ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Installation of git into home directory
Hi, I would like to have the distribution NetworkManager in the usual places on the disc and at the same time have a git NetworkManager in my home directory installed. (And the same for nm-applet.) I was trying: ./autogen.sh --prefix=/home/mab/install/usr --sysconfdir=/home/mab/install/etc --localstatedir=/home/mab/install/var and ./autogen.sh --prefix=/home/mab/install/usr --sysconfdir=/home/mab/install/etc --localstatedir=/home/mab/install/var --libdir=/home/mab/install/lib Both times it tries to install something into /lib: /usr/bin/install: cannot create regular file `/lib/udev/rules.d/77-nm-olpc-mesh.rules': Permission denied Isn't this the supposed in-home-directory procedure? Or is $(LIBDIR) missing somewhere in the scripts? Thanks, Markus | Dipl.-Ing. Markus Becker | Communication Networks | Mobile Research Center | TZI - Center for Computing Technologies | University Bremen | Germany | web: http://www.comnets.uni-bremen.de/~mab/ | mailto: m...@comnets.uni-bremen.de ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
small fixes for de.po
Hello, attached are some small de translation fixes. BR, MarkusIndex: networkmanager/vpn-daemons/openvpn/po/de.po === --- networkmanager.orig/vpn-daemons/openvpn/po/de.po 2008-07-10 17:18:26.0 +0200 +++ networkmanager/vpn-daemons/openvpn/po/de.po 2008-07-10 17:21:14.0 +0200 @@ -18,12 +18,12 @@ #: ../auth-dialog/gnome-two-password-dialog.c:145 msgid "_Password:" -msgstr "_Password:" +msgstr "_Passwort:" # CHECK: Secondary => Zweit...? #: ../auth-dialog/gnome-two-password-dialog.c:146 msgid "_Secondary Password:" -msgstr "_Zweitpassword:" +msgstr "_Zweitpasswort:" #: ../auth-dialog/gnome-two-password-dialog.c:263 msgid "_Username:" @@ -64,7 +64,7 @@ #: ../auth-dialog/main.c:227 msgid "Certificate pass_word:" -msgstr "Pass_wort zertifzieren:" +msgstr "Pass_wort zertifizieren:" #: ../auth-dialog/main.c:252 msgid "Certificate password:" Index: networkmanager/vpn-daemons/vpnc/po/de.po === --- networkmanager.orig/vpn-daemons/vpnc/po/de.po 2008-07-10 17:22:19.0 +0200 +++ networkmanager/vpn-daemons/vpnc/po/de.po 2008-07-10 17:24:54.0 +0200 @@ -21,7 +21,7 @@ #: ../auth-dialog/gnome-two-password-dialog.c:258 msgid "_Username:" -msgstr "_Benuterzname:" +msgstr "_Benutzername:" #: ../auth-dialog/gnome-two-password-dialog.c:260 msgid "_Domain:" @@ -141,7 +141,7 @@ #: ../properties/nm-vpnc.c:567 #, c-format msgid "The VPN settings file '%s' does not contain valid data." -msgstr "Die VPN-Einstellugnendatei »%s« enthält keine gültigen Daten." +msgstr "Die VPN-Einstellungendatei »%s« enthält keine gültigen Daten." #: ../properties/nm-vpnc.c:584 msgid "Select file to import" @@ -247,7 +247,7 @@ msgid "" "The VPN login failed because the user name and password were not accepted." msgstr "" -"Die VPN-Anmeldung scheiterte, das Benutzername und Kennwort nicht akzeptiert " +"Die VPN-Anmeldung scheiterte, da Benutzername und Kennwort nicht akzeptiert " "wurden." #: ../src/nm-vpnc-service.c:121 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
PPP: "Re: IPCP with mobile ISP sometimes gives bogus DNS address"
Hi all, several 3G cards (e.g. from Option) are reporting 10.11.12.13 as DNS server, when they are not yet attached to a network, as you probably know, see http://marc.info/?l=linux-ppp&w=2&r=1&s=bogus+DNS&q=b There seem to be 2 possible solutions to this: 1) Patch PPP to accept MS-WINS settings and use high values for ipcp-max-configure, ipcp-max-failure, ipcp-max-terminate and/or ipcp-restart. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445711 . (I am using the mentioned patch currently. Works fine for me.) 2) Checking with AT command CGATT, whether the device is attached to a network and only try to dial in when this is true. (http://marc.info/?l=linux-ppp&m=121305432406467&w=2) In order to get this fixed, I have several questions: a) The Debian bug report states, this has been sent upstream. Has upstream accepted, denied or forgotten about it? Is there an upstream bugzilla for linux-ppp? b) Marco, could this patch be part of the Debian package? Dan, how is this done in Fedora? c) Dan, could solution 2 be integrated into NM? Markus ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Pruning the active AP
On Thu, 3 Jul 2008, Dan Williams wrote: On Thu, 2008-07-03 at 17:28 +0200, Markus Becker wrote: Hello, I was checking how NM reacts, when an AP, that we are connected to, dies or is getting out of range. I was expecting NM to notice that and remove the current AP from the list of available APs. However, NM keeps the AP in its list. I think this is because of this in nm-device-wifi.c: Have you tried it with the patch from Adel Gallah for the scan timeout stuff from last week? That patch specifically fixed the issue of never noticing that the AP was out of range even after the supplicant had sent the disconnection status. No, I was trying without it (with Michael Biebl's packages). With r3811 NM seems to notice that an AP is gone, after about 30 sec. And it takes about 50s to figure out that an AP has come back (Including the booting time of the AP.) But what I was looking for, but didn't see, is link_timeout_cb(). /* Don't ever prune the AP we're currently associated with */ if (cur_ap_path && !strcmp (cur_ap_path, nm_ap_get_dbus_path (ap))) keep = TRUE; What was the reasoning behind keeping the AP we're connected to, when it is not in the scanning list anymore? Are some cards not reporting the AP we are connected to in the scanning list or why? Yes, even though they technically should, drivers and cards don't necessarily do this. Since wireless is a fairly unreliable medium, it's not always the case that the connected AP's beacons will show up in a given scan. We simply cannot rely on that unless drivers are mandated to include that upstream in the kernel. Well, it works with the ndiswrapper for the Marvell card (sorry, currently no time for the mrv8k driver). Dan Markus -------- | Dipl.-Ing. Markus Becker | Communication Networks | Mobile Research Center | TZI - Center for Computing Technologies | University Bremen | Germany | web: http://www.comnets.uni-bremen.de/~mab/ | mailto: [EMAIL PROTECTED] | telephone: +49 421 218 2287 | building: NW1 room: N2260 ___ 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
Pruning the active AP
Hello, I was checking how NM reacts, when an AP, that we are connected to, dies or is getting out of range. I was expecting NM to notice that and remove the current AP from the list of available APs. However, NM keeps the AP in its list. I think this is because of this in nm-device-wifi.c: /* Don't ever prune the AP we're currently associated with */ if (cur_ap_path && !strcmp (cur_ap_path, nm_ap_get_dbus_path (ap))) keep = TRUE; What was the reasoning behind keeping the AP we're connected to, when it is not in the scanning list anymore? Are some cards not reporting the AP we are connected to in the scanning list or why? Markus -------- | Dipl.-Ing. Markus Becker | Communication Networks | Mobile Research Center | TZI - Center for Computing Technologies | University Bremen | Germany | web: http://www.comnets.uni-bremen.de/~mab/ | mailto: [EMAIL PROTECTED] | telephone: +49 421 218 2287 | building: NW1 room: N2260 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 3G; wireless auth; policies; docs
On Thu, 3 Jul 2008, Jens-Michael Hoffmann wrote: Hi, first of all let me thank you for your great work and NetworkManager. We are currently evaluating NetworkManager and would like to ask some questions: What is the status of support for 3G devices? Works very nicely for me with Option Fusion+ (:-)) and others. However the cards sometimes report bogus DNS server IP addresses, see e.g. http://www.mail-archive.com/networkmanager-list%40gnome.org/msg08359.html How and where are policies (like choose wired over wireless) implemented? In NetworkManagerPolicy.c: get_device_priority() Is it possible to do connect on demand with NetwokManager? How is the wireless authentication stuff (WEP/WPA/WPA2) handled? Are there callbacks to get the keys or any other mechanism? Is there any kind of documentation apart from the generated spec.html? We are especially looking for developer documentation. Best regards Jens-Michael Hoffmann ___ 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: dnsmasq make error with current svn snapshot
Hi. Just add "= NULL" to that line. Markus On Wed, 4 Jun 2008, Tom Sutherland wrote: this is on kubuntu hardy - any ideas? cc1: warnings being treated as errors nm-dnsmasq-manager.c: In function ÿÿdm_watch_cbÿÿ: nm-dnsmasq-manager.c:174: warning: ÿÿmsgÿÿ may be used uninitialized in this function nm-dnsmasq-manager.c:174: note: ÿÿmsgÿÿ was declared here make[3]: *** [libdnsmasq_manager_la-nm-dnsmasq-manager.lo] Error 1 ___ 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
nm-tool showing default route
Hi Dan,
below is a patch that shows the default route in nm-tool. Feel free to
modify it.
Markus
Index: test/nm-tool.c
===
--- test/nm-tool.c (revision 3715)
+++ test/nm-tool.c (working copy)
@@ -198,11 +198,14 @@
detail_device (gpointer data, gpointer user_data)
{
NMDevice *device = NM_DEVICE (data);
+ NMClient *client = NM_CLIENT (user_data);
char *tmp;
NMDeviceState state;
guint32 caps;
guint32 speed;
const GArray *array;
+ const GPtrArray *connections;
+ int j;
state = nm_device_get_state (device);
@@ -223,6 +226,21 @@
print_string ("State", get_dev_state_string (state));
+ connections = nm_client_get_active_connections (client);
+ for (j = 0; connections && (j < connections->len); j++) {
+ NMActiveConnection *candidate = g_ptr_array_index (connections,
j);
+ const GPtrArray *devices = nm_active_connection_get_devices
(candidate);
+ NMDevice *candidate_dev;
+
+ if (!devices || !devices->len)
+ continue;
+ candidate_dev = g_ptr_array_index (devices, 0);
+
+ if ( candidate_dev == device &&
+nm_active_connection_get_default(candidate))
+ print_string ("Route", "IPv4 Default Route");
+ }
+
tmp = NULL;
if (NM_IS_DEVICE_802_3_ETHERNET (device))
tmp = g_strdup (nm_device_802_3_ethernet_get_hw_address
(NM_DEVICE_802_3_ETHERNET (device)));
@@ -362,7 +380,7 @@
}
devices = nm_client_get_devices (client);
- g_ptr_array_foreach ((GPtrArray *) devices, detail_device, NULL);
+ g_ptr_array_foreach ((GPtrArray *) devices, detail_device, client);
g_object_unref (client);
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Possibility to auto-connect also dialup connections
And again hello.
Another patch for discussion. This time it is about having the possibility
to use auto-connect for dial-up. I know, usually most people, do not want
to auto-connect UMTS, but this patch just gives people the possibility to
auto-connect and let NM decide, whether the UMTS connection is the best
available connection.
BR,
Markus
Index: src/nm-gsm-device.c
===
--- src/nm-gsm-device.c (revision 3644)
+++ src/nm-gsm-device.c (working copy)
@@ -5,6 +5,7 @@
#include "nm-gsm-device.h"
#include "nm-device-interface.h"
#include "nm-device-private.h"
+#include "nm-setting-connection.h"
#include "nm-setting-gsm.h"
#include "nm-utils.h"
#include "nm-properties-changed-signal.h"
@@ -515,6 +550,31 @@
return priv->pending_id ? NM_ACT_STAGE_RETURN_POSTPONE :
NM_ACT_STAGE_RETURN_FAILURE;
}
+static NMConnection *
+real_get_best_auto_connection (NMDevice *dev,
+ GSList *connections,
+ char **specific_object)
+{
+ GSList *iter;
+
+ for (iter = connections; iter; iter = g_slist_next (iter)) {
+ NMConnection *connection = NM_CONNECTION (iter->data);
+ NMSettingConnection *s_con;
+
+ s_con = (NMSettingConnection *) nm_connection_get_setting
(connection, NM_TYPE_SETTING_CONNECTION);
+ g_assert (s_con);
+
+ if (!s_con->autoconnect)
+ continue;
+
+ if (strcmp (s_con->type, NM_SETTING_GSM_SETTING_NAME))
+ continue;
+
+ return connection;
+ }
+ return NULL;
+}
+
static guint32
real_get_generic_capabilities (NMDevice *dev)
{
@@ -765,6 +825,8 @@
object_class->set_property = set_property;
object_class->finalize = finalize;
+ device_class->get_best_auto_connection = real_get_best_auto_connection;
+
device_class->get_generic_capabilities = real_get_generic_capabilities;
device_class->act_stage1_prepare = real_act_stage1_prepare;
device_class->connection_secrets_updated =
real_connection_secrets_updated;
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
IPv4/DNS Settings for Dialup from gconf (2)
Hello again,
sorry, this part belongs to the patch as well.
Markus
Index: src/nm-serial-device.c
===
--- src/nm-serial-device.c (revision 3644)
+++ src/nm-serial-device.c (working copy)
@@ -982,11 +982,17 @@
real_act_stage4_get_ip4_config (NMDevice *device, NMIP4Config **config)
{
NMSerialDevicePrivate *priv = NM_SERIAL_DEVICE_GET_PRIVATE (device);
+ NMActStageReturn ret = NM_ACT_STAGE_RETURN_FAILURE;
+ NMDeviceClass *parent_class;
+
*config = priv->pending_ip4_config;
priv->pending_ip4_config = NULL;
+
+ parent_class = NM_DEVICE_CLASS (nm_serial_device_parent_class);
+ ret = parent_class->act_stage4_get_ip4_config (device, config);
- return NM_ACT_STAGE_RETURN_SUCCESS;
+ return ret;
}
static void
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
IPv4/DNS Settings for Dialup from gconf
Hello Dan, Tambet,
as a follow-up on the 'weird' DNS address (10.11.12.13) issue, I added
some code that enables using the ipv4 settings (well currently only the
DNS addresses) from gconf. I would love to hear your opinion on this.
I also have a patch adding the ipv4 page to the connection-editor, which I
could provide, if you think this patch is OK.
BR,
Markus
Index: src/NetworkManagerUtils.c
===
--- src/NetworkManagerUtils.c (revision 3644)
+++ src/NetworkManagerUtils.c (working copy)
@@ -259,7 +259,7 @@
}
if (!found)
- nm_ip4_config_add_nameserver (ip4_config, ns);
+ nm_ip4_config_prepend_nameserver (ip4_config,
ns);
}
}
Index: src/nm-device.c
===
--- src/nm-device.c (revision 3644)
+++ src/nm-device.c (working copy)
@@ -646,7 +646,6 @@
NMSettingIP4Config *s_ip4;
g_return_val_if_fail (config != NULL, NM_ACT_STAGE_RETURN_FAILURE);
- g_return_val_if_fail (*config == NULL, NM_ACT_STAGE_RETURN_FAILURE);
connection = nm_act_request_get_connection (nm_device_get_act_request
(self));
g_assert (connection);
@@ -654,6 +653,7 @@
s_ip4 = (NMSettingIP4Config *) nm_connection_get_setting (connection,
NM_TYPE_SETTING_IP4_CONFIG);
if (nm_device_get_use_dhcp (self)) {
+ g_return_val_if_fail (*config == NULL,
NM_ACT_STAGE_RETURN_FAILURE);
*config = nm_dhcp_manager_get_ip4_config (NM_DEVICE_GET_PRIVATE
(self)->dhcp_manager,
nm_device_get_iface (self));
nm_utils_merge_ip4_config (*config, s_ip4);
@@ -663,8 +663,16 @@
if (!strcmp (s_ip4->method,
NM_SETTING_IP4_CONFIG_METHOD_AUTOIP)) {
nm_device_new_ip4_autoip_config (self);
} else if (!strcmp (s_ip4->method,
NM_SETTING_IP4_CONFIG_METHOD_MANUAL)) {
+ g_return_val_if_fail (*config == NULL,
NM_ACT_STAGE_RETURN_FAILURE);
*config = nm_ip4_config_new ();
nm_utils_merge_ip4_config (*config, s_ip4);
+ } else if ( s_ip4->dns != NULL ) {
+ nm_info ("real_act_stage4_get_ip4_config: %x %x ",
+g_array_index (s_ip4->dns, guint32, 0),
+
g_array_index (s_ip4->dns, guint32, 1)
+ );
+ nm_utils_merge_ip4_config (*config, s_ip4);
+ return NM_ACT_STAGE_RETURN_SUCCESS;
}
}
Index: src/nm-ip4-config.c
===
--- src/nm-ip4-config.c (revision 3644)
+++ src/nm-ip4-config.c (working copy)
@@ -216,6 +216,14 @@
NM_IP4_CONFIG_GET_PRIVATE (config)->ptp_address = ptp_addr;
}
+void nm_ip4_config_prepend_nameserver (NMIP4Config *config, guint32 nameserver)
+{
+ g_return_if_fail (NM_IS_IP4_CONFIG (config));
+
+ if (nameserver != 0)
+ g_array_prepend_val (NM_IP4_CONFIG_GET_PRIVATE
(config)->nameservers, nameserver);
+}
+
void nm_ip4_config_add_nameserver (NMIP4Config *config, guint32 nameserver)
{
g_return_if_fail (NM_IS_IP4_CONFIG (config));
Index: src/nm-ip4-config.h
===
--- src/nm-ip4-config.h (revision 3644)
+++ src/nm-ip4-config.h (working copy)
@@ -67,6 +67,7 @@
guint32 nm_ip4_config_get_ptp_address (NMIP4Config
*config);
void nm_ip4_config_set_ptp_address (NMIP4Config
*config, guint32 ptp_addr);
+void nm_ip4_config_prepend_nameserver
(NMIP4Config *config, guint32 nameserver);
void nm_ip4_config_add_nameserver(NMIP4Config
*config, guint32 nameserver);
guint32 nm_ip4_config_get_nameserver(NMIP4Config
*config, guint i);
guint32 nm_ip4_config_get_num_nameservers (NMIP4Config
*config);
Index: src/ppp-manager/nm-ppp-manager.c
===
--- src/ppp-manager/nm-ppp-manager.c(revision 3644)
+++ src/ppp-manager/nm-ppp-manager.c(working copy)
@@ -11,6 +11,7 @@
#include "nm-setting-connection.h"
#include "nm-setting-ppp.h"
#include "nm-setting-pppoe.h"
+#include "nm-setting-ip4-config.h"
#include "nm-dbus-manager.h"
#include "nm-utils.h"
#include "nm-marshal.h"
@@ -278,8 +279,13 @@
if (val) {
GArray *dns = (GArray *) g_value_get_boxed (val);
- for (i = 0; i < dns->len; i++)
+ for (i = 0; i <
Re: Regression from Revision 3456: Dialup GSM/UMTS
On Wed, 30 Apr 2008, Dan Williams wrote:
> On Tue, 2008-04-29 at 11:59 +0200, Markus Becker wrote:
>> Hi,
>>
>> since revision 3456 dialup is not working for me anymore.
>>
>> When dialing in the response I get is:
>>
>> CONNECT 180
>>
>> The problem is in nm-serial-device.c find_terminators(), which does not
>> think that the answer above is a terminator.
>>
>> This patch worked for me, but might also find the terminator in the middle
>> of the line, which might not be wanted for other reponses.
>>
>> Index: src/nm-serial-device.c
>> ===
>> --- src/nm-serial-device.c (revision 3615)
>> +++ src/nm-serial-device.c (working copy)
>> @@ -566,7 +566,7 @@
>> int i;
>>
>> for (i = 0; terminators[i]; i++) {
>> - if (!strcasecmp (line, terminators[i]))
>> + if (strcasestr (line, terminators[i]))
>
> That should probably be a strncasecmp(). We don't want strcaststr()
> because that might find a terminator in the middle of the line, and we
> don't want that. Modem responses will be on the beginning of the line,
> and that's what we'll be matching against.
if (strncasecmp (line, terminators[i], strlen(terminators[i])))
Works for me.
Thanks, Markus
>
> I'll code up strncasecmp() and see if that works for me. In the mean
> time, could you test that out and report whether it seems to work for
> you too?
>
> Thanks!
> Dan
>
>
>> return TRUE;
>> }
>> return FALSE;
>>
>>
>>
>> BR,
>> Markus
>> ___
>> 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
Regression from Revision 3456: Dialup GSM/UMTS
Hi,
since revision 3456 dialup is not working for me anymore.
When dialing in the response I get is:
CONNECT 180
The problem is in nm-serial-device.c find_terminators(), which does not
think that the answer above is a terminator.
This patch worked for me, but might also find the terminator in the middle
of the line, which might not be wanted for other reponses.
Index: src/nm-serial-device.c
===
--- src/nm-serial-device.c (revision 3615)
+++ src/nm-serial-device.c (working copy)
@@ -566,7 +566,7 @@
int i;
for (i = 0; terminators[i]; i++) {
- if (!strcasecmp (line, terminators[i]))
+ if (strcasestr (line, terminators[i]))
return TRUE;
}
return FALSE;
BR,
Markus
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: SVN HEAD: Compilation error
On Thu, 10 Apr 2008, Tambet Ingo wrote: > On Thu, Apr 10, 2008 at 12:56 PM, Markus Becker > <[EMAIL PROTECTED]> wrote: >> nm-system-config-hal-manager.c: In function >> 'nm_system_config_hal_manager_class_init': >> nm-system-config-hal-manager.c:306: error: 'nm_marshal_VOID__STRING_UINT' >> undeclared (first use in this function) > > Remove all the generated nm-marshal.[ch] files from all directories > and rebuild. There was a different nm-marshal.[ch] in almost every > source directory, it's now unified, but the build finds an old and > obsoleted one. Works, thanks. > > Tambet > ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
SVN HEAD: Compilation error
Hello, I was trying to compile svn head of network-manager. I am getting the following error with gcc-4.2: if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../include -I../../libnm-util -I../../libnm-glib -I../../marshallers -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DDBUS_VERSION_MAJOR=1 -DDBUS_VERSION_MINOR=1 -DDBUS_VERSION_MICRO=20 -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DDBUS_API_SUBJECT_TO_CHANGE -DG_DISABLE_DEPRECATED -DBINDIR=\"/home/mab/install/bin\" -DSBINDIR=\"/home/mab/install/sbin\" -DLIBEXECDIR=\"/home/mab/install/libexec\" -DDATADIR=\"/home/mab/install/share\" -DSYSCONFDIR=\"/home/mab/install/etc\" -DLOCALSTATEDIR=\"/home/mab/install/var\" -DGNOMELOCALEDIR=\"/home/mab/install/share/locale\" -DPLUGINDIR=\"/home/mab/install/lib/NetworkManager\" -Wall -Werror -std=gnu89 -g -O2 -Wshadow -Wmissing-declarations -Wmissing-prototypes -Wdeclaration-after-statement -Wfloat-equal -Wno-unused-parameter -Wno-sign-compare -MT nm_system_settings-nm-system-config-hal-manager.o -MD -MP -MF ".deps/nm_system_settings-nm-system-config-hal-manager.Tpo" -c -o nm_system_settings-nm-system-config-hal-manager.o `test -f 'nm-system-config-hal-manager.c' || echo './'`nm-system-config-hal-manager.c; \ then mv -f ".deps/nm_system_settings-nm-system-config-hal-manager.Tpo" ".deps/nm_system_settings-nm-system-config-hal-manager.Po"; else rm -f ".deps/nm_system_settings-nm-system-config-hal-manager.Tpo"; exit 1; fi nm-system-config-hal-manager.c: In function 'init_dbus': nm-system-config-hal-manager.c:205: error: 'nm_marshal_VOID__STRING_STRING' undeclared (first use in this function) nm-system-config-hal-manager.c:205: error: (Each undeclared identifier is reported only once nm-system-config-hal-manager.c:205: error: for each function it appears in.) nm-system-config-hal-manager.c: In function 'nm_system_config_hal_manager_class_init': nm-system-config-hal-manager.c:306: error: 'nm_marshal_VOID__STRING_UINT' undeclared (first use in this function) make[4]: *** [nm_system_settings-nm-system-config-hal-manager.o] Error 1 BR, Markus ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM using Option card
On Fri, 8 Feb 2008, Markus Becker wrote: > I looked at it as well today and they are just informing the user about > the bad DNS IP address, but not doing anything. Hi Dan, I have patched nm-pppd-plugin.c to use static DNS addresses, if it gets a bogus 10.11.12.13 DNS address. The patch however has the static address hardcoded. Is it possible to enable the pppd-plugin get static DNS addresses from the gconf settings? Are there already implementations for static DNS for NM? Should one enter supersede entries in dhclient.conf? What would be your preferences there? Best regards, Markus >>>>> The 10.64.64.64 default peer address is also no problem - the network just >>>>> does not return a peer address, so pppd uses this default. It does not >>>>> matter, >>>>> as long as your default route points to the ppp interface, it just works. >>>>> At least for me, with a quite some hardware and providers that have >>>>> tested. >>>> >>>> Not really; I needed a valid peer address for Sprint here in the US >>>> otherwise my packets would go nowhere. Previously, the NM >>>> implementation would just assign the local address as the peer address, >>>> and that simply didn't work. I can't imagine how assigning the random >>>> 10.64.64.6x address would work any better? >>> >>> If the peer does not supply a peer address it will basically go like >>> >>> route add default dev ppp0 >>> >>> As long as the other end takes all traffic and routes it, you don't >>> need a default gateway set up on your machine. >>> >>> [EMAIL PROTECTED]:~# ifconfig modemB >>> modemBLink encap:Point-to-Point Protocol >>> inet addr:10.129.77.52 P-t-P:10.64.64.64 Mask:255.255.255.255 >>> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 >>> RX packets:4 errors:0 dropped:0 overruns:0 frame:0 >>> TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 >>> collisions:0 txqueuelen:3 >>> RX bytes:58 (58.0 b) TX bytes:327 (327.0 b) >>> >>> [EMAIL PROTECTED]:~# route -n >>> Kernel IP routing table >>> Destination Gateway Genmask Flags Metric RefUse >>> Iface >>> 10.64.64.64 0.0.0.0 255.255.255.255 UH0 00 >>> modemB >>> 127.0.0.0 0.0.0.0 255.0.0.0 U 0 00 lo >>> 0.0.0.0 0.0.0.0 0.0.0.0 U 0 00 >>> modemB >>> >>> and it works just fine. (Yes, ifconfig and route are lame and real men use >>> ip >>> for that today... :-) >>> >>> This does not mean that this will work for all configurations, but for those >>> i encountered here in europe, it worked just fine. >> > ___ > 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: NM using Option card
On Thu, 7 Feb 2008, Dan Williams wrote:
> On Thu, 2008-02-07 at 20:38 +0100, Markus Becker wrote:
>> Hi,
>>
>> I was trying to get NM SVN working using an Option UMTS card. After
>> figuring out that additionally to the capability "modem" (mentioned
>> previously on the mailing list) also the capability "gsm" is needed, my
>> /usr/share/hal/fdi/information/20thirdparty/10-3g-modem.fdi looks like
>> this:
>
> What's the exact model of your card, BTW? I'm trying to put together a
> database of all the ones I come across.
I got another card: Option Fusion+ (WLAN and HSDPA). It is working using
the nozomi driver. The following fdi file adds the capabilities modem and
gsm to the serial.port 0.
modem
gsm
>
> Thanks,
> Dan
>
>>
>>
>>
>>
>>
>>
>>
>>
>> modem
>> gsm
>>
>>
>>
>>
>>
>>
>>
>> However, I needed to modify nm-gsm-device to work with the Option card to
>> try the registration again also for the reply "+CREG: 0,0". After the
>> second or third "+CREG: 0,0" reply, it then replies with "+CREG: 0,2" as
>> expected. This patch works for me:
>>
>> Index: nm-gsm-device.c
>> ===
>> --- nm-gsm-device.c (revision 3294)
>> +++ nm-gsm-device.c (working copy)
>> @@ -233,6 +233,7 @@
>> automatic_registration_get_network (device);
>> break;
>> case 2:
>> +case 3:
>> gsm_device_set_pending (NM_GSM_DEVICE (device),
>> g_timeout_add (1000,
>> automatic_registration_again, device));
>> break;
>> @@ -251,7 +252,7 @@
>> automatic_registration (NMSerialDevice *device)
>> {
>> guint id;
>> -char *responses[] = { "+CREG: 0,1", "+CREG: 0,5", "+CREG: 0,2", NULL };
>> +char *responses[] = { "+CREG: 0,1", "+CREG: 0,5", "+CREG: 0,2", "+CREG:
>> 0,0", NULL };
>>
>> nm_serial_device_send_command_string (device, "AT+CREG?");
>> id = nm_serial_device_wait_for_reply (device, 60, responses,
>> automatic_registration_response, NULL);
>>
>> --
>>
>> I needed to tick "noauth" in gconf-editor, shouldn't this be the default
>> for dialup?
>>
>> Currently I am struggling with the routes and the IP configuration, setted
>> after dialing in. They do not seem reasonable to me and I cannot reach the
>> DNS server nor the peer (10.64.64.64).
>>
>> ppp0 Link encap:Point-to-Point Protocol
>>inet addr:90.187.199.128 P-t-P:10.64.64.64 Mask:255.255.255.255
>>
>> Kernel IP routing table
>> Destination Gateway Genmask Flags Metric RefUse Iface
>> 10.64.64.64 0.0.0.0 255.255.255.255 UH0 00 ppp0
>> 0.0.0.0 0.0.0.0 0.0.0.0 U 0 00 ppp0
>>
>> Has anyone a clue?
>>
>> Thanks for NetworkManager and the GSM/UMTS support.
>>
>> BR,
>> Markus
>>
>>
>> | Dipl.-Ing. Markus Becker
>> | Communication Networks
>> | Mobile Research Center
>> | TZI - Center for Computing Technologies
>> | University Bremen
>> | Germany
>>
>> | web: http://www.comnets.uni-bremen.de/~mab/
>> | mailto: [EMAIL PROTECTED]
>> | telephone: +49 421 218 2287
>> | building: NW1 room: N2260
>>
>> ___
>> 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: NM using Option card
On Fri, 8 Feb 2008, Dan Williams wrote: > On Fri, 2008-02-08 at 17:03 +0100, Stefan Seyfried wrote: >> On Fri, Feb 08, 2008 at 09:54:28AM -0500, Dan Williams wrote: >>> We've been talking to the VMC developers, who have added a D-Bus >>> interface to VMC. You're right, it's pointless to have many projects >>> duplicate the same quirks and workarounds for cards, and using some >>> existing tool is the way to go. Since VMC is adding the D-Bus >>> interface, Tambet and I thought that using VMC like we currently use >>> wpa_supplicant would be a good option. >> >> Did you ever look at VMC? IMHO it is much too heavyweight to be a backend >> for a system daemon like NM. And it supported almost no hardware the last >> time i looked (a few weeks ago). > > They were separating it into a backend and a front-end GUI client as far > as I know. Their GUI frontend would do stuff like SMS and address book > manipulation and communicate with the backend via D-Bus, like NM would > do. > > Dan I looked at it as well today and they are just informing the user about the bad DNS IP address, but not doing anything. The 10.64.64.64 default peer address is also no problem - the network just does not return a peer address, so pppd uses this default. It does not matter, as long as your default route points to the ppp interface, it just works. At least for me, with a quite some hardware and providers that have tested. >>> >>> Not really; I needed a valid peer address for Sprint here in the US >>> otherwise my packets would go nowhere. Previously, the NM >>> implementation would just assign the local address as the peer address, >>> and that simply didn't work. I can't imagine how assigning the random >>> 10.64.64.6x address would work any better? >> >> If the peer does not supply a peer address it will basically go like >> >> route add default dev ppp0 >> >> As long as the other end takes all traffic and routes it, you don't >> need a default gateway set up on your machine. >> >> [EMAIL PROTECTED]:~# ifconfig modemB >> modemBLink encap:Point-to-Point Protocol >> inet addr:10.129.77.52 P-t-P:10.64.64.64 Mask:255.255.255.255 >> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 >> RX packets:4 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:3 >> RX bytes:58 (58.0 b) TX bytes:327 (327.0 b) >> >> [EMAIL PROTECTED]:~# route -n >> Kernel IP routing table >> Destination Gateway Genmask Flags Metric RefUse Iface >> 10.64.64.64 0.0.0.0 255.255.255.255 UH0 00 >> modemB >> 127.0.0.0 0.0.0.0 255.0.0.0 U 0 00 lo >> 0.0.0.0 0.0.0.0 0.0.0.0 U 0 00 >> modemB >> >> and it works just fine. (Yes, ifconfig and route are lame and real men use ip >> for that today... :-) >> >> This does not mean that this will work for all configurations, but for those >> i encountered here in europe, it worked just fine. > ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM using Option card
On Fri, 8 Feb 2008, Stefan Seyfried wrote: Markus Becker wrote: No. Debian. It might be that I do not get the correct DNS server from the peer: Feb 7 20:55:56 shelbyville pppd[10716]: Using interface ppp0 Feb 7 20:55:56 shelbyville pppd[10716]: Connect: ppp0 <--> /dev/ttyUSB0 Feb 7 20:55:56 shelbyville pppd[10716]: PAP authentication succeeded Feb 7 20:56:34 shelbyville pppd[10716]: Could not determine remote IP address: defaulting to 10.64.64.64 Feb 7 20:56:34 shelbyville pppd[10716]: Cannot determine ethernet address for proxy ARP Feb 7 20:56:34 shelbyville pppd[10716]: local IP address 90.186.19.42 Feb 7 20:56:34 shelbyville pppd[10716]: remote IP address 10.64.64.64 Feb 7 20:56:34 shelbyville pppd[10716]: primary DNS address 10.11.12.13 Feb 7 20:56:34 shelbyville pppd[10716]: secondary DNS address 10.11.12.14 This happens for me (using umtsmon) when the dialup takes too long. Apparently the card is not patient enough and just returns some standard DNS server addresses. Also this happens more often with vodafone than, say, eplus as provider. Generally goes away if you hang up and dial in again. Yes, the second dialin sets the correct DNS as well for me most of the times. It seems that this is actually a ppp bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445711 which has been forwarded upstream to [EMAIL PROTECTED], see http://www.opensubscriber.com/message/linux-ppp%40vger.kernel.org/7889888.html It is supposed to be a problem of the PCMCIA card insisting on ms-wins settings, which ppp denies and because of that it does not get the real DNS information from the PCMCIA card. The patch for ppp seems to solve the problem. I have not tested it. BTW, there is a lot of debugging and magic quirks for different cards already done in umtsmon, if somebody working on UMTS features for NM would ask Klaas for some hints, this would probably spare you lots of unnecessary work and you could profit from his knowledge. The 10.64.64.64 default peer address is also no problem - the network just does not return a peer address, so pppd uses this default. It does not matter, as long as your default route points to the ppp interface, it just works. At least for me, with a quite some hardware and providers that have tested. Good luck, Stefan -- Stefan Seyfried R&D Team Mobile Devices| "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM using Option card
On Thu, 7 Feb 2008, Dan Williams wrote:
> On Thu, 2008-02-07 at 21:59 +0100, Markus Becker wrote:
>> On Thu, 7 Feb 2008, Dan Williams wrote:
>>
>>> On Thu, 2008-02-07 at 21:40 +0100, Markus Becker wrote:
>>>> On Thu, 7 Feb 2008, Dan Williams wrote:
>>>>
>>>>> On Thu, 2008-02-07 at 21:19 +0100, Markus Becker wrote:
>>>>>> Feb 7 20:56:34 shelbyville pppd[10716]: Could not determine remote
>>>>>> IP
>>>>>> address: defaulting to 10.64.64.64
>>>>
>>>> Searching the web for this, reveals, that this seems to be very common
>>>> with UMTS dialup, but works nevertheless, if the DNS is correct, e.g.
>>>> something like 194.48.139.254. If I enter that manually into
>>>> /etc/resolv.conf, the connection works. But why is ppp not getting DNS
>>>> addresses?
>>>
>>> Any chance you could patch the nm-pppd-helper binary to write all the
>>> options it gets out to a file somewhere and then send that to the list?
>>
>> You mean nm-ppp-manager.c or the ppp executable? nm-ppp-manager already
>> outputs the command line:
>> Feb 7 21:38:35 shelbyville NetworkManager: [1202416715.931005]
>> nm_ppp_manager_start(): Command line: /usr/sbin/pppd nodetach lock ttyUSB0
>> noauth refuse-eap refuse-chap nodeflate usepeerdns plugin
>> /home/mab/install/lib/pppd/2.4.4/nm-pppd-plugin.so
>
> nm-pppd-plugin, basically print out the stuff that this function stuffs
> into the hash table:
>
> src/ppp-manager/nm-pppd-plugin.c::nm_ip_up()
>
> You're interested in opts.dnsaddr[0] and opts.dnsaddr[1], and possibly
> opts.dnsaddr[2] as well if that exists. Log those integers to a file,
> or if you want to get fancy, run them through inet_ntop() and get the
> real address string.
OK, done that and investigated further on the web. When you are not giving
the option "defaultroute" it will give you the following DNS entries:
nm-pppd-plugin: DNS1 10.11.12.13
nm-pppd-plugin: DNS2 10.11.12.14
When you are providing the option "defaultroute" (I patched
nm-ppp-manager.c), it will give you the correct DNS addresses:
nm-pppd-plugin: DNS1 139.7.30.125
nm-pppd-plugin: DNS2 139.7.30.126
With this option, it works perfectly for me. However, I think you do not
want ppp to modify the routes, but rather handle the routes from NM. Why
is ppp not returning the right DNS addresses, when it is not allowed to
modify the routes?
> Dan
>
>> If you mean ppp or something else, it would have to wait until tomorrow.
>>
>> Thanks,
>> Markus
>>
>>> That's what I had to do when debugging the P-t-P address thing, because
>>> pppd squelches any output the plugin might print. That would help us
>>> figure out if your remote side has the issue, or if it's a
>>> NetworkManager problem, and if so where in NetworkManager the problem
>>> lies.
>>>
>>> Dan
>>>
>>>>>
>>>>> That bit looks suspect... Never seen that message from pppd before, but
>>>>> it might have something to do with it. I had to modify the ppp helper
>>>>> code when adding CDMA support to grab the remote IP address and set that
>>>>> as the interface's P-t-P address, otherwise my Sprint cards wouldn't
>>>>> work. Previously to this, the interface's P-t-P address was getting set
>>>>> to the same address as the interface address.
>>>>>
>>>>> Ultimate fail:
>>>>>
>>>>> pppd/ipcp.c
>>>>>if (ho->hisaddr == 0) {
>>>>> ho->hisaddr = htonl(0x0a404040 + ifunit);
>>>>> warn("Could not determine remote IP address: defaulting to %I",
>>>>>ho->hisaddr);
>>>>>}
>>>>>
>>>>> WTF?
>>>>>
>>>>> Maybe NetworkManager should trap that magic and replace it with the
>>>>> interface address like use to happen before.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>
>
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM using Option card
On Thu, 7 Feb 2008, Dan Williams wrote:
> On Thu, 2008-02-07 at 21:40 +0100, Markus Becker wrote:
>> On Thu, 7 Feb 2008, Dan Williams wrote:
>>
>>> On Thu, 2008-02-07 at 21:19 +0100, Markus Becker wrote:
>>>> Feb 7 20:56:34 shelbyville pppd[10716]: Could not determine remote
>>>> IP
>>>> address: defaulting to 10.64.64.64
>>
>> Searching the web for this, reveals, that this seems to be very common
>> with UMTS dialup, but works nevertheless, if the DNS is correct, e.g.
>> something like 194.48.139.254. If I enter that manually into
>> /etc/resolv.conf, the connection works. But why is ppp not getting DNS
>> addresses?
>
> Any chance you could patch the nm-pppd-helper binary to write all the
> options it gets out to a file somewhere and then send that to the list?
You mean nm-ppp-manager.c or the ppp executable? nm-ppp-manager already
outputs the command line:
Feb 7 21:38:35 shelbyville NetworkManager: [1202416715.931005]
nm_ppp_manager_start(): Command line: /usr/sbin/pppd nodetach lock ttyUSB0
noauth refuse-eap refuse-chap nodeflate usepeerdns plugin
/home/mab/install/lib/pppd/2.4.4/nm-pppd-plugin.so
If you mean ppp or something else, it would have to wait until tomorrow.
Thanks,
Markus
> That's what I had to do when debugging the P-t-P address thing, because
> pppd squelches any output the plugin might print. That would help us
> figure out if your remote side has the issue, or if it's a
> NetworkManager problem, and if so where in NetworkManager the problem
> lies.
>
> Dan
>
>>>
>>> That bit looks suspect... Never seen that message from pppd before, but
>>> it might have something to do with it. I had to modify the ppp helper
>>> code when adding CDMA support to grab the remote IP address and set that
>>> as the interface's P-t-P address, otherwise my Sprint cards wouldn't
>>> work. Previously to this, the interface's P-t-P address was getting set
>>> to the same address as the interface address.
>>>
>>> Ultimate fail:
>>>
>>> pppd/ipcp.c
>>>if (ho->hisaddr == 0) {
>>> ho->hisaddr = htonl(0x0a404040 + ifunit);
>>> warn("Could not determine remote IP address: defaulting to %I",
>>> ho->hisaddr);
>>>}
>>>
>>> WTF?
>>>
>>> Maybe NetworkManager should trap that magic and replace it with the
>>> interface address like use to happen before.
>>>
>>> Dan
>>>
>>>
>
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM using Option card
On Thu, 7 Feb 2008, Dan Williams wrote:
> On Thu, 2008-02-07 at 20:38 +0100, Markus Becker wrote:
>> Hi,
>>
>> I was trying to get NM SVN working using an Option UMTS card. After
>> figuring out that additionally to the capability "modem" (mentioned
>> previously on the mailing list) also the capability "gsm" is needed, my
>> /usr/share/hal/fdi/information/20thirdparty/10-3g-modem.fdi looks like
>> this:
>
> What's the exact model of your card, BTW? I'm trying to put together a
> database of all the ones I come across.
That's the Vodafone Mobile Connect branded Option card. Not exactly sure,
which Option name it has, one of the older ones with GPRS/UMTS only.
>
> Thanks,
> Dan
>
>>
>>
>>
>>
>>
>>
>>
>>
>> modem
>> gsm
>>
>>
>>
>>
>>
>>
>>
>> However, I needed to modify nm-gsm-device to work with the Option card to
>> try the registration again also for the reply "+CREG: 0,0". After the
>> second or third "+CREG: 0,0" reply, it then replies with "+CREG: 0,2" as
>> expected. This patch works for me:
>>
>> Index: nm-gsm-device.c
>> ===
>> --- nm-gsm-device.c (revision 3294)
>> +++ nm-gsm-device.c (working copy)
>> @@ -233,6 +233,7 @@
>> automatic_registration_get_network (device);
>> break;
>> case 2:
>> +case 3:
>> gsm_device_set_pending (NM_GSM_DEVICE (device),
>> g_timeout_add (1000,
>> automatic_registration_again, device));
>> break;
>> @@ -251,7 +252,7 @@
>> automatic_registration (NMSerialDevice *device)
>> {
>> guint id;
>> -char *responses[] = { "+CREG: 0,1", "+CREG: 0,5", "+CREG: 0,2", NULL };
>> +char *responses[] = { "+CREG: 0,1", "+CREG: 0,5", "+CREG: 0,2", "+CREG:
>> 0,0", NULL };
>>
>> nm_serial_device_send_command_string (device, "AT+CREG?");
>> id = nm_serial_device_wait_for_reply (device, 60, responses,
>> automatic_registration_response, NULL);
>>
>> --
>>
>> I needed to tick "noauth" in gconf-editor, shouldn't this be the default
>> for dialup?
>>
>> Currently I am struggling with the routes and the IP configuration, setted
>> after dialing in. They do not seem reasonable to me and I cannot reach the
>> DNS server nor the peer (10.64.64.64).
>>
>> ppp0 Link encap:Point-to-Point Protocol
>>inet addr:90.187.199.128 P-t-P:10.64.64.64 Mask:255.255.255.255
>>
>> Kernel IP routing table
>> Destination Gateway Genmask Flags Metric RefUse Iface
>> 10.64.64.64 0.0.0.0 255.255.255.255 UH0 00 ppp0
>> 0.0.0.0 0.0.0.0 0.0.0.0 U 0 00 ppp0
>>
>> Has anyone a clue?
>>
>> Thanks for NetworkManager and the GSM/UMTS support.
>>
>> BR,
>> Markus
>>
>>
>> | Dipl.-Ing. Markus Becker
>> | Communication Networks
>> | Mobile Research Center
>> | TZI - Center for Computing Technologies
>> | University Bremen
>> | Germany
>>
>> | web: http://www.comnets.uni-bremen.de/~mab/
>> | mailto: [EMAIL PROTECTED]
>> | telephone: +49 421 218 2287
>> | building: NW1 room: N2260
>>
>> ___
>> 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: NM using Option card
On Thu, 7 Feb 2008, Dan Williams wrote:
> On Thu, 2008-02-07 at 21:19 +0100, Markus Becker wrote:
>> Feb 7 20:56:34 shelbyville pppd[10716]: Could not determine remote
>> IP
>> address: defaulting to 10.64.64.64
Searching the web for this, reveals, that this seems to be very common
with UMTS dialup, but works nevertheless, if the DNS is correct, e.g.
something like 194.48.139.254. If I enter that manually into
/etc/resolv.conf, the connection works. But why is ppp not getting DNS
addresses?
>
> That bit looks suspect... Never seen that message from pppd before, but
> it might have something to do with it. I had to modify the ppp helper
> code when adding CDMA support to grab the remote IP address and set that
> as the interface's P-t-P address, otherwise my Sprint cards wouldn't
> work. Previously to this, the interface's P-t-P address was getting set
> to the same address as the interface address.
>
> Ultimate fail:
>
> pppd/ipcp.c
>if (ho->hisaddr == 0) {
> ho->hisaddr = htonl(0x0a404040 + ifunit);
> warn("Could not determine remote IP address: defaulting to %I",
>ho->hisaddr);
>}
>
> WTF?
>
> Maybe NetworkManager should trap that magic and replace it with the
> interface address like use to happen before.
>
> Dan
>
>
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM using Option card
On Thu, 7 Feb 2008, Tambet Ingo wrote: > On Feb 7, 2008 1:38 PM, Markus Becker <[EMAIL PROTECTED]> wrote: > >> However, I needed to modify nm-gsm-device to work with the Option card to >> try the registration again also for the reply "+CREG: 0,0". After the >> second or third "+CREG: 0,0" reply, it then replies with "+CREG: 0,2" as >> expected. This patch works for me: > > This doesn't look quite right to me. CREG: 0,0 means 0,"not > registered, MT is not currently searching a new operator to register > to". Or, the device isn't trying to associate so there's no point in > waiting for successful attempt. The correct thing to do in case of > that response would be to make the card start registration. At the > same time, the registration code we have is very primitive and works > only on ideal case, so if the patch makes it work for you, I wouldn't > mind committing it. The only side effect (in case of some other cards) > would be that NM just waits there doing nothing before it finally > fails. I know that 0,0 says that the card is currently not scanning. But after a few seconds this changes for me(TM): Feb 7 20:55:46 shelbyville NetworkManager: [1202414146.183905] serial_debug(): Sending: 'AT+CPIN="1234" ' Feb 7 20:55:46 shelbyville NetworkManager: [1202414146.404885] serial_debug(): Got: ' OK ' Feb 7 20:55:46 shelbyville NetworkManager: [1202414146.405141] serial_debug(): Sending: 'AT+CREG? ' Feb 7 20:55:46 shelbyville NetworkManager: [1202414146.424868] serial_debug(): Got: ' +CREG: 0,0OK ' Feb 7 20:55:47 shelbyville NetworkManager: [1202414147.424280] serial_debug(): Sending: 'AT+CREG? ' Feb 7 20:55:47 shelbyville NetworkManager: [1202414147.444827] serial_debug(): Got: ' +CREG: 0,0OK ' Feb 7 20:55:48 shelbyville NetworkManager: [1202414148.444296] serial_debug(): Sending: 'AT+CREG? ' Feb 7 20:55:48 shelbyville NetworkManager: [1202414148.464781] serial_debug(): Got: ' +CREG: 0,0OK ' Feb 7 20:55:49 shelbyville NetworkManager: [1202414149.464297] serial_debug(): Sending: 'AT+CREG? ' Feb 7 20:55:49 shelbyville NetworkManager: [1202414149.484714] serial_debug(): Got: ' +CREG: 0,2OK ' Feb 7 20:55:50 shelbyville NetworkManager: [1202414150.484278] serial_debug(): Sending: 'AT+CREG? ' Feb 7 20:55:50 shelbyville NetworkManager: [1202414150.505641] serial_debug(): Got: ' +CREG: 0,2OK ' Feb 7 20:55:51 shelbyville NetworkManager: [1202414151.508265] serial_debug(): Sending: 'AT+CREG? ' Feb 7 20:55:51 shelbyville NetworkManager: [1202414151.533581] serial_debug(): Got: ' +CREG: 0,2OK ' Feb 7 20:55:52 shelbyville NetworkManager: [1202414152.536290] serial_debug(): Sending: 'AT+CREG? ' Feb 7 20:55:52 shelbyville NetworkManager: [1202414152.558516] serial_debug(): Got: ' +CREG: 0,2OK ' Feb 7 20:55:53 shelbyville NetworkManager: [1202414153.560265] serial_debug(): Sending: 'AT+CREG? ' Feb 7 20:55:53 shelbyville NetworkManager: [1202414153.582456] serial_debug(): Got: ' +CREG: 0,2OK ' Feb 7 20:55:54 shelbyville NetworkManager: [1202414154.585256] serial_debug(): Sending: 'AT+CREG? ' Feb 7 20:55:54 shelbyville NetworkManager: [1202414154.608355] serial_debug(): Got: ' +CREG: 0,2OK ' Feb 7 20:55:55 shelbyville NetworkManager: [1202414155.608304] serial_debug(): Sending: 'AT+CREG? ' Feb 7 20:55:55 shelbyville NetworkManager: [1202414155.847324] serial_debug(): Got: ' +CREG: 0,1OK ' Feb 7 20:55:55 shelbyville NetworkManager: Registered on Home network I cross checked with gcom / comgt from pharscape, it does it similarly to NM. After sending CPIN gcom also sends CREG and retries CREG until it gets either 0,1, 0,5 or timeout. > >> Currently I am struggling with the routes and the IP configuration, setted >> after dialing in. They do not seem reasonable to me and I cannot reach the >> DNS server nor the peer (10.64.64.64). > > Are you on some suse distribution? No. Debian. It might be that I do not get the correct DNS server from the peer: Feb 7 20:55:56 shelbyville pppd[10716]: Using interface ppp0 Feb 7 20:55:56 shelbyville pppd[10716]: Connect: ppp0 <--> /dev/ttyUSB0 Feb 7 20:55:56 shelbyville pppd[10716]: PAP authentication succeeded Feb 7 20:56:34 shelbyville pppd[10716]: Could not determine remote IP address: defaulting to 10.64.64.64 Feb 7 20:56:34 shelbyville pppd[10716]: Cannot determine ethernet address for proxy ARP Feb 7 20:56:34 shelbyville pppd[10716]: local IP address 90.186.19.42 Feb 7 20:56:34 shelbyville pppd[10716]: remote IP address 10.64.64.64 Feb 7 20:56:34 she
NM using Option card
Hi,
I was trying to get NM SVN working using an Option UMTS card. After
figuring out that additionally to the capability "modem" (mentioned
previously on the mailing list) also the capability "gsm" is needed, my
/usr/share/hal/fdi/information/20thirdparty/10-3g-modem.fdi looks like
this:
modem
gsm
However, I needed to modify nm-gsm-device to work with the Option card to
try the registration again also for the reply "+CREG: 0,0". After the
second or third "+CREG: 0,0" reply, it then replies with "+CREG: 0,2" as
expected. This patch works for me:
Index: nm-gsm-device.c
===
--- nm-gsm-device.c (revision 3294)
+++ nm-gsm-device.c (working copy)
@@ -233,6 +233,7 @@
automatic_registration_get_network (device);
break;
case 2:
+ case 3:
gsm_device_set_pending (NM_GSM_DEVICE (device),
g_timeout_add (1000,
automatic_registration_again, device));
break;
@@ -251,7 +252,7 @@
automatic_registration (NMSerialDevice *device)
{
guint id;
- char *responses[] = { "+CREG: 0,1", "+CREG: 0,5", "+CREG: 0,2", NULL };
+ char *responses[] = { "+CREG: 0,1", "+CREG: 0,5", "+CREG: 0,2", "+CREG:
0,0", NULL };
nm_serial_device_send_command_string (device, "AT+CREG?");
id = nm_serial_device_wait_for_reply (device, 60, responses,
automatic_registration_response, NULL);
--
I needed to tick "noauth" in gconf-editor, shouldn't this be the default
for dialup?
Currently I am struggling with the routes and the IP configuration, setted
after dialing in. They do not seem reasonable to me and I cannot reach the
DNS server nor the peer (10.64.64.64).
ppp0 Link encap:Point-to-Point Protocol
inet addr:90.187.199.128 P-t-P:10.64.64.64 Mask:255.255.255.255
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
10.64.64.64 0.0.0.0 255.255.255.255 UH0 00 ppp0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 00 ppp0
Has anyone a clue?
Thanks for NetworkManager and the GSM/UMTS support.
BR,
Markus
| Dipl.-Ing. Markus Becker
| Communication Networks
| Mobile Research Center
| TZI - Center for Computing Technologies
| University Bremen
| Germany
| web: http://www.comnets.uni-bremen.de/~mab/
| mailto: [EMAIL PROTECTED]
| telephone: +49 421 218 2287
| building: NW1 room: N2260
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Request for ergonomy feature
On Thu, 11 Oct 2007, Peter Clifton wrote: > > On Thu, 2007-10-11 at 11:45 -0400, Scott Rossillo wrote: >> I have a similar problem with sleeping my laptop at work and then >> going home to connect to my wireless network. I usually resort to >> opening a terminal and restarting the Network Manager service on the >> occasions that the applet refuses to scan for wireless networks in >> timely fashion. > > Rescan on wake from suspend or hibernate might be the way to solve this? Did you have a look in /etc/hibernate/common.conf? At least on Debian there is an option "EnableNMReconnect yes". BR, Markus Becker > > -- > Peter Clifton > > Electrical Engineering Division, > Engineering Department, > University of Cambridge, > 9, JJ Thomson Avenue, > Cambridge > CB3 0FA > > Tel: +44 (0)7729 980173 - (No signal in the lab!) > > ___ > 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: Finding existing PPP connection?
On Fri, 15 Dec 2006, Jason Greb wrote: > What about two different plugins for PPPD and WVDial? Just how many > dialers are there? I only know of the two, but I am sure there are some > others out there... Additionally there is comgt/gcom for GPRS and 3G cards: http://www.pharscape.org/content/view/46/70/ > But they probably don't run NM on those computers anyway. Why not? Best regards, Markus ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
