Re: PPP LCP configuration issue

2010-04-02 Thread Marcel Holtmann
Hi Kristen,

  so I added some debug code to actually print the options during the
  configuration stage. And something seems to be wrong here.
  
  lcp: pppcp_open_event: current state 0:INITIAL
  lcp: pppcp_up_event: current state 1:STARTING
  lcp: pppcp_initialize_restart_count: current state 1:STARTING
  lcp: pppcp_send_configure_request: current state 1:STARTING
  lcp: option 2 len 6 (Async-Control-Character-Map) 00 00 00 00
  lcp: pppcp_process_configure_request: current state 6:REQSENT
  lcp: option 2 len 6 (Async-Control-Character-Map) 00 00 00 00
  lcp: option 3 len 5 (Authentication-Protocol) c2 23 05
  lcp: option 5 len 6 (Magic-Number) 01 ff ef e0
  lcp: option 7 len 2 (Protocol-Field-Compression)
  lcp: option 8 len 2 (Address-and-Control-Field-Compression)
  lcp: pppcp_rcr_plus_event: current state 6:REQSENT
  lcp: pppcp_send_configure_ack: current state 6:REQSENT
  lcp: option 2 len 6 (Async-Control-Character-Map) 00 00 00 00
  lcp: option 3 len 5 (Authentication-Protocol) c2 23 05
  lcp: option 5 len 6 (Magic-Number) 01 ff ef e0
  lcp: option 7 len 2 (Protocol-Field-Compression)
  lcp: option 8 len 2 (Address-and-Control-Field-Compression)
  lcp: pppcp_process_configure_ack: current state 8:ACKSENT
  lcp: option 2 len 6 (Async-Control-Character-Map) 00 00 00 00
  oops -- found acked option 2 we didn't request
  lcp: pppcp_rca_event: current state 8:ACKSENT
  lcp: pppcp_initialize_restart_count: current state 8:ACKSENT
  
  I see the oops comment here, but we clearly requested the async control
  character map. So why does it get recognized as not requested? This is
  clearly a bug and needs to be fixed.
 
 what is happening is that we are first send a Config-Request with 
 the accm option as our only option.  We then receive a Config-Request
 from the modem, with accm along with several other options requested.
 We ack the modem's Config-Request and apply the options, and then delete
 them from the list of options that we need to have.  Then the modem
 response to our original Config-Request with an ack to our accm option.
 Because we already applied this option and removed it from the list of
 things we care about, it shows up as an option we didn't request.
 I think I could just delete the error message, and silently ignore 
 this condition. 

are these options really negotiated for both sides in common. Or is the
negotiation process for each side individual?

Personally I like to keep such error messages. We need to cope with
these cases nicely.

Regards

Marcel


___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono


PPP LCP configuration issue

2010-04-01 Thread Marcel Holtmann
Hi Kristen,

so I added some debug code to actually print the options during the
configuration stage. And something seems to be wrong here.

lcp: pppcp_open_event: current state 0:INITIAL
lcp: pppcp_up_event: current state 1:STARTING
lcp: pppcp_initialize_restart_count: current state 1:STARTING
lcp: pppcp_send_configure_request: current state 1:STARTING
lcp: option 2 len 6 (Async-Control-Character-Map) 00 00 00 00
lcp: pppcp_process_configure_request: current state 6:REQSENT
lcp: option 2 len 6 (Async-Control-Character-Map) 00 00 00 00
lcp: option 3 len 5 (Authentication-Protocol) c2 23 05
lcp: option 5 len 6 (Magic-Number) 01 ff ef e0
lcp: option 7 len 2 (Protocol-Field-Compression)
lcp: option 8 len 2 (Address-and-Control-Field-Compression)
lcp: pppcp_rcr_plus_event: current state 6:REQSENT
lcp: pppcp_send_configure_ack: current state 6:REQSENT
lcp: option 2 len 6 (Async-Control-Character-Map) 00 00 00 00
lcp: option 3 len 5 (Authentication-Protocol) c2 23 05
lcp: option 5 len 6 (Magic-Number) 01 ff ef e0
lcp: option 7 len 2 (Protocol-Field-Compression)
lcp: option 8 len 2 (Address-and-Control-Field-Compression)
lcp: pppcp_process_configure_ack: current state 8:ACKSENT
lcp: option 2 len 6 (Async-Control-Character-Map) 00 00 00 00
oops -- found acked option 2 we didn't request
lcp: pppcp_rca_event: current state 8:ACKSENT
lcp: pppcp_initialize_restart_count: current state 8:ACKSENT

I see the oops comment here, but we clearly requested the async control
character map. So why does it get recognized as not requested? This is
clearly a bug and needs to be fixed.

Regards

Marcel


___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono


Re: PPP LCP configuration issue

2010-04-01 Thread Marcel Holtmann
Hi Kristen,

 so I added some debug code to actually print the options during the
 configuration stage. And something seems to be wrong here.
 
 lcp: pppcp_open_event: current state 0:INITIAL
 lcp: pppcp_up_event: current state 1:STARTING
 lcp: pppcp_initialize_restart_count: current state 1:STARTING
 lcp: pppcp_send_configure_request: current state 1:STARTING
 lcp: option 2 len 6 (Async-Control-Character-Map) 00 00 00 00
 lcp: pppcp_process_configure_request: current state 6:REQSENT
 lcp: option 2 len 6 (Async-Control-Character-Map) 00 00 00 00
 lcp: option 3 len 5 (Authentication-Protocol) c2 23 05
 lcp: option 5 len 6 (Magic-Number) 01 ff ef e0
 lcp: option 7 len 2 (Protocol-Field-Compression)
 lcp: option 8 len 2 (Address-and-Control-Field-Compression)
 lcp: pppcp_rcr_plus_event: current state 6:REQSENT
 lcp: pppcp_send_configure_ack: current state 6:REQSENT
 lcp: option 2 len 6 (Async-Control-Character-Map) 00 00 00 00
 lcp: option 3 len 5 (Authentication-Protocol) c2 23 05
 lcp: option 5 len 6 (Magic-Number) 01 ff ef e0
 lcp: option 7 len 2 (Protocol-Field-Compression)
 lcp: option 8 len 2 (Address-and-Control-Field-Compression)
 lcp: pppcp_process_configure_ack: current state 8:ACKSENT
 lcp: option 2 len 6 (Async-Control-Character-Map) 00 00 00 00
 oops -- found acked option 2 we didn't request
 lcp: pppcp_rca_event: current state 8:ACKSENT
 lcp: pppcp_initialize_restart_count: current state 8:ACKSENT
 
 I see the oops comment here, but we clearly requested the async control
 character map. So why does it get recognized as not requested? This is
 clearly a bug and needs to be fixed.

so I added pppdump support to GAtPPP and gsmdial. This allows us to
create log files that can be read by pppdump and Wireshark. The method
of debugging with strace is just not feasible. The attached log file is
one of these. I see a couple of confirmation requests that were send
twice in a row. That seems to be wrong. Can you explain what is going
on.

Regards

Marcel

Kµû~ÿ}#À!}!}!} }*}}} } } } X{~KµûU~ÿ}#À!}!} } }9}}} } } } }#}%Â#}%}%}}!œ}]+}'}}(}˜Ú~~ÿ}#À!}}!} }*}}} } } } 1}/~Kµû8~ÿ}#À!}} } }9}}} } } } }#}%Â#}%}%}}!œ}]+}'}}(}}5Ö~Kµû~ÿ€!
(~KµûD~ÿ}#À!}+}!} }(}!œ}]+}-}5~~ÿÂ##Ú!Tdv®F µÞäEZEUMTS_CHAP_SRVR[¦~Kµû~ÿÂ#5Ü=ï‰W…×GÉ/꽃®äò~Kµû~ÿÂ#y’~Kµü$~ÿ€!

ƒ
‚

„
åº~Kµü*~ÿ€!

ƒ
‚

„
üB~Kµý$~ÿ€!

ƒ
‚

„
=L~Kµý*~ÿ€!

ƒ
‚

„
Ÿ~Kµþ$~ÿ€!

ƒ
‚

„
u~Kµþ*~ÿ€!

ƒ
‚

„
§Ë~Kµþ*~ÿ€!

ƒ
‚

„
§Ë~Kµÿ$~ÿ€!

ƒ
‚

„
œ©~Kµÿ*~ÿ€!

ƒ
‚

„
ċ~Kµ$~ÿ€!

ƒ
‚

„
Ôû~Kµ*~ÿ€!

ƒ
‚

„
aK~Kµ*~ÿ€!

ƒ
‚

„
aK~Kµ$~ÿ€!

ƒ
‚

„

~Kµ*~ÿ€!

ƒ
‚

„
~Kµ$~ÿ€!

ƒ
‚

„
D_~Kµ*~ÿ€!

ƒ
‚

„
Ñ~Kµ*~ÿ€!

ƒ
‚

„
Ñ~Kµ$~ÿ€!

ƒ
‚

„
Ïj~Kµ*~ÿ€!	

ƒ
‚

„
c‘~Kµ$~ÿ€!	

ƒ
‚

„
‡8~Kµ*~ÿ€!


ƒ
‚

„
ÆQ~Kµ*~ÿ€!


ƒ
‚

„
ÆQ~Kµ$~ÿ€!


ƒ
‚

„
_Î~Kµ*~ÿ€!

ƒ
‚

„
¥~Kµ	$~ÿ€!

ƒ
‚

„
œ~Kµ	*~ÿ€!

ƒ
‚

„
Ø~Kµ
*~ÿ€!

ƒ
‚

„
Ø~Kµ$~ÿ€!

ƒ
‚

„
þ+~Kµ*~ÿ€!


ƒ
‚

„
þ˜~Kµ$~ÿ€!


ƒ
‚

„
¶y~Kµ*~ÿ€!

ƒ
‚

„
[X~Kµ
*~ÿ€!

ƒ
‚

„
[X~Kµ$~ÿ€!

ƒ
‚

„
n~Kµ*~ÿ€!

ƒ
‚

„
8~Kµ$~ÿ€!

ƒ
‚

„
Ý~Kµ*~ÿ€!

ƒ
‚

„
Nä~Kµ*~ÿ€!

ƒ
‚

„
Nä~Kµ$~ÿ€!

ƒ
‚

„
xä~Kµ*~ÿ€!

ƒ
‚

„
-¤~Kµ$~ÿ€!

ƒ
‚

„
0¶~Kµ*~ÿ€!

ƒ
‚

„
ˆd~Kµ*~ÿ€!

ƒ
‚

„
ˆd~Kµ$~ÿ€!

ƒ
‚

„
...@~kµ*~ÿ€!

ƒ
‚

„
ë$~Kµ$~ÿ€!

ƒ
‚

„
 ~Kµ*~ÿ€!

ƒ
‚

„
Óí~Kµ*~ÿ€!

ƒ
‚

„
Óí~Kµ$~ÿ€!

ƒ
‚

„
I¥~Kµ*~ÿ€!

ƒ
‚

„
°­~Kµ$~ÿ€!

ƒ
‚

„
÷~Kµ*~ÿ€!

ƒ
‚

„
m~Kµ*~ÿ€!

ƒ
‚

„
m~Kµ$~ÿ€!

ƒ
‚

„
Ù~Kµ*~ÿ€!

ƒ
‚

„
v-~Kµ$~ÿ€!

ƒ
‚

„
‘S~Kµ*~ÿ€!

ƒ
‚

„
t÷~Kµ*~ÿ€!

ƒ
‚