Hi,

when I try to connect to vodafone using the audiovox rtm 8000, I get myself stuck at the LCP negotiation; during the negotiation, no Rejection nor Nack responses appear, but negotiation doesn't go beyong the first step:



waiting for connect...

ATD*99***1#
CONNECT
Connected.
If the following ppp negotiations fail,
try restarting the phone.

Serial connection established.
using channel 62
Using interface ppp0
Connect: ppp0 <--> /dev/ttyS3
sent [LCP ConfReq id=0x1 <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x3c <auth pap> <pcomp> <accomp>]
sent [LCP ConfAck id=0x3c <auth pap> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x3c <auth pap> <pcomp> <accomp>]
sent [LCP ConfAck id=0x3c <auth pap> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x3c <auth pap> <pcomp> <accomp>]
sent [LCP ConfAck id=0x3c <auth pap> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x3c <auth pap> <pcomp> <accomp>]
sent [LCP ConfAck id=0x3c <auth pap> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x3c <auth pap> <pcomp> <accomp>]
sent [LCP ConfAck id=0x3c <auth pap> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x3c <auth pap> <pcomp> <accomp>]
sent [LCP ConfAck id=0x3c <auth pap> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x3c <auth pap> <pcomp> <accomp>]
sent [LCP ConfAck id=0x3c <auth pap> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x3c <auth pap> <pcomp> <accomp>]
sent [LCP ConfAck id=0x3c <auth pap> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x3c <auth pap> <pcomp> <accomp>]
sent [LCP ConfAck id=0x3c <auth pap> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <pcomp> <accomp>]
LCP: timeout sending Config-Requests
Connection terminated.


Any hints about proper settings in ppp files will be much appreciated.

It would help if you posted the contents of your config files. Mine are in /etc/ppp/peers/ and in /etc/ppp/options.ttyS3

I had similar problems with dialup connections timing out. You might make sure the following line in your peers file isn't the problem. I had chosen too big a connect-delay. What's now working much better on dialup for me is:

connect-delay 1000_

If that doesn't work, then make sure you post your files (without any private info) here so others with similar setups can compare theirs to yours.

Oh, another thing, if you give the exact address rather than auto-detect, that may help, if you have that option.

HTH,
sdjf

same problem here. I'm tyring to use an Audiovox RTM 8000 card on my HP hx4700 (arm based) running familiar linux 0.8.4, kernel is 2.6.15.
the card is correctly recognised, serial_cs is loaded, and the device maps to /dev/ttyS4, but I have to force the UART to 16550A and `cardctl reset`, or no program will be able to talk on the serial line. after that, I'm able to minicom out (also tried to call, and it works). but if I try to use ppp, it runs all right up to the LCP negotianion, where it gets stuck.

here is my pppd script is:



and my chat script:



(I already checked out with my service provider, and the values there are right.. I even could talk with an operator who really knew what I was talking about..)

with these configs, I get the following:



I read all the documentation I could find, and the most similar thing I found is the "Serial line is looped back" behaviour.. but it doesn't seem the case, as I never get that message. If I run through minicom the same AT commands that are in the chat script, I get:



thus it seems the connection is really initiated. last things to say:

• I tried the same card on a gentoo linux based laptop, with the same configuration and the same result
• I tried the card on a windows based laptop, and I could connect without any problems. I looked at the connect script output, and the AT commands Windows issues are almost the same I'm using
• I tried with a similar confiiguration with a SIM of another service provider, and it didn't work either
• I already tried lots of pppd options and AT commands, but none of them changed the behaviour, even the one suggested in the previous post
• the (almost) same scripts work pretty well using, instead of the audiovox card, a mobile phone connected via bluetooth. here is the output of running pppd in those cases (chat output was suppressed, as I added the echo option only for debug):
  
  
  QUOTE
  chat: Apr 16 11:08:28 CONNECT
  Serial connection established.
  using channel 5
  Using interface ppp0
  Connect: ppp0 <--> /dev/rfcomm0
  sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x8ff5dbbf> <pcomp> <accomp>]
  rcvd [LCP ConfRej id=0x1 <magic 0x8ff5dbbf> <pcomp> <accomp>]
  sent [LCP ConfReq id=0x2 <asyncmap 0x0>]
  rcvd [LCP ConfAck id=0x2 <asyncmap 0x0>]
  rcvd [LCP ConfReq id=0x0 <auth pap> <mru 1500> <asyncmap 0xa0000>]
  No auth is possible
  sent [LCP ConfRej id=0x0 <auth pap>]
  rcvd [LCP ConfReq id=0x1 <mru 1500> <asyncmap 0xa0000>]
  sent [LCP ConfAck id=0x1 <mru 1500> <asyncmap 0xa0000>]
  sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15>]
  sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
  rcvd [IPCP ConfReq id=0x0 <addr 10.6.6.6>]
  sent [IPCP ConfAck id=0x0 <addr 10.6.6.6>]
  rcvd [LCP ProtRej id=0x0 80 fd 01 01 00 0c 1a 04 78 00 18 04 78 00]
  rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
  sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
  rcvd [IPCP ConfNak id=0x2 <addr 91.80.113.29> <ms-dns1 83.224.65.134> <ms-dns3 83.224.66.134>]
  sent [IPCP ConfReq id=0x3 <addr 91.80.113.29> <ms-dns1 83.224.65.134> <ms-dns3 83.224.66.134>]
  rcvd [IPCP ConfAck id=0x3 <addr 91.80.113.29> <ms-dns1 83.224.65.134> <ms-dns3 83.224.66.134>]
  local IP address 91.80.113.29
  remote IP address 10.6.6.6
  primary DNS address 83.224.65.134
  secondary DNS address 83.224.66.134

any hint?

Oh, drat! My time to help with complex problem solving over the next month or two is limited, so can't study your output carefully.

Seems to me when I had that trouble with plain dialup, it was because of the delay being too many seconds I had in config file. Was too many 1000's to respond, and decreasing it solved the problem with mysterious endings you mentioned:

Modem hangup
Connection terminated.

Sorry can't be more help right now. If can, will study my files, but no guarantees.

sdjf

If you have files in the following directory named something like the following, then what worked for me on dialup on my sl5500 may work for you. Remember I'm on a Sharp ROM, and I don't know if the syntax or file location may be different for others.

/home/root/Applications/Network/modules/DialUp20.conf

This seems to be a Qtopia Desktop entry, telling the Z what to do.

One of the lines is the connect delay to allow before responding to my modem, and setting it too high was resulting in timeouts for my modem as Z wasn't responding fast enough. I changed the number from something high like the following:

connectdelay = 120000

to the following using vi:

connectdelay = 8000

I would NOT add the above to a file if it isn't already there...'cause if it ain't there, your software isn't set to recognize it. I would just tweak it if your file has a line that looks like the above.

If you use the built in GUI connection wizard, it will reset to original values, and I do not know what those are any more. I had thought a long connect delay was best, and that was totally wrong.

Again, I don't know if this will correlate with your Audiovox issue, but if the machines can't sync with each other smoothly, one of them will give up.

If you are using Qtopia to perform the connection, then this will be relevant. Otherwise, I don't know where or how that connect delay would be coded into the actual kernel files.

sdjf

EDIT: found it, in my /etc/ppp/peers/filename12346

the line reads:

connect-delay 8000

I don't see a line like that in yours...hmmm

at last, I found the solution. I was sure to already have tried this, but evidently I was wrong.. the trick is about the correct UART to set. I was forcing 16550A, while the correct value is 16750.

here is the link to the post (moreover on this same forum) that gave me the hint:
http://www.oesf.org/forum/index.php?showto...mp;#entry157957

thanks to everyone that tried to help!