Re: [lwip-users] PPP: request ID is not increasing?

[David Empson]

Presumably this is in fsm.c. The f->id field is set to zero in fsm_init(), 
which has a comment saying "XXX Start with random id?", but that is 
incidental.

fsm_init() is used for both LCP and IPCP, and is called by lcp_init() or 
ipcp_init() respectively (on different fsm data structures for each 
protocol). Based on that, it appears that every new PPP connection will 
start with reqid = 1 in the first LCP or IPCP request, and it will be 
incremented in each subsequent request.

If something was calling lcp_init() or ipcp_init() during a connection, that 
would cause f->id to be reset to zero and reqid to start at 1 again on the 
next outgoing request. These functions are normally called via a pointer in 
the protent structure and I haven't tracked down where that happens, but it 
is unlikely these functions are being called, because they would reset the 
entire protocol state, not just f->id. The same would happen (to a somewhat 
lesser degree) if something called fsm_init() during a connection.

That leaves two possible explanations:

(a) Something is writing a zero into f->id on a frequent enough basis during 
your PPP connection that every time it is referenced by an "f->reqid = 
++f->id" statement, f->id is zero again.

There is no code apart from the init function which writes zero into f->id, 
so this would have to be a memory overwriting bug of some kind. Do you have 
hardware debugging tools which would allow detection of zero writes to a 
specific memory location?

(b) Something is causing the "f->reqid = ++f->id" statement to misbehave on 
your platform, resulting in the value 1 being written into f->reqid, but 
f->id remaining zero.

What value do you see in the f->id field immediately after one of these 
statements?

This might be a bug in your compiler, or something unusual about the memory 
location which f->id happens to be occupying. Since f->id and f->reqid are 
adjacent byte-sized fields, a compiler optimization bug seems the most 
likely explanation. It may be trying to do a 16 bit write but getting the 
value wrong in the byte going to the first memory location.

If you are seeing f->id is zero immediately after one of these statements, 
try disabling your compiler's optimization, or split the statement into two 
separate ones and see if that makes any difference.

e.g.

++f->id;
f->reqid = f->id;

----- Original Message ----- 
From: "narke" <address@hidden>
To: "Mailing list for lwIP users" <address@hidden>; "lwip-devel" 
<address@hidden>
Sent: Tuesday, August 30, 2011 3:23 PM
Subject: Re: [lwip-users] PPP: request ID is not increasing?


On 30 August 2011 11:14, narke <address@hidden> wrote:
> Hi,
>
> I see all the outgoing request ID are keep 0x01 and never increase.
> In the code, I can see something something like:
>
> f->reqid = ++f->id
>
> but the f->id itself does not get changed.
>
> It's intended so? It's seems it's required to increase the request id
> according to RFC 1661. This also can be confirmed with pppd behavior.
>
> Thanks in advance.

Sorry, I didn't make it clear.  I mean, every time when the code goes
to the above statement, I found (in the debuger) f->id is still 0x00.
And, the result is, observed from my communication log, the request id
is never get increased.

So, what's the possible reason the f->id get reset? And where?

Thanks.

--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer

narke
public key at http://subkeys.pgp.net:11371 (address@hidden)

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users