Peer terminates PPP connection after establishing (successful?) aconnection - PPP

This is a discussion on Peer terminates PPP connection after establishing (successful?) aconnection - PPP ; Hi I'm trying to get a successful GPRS connection for a while now with no success. Once it works, another time it fails. I need some ideas where the error could be. I'm using pppd version 2.4.3 And heres the ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Peer terminates PPP connection after establishing (successful?) aconnection

  1. Peer terminates PPP connection after establishing (successful?) aconnection

    Hi

    I'm trying to get a successful GPRS connection for a while now
    with no success. Once it works, another time it fails. I need
    some ideas where the error could be.

    I'm using pppd version 2.4.3

    And heres the option (provider) file:
    debug
    connect '/usr/sbin/chat -v -f /etc/ppp/chat/provider'
    /dev/ttyUSB1 115200 lock crtscts ktune
    novj novjccomp nodeflate nobsdcomp
    persist holdoff 30
    noauth user gprs remotename gprs
    0.0.0.0:0.0.0.0 defaultroute

    The content of the pap-secret file:
    "gprs" * "" *

    After a 'pppd call provider', the following logs are generated
    (comments inline):

    12:19:03 pppd: Serial connection established.
    12:19:03 pppd: using channel 11
    12:19:03 pppd: Using interface ppp0
    12:19:03 pppd: Connect: ppp0 <--> /dev/ttyUSB1
    12:19:04 pppd: sent [LCP ConfReq id=0x1
    ]
    12:19:04 pppd: rcvd [LCP ConfRej id=0x1 ]
    12:19:04 pppd: sent [LCP ConfReq id=0x2 ]
    12:19:04 pppd: rcvd [LCP ConfAck id=0x2 ]
    12:19:05 pppd: rcvd [LCP ConfReq id=0x1
    ]
    12:19:05 pppd: sent [LCP ConfAck id=0x1
    ]
    12:19:05 pppd: sent [LCP EchoReq id=0x0 magic=0x0]
    12:19:05 pppd: sent [PAP AuthReq id=0x1 user="gprs" password=]
    12:19:05 pppd: rcvd [LCP EchoRep id=0x0 magic=0x0]
    12:19:05 pppd: rcvd [PAP AuthAck id=0x1 "Welcome!"]
    12:19:05 pppd: Remote message: Welcome!
    12:19:05 pppd: PAP authentication succeeded
    12:19:05 pppd: sent [IPCP ConfReq id=0x1 ]
    12:19:05 pppd: rcvd [IPCP ConfReq id=0x1 ]
    12:19:05 pppd: sent [IPCP ConfAck id=0x1 ]
    12:19:05 pppd: rcvd [IPCP ConfNak id=0x1 ]
    12:19:05 pppd: sent [IPCP ConfReq id=0x2 ]
    12:19:05 pppd: rcvd [IPCP ConfAck id=0x2 ]

    Until here, all seems to be fine...

    12:19:05 pppd: Cannot determine ethernet address for proxy ARP

    This should not matter, thats just a warning (and can easly be
    turned off with noproxyarp option).

    12:19:05 pppd: local IP address 192.168.111.112
    12:19:05 pppd: remote IP address 192.168.111.111
    12:19:05 pppd: Script /etc/ppp/ip-up started (pid 2849)

    As I understand, the connection is established after pppd prints
    local and remote IP address. This should be confirmed by the fact,
    that ip-up is executed. Even the default route is installed at
    this point and points to 192.168.111.112
    The connection should be up now and usable. But:

    12:19:05 pppd: Script /etc/ppp/ip-up finished (pid 2849), status = 0x0
    12:19:05 poll.tcpip: Starting mail and news send/fetch
    12:19:05 pppd: rcvd [LCP TermReq id=0x2]
    12:19:05 pppd: LCP terminated by peer

    The remote peer terminates the connection with no reason!?
    This is the point I've no idea what can be the cause.

    12:19:05 pppd: Connect time 0.1 minutes.
    12:19:05 pppd: Sent 0 bytes, received 0 bytes.
    12:19:05 pppd: Script /etc/ppp/ip-down started (pid 2863)
    12:19:05 pppd: sent [LCP TermAck id=0x2]
    12:19:05 pppd: Script /etc/ppp/ip-down finished (pid 2863), status = 0x0
    12:19:08 pppd: Connection terminated.

    After this pppd tries again with a completly other pattern in log
    file, but to keep this mail short I'll submit it only if it will
    help.

    Cheers,
    Andy

  2. Re: Peer terminates PPP connection after establishing (successful?) a connection

    Andreas Stricker writes:
    > And heres the option (provider) file:
    > debug
    > connect '/usr/sbin/chat -v -f /etc/ppp/chat/provider'
    > /dev/ttyUSB1 115200 lock crtscts ktune
    > novj novjccomp nodeflate nobsdcomp
    > persist holdoff 30
    > noauth user gprs remotename gprs
    > 0.0.0.0:0.0.0.0 defaultroute


    You shouldn't have to say "0.0.0.0:0.0.0.0". A better answer should
    be to use the "noipdefault" option.

    You shouldn't need "ktune," unless you're running a server or doing
    routing with this interface.

    Adding "novjccomp" with "novj" has no effect.

    Instead of "nodeflate nobsdcomp," I think you actually want "noccp."

    I'm not sure what the "persist holdoff 30" is for here. Does it work
    around a bug ... ?

    > The content of the pap-secret file:
    > "gprs" * "" *


    Don't you need to provide a password for this provider?

    > 12:19:05 pppd: sent [IPCP ConfReq id=0x1 ]
    > 12:19:05 pppd: rcvd [IPCP ConfReq id=0x1 ]


    Unless your provider really wants you to specify the addresses on the
    link, which would be quite strange, this doesn't look healthy at all.
    It looks like a side-effect of not using the "noipdefault" option.

    This *could* be the cause of the problem you're seeing ... but see
    below; GPRS is weird.

    > Until here, all seems to be fine...
    >
    > 12:19:05 pppd: Cannot determine ethernet address for proxy ARP


    That's fine. It just means that you have "proxyarp" specified
    somewhere in your configuration. You should not be using that option
    unless you're running a PPP dial-in server.

    > This should not matter, thats just a warning (and can easly be
    > turned off with noproxyarp option).


    Yes.

    > 12:19:05 pppd: local IP address 192.168.111.112
    > 12:19:05 pppd: remote IP address 192.168.111.111
    > 12:19:05 pppd: Script /etc/ppp/ip-up started (pid 2849)
    >
    > As I understand, the connection is established after pppd prints
    > local and remote IP address.


    That's right.

    > 12:19:05 pppd: Script /etc/ppp/ip-up finished (pid 2849), status = 0x0
    > 12:19:05 poll.tcpip: Starting mail and news send/fetch
    > 12:19:05 pppd: rcvd [LCP TermReq id=0x2]
    > 12:19:05 pppd: LCP terminated by peer
    >
    > The remote peer terminates the connection with no reason!?
    > This is the point I've no idea what can be the cause.


    Unfortunately, that sort of misbehavior is typical on GPRS, due to
    inherent design mistakes that GPRS has made. There is no complete fix
    other than to switch to something that works right.

    The design mistake that they made is that link authentication doesn't
    actually take place during the Authentication phase, as it's intended
    to. Instead, GPRS delays this process to the Network phase -- when
    IPCP negotiates addresses. This means that the access denial occurs
    when PPP really isn't expecting it, and it has two common (and ugly)
    side-effects:

    - The provider will accept your password but then refuse to provide
    an IP address, and IPCP falls apart. This is a symptom that the
    password (or user name) are actually wrong, and not that the peer
    doesn't have an address for you.

    - The provider seems to negotiate IPCP just fine, but then abruptly
    hangs up. This could also be an authentication (or "service
    registration") problem, or it could be that the apparently
    negotiated addresses are in fact _incorrect_.

    I think you're seeing the latter. Your GPRS provider doesn't have you
    as a registered user, is confused by your use of 192.168.* addresses,
    or is just plain broken.

    > After this pppd tries again with a completly other pattern in log
    > file, but to keep this mail short I'll submit it only if it will
    > help.


    If it works correctly sometimes but not at other times, then that's a
    symptom that the provider you're dialing into actually has a bank of
    dial-in servers. Some of them are configured properly, and others
    aren't.

    If so, and if a call to your provider doesn't clear up the problem,
    then it's time to find a new provider.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  3. Re: Peer terminates PPP connection after establishing (successful?)a connection

    Yo James

    I very appreciate your help. Your inputs were very profound.
    I was able to clean up the mess in my config file.

    But the real cause was a missing antenna (*hitting the head
    on keyboard*).

    James Carlson wrote:
    > You shouldn't have to say "0.0.0.0:0.0.0.0". A better answer should
    > be to use the "noipdefault" option.
    >
    > You shouldn't need "ktune," unless you're running a server or doing
    > routing with this interface.
    >
    > Adding "novjccomp" with "novj" has no effect.
    >
    > Instead of "nodeflate nobsdcomp," I think you actually want "noccp."


    This all works as suggested by you.

    > I'm not sure what the "persist holdoff 30" is for here. Does it work
    > around a bug ... ?


    No, once the idea was to keep the connection available with
    LCP-Echo (lcp-echo-interval and lcp-echo-failure). But I think
    I don't need them anymore.

    >>The content of the pap-secret file:
    >>"gprs" * "" *

    >
    > Don't you need to provide a password for this provider?


    No, the provider request an empty username and password.

    >
    >>12:19:05 pppd: sent [IPCP ConfReq id=0x1 ]
    >>12:19:05 pppd: rcvd [IPCP ConfReq id=0x1 ]

    >
    > Unless your provider really wants you to specify the addresses on the
    > link, which would be quite strange, this doesn't look healthy at all.
    > It looks like a side-effect of not using the "noipdefault" option.


    I've changed this to noipdefault, and it looks like this now:

    17:33:44 pppd: local IP address 10.142.8.15
    17:33:44 pppd: remote IP address 192.168.111.111

    >>
    >>The remote peer terminates the connection with no reason!?
    >>This is the point I've no idea what can be the cause.

    >
    > Unfortunately, that sort of misbehavior is typical on GPRS, due to
    > inherent design mistakes that GPRS has made. There is no complete fix
    > other than to switch to something that works right.
    >
    > The design mistake that they made is that link authentication doesn't
    > actually take place during the Authentication phase, as it's intended
    > to. Instead, GPRS delays this process to the Network phase -- when
    > IPCP negotiates addresses. This means that the access denial occurs
    > when PPP really isn't expecting it, and it has two common (and ugly)
    > side-effects:
    >
    > - The provider will accept your password but then refuse to provide
    > an IP address, and IPCP falls apart. This is a symptom that the
    > password (or user name) are actually wrong, and not that the peer
    > doesn't have an address for you.
    >
    > - The provider seems to negotiate IPCP just fine, but then abruptly
    > hangs up. This could also be an authentication (or "service
    > registration") problem, or it could be that the apparently
    > negotiated addresses are in fact _incorrect_.
    >
    > I think you're seeing the latter. Your GPRS provider doesn't have you
    > as a registered user, is confused by your use of 192.168.* addresses,
    > or is just plain broken.


    This information is very valuable. The only GSM net available was
    from another provider. This one seems to reject the PPP connection
    request, and as late as you mentioned.

    Thank you

    Cheers, Andy

  4. Re: Peer terminates PPP connection after establishing (successful?) a connection

    Andreas Stricker writes:

    >Hi


    >I'm trying to get a successful GPRS connection for a while now
    >with no success. Once it works, another time it fails. I need
    >some ideas where the error could be.


    GPRS ppp writers seem in general to be incompetent, so that any behaviour
    is not a surprise.


    >I'm using pppd version 2.4.3


    >And heres the option (provider) file:
    >debug
    >connect '/usr/sbin/chat -v -f /etc/ppp/chat/provider'
    >/dev/ttyUSB1 115200 lock crtscts ktune
    >novj novjccomp nodeflate nobsdcomp
    >persist holdoff 30
    >noauth user gprs remotename gprs
    >0.0.0.0:0.0.0.0 defaultroute


    >The content of the pap-secret file:
    >"gprs" * "" *


    Are you sure that they will accept a blank password?


    >After a 'pppd call provider', the following logs are generated
    >(comments inline):


    >12:19:03 pppd: Serial connection established.
    >12:19:03 pppd: using channel 11
    >12:19:03 pppd: Using interface ppp0
    >12:19:03 pppd: Connect: ppp0 <--> /dev/ttyUSB1
    >12:19:04 pppd: sent [LCP ConfReq id=0x1
    >]
    >12:19:04 pppd: rcvd [LCP ConfRej id=0x1 ]


    The first idiocy. Why the hell do they reject magic?

    >12:19:04 pppd: sent [LCP ConfReq id=0x2 ]
    >12:19:04 pppd: rcvd [LCP ConfAck id=0x2 ]
    >12:19:05 pppd: rcvd [LCP ConfReq id=0x1
    > ]
    >12:19:05 pppd: sent [LCP ConfAck id=0x1
    > ]
    >12:19:05 pppd: sent [LCP EchoReq id=0x0 magic=0x0]
    >12:19:05 pppd: sent [PAP AuthReq id=0x1 user="gprs" password=]
    >12:19:05 pppd: rcvd [LCP EchoRep id=0x0 magic=0x0]
    >12:19:05 pppd: rcvd [PAP AuthAck id=0x1 "Welcome!"]
    >12:19:05 pppd: Remote message: Welcome!
    >12:19:05 pppd: PAP authentication succeeded
    >12:19:05 pppd: sent [IPCP ConfReq id=0x1 ]


    Do not bother sending your IP address. (Use the noipdefault option)



    >12:19:05 pppd: rcvd [IPCP ConfReq id=0x1 ]
    >12:19:05 pppd: sent [IPCP ConfAck id=0x1 ]
    >12:19:05 pppd: rcvd [IPCP ConfNak id=0x1 ]
    >12:19:05 pppd: sent [IPCP ConfReq id=0x2 ]
    >12:19:05 pppd: rcvd [IPCP ConfAck id=0x2 ]


    >Until here, all seems to be fine...


    >12:19:05 pppd: Cannot determine ethernet address for proxy ARP


    Get rid of the proxyarp option. It is on no use to you.


    >This should not matter, thats just a warning (and can easly be
    >turned off with noproxyarp option).


    Turn it off.


    >12:19:05 pppd: local IP address 192.168.111.112
    >12:19:05 pppd: remote IP address 192.168.111.111
    >12:19:05 pppd: Script /etc/ppp/ip-up started (pid 2849)


    >As I understand, the connection is established after pppd prints
    >local and remote IP address. This should be confirmed by the fact,
    >that ip-up is executed. Even the default route is installed at
    >this point and points to 192.168.111.112
    >The connection should be up now and usable. But:


    >12:19:05 pppd: Script /etc/ppp/ip-up finished (pid 2849), status = 0x0
    >12:19:05 poll.tcpip: Starting mail and news send/fetch
    >12:19:05 pppd: rcvd [LCP TermReq id=0x2]
    >12:19:05 pppd: LCP terminated by peer


    >The remote peer terminates the connection with no reason!?
    >This is the point I've no idea what can be the cause.


    It is probably your password and username. Apparently a standard behaviour
    of GPRS is to accept anything as username and password, and then send them
    on to the real ISP. That ISP will reject and the GPRS terminate without
    explanation. I told you the authors were incompetent didn't I?



    >12:19:05 pppd: Connect time 0.1 minutes.
    >12:19:05 pppd: Sent 0 bytes, received 0 bytes.
    >12:19:05 pppd: Script /etc/ppp/ip-down started (pid 2863)
    >12:19:05 pppd: sent [LCP TermAck id=0x2]
    >12:19:05 pppd: Script /etc/ppp/ip-down finished (pid 2863), status = 0x0
    >12:19:08 pppd: Connection terminated.


    >After this pppd tries again with a completly other pattern in log
    >file, but to keep this mail short I'll submit it only if it will
    >help.


    >Cheers,
    >Andy


  5. Re: Peer terminates PPP connection after establishing (successful?) a connection

    Andreas Stricker writes:

    >Yo James


    >I very appreciate your help. Your inputs were very profound.
    >I was able to clean up the mess in my config file.


    >But the real cause was a missing antenna (*hitting the head
    >on keyboard*).


    ??????? and how could a missing antenna cause the problems?



    >James Carlson wrote:
    >> You shouldn't have to say "0.0.0.0:0.0.0.0". A better answer should
    >> be to use the "noipdefault" option.
    >>
    >> You shouldn't need "ktune," unless you're running a server or doing
    >> routing with this interface.
    >>
    >> Adding "novjccomp" with "novj" has no effect.
    >>
    >> Instead of "nodeflate nobsdcomp," I think you actually want "noccp."


    >This all works as suggested by you.


    >> I'm not sure what the "persist holdoff 30" is for here. Does it work
    >> around a bug ... ?


    >No, once the idea was to keep the connection available with
    >LCP-Echo (lcp-echo-interval and lcp-echo-failure). But I think
    >I don't need them anymore.


    >>>The content of the pap-secret file:
    >>>"gprs" * "" *

    >>
    >> Don't you need to provide a password for this provider?


    >No, the provider request an empty username and password.


    >>
    >>>12:19:05 pppd: sent [IPCP ConfReq id=0x1 ]
    >>>12:19:05 pppd: rcvd [IPCP ConfReq id=0x1 ]

    >>
    >> Unless your provider really wants you to specify the addresses on the
    >> link, which would be quite strange, this doesn't look healthy at all.
    >> It looks like a side-effect of not using the "noipdefault" option.


    >I've changed this to noipdefault, and it looks like this now:


    >17:33:44 pppd: local IP address 10.142.8.15
    >17:33:44 pppd: remote IP address 192.168.111.111


    >>>
    >>>The remote peer terminates the connection with no reason!?
    >>>This is the point I've no idea what can be the cause.

    >>
    >> Unfortunately, that sort of misbehavior is typical on GPRS, due to
    >> inherent design mistakes that GPRS has made. There is no complete fix
    >> other than to switch to something that works right.
    >>
    >> The design mistake that they made is that link authentication doesn't
    >> actually take place during the Authentication phase, as it's intended
    >> to. Instead, GPRS delays this process to the Network phase -- when
    >> IPCP negotiates addresses. This means that the access denial occurs
    >> when PPP really isn't expecting it, and it has two common (and ugly)
    >> side-effects:
    >>
    >> - The provider will accept your password but then refuse to provide
    >> an IP address, and IPCP falls apart. This is a symptom that the
    >> password (or user name) are actually wrong, and not that the peer
    >> doesn't have an address for you.
    >>
    >> - The provider seems to negotiate IPCP just fine, but then abruptly
    >> hangs up. This could also be an authentication (or "service
    >> registration") problem, or it could be that the apparently
    >> negotiated addresses are in fact _incorrect_.
    >>
    >> I think you're seeing the latter. Your GPRS provider doesn't have you
    >> as a registered user, is confused by your use of 192.168.* addresses,
    >> or is just plain broken.


    >This information is very valuable. The only GSM net available was
    >from another provider. This one seems to reject the PPP connection
    >request, and as late as you mentioned.


    >Thank you


    >Cheers, Andy


  6. Re: Peer terminates PPP connection after establishing (successful?)a connection

    Unruh wrote:
    > ??????? and how could a missing antenna cause the problems?


    There was still a strong transmitter from another provider,
    that worked without an antenna. But his network don't allow
    a PPP connection or is just buggy as you mentioned.

    Cheers, Andy

+ Reply to Thread