Establishing a 3G/UMTS/CDMA modem connection - Mandriva

This is a discussion on Establishing a 3G/UMTS/CDMA modem connection - Mandriva ; I had successfully used 3G/UMTS/CDMA connetion on my laptop on Madriva 2007 setting up /etc/ppp/peers/umts adn /etc/chatscripts/umts modprobe usbserial vendor=0xhhhh product=0xhhhh and pppd call umts I'm currently trying to set it up on Mandriva 2008.1 and: It's getting connected but ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Establishing a 3G/UMTS/CDMA modem connection

  1. Establishing a 3G/UMTS/CDMA modem connection

    I had successfully used 3G/UMTS/CDMA connetion on my laptop on Madriva
    2007 setting up
    /etc/ppp/peers/umts adn /etc/chatscripts/umts
    modprobe usbserial vendor=0xhhhh product=0xhhhh
    and
    pppd call umts

    I'm currently trying to set it up on Mandriva 2008.1 and: It's getting
    connected but connection doesn't really work. When I ping to google.com,
    I get "Unknown host".

    I've got same result trying it on fresh installation of CentOS 5.2...


    Daneel

  2. Re: Establishing a 3G/UMTS/CDMA modem connection

    On Mon, 25 Aug 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    , Daneel wrote:

    >I had successfully used 3G/UMTS/CDMA connetion on my laptop on Madriva
    >2007 setting up


    [...]

    >I'm currently trying to set it up on Mandriva 2008.1 and: It's getting
    >connected but connection doesn't really work.


    How do you know you are connected? What shows up in the output of
    '/sbin/ifconfig -a' and '/sbin/route -n' when you think you are
    connected? What is in /etc/resolv.conf ?

    >When I ping to google.com, I get "Unknown host".


    So name resolution isn't working - but is that because the file
    /etc/nsswitch.conf isn't correct, or /etc/resolv.conf, or because
    the routing table (/sbin/route -n) has no (or the incorrect) default
    route to the world? Or is it that the connection really isn't there
    (/sbin/ifconfig)? Can you ping the IP address 64.233.167.99,
    209.131.36.158, or 209.191.93.52 for example (use 'ping -c2 -n
    IP.ADD.RE.SS' - no need to be abusive)

    >I've got same result trying it on fresh installation of CentOS 5.2...


    Same questions. You might try a traceroute to some remote site (try
    '/usr/sbin/traceroute -n 195.59.44.134'). Do the packets go out the
    "right" interface? Do they go at least 3 or 4 hops (at least out to
    some host _beyond_ your ISP)?

    Old guy

  3. Re: Establishing a 3G/UMTS/CDMA modem connection

    Thank you for your answers and questions. My answers inserted:

    Messages when connecting:
    (...)
    Aug 26 08:38:18 pppd[3999]: Using interface ppp0
    Aug 26 08:38:18 pppd[3999]: Connect: ppp0 <--> /dev/ttyUSB3
    Aug 26 08:38:21 pppd[3999]: Could not determine remote IP address:
    defaulting to 10.64.64.64
    Aug 26 08:38:21 pppd[3999]: local IP address 10.172.244.90
    Aug 26 08:38:21 pppd[3999]: remote IP address 10.64.64.64
    Aug 26 08:38:21 pppd[3999]: primary DNS address 160.218.43.200
    Aug 26 08:38:21 pppd[3999]: secondary DNS address 160.218.10.200
    (...)

    Moe Trin wrote:
    > On Mon, 25 Aug 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    > , Daneel wrote:
    >
    >> I had successfully used 3G/UMTS/CDMA connetion on my laptop on Madriva
    >> 2007 setting up

    >
    > [...]
    >
    >> I'm currently trying to set it up on Mandriva 2008.1 and: It's getting
    >> connected but connection doesn't really work.

    >
    > How do you know you are connected? What shows up in the output of
    > '/sbin/ifconfig -a' and '/sbin/route -n' when you think you are
    > connected? What is in /etc/resolv.conf ?


    Connection LED starts flashing.

    [root@]# cat /etc/resolv.conf
    ; generated by /sbin/dhclient-script


    [root@ ~]# ifconfig -a
    eth0 Link encap:Ethernet HWaddr 00:08:74:18:73:E6
    inet addr:10.182.4.91 Bcast:10.182.4.255 Mask:255.255.255.0
    inet6 addr: fe80::208:74ff:fe18:73e6/64 Scope:Link
    UP BROADCAST MULTICAST MTU:1500 Metric:1
    RX packets:185640 errors:0 dropped:0 overruns:0 frame:0
    TX packets:104525 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:170923635 (163.0 MiB) TX bytes:10948908 (10.4 MiB)
    Base address:0xecc0 Memory:ff8e0000-ff900000

    lo Link encap:Local Loopback
    inet addr:127.0.0.1 Mask:255.0.0.0
    inet6 addr: ::1/128 Scope:Host
    UP LOOPBACK RUNNING MTU:16436 Metric:1
    RX packets:58430 errors:0 dropped:0 overruns:0 frame:0
    TX packets:58430 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:160170224 (152.7 MiB) TX bytes:160170224 (152.7 MiB)

    ppp0 Link encap:Point-to-Point Protocol
    inet addr:10.172.228.151 P-t-P:10.64.64.64 Mask:255.255.255.255
    UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
    RX packets:8 errors:1 dropped:0 overruns:0 frame:0
    TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:3
    RX bytes:128 (128.0 b) TX bytes:154 (154.0 b)

    sit0 Link encap:IPv6-in-IPv4
    NOARP MTU:1480 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)


    [root@ ~]# route -n
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use
    Iface
    10.64.64.64 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
    0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0


    >
    >> When I ping to google.com, I get "Unknown host".

    >
    > So name resolution isn't working - but is that because the file
    > /etc/nsswitch.conf isn't correct, or /etc/resolv.conf, or because
    > the routing table (/sbin/route -n) has no (or the incorrect) default
    > route to the world? Or is it that the connection really isn't there
    > (/sbin/ifconfig)? Can you ping the IP address 64.233.167.99,
    > 209.131.36.158, or 209.191.93.52 for example (use 'ping -c2 -n
    > IP.ADD.RE.SS' - no need to be abusive)


    [root@ ~]# cat /etc/nsswitch.conf
    #
    # /etc/nsswitch.conf
    #
    # An example Name Service Switch config file. This file should be
    # sorted with the most-used services at the beginning.
    #
    # The entry '[NOTFOUND=return]' means that the search for an
    # entry should stop if the search in the previous entry turned
    # up nothing. Note that if the search failed due to some other reason
    # (like no NIS server responding) then the search continues with the
    # next entry.
    #
    # Legal entries are:
    #
    # nisplus or nis+ Use NIS+ (NIS version 3)
    # nis or yp Use NIS (NIS version 2), also called YP
    # dns Use DNS (Domain Name Service)
    # files Use the local files
    # db Use the local database (.db) files
    # compat Use NIS on compat mode
    # hesiod Use Hesiod for user lookups
    # [NOTFOUND=return] Stop searching if not found so far
    #

    # To use db, put the "db" in front of "files" for entries you want to be
    # looked up first in the databases
    #
    # Example:
    #passwd: db files nisplus nis
    #shadow: db files nisplus nis
    #group: db files nisplus nis

    passwd: files
    shadow: files
    group: files

    #hosts: db files nisplus nis dns
    hosts: files dns

    # Example - obey only what nisplus tells us...
    #services: nisplus [NOTFOUND=return] files
    #networks: nisplus [NOTFOUND=return] files
    #protocols: nisplus [NOTFOUND=return] files
    #rpc: nisplus [NOTFOUND=return] files
    #ethers: nisplus [NOTFOUND=return] files
    #netmasks: nisplus [NOTFOUND=return] files

    bootparams: nisplus [NOTFOUND=return] files

    ethers: files
    netmasks: files
    networks: files
    protocols: files
    rpc: files
    services: files

    netgroup: nisplus

    publickey: nisplus

    automount: files nisplus
    aliases: files nisplus



    [root@ ~]# ping -c2 -n 64.233.167.99
    PING 64.233.167.99 (64.233.167.99) 56(84) bytes of data.
    From 10.182.4.91 icmp_seq=1 Destination Host Unreachable
    From 10.182.4.91 icmp_seq=2 Destination Host Unreachable

    --- 64.233.167.99 ping statistics ---
    2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1000ms
    , pipe 2


    >
    >> I've got same result trying it on fresh installation of CentOS 5.2...

    >
    > Same questions. You might try a traceroute to some remote site (try
    > '/usr/sbin/traceroute -n 195.59.44.134'). Do the packets go out the
    > "right" interface? Do they go at least 3 or 4 hops (at least out to
    > some host _beyond_ your ISP)?
    >
    > Old guy


    [root@ ~]# traceroute -n 195.59.44.134
    traceroute to 195.59.44.134 (195.59.44.134), 30 hops max, 40 byte packets
    1 10.182.4.91 3000.223 ms !H 3000.210 ms !H 3000.184 ms !H

  4. Re: Establishing a 3G/UMTS/CDMA modem connection

    On Tue, 26 Aug 2008 03:30:22 -0400, Daneel wrote:

    > Thank you for your answers and questions. My answers inserted:
    >
    > Messages when connecting:
    > (...)
    > Aug 26 08:38:18 pppd[3999]: Using interface ppp0
    > Aug 26 08:38:18 pppd[3999]: Connect: ppp0 <--> /dev/ttyUSB3
    > Aug 26 08:38:21 pppd[3999]: Could not determine remote IP address:
    > defaulting to 10.64.64.64


    The above indicates it is failing to connect. In /etc/ppp/options add lines with
    debug and dump, to get more info in the log.

    My first guess, would be that the wrong tty device is in use. What messages show
    in syslog, when you unplug/reconnect the usb device?

    Regards, Dave Hodgins

    --
    Change nomail.afraid.org to ody.ca to reply by email.
    (nomail.afraid.org has been set up specifically for
    use in usenet. Feel free to use it yourself.)

  5. Re: Establishing a 3G/UMTS/CDMA modem connection

    On Tue, 26 Aug 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    , Daneel wrote:

    >Messages when connecting:


    >Aug 26 08:38:21 pppd[3999]: Could not determine remote IP address:
    >defaulting to 10.64.64.64


    OK - buggy peer. The normal solution is to propose an RFC1918 address
    that is otherwise unused (such as 192.168.10.10 - pick what-ever you
    want) by adding the options ':192.168.10.10' and 'ipcp-accept-remote'
    to /etc/ppp/options (to hint to the peer that we're talking IP and
    his interface should have an IP address) - but this may not be that
    critical (unless you are specifically trying to talk to the peer
    itself, the peer's address isn't seen on the link).

    >Aug 26 08:38:21 pppd[3999]: primary DNS address 160.218.43.200
    >Aug 26 08:38:21 pppd[3999]: secondary DNS address 160.218.10.200


    Peer has supplied two DNS addresses.

    >> How do you know you are connected? What shows up in the output of
    >> '/sbin/ifconfig -a' and '/sbin/route -n' when you think you are
    >> connected? What is in /etc/resolv.conf ?

    >
    >Connection LED starts flashing.


    That doesn't provide much information (see below), but

    >[root@]# cat /etc/resolv.conf
    >; generated by /sbin/dhclient-script


    All righty! Your peer supplied two addresses, but they didn't make it
    into this file. The pppd daemon intentionally doesn't muck with this
    file, but you have two possible solutions:

    1. Manually insert the data

    nameserver 160.218.43.200
    nameserver 160.218.10.200

    I don't use DHCP to set up my systems, but your dhclient
    configuration may be assuming that the server is supplying
    nameserver data, and it doesn't appear to do so - perhaps setting
    'PEERDNS=no' in your /etc/sysconfig/network-scripts/ifcfg-eth0
    will stop the dhclient from overwriting this file.
    2. The pppd does put this into /etc/ppp/resolv.conf, and also sets the
    environmental variables DNS1 and DNS2. You can edit the file
    /etc/ppp/ip-up (though this file may want you to use ip-up.local
    or similar) and add the lines

    /bin/mv /etc/resolv.conf /etc/resolv.conf.dhcp_client
    /bin/cp /etc/ppp/resolv.conf /etc/resolv.conf
    /bin/chmod 644 /etc/resolv.conf

    which will move the existing file out of the way, and create one
    with the appropriate name server data. This action is reversed at
    the end of the dialin session by adding a line to the file
    /etc/ppp/ip-down (though this file may want you to use ip-down.local
    or similar)

    /bin/mv /etc/resolv.conf.dhcp_client /etc/resolv.conf

    >[root@ ~]# ifconfig -a
    >eth0 Link encap:Ethernet HWaddr 00:08:74:18:73:E6
    > inet addr:10.182.4.91 Bcast:10.182.4.255 Mask:255.255.255.0


    OK

    >lo Link encap:Local Loopback
    > inet addr:127.0.0.1 Mask:255.0.0.0


    OK

    >ppp0 Link encap:Point-to-Point Protocol
    > inet addr:10.172.228.151 P-t-P:10.64.64.64 Mask:255.255.255.255


    OK, but

    > RX packets:8 errors:1 dropped:0 overruns:0 frame:0
    > TX packets:8 errors:0 dropped:0 overruns:0 carrier:0


    Those are the cause of the blinking LED, but you had an unspecified
    error receiving a packet. I normally don't expect to see any errors.
    You may want to watch that.

    >[root@ ~]# route -n
    >Kernel IP routing table
    >Destination Gateway Genmask Flags Metric Ref Use Iface
    >10.64.64.64 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
    >0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0


    Two more problems here. First, your eth0 route isn't showing up. Second,
    the last route you show (0.0.0.0/0) is technically incorrect, because
    the entire world (which is what 0.0.0.0/0 means) isn't _directly_
    connected to your ppp0 interface. What is there is a gateway, meaning
    this line should look like

    0.0.0.0 10.64.64.64 0.0.0.0 UG 0 0 0 ppp0

    and this is controlled by the 'defaultroute' option in /etc/ppp/options.
    Make sure there is not some _other_ route to 'Destination' '0.0.0.0'
    (below), probably using the eth0 interface.

    >[root@ ~]# cat /etc/nsswitch.conf


    [...]

    >hosts: files dns


    OK - except lacking the 'nameserver' lines in /etc/resolv.conf, you don't
    know who to ask.

    >[root@ ~]# ping -c2 -n 64.233.167.99
    >PING 64.233.167.99 (64.233.167.99) 56(84) bytes of data.
    > From 10.182.4.91 icmp_seq=1 Destination Host Unreachable
    > From 10.182.4.91 icmp_seq=2 Destination Host Unreachable


    The routing table. The kernel has decided that the way to the world is
    out the eth0 interface. This is not correct.

    >[root@ ~]# traceroute -n 195.59.44.134
    >traceroute to 195.59.44.134 (195.59.44.134), 30 hops max, 40 byte packets
    > 1 10.182.4.91 3000.223 ms !H 3000.210 ms !H 3000.184 ms !H


    Again, it thinks the way to the world is out the eth0 interface. What is
    indicated here is that the kernel thinks there is a route that reads

    0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 eth0

    in the routing table, and it's trying to send the packet directly to
    that host which is _directly attached_ to the eth0 interface. That is
    certainly not the case, and this line should NOT appear in the output
    of the command '/sbin/route -n'. If the interface is being setup by
    DHCP, the server is misconfigured. But this could also be caused by a
    line in /etc/sysconfig/network-scripts/ifcfg-eth0 that reads

    GATEWAYDEV=eth0

    With the link _down_ your '/sbin/route -n' output should look like:

    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use Iface
    10.182.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
    127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo

    (which says there is a local LAN, and the loopback _only_). There may
    be an IPv6 route or two, but I'm ignoring them as not involved. With
    the link _up_ it should look like

    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use Iface
    10.64.64.64 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
    10.182.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
    127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
    0.0.0.0 10.64.64.64 0.0.0.0 UG 0 0 0 ppp0

    (which says point-to-point link to a peer, local LAN, loopback, and the
    world is reachable using the peer as gateway).

    You've got two problems.

    1. No name server data in /etc/resolv.conf
    2. Default route messed up

    Old guy

  6. Re: Establishing a 3G/UMTS/CDMA modem connection

    On Tue, 26 Aug 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    , David W. Hodgins wrote:

    >Daneel wrote:


    >> Messages when connecting:
    >> (...)
    >> Aug 26 08:38:18 pppd[3999]: Using interface ppp0
    >> Aug 26 08:38:18 pppd[3999]: Connect: ppp0 <--> /dev/ttyUSB3
    >> Aug 26 08:38:21 pppd[3999]: Could not determine remote IP address:
    >> defaulting to 10.64.64.64

    >
    >The above indicates it is failing to connect.


    Then how do you explain the next four lines that you trimmed?

    ]]Aug 26 08:38:21 pppd[3999]: local IP address 10.172.244.90
    ]]Aug 26 08:38:21 pppd[3999]: remote IP address 10.64.64.64
    ]]Aug 26 08:38:21 pppd[3999]: primary DNS address 160.218.43.200
    ]]Aug 26 08:38:21 pppd[3999]: secondary DNS address 160.218.10.200

    >In /etc/ppp/options add lines with debug and dump, to get more info
    >in the log.


    I'm not to sure it's needed. It's using 'usepeerdns' but (per the
    man page) the name server data isn't being written to /etc/resolv.conf

    >My first guess, would be that the wrong tty device is in use. What
    >messages show in syslog, when you unplug/reconnect the usb device?


    Like I say - where are those four lines coming from if not from the
    peer? Why is pppd not exiting (perhaps immediately, or at 08:38:21
    plus 30 seconds) with an EXIT CODE (see the man page) of 10, and a
    message here of "LCP: timeout sending Config-Requests" or similar?

    ppp networking is somewhat different from Ethernet. It's a point to
    point thing, and whether using the peer as a gateway (as normal) or
    simply assuming that the entire world is connected to the other end
    of the link, the packets going over the wire are identical. In
    Ethernet, the IP packet has ultimate source and destination IPs in the
    header, but the packet is delivered from/to the MAC address of you and
    the router in the Ethernet header (see RFC0894). If you look at
    RFC1662 section 3, there is only one address in the ppp packet, and
    it's _ALWAYS_ 0xff. So a packet sent _directly_ to 192.0.2.22 (pick
    some real IP on the Internet) looks absolutely identical to one sent
    to the peer to be forwarded to 192.0.2.22. The kernel on "this" box
    knows "the way to San Jose" is to use the ppp0 link, but the gateway's
    IP address never appears in that packet. It's ONLY used when you are
    trying to talk (via IP) specifically to the peer.

    There are two problems. /etc/resolv.conf isn't being updated, or
    set to begin with, so name service is screwed. Secondly, look at
    this:

    ]][root@ ~]# ifconfig -a
    ]]eth0 Link encap:Ethernet HWaddr 00:08:74:18:73:E6
    ]] inet addr:10.182.4.91 Bcast:10.182.4.255 Mask:255.255.255.0

    There is a LAN, but it isn't listed in the posted /sbin/route output.

    ]][root@ ~]# route -n
    ]]Kernel IP routing table
    ]]Destination Gateway Genmask Flags Metric Ref Use Iface
    ]]10.64.64.64 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
    ]]0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0

    and yet the ping and traceroute to some Internet host show

    ]][root@ ~]# ping -c2 -n 64.233.167.99
    ]]PING 64.233.167.99 (64.233.167.99) 56(84) bytes of data.
    ]] From 10.182.4.91 icmp_seq=1 Destination Host Unreachable
    ]] From 10.182.4.91 icmp_seq=2 Destination Host Unreachable

    and

    ]][root@ ~]# traceroute -n 195.59.44.134
    ]]traceroute to 195.59.44.134 (195.59.44.134), 30 hops max, 40 byte packets
    ]] 1 10.182.4.91 3000.223 ms !H 3000.210 ms !H 3000.184 ms !H

    the network stack is assuming that the world is _directly_ attached to
    the eth0 interface (otherwise it would be Network unreachable). This
    means the routing table is screwed up as well. In both cases, the eth0
    interface is reporting that it can't get the MAC address of the host
    that is supposed to be on this wire.

    Old guy

  7. Re: Establishing a 3G/UMTS/CDMA modem connection

    On Tue, 26 Aug 2008 20:41:24 -0400, Moe Trin wrote:

    > On Tue, 26 Aug 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    > , David W. Hodgins wrote:
    >
    >>Daneel wrote:

    >
    >>> Messages when connecting:
    >>> (...)
    >>> Aug 26 08:38:18 pppd[3999]: Using interface ppp0
    >>> Aug 26 08:38:18 pppd[3999]: Connect: ppp0 <--> /dev/ttyUSB3
    >>> Aug 26 08:38:21 pppd[3999]: Could not determine remote IP address:
    >>> defaulting to 10.64.64.64

    >>
    >>The above indicates it is failing to connect.

    >
    > Then how do you explain the next four lines that you trimmed?
    >
    > ]]Aug 26 08:38:21 pppd[3999]: local IP address 10.172.244.90
    > ]]Aug 26 08:38:21 pppd[3999]: remote IP address 10.64.64.64
    > ]]Aug 26 08:38:21 pppd[3999]: primary DNS address 160.218.43.200
    > ]]Aug 26 08:38:21 pppd[3999]: secondary DNS address 160.218.10.200


    A mistake on my part, from not reading far enough into the message. Thanks
    for the correction.

    Regards, Dave Hodgins

    --
    Change nomail.afraid.org to ody.ca to reply by email.
    (nomail.afraid.org has been set up specifically for
    use in usenet. Feel free to use it yourself.)

+ Reply to Thread