"John Doehead" writes:
> What is the proper format of a NAK to a MD5 CHAP request of the format: 03
> 05 C0 23 05?

It should contain the desired protocol.

> Sending back a configure NAK with 03 05 C0 23 05 seems to be failing on some
> service providers, but sending back just 03 05 C0 23 seems to succeed. I

Neither of those make any sense as a Configure-Nak. If you don't have
some other preferred authentication protocol, then you shouldn't be
sending Configure-Nak -- you should send Configure-Reject instead.

If you're trying to say "use PAP instead," then that should be 03 04
C0 23 -- see RFC 1334 section 2.1. PAP doesn't have any option data.

03 05 C0 23 05 doesn't make sense as PAP, since PAP doesn't take any
option data. Better-written implementations should accept it, but
some may not.

03 05 C0 23 is just impossible. That's a malformed option; the option
length doesn't match the Length value.

> have torn through the rfc's (1334, 1661 in particular) and if I have
> interpreted it correctly, it appears as thought the NAK should contain the
> same command received (including the data packets)? Is this not the case
> and if not, could someone point me to where I can read up on the details of
> proper NAK packet formats.

RFC 1661, section 5.3:

Each Configuration Option which is allowed only a single instance
MUST be modified to a value acceptable to the Configure-Nak
sender. The default value MAY be used, when this differs from the
requested value.
[...]
Reception of a valid Configure-Nak indicates that when a new
Configure-Request is sent, the Configuration Options MAY be
modified as specified in the Configure-Nak. When multiple

The options data for Configure-Nak should have what you want the peer
to send you in its next Configure-Request.

(I can recommend a book if you're interested ...)

--
James Carlson, IP Systems Group
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

Thanks very much! That helps... a couple more comments:

Sorry about the typo...03 05 C0 23 was supposed to read 03 04 C0 23 (my
question was due to my confusion thinking that the NAK'd request might have
to be an echo of the initial request and so I was wondering why 03 04 C0 23
was working as a NAK response).

This all makes sense now as you have clarified it perfectly - NAK with the
parameters that are acceptable.

....and yes, I would be very much interested in any book recommendations you
could make.

Once again, thank you.

"James Carlson" wrote in message
news:xoavoeoly66j.fsf@sun.com...
> "John Doehead" writes:
> > What is the proper format of a NAK to a MD5 CHAP request of the format:
03
> > 05 C0 23 05?
>
> It should contain the desired protocol.
>
> > Sending back a configure NAK with 03 05 C0 23 05 seems to be failing on
some
> > service providers, but sending back just 03 05 C0 23 seems to succeed.
I
>
> Neither of those make any sense as a Configure-Nak. If you don't have
> some other preferred authentication protocol, then you shouldn't be
> sending Configure-Nak -- you should send Configure-Reject instead.
>
> If you're trying to say "use PAP instead," then that should be 03 04
> C0 23 -- see RFC 1334 section 2.1. PAP doesn't have any option data.
>
> 03 05 C0 23 05 doesn't make sense as PAP, since PAP doesn't take any
> option data. Better-written implementations should accept it, but
> some may not.
>
> 03 05 C0 23 is just impossible. That's a malformed option; the option
> length doesn't match the Length value.
>
> > have torn through the rfc's (1334, 1661 in particular) and if I have
> > interpreted it correctly, it appears as thought the NAK should contain
the
> > same command received (including the data packets)? Is this not the
case
> > and if not, could someone point me to where I can read up on the details
of
> > proper NAK packet formats.
>
> RFC 1661, section 5.3:
>
> Each Configuration Option which is allowed only a single instance
> MUST be modified to a value acceptable to the Configure-Nak
> sender. The default value MAY be used, when this differs from the
> requested value.
> [...]
> Reception of a valid Configure-Nak indicates that when a new
> Configure-Request is sent, the Configuration Options MAY be
> modified as specified in the Configure-Nak. When multiple
>
> The options data for Configure-Nak should have what you want the peer
> to send you in its next Configure-Request.
>
> (I can recommend a book if you're interested ...)
>
> --
> James Carlson, IP Systems Group
> Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

"John Doehead" writes:
> Thanks very much! That helps... a couple more comments:
>
> Sorry about the typo...03 05 C0 23 was supposed to read 03 04 C0 23 (my
> question was due to my confusion thinking that the NAK'd request might have
> to be an echo of the initial request and so I was wondering why 03 04 C0 23
> was working as a NAK response).

No -- Configure-Ack and Configure-Reject must be echoed exactly as-is,
but Configure-Nak is different.

Well, almost. At least that was the original design intent. There
are some broken NCPs defined that require the Configure-Ack to differ
in some small ways, so it's not completely true.

> This all makes sense now as you have clarified it perfectly - NAK with the
> parameters that are acceptable.
>
> ...and yes, I would be very much interested in any book recommendations you
> could make.


http://www.amazon.com/exec/obidos/tg...books&n=507846


Although, honestly, I'd council anyone away from reinventing the
wheel. There's perfectly good source code available on the net for
PPP, it's under a fairly flexible BSD license, and it's quite mature.

--
James Carlson, IP Systems Group
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

You just had to offer up some more tantalizing information, didn't you?

> Although, honestly, I'd council anyone away from reinventing the
> wheel. There's perfectly good source code available on the net for
> PPP, it's under a fairly flexible BSD license, and it's quite mature.
How would I go about finding the above source? A quick scan on google turns
up references to the BSD compress utility but I have not yet found mention
of the source.

I too would rather work from a *mature* source base...in an effort to do so,
my PPP implementation was derived from a technote from my chipset
manufacturer...the problem is that it is only a very basic implementation
which does not scale well over various providers (i.e. I have had to code
magic-number support which wasn't there in the first place).

Cheers.

"James Carlson" wrote in message
news:xoavfz9xxyhs.fsf@sun.com...
> "John Doehead" writes:
> > Thanks very much! That helps... a couple more comments:
> >
> > Sorry about the typo...03 05 C0 23 was supposed to read 03 04 C0 23 (my
> > question was due to my confusion thinking that the NAK'd request might
have
> > to be an echo of the initial request and so I was wondering why 03 04 C0
23
> > was working as a NAK response).
>
> No -- Configure-Ack and Configure-Reject must be echoed exactly as-is,
> but Configure-Nak is different.
>
> Well, almost. At least that was the original design intent. There
> are some broken NCPs defined that require the Configure-Ack to differ
> in some small ways, so it's not completely true.
>
> > This all makes sense now as you have clarified it perfectly - NAK with
the
> > parameters that are acceptable.
> >
> > ...and yes, I would be very much interested in any book recommendations
you
> > could make.
>
>
>
http://www.amazon.com/exec/obidos/tg...084912502/sr=8
-2/ref=sr_8_xs_ap_i2_xgl14/103-0342719-0021420?v=glance&s=books&n=507846
>
>
> Although, honestly, I'd council anyone away from reinventing the
> wheel. There's perfectly good source code available on the net for
> PPP, it's under a fairly flexible BSD license, and it's quite mature.
>
> --
> James Carlson, IP Systems Group
> Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

"John Doehead" writes:


]...and yes, I would be very much interested in any book recommendations you
]could make.

He means the book written by James D Carlson .
PPP Design Implimentation and Debugging.
It is supposed to be very good.


]"James Carlson" wrote in message
]>
]> (I can recommend a book if you're interested ...)
]>
]> --
]> James Carlson, IP Systems Group
]> Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
]> MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

"John Doehead" writes:

]You just had to offer up some more tantalizing information, didn't you?

]> Although, honestly, I'd council anyone away from reinventing the
]> wheel. There's perfectly good source code available on the net for
]> PPP, it's under a fairly flexible BSD license, and it's quite mature.
]How would I go about finding the above source? A quick scan on google turns
]up references to the BSD compress utility but I have not yet found mention
]of the source.

]I too would rather work from a *mature* source base...in an effort to do so,
]my PPP implementation was derived from a technote from my chipset
]manufacturer...the problem is that it is only a very basic implementation
]which does not scale well over various providers (i.e. I have had to code
]magic-number support which wasn't there in the first place).


pppd
ftp.samba.org/pub/ppp

"John Doehead" writes:
> You just had to offer up some more tantalizing information, didn't you?

Couldn't help it, I suppose.

> > Although, honestly, I'd council anyone away from reinventing the
> > wheel. There's perfectly good source code available on the net for
> > PPP, it's under a fairly flexible BSD license, and it's quite mature.
> How would I go about finding the above source? A quick scan on google turns
> up references to the BSD compress utility but I have not yet found mention
> of the source.

Among the links here (which, yes, I have to update someday):

http://carlson-ne.home.comcast.net/ppp/reference.html

Are several links for PPP sources, including:

ftp://ftp.samba.org/pub/ppp/

(Home page for that is http://samba.org/ppp/)

> I too would rather work from a *mature* source base...in an effort to do so,
> my PPP implementation was derived from a technote from my chipset
> manufacturer...the problem is that it is only a very basic implementation
> which does not scale well over various providers (i.e. I have had to code
> magic-number support which wasn't there in the first place).

At least look over the open sources. You might find that tailoring it
down to fit your application may be easier than scaling up a toy
implementation.

--
James Carlson, IP Systems Group
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

Thanks very much...I will definitely give this a look.

Unfortunately, due to time constraints and the fact that I am close to
having this working now, I am hoping it will take less time for me to
resolve the current issue, than to tailor down the code sample.

As I mentioned, I have a PPP implementation which negotiates the connection
fine on 2 of 3 wireless carriers. The 3rd carrier is causing me some grief.
I have a serial port analyzer capture of a DUN session through Windows that
is successful in establishing a PPP session.
I also have a capture of my code (in an embedded unit) that is not
successful. (Both traces could be provided in an Excel format to show the
communications).

I will summarize the difference below:

DUN Connection:
Carrier: LCP config req
DUN client: ACKs req in 19 ms
DUN client: PAP config req 6 ms later
Carrier: ACKs PAP req 327 ms later
IP address resolution continues successfully

Embedded connection (my code):
1) Carrier: LCP config req
2) Embedded client: ACKs req in 32 ms
3) Embedded client: PAP config req 1330 ms later
Carrier: Repeats initial LCP config req above ACKs PAP req 327 ms later
Steps 1, 2, and 3 are continually repeated, with the carrier never ACK'ing
my PAP request.

I have tried reducing the delay in 3) to be approximately 350 ms to no avail
but don't really understand why the difference in behaviour.

One thing of note however is that the initial config request in the Embedded
connection in 1) has ID 255 and this ID stays the same through the repeated
1, 2, 3 sequence.

Any help would GREATLY be appreciated.
Cheers.




"James Carlson" wrote in message
news:xoavwu38vgn4.fsf@sun.com...
> "John Doehead" writes:
> > You just had to offer up some more tantalizing information, didn't you?
>
> Couldn't help it, I suppose.
>
> > > Although, honestly, I'd council anyone away from reinventing the
> > > wheel. There's perfectly good source code available on the net for
> > > PPP, it's under a fairly flexible BSD license, and it's quite mature.
> > How would I go about finding the above source? A quick scan on google
turns
> > up references to the BSD compress utility but I have not yet found
mention
> > of the source.
>
> Among the links here (which, yes, I have to update someday):
>
> http://carlson-ne.home.comcast.net/ppp/reference.html
>
> Are several links for PPP sources, including:
>
> ftp://ftp.samba.org/pub/ppp/
>
> (Home page for that is http://samba.org/ppp/)
>
> > I too would rather work from a *mature* source base...in an effort to do
so,
> > my PPP implementation was derived from a technote from my chipset
> > manufacturer...the problem is that it is only a very basic
implementation
> > which does not scale well over various providers (i.e. I have had to
code
> > magic-number support which wasn't there in the first place).
>
> At least look over the open sources. You might find that tailoring it
> down to fit your application may be easier than scaling up a toy
> implementation.
>
> --
> James Carlson, IP Systems Group
> Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

Sorry, typo in previous post
The line that reads:
Carrier: Repeats initial LCP comfit req above ACKs PAP req 327 ms later
Should read:
Carrier: Repeats initial LCP comfit req above

Damn cut & paste .

"John Doehead" wrote in message
news:F2Mqc.15$SQ2.3@edtnps89...
> Thanks very much...I will definitely give this a look.
>
> Unfortunately, due to time constraints and the fact that I am close to
> having this working now, I am hoping it will take less time for me to
> resolve the current issue, than to tailor down the code sample.
>
> As I mentioned, I have a PPP implementation which negotiates the
connection
> fine on 2 of 3 wireless carriers. The 3rd carrier is causing me some
grief.
> I have a serial port analyzer capture of a DUN session through Windows
that
> is successful in establishing a PPP session.
> I also have a capture of my code (in an embedded unit) that is not
> successful. (Both traces could be provided in an Excel format to show the
> communications).
>
> I will summarize the difference below:
>
> DUN Connection:
> Carrier: LCP config req
> DUN client: ACKs req in 19 ms
> DUN client: PAP config req 6 ms later
> Carrier: ACKs PAP req 327 ms later
> IP address resolution continues successfully
>
> Embedded connection (my code):
> 1) Carrier: LCP config req
> 2) Embedded client: ACKs req in 32 ms
> 3) Embedded client: PAP config req 1330 ms later
> Carrier: Repeats initial LCP config req above ACKs PAP req 327 ms later
> Steps 1, 2, and 3 are continually repeated, with the carrier never ACK'ing
> my PAP request.
>
> I have tried reducing the delay in 3) to be approximately 350 ms to no
avail
> but don't really understand why the difference in behaviour.
>
> One thing of note however is that the initial config request in the
Embedded
> connection in 1) has ID 255 and this ID stays the same through the
repeated
> 1, 2, 3 sequence.
>
> Any help would GREATLY be appreciated.
> Cheers.
>
>
>
>
> "James Carlson" wrote in message
> news:xoavwu38vgn4.fsf@sun.com...
> > "John Doehead" writes:
> > > You just had to offer up some more tantalizing information, didn't
you?
> >
> > Couldn't help it, I suppose.
> >
> > > > Although, honestly, I'd council anyone away from reinventing the
> > > > wheel. There's perfectly good source code available on the net for
> > > > PPP, it's under a fairly flexible BSD license, and it's quite
mature.
> > > How would I go about finding the above source? A quick scan on google
> turns
> > > up references to the BSD compress utility but I have not yet found
> mention
> > > of the source.
> >
> > Among the links here (which, yes, I have to update someday):
> >
> > http://carlson-ne.home.comcast.net/ppp/reference.html
> >
> > Are several links for PPP sources, including:
> >
> > ftp://ftp.samba.org/pub/ppp/
> >
> > (Home page for that is http://samba.org/ppp/)
> >
> > > I too would rather work from a *mature* source base...in an effort to
do
> so,
> > > my PPP implementation was derived from a technote from my chipset
> > > manufacturer...the problem is that it is only a very basic
> implementation
> > > which does not scale well over various providers (i.e. I have had to
> code
> > > magic-number support which wasn't there in the first place).
> >
> > At least look over the open sources. You might find that tailoring it
> > down to fit your application may be easier than scaling up a toy
> > implementation.
> >
> > --
> > James Carlson, IP Systems Group
> > Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
> > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677
>
>

"John Doehead" writes:
> Unfortunately, due to time constraints and the fact that I am close to
> having this working now, I am hoping it will take less time for me to
> resolve the current issue, than to tailor down the code sample.

Don't forget that you (or someone who knows where you live) may have
to maintain the results. ;-}

> DUN Connection:
> Carrier: LCP config req
> DUN client: ACKs req in 19 ms
> DUN client: PAP config req 6 ms later
> Carrier: ACKs PAP req 327 ms later
> IP address resolution continues successfully
>
> Embedded connection (my code):
> 1) Carrier: LCP config req
> 2) Embedded client: ACKs req in 32 ms
> 3) Embedded client: PAP config req 1330 ms later
> Carrier: Repeats initial LCP config req above ACKs PAP req 327 ms later
> Steps 1, 2, and 3 are continually repeated, with the carrier never ACK'ing
> my PAP request.

Please provide a regular debug log. It's hard to tell exactly what
you mean there. (I suppose I could decode 'excel' but text would be
much preferred.)

On what you've posted:

- I don't see LCP completing. You need to have LCP
Configure-Request and LCP Configure-Ack sent by both sides.
Does that happen?

- PAP doesn't have a Configure-Request message. Did you mean
Authenticate-Request?

Repeating often means that the peer is unable to hear you, and that's
often due to ACCM errors.

Other than that, without a debug log, it's hard to tell.

> I have tried reducing the delay in 3) to be approximately 350 ms to no avail
> but don't really understand why the difference in behaviour.

Timing should _not_ matter, unless the peer is bug-ridden.

> One thing of note however is that the initial config request in the Embedded
> connection in 1) has ID 255 and this ID stays the same through the repeated
> 1, 2, 3 sequence.

Eeek!

Don't do that. At least try using different ID numbers for different
(not-retransmitted) packets.

--
James Carlson, IP Systems Group
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

Comments embedded:

"James Carlson" wrote in message
news:xoavk6z8uzby.fsf@sun.com...
> "John Doehead" writes:
> > Unfortunately, due to time constraints and the fact that I am close to
> > having this working now, I am hoping it will take less time for me to
> > resolve the current issue, than to tailor down the code sample.
>
> Don't forget that you (or someone who knows where you live) may have
> to maintain the results. ;-}
Definitely...it is exactly that that has got me into this mess - starting
off from another's code base
>
> > DUN Connection:
> > Carrier: LCP config req
> > DUN client: ACKs req in 19 ms
> > DUN client: PAP config req 6 ms later
> > Carrier: ACKs PAP req 327 ms later
> > IP address resolution continues successfully
> >
> > Embedded connection (my code):
> > 1) Carrier: LCP config req
> > 2) Embedded client: ACKs req in 32 ms
> > 3) Embedded client: PAP config req 1330 ms later
> > Carrier: Repeats initial LCP config req above ACKs PAP req 327 ms later
> > Steps 1, 2, and 3 are continually repeated, with the carrier never
ACK'ing
> > my PAP request.
>
> Please provide a regular debug log. It's hard to tell exactly what
> you mean there. (I suppose I could decode 'excel' but text would be
> much preferred.)
Would you like one sent via email?
>
> On what you've posted:
>
> - I don't see LCP completing. You need to have LCP
> Configure-Request and LCP Configure-Ack sent by both sides.
> Does that happen?
Yes. Sorry, wasn't clear...2) was doing the LCP Configure-Ack
>
> - PAP doesn't have a Configure-Request message. Did you mean
> Authenticate-Request?
Yes. Code C023...Auth Request, but never get the Auth Req Ack, instead the
initial LCP config req is just repeated.
>
> Repeating often means that the peer is unable to hear you, and that's
> often due to ACCM errors.
Don't think this is the case since all other requests seem to get responses,
and it is always the auth-req that never seems to get the response.
>
> Other than that, without a debug log, it's hard to tell.
>
> > I have tried reducing the delay in 3) to be approximately 350 ms to no
avail
> > but don't really understand why the difference in behaviour.
>
> Timing should _not_ matter, unless the peer is bug-ridden.
>
> > One thing of note however is that the initial config request in the
Embedded
> > connection in 1) has ID 255 and this ID stays the same through the
repeated
> > 1, 2, 3 sequence.
>
> Eeek!
>
> Don't do that. At least try using different ID numbers for different
> (not-retransmitted) packets.
Oops yet again...that repeated ID is actually in the carriers request, not
our code. Although it may be bad *practice*, is this a sign of a potential
issue? Strangely, it doesn't hapeen when the carrier is talking to a DUN
connection.
>
> --
> James Carlson, IP Systems Group
> Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

"John Doehead" writes:
> > Please provide a regular debug log. It's hard to tell exactly what
> > you mean there. (I suppose I could decode 'excel' but text would be
> > much preferred.)
> Would you like one sent via email?

OK.

> > - PAP doesn't have a Configure-Request message. Did you mean
> > Authenticate-Request?
> Yes. Code C023...Auth Request, but never get the Auth Req Ack, instead the
> initial LCP config req is just repeated.

It sounds like the peer can't hear you -- and possibly didn't hear
your LCP Configure-Ack either.

> > Repeating often means that the peer is unable to hear you, and that's
> > often due to ACCM errors.
> Don't think this is the case since all other requests seem to get responses,
> and it is always the auth-req that never seems to get the response.

PAP is the first thing that runs right after LCP negotiates. Before
LCP negotiates, the ACCM is set to the default (FFFFFFFF). Once LCP
goes to Opened (after you send or receive that last Configure-Ack) it
switches to the negotiated value.

This means that if the next protocol right after LCP fails, you should
suspect ACCM first, and perhaps ACFC or PFC.

> > Don't do that. At least try using different ID numbers for different
> > (not-retransmitted) packets.
> Oops yet again...that repeated ID is actually in the carriers request, not
> our code. Although it may be bad *practice*, is this a sign of a potential
> issue? Strangely, it doesn't hapeen when the carrier is talking to a DUN
> connection.

If you're seeing a repeated ID from the peer, that usually means that
the peer is retransmitting. And he'll do that if he can't hear you.

(It could just be a bug on his part, though.)

--
James Carlson, IP Systems Group
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

What sort of errors would be occurring in ACCM and how can I verify this?

I will fire the debug log to this email.

Thanks for taking the time with this.


"James Carlson" wrote in message
news:xoavbrkkuxr1.fsf@sun.com...
> "John Doehead" writes:
> > > Please provide a regular debug log. It's hard to tell exactly what
> > > you mean there. (I suppose I could decode 'excel' but text would be
> > > much preferred.)
> > Would you like one sent via email?
>
> OK.
>
> > > - PAP doesn't have a Configure-Request message. Did you mean
> > > Authenticate-Request?
> > Yes. Code C023...Auth Request, but never get the Auth Req Ack, instead
the
> > initial LCP config req is just repeated.
>
> It sounds like the peer can't hear you -- and possibly didn't hear
> your LCP Configure-Ack either.
>
> > > Repeating often means that the peer is unable to hear you, and that's
> > > often due to ACCM errors.
> > Don't think this is the case since all other requests seem to get
responses,
> > and it is always the auth-req that never seems to get the response.
>
> PAP is the first thing that runs right after LCP negotiates. Before
> LCP negotiates, the ACCM is set to the default (FFFFFFFF). Once LCP
> goes to Opened (after you send or receive that last Configure-Ack) it
> switches to the negotiated value.
>
> This means that if the next protocol right after LCP fails, you should
> suspect ACCM first, and perhaps ACFC or PFC.
>
> > > Don't do that. At least try using different ID numbers for different
> > > (not-retransmitted) packets.
> > Oops yet again...that repeated ID is actually in the carriers request,
not
> > our code. Although it may be bad *practice*, is this a sign of a
potential
> > issue? Strangely, it doesn't hapeen when the carrier is talking to a
DUN
> > connection.
>
> If you're seeing a repeated ID from the peer, that usually means that
> the peer is retransmitting. And he'll do that if he can't hear you.
>
> (It could just be a bug on his part, though.)
>
> --
> James Carlson, IP Systems Group
> Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

"John Doehead" writes:
> What sort of errors would be occurring in ACCM and how can I verify this?

Any of the following:

- If the ACCM requested by the peer is 0x000a0000, then it's
fairly likely that the peer has one of the well-known
implementation bugs. Adapting from your side to also
request 0x000a0000 is the only good solution to the
problem, even though it's not required by the standards.

- If the data path between you and the peer is unable to
handle one or more characters in the range 00 through 1F
hex, and the corresponding bit is set to zero in the ACCM
(disabling escaping), then the link is misconfigured.

- If your implementation or the peer has misinterpreted how
the ACCM option works, then that'd lead to trouble. Sending
ACCM in LCP Configure-Request with some bits set to zero
means "you don't have to escape these particular characters
when you send them to me, but you still can if you want."
Sending LCP Configure-Ack with some bits set to zero means
"I might not escape some of these characters when I send
them to you, though I still may if I choose." And the
actual ACCM on the link must be kept at the default of
FFFFFFFF until LCP goes all the way to Opened state, though
you *may* have to deal with bug-ridden peers that fail to
manage the transition correctly.

> I will fire the debug log to this email.

OK.

--
James Carlson, IP Systems Group
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

Aight, that was a mouthful...I will verify that ACCM is being handled
correctly - still a bit of a PPP noob - before hassling you any more.

The debug file will have to wait as my analyzer does not export it to a
*friendly* format with timestamps so I will try to work some magic on this.

Thanks again.

"James Carlson" wrote in message
news:xoav3c5wurof.fsf@sun.com...
> "John Doehead" writes:
> > What sort of errors would be occurring in ACCM and how can I verify
this?
>
> Any of the following:
>
> - If the ACCM requested by the peer is 0x000a0000, then it's
> fairly likely that the peer has one of the well-known
> implementation bugs. Adapting from your side to also
> request 0x000a0000 is the only good solution to the
> problem, even though it's not required by the standards.
>
> - If the data path between you and the peer is unable to
> handle one or more characters in the range 00 through 1F
> hex, and the corresponding bit is set to zero in the ACCM
> (disabling escaping), then the link is misconfigured.
>
> - If your implementation or the peer has misinterpreted how
> the ACCM option works, then that'd lead to trouble. Sending
> ACCM in LCP Configure-Request with some bits set to zero
> means "you don't have to escape these particular characters
> when you send them to me, but you still can if you want."
> Sending LCP Configure-Ack with some bits set to zero means
> "I might not escape some of these characters when I send
> them to you, though I still may if I choose." And the
> actual ACCM on the link must be kept at the default of
> FFFFFFFF until LCP goes all the way to Opened state, though
> you *may* have to deal with bug-ridden peers that fail to
> manage the transition correctly.
>
> > I will fire the debug log to this email.
>
> OK.
>
> --
> James Carlson, IP Systems Group
> Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

Comments inline.
"James Carlson" wrote in message
news:xoav3c5wurof.fsf@sun.com...
> "John Doehead" writes:
> > What sort of errors would be occurring in ACCM and how can I verify
this?
>
> Any of the following:
>
> - If the ACCM requested by the peer is 0x000a0000, then it's
> fairly likely that the peer has one of the well-known
> implementation bugs. Adapting from your side to also
> request 0x000a0000 is the only good solution to the
> problem, even though it's not required by the standards.
Funny you should say that...the code base I worked from used that very
ACCM...it worked on the other two carriers, but not on this...this must
imply that the other two did not escape any characters? What should I look
for to determine if the code base we used had this 'implementation bug'?
>
> - If the data path between you and the peer is unable to
> handle one or more characters in the range 00 through 1F
> hex, and the corresponding bit is set to zero in the ACCM
> (disabling escaping), then the link is misconfigured.
We remap/escape any characters < 0x20, but the async map was set to
0x000A0000. I am a little confused since this seems to be the wrong map for
those characters. Also, this sequence concerns me due to your point above -
what exactly is the implementation bug result in? Does this not then imply
that the 2 previous carriers we had success with are not encoding any
characters?

>
> - If your implementation or the peer has misinterpreted how
> the ACCM option works, then that'd lead to trouble. Sending
> ACCM in LCP Configure-Request with some bits set to zero
> means "you don't have to escape these particular characters
> when you send them to me, but you still can if you want."
> Sending LCP Configure-Ack with some bits set to zero means
> "I might not escape some of these characters when I send
> them to you, though I still may if I choose." And the
> actual ACCM on the link must be kept at the default of
> FFFFFFFF until LCP goes all the way to Opened state, though
> you *may* have to deal with bug-ridden peers that fail to
> manage the transition correctly.
I have tried setting the ACCM to both 0xFFFFFFFF and 0x00000000 to no avail.

Cheers.
> --
> James Carlson, IP Systems Group
> Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

And somewhere around the time of 05/18/2004 15:06, the world stopped and
listened as John Doehead contributed the following to humanity:

> You just had to offer up some more tantalizing information, didn't you?
>
>
>>Although, honestly, I'd council anyone away from reinventing the
>>wheel. There's perfectly good source code available on the net for
>>PPP, it's under a fairly flexible BSD license, and it's quite mature.
>
> How would I go about finding the above source? A quick scan on google turns
> up references to the BSD compress utility but I have not yet found mention
> of the source.
>
> I too would rather work from a *mature* source base...in an effort to do so,
> my PPP implementation was derived from a technote from my chipset
> manufacturer...the problem is that it is only a very basic implementation
> which does not scale well over various providers (i.e. I have had to code
> magic-number support which wasn't there in the first place).
>
> Cheers.
>

http://www.freebsd.org/cgi/cvsweb.cg...=RELENG_4_9_BP

That's the base source code used in FreeBSD.
--
Daniel Rudy

Remove nospam, invalid, and 0123456789 to reply.

"John Doehead" writes:
> > - If the ACCM requested by the peer is 0x000a0000, then it's
> > fairly likely that the peer has one of the well-known
> > implementation bugs. Adapting from your side to also
> > request 0x000a0000 is the only good solution to the
> > problem, even though it's not required by the standards.
> Funny you should say that...the code base I worked from used that very
> ACCM...it worked on the other two carriers, but not on this...this must
> imply that the other two did not escape any characters? What should I look
> for to determine if the code base we used had this 'implementation bug'?

The bug (as best it's known) is that some implementations seem not to
understand that ACCM (like nearly all PPP options) is negotiated
independently in each direction.

For example, let's suppose we have this sequence:

Peer A Peer B
LCP Configure-Request ->
ACCM = 00011000
<- LCP Configure-Request
ACCM = 00000002
LCP Configure-Ack ->
ACCM = 00000002
<- LCP Configure-Ack
ACCM = 00011000

In this case, in accepting 00000002 from the other side, Peer A has
agreed to escape at least the value '01' hex (as 7D 21) when it sends
data to Peer B. It may -- at its option, and without notifying Peer B
-- decide to escape other characters.

Similarly, Peer B has agreed to escape '0C' and '10' hex when it
transmits data.

> > - If the data path between you and the peer is unable to
> > handle one or more characters in the range 00 through 1F
> > hex, and the corresponding bit is set to zero in the ACCM
> > (disabling escaping), then the link is misconfigured.
> We remap/escape any characters < 0x20, but the async map was set to
> 0x000A0000. I am a little confused since this seems to be the wrong map for
> those characters. Also, this sequence concerns me due to your point above -
> what exactly is the implementation bug result in? Does this not then imply
> that the 2 previous carriers we had success with are not encoding any
> characters?

That ACCM means that the peer wants you to escape at least 11 and 13
hex -- also known as ^Q and ^S, ASCII DC1 and DC3, or XON and XOFF.

The result is _sometimes_ fairly easy to see with a line analyzer --
one side starts sending values that the other side specifically said
need to be escaped. At other times, it can be difficult because the
problem is deeper in an implementation (one peer said it would accept
a particular value without escaping, and yet it actually doesn't).
Those cases need good debug tools.

If you are writing your own PPP and you don't have a line analyzer,
you're living on the hairy edge. I recommend looking into getting
one, such as SerialView from Klos. It'll save you a lot of time
looking at the wrong things.

> > them to you, though I still may if I choose." And the
> > actual ACCM on the link must be kept at the default of
> > FFFFFFFF until LCP goes all the way to Opened state, though
> > you *may* have to deal with bug-ridden peers that fail to
> > manage the transition correctly.
> I have tried setting the ACCM to both 0xFFFFFFFF and 0x00000000 to no avail.

Without seeing the data on the wire, it's tough to make a guess about
what might be going on.

--
James Carlson, IP Systems Group
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

Cool...thanks.

We are using the FTS analyzer and it has been a great help.

Re the ACCM, the ported code has the following logic:
Sending (pbyData is input array):
if (pbyData[uiCount] < 0x20 ||
pbyData[uiCount] == 0x7D ||
pbyData[uiCount] == 0x7E)
{
chTmp = 0x7D;
USART_Transmit(USART0, &chTmp, 1);//send out byte
chTmp = pbyData[uiCount] ^ 0x20;
USART_Transmit(USART0, &chTmp, 1);//send out byte
}
else
{
USART_Transmit(USART0, &pbyData[uiCount], 1);
}
Receiving:
if (ucByte == 0x7E)
{ // start or end of a packet
if (guiRxFramePtr && (uiRxChkSum==0xF0B8))
{
gpucFrame[guiRxFramePtr++] = ucByte; // insert character
in buffer
//uiPacket = gpucFrame[2]*256 + gpucFrame[3]; // if CRC
passes accept packet
pbyData = gpucFrame;
pbyData += PPPProtocolType;
*puiDataLen = (unsigned int)(gpucFrame[IPLengthOffset]) *
0x100 + (gpucFrame[IPLengthOffset+1]);
}
ucEscapedFlag &= 0x7E; // clear escape character flag
guiRxFramePtr = 0; // get ready for next packet
gpucFrame[guiRxFramePtr++] = ucByte; // insert character in
buffer
uiRxChkSum = 0xFFFF; // start new checksum
}
else if (ucByte == 0x7D)
{ // if tilde character set escape flag
ucEscapedFlag |= 1;
}
else
{
if ( ucEscapedFlag & 1 )
{ // if escape flag
ucByte ^= 0x20; // recover next character
ucEscapedFlag &= 0xFE; // clear Rx escape flag
}
if ( guiRxFramePtr == 1 && ucByte != 0xff )
{
gpucFrame[guiRxFramePtr++] = 0xff; // uncompress PPP header
}
if ( guiRxFramePtr == 2 && ucByte != 3)
{
gpucFrame[guiRxFramePtr++] = 3;
}
if ( guiRxFramePtr == 3 && ( ucByte & 1) )
{
gpucFrame[guiRxFramePtr++] = 0;
}
gpucFrame[guiRxFramePtr++] = ucByte; // insert character in
buffer
if (guiRxFramePtr > PPP_RX_FRAME_MAX)
{
guiRxFramePtr = PPP_RX_FRAME_MAX; // Inc pointer up to end
of buffer
}
uiRxChkSum = CalcChkSum(ucByte^uiRxChkSum) ^ (uiRxChkSum/256);
// calculate CRC checksum
}

Would this not be a safe implementation regardless of the negotiated ACCM?
We are escaping all characters on send/receive.
Further, the carrier is negotiating an ACCM of 0x00000000 all the way
through session negotiation which seems to violate using the default
0xFFFFFFFF that you mentioned, even though that seems to work through DUN
but not our code.

As mentioned before, I have tried both 0x00000000 and 0xFFFFFFFF ACCM
negotiations without success, but I did not change the processing logic
above thinking that the ACCM wouldn't really matter given the *safe?*
escaping we are doing.

I finally rendered a good debug dump to pdf...one for the DUN Success and
the other for the Micro Failure...I will fire them off to your @sun.com
email.

I really appreciate you taking the time to look over this.
Cheers.

"James Carlson" wrote in message
news:xoavlljn74mi.fsf@sun.com...
> "John Doehead" writes:
> > > - If the ACCM requested by the peer is 0x000a0000, then it's
> > > fairly likely that the peer has one of the well-known
> > > implementation bugs. Adapting from your side to also
> > > request 0x000a0000 is the only good solution to the
> > > problem, even though it's not required by the standards.
> > Funny you should say that...the code base I worked from used that very
> > ACCM...it worked on the other two carriers, but not on this...this must
> > imply that the other two did not escape any characters? What should I
look
> > for to determine if the code base we used had this 'implementation bug'?
>
> The bug (as best it's known) is that some implementations seem not to
> understand that ACCM (like nearly all PPP options) is negotiated
> independently in each direction.
>
> For example, let's suppose we have this sequence:
>
> Peer A Peer B
> LCP Configure-Request ->
> ACCM = 00011000
> <- LCP Configure-Request
> ACCM = 00000002
> LCP Configure-Ack ->
> ACCM = 00000002
> <- LCP Configure-Ack
> ACCM = 00011000
>
> In this case, in accepting 00000002 from the other side, Peer A has
> agreed to escape at least the value '01' hex (as 7D 21) when it sends
> data to Peer B. It may -- at its option, and without notifying Peer B
> -- decide to escape other characters.
>
> Similarly, Peer B has agreed to escape '0C' and '10' hex when it
> transmits data.
>
> > > - If the data path between you and the peer is unable to
> > > handle one or more characters in the range 00 through 1F
> > > hex, and the corresponding bit is set to zero in the ACCM
> > > (disabling escaping), then the link is misconfigured.
> > We remap/escape any characters < 0x20, but the async map was set to
> > 0x000A0000. I am a little confused since this seems to be the wrong map
for
> > those characters. Also, this sequence concerns me due to your point
above -
> > what exactly is the implementation bug result in? Does this not then
imply
> > that the 2 previous carriers we had success with are not encoding any
> > characters?
>
> That ACCM means that the peer wants you to escape at least 11 and 13
> hex -- also known as ^Q and ^S, ASCII DC1 and DC3, or XON and XOFF.
>
> The result is _sometimes_ fairly easy to see with a line analyzer --
> one side starts sending values that the other side specifically said
> need to be escaped. At other times, it can be difficult because the
> problem is deeper in an implementation (one peer said it would accept
> a particular value without escaping, and yet it actually doesn't).
> Those cases need good debug tools.
>
> If you are writing your own PPP and you don't have a line analyzer,
> you're living on the hairy edge. I recommend looking into getting
> one, such as SerialView from Klos. It'll save you a lot of time
> looking at the wrong things.
>
> > > them to you, though I still may if I choose." And the
> > > actual ACCM on the link must be kept at the default of
> > > FFFFFFFF until LCP goes all the way to Opened state, though
> > > you *may* have to deal with bug-ridden peers that fail to
> > > manage the transition correctly.
> > I have tried setting the ACCM to both 0xFFFFFFFF and 0x00000000 to no
avail.
>
> Without seeing the data on the wire, it's tough to make a guess about
> what might be going on.
>
> --
> James Carlson, IP Systems Group
> Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677