- CHANGELOG should contain worthy entries only, a complete log of all source code changes can be found in git (I'm not saying this has always been observed, but I'd like to keep the list of changes as short as possible for anyone to read if interested)
PPP notify phase support, using compile-time PPP_NOTIFY_PHASE macro.
This can be used for example to set a LED pattern depending on the
current phase of the PPP session.
Callback example:
static void ppp_notify_phase_cb(ppp_pcb *pcb, u8_t phase, void *ctx) {
switch(phase) {
case PPP_PHASE_DEAD: /* Kept off */
case PPP_PHASE_MASTER:
/* LED Off */
break;
case PPP_PHASE_INITIALIZE: /* Session opened */
/* LED FastBlink */
break;
case PPP_PHASE_RUNNING: /* Session running */
/* LED On */
break;
default:
/* LED SlowBlink */
}
}
pbuf_type PPP is using for LCP, PAP, CHAP, EAP, IPCP and IP6CP packets.
Memory allocated must be single buffered for PPP to works, it requires pbuf
that are not going to be chained when allocated. This requires setting
PBUF_POOL_BUFSIZE to at least 512 bytes, which is quite huge for small systems.
Setting PPP_USE_PBUF_RAM to 1 makes PPP use memory from heap where continuous
buffers are required, allowing you to use a smaller PBUF_POOL_BUFSIZE.
I consider to remove the PPP_INPROC_OWNTHREAD crap in ppp-new,
as said in bugs #37278 and #37353.
1. It requires the ppp_input_thread() function to be modified to match
user system, like some did by adding the vTaskDelete(NULL); FreeRTOS
call at the end of the function, for example.
This is a tiny-tiny fonction that should be, in my opinion, on the user
port, like the Ethernet input thread we see in many Ethernet port.
2. It is actually not that thread safe.
2.1. pcb->phase IS modified by the lwIP core thread so it should at
least be set to volatile, otherwise the pcb->phase copy may live
indefinitely in CPU register. It works because of the sio_read()
function call which without doubt flush pcb->phase copy from CPU
register. I dont want to set ppp_pcb struct to volatile for obvious
performance reasons.
2.2. This function assume PCB still exists whatever is happening, which
is not the case after you called ppp_delete() function outside of this
thread. If sio_read() is blocking waiting data and pcb destroyed, it is
going to read a deallocated pcb which luckily should still have
pcb->phase set to 0 (=PHASE_DEAD) due to preallocated "control block"
structures of lwIP. Even with sio_read_abort(), there might be timings
issue due to a lack of a synchronization mechanism.
3. I dislike the sys_msleep(1), it means that systems should have at
least a 11 chr buffer at 115200/10 byte/s, and bigger with higher serial
speed, for example with 3G/HSDPA modems accessed through SPI, at 20
Mbits/s this is a ~2000 bytes buffer required to keep incoming data
during this sleep, I don't see why we require systems to do so,
sio_read() should obviously be a blocking call. I cannot easily
remove this sleep because some systems might have wrongfully used this
call as a CPU idle feature with a non blocking sio_read() call.
Free the control block, clean everything except the PPP PCB itself
and the netif, it allows you to change the underlying PPP protocol
(eg. from PPPoE to PPPoS to switch from DSL to GPRS) without losing
your PPP and netif handlers.
Created new ppp_over_X_create() functions which only prepare the PPP session without starting it
Removed ppp_reopen() and all of its sub ppp_over_X_reopen()
Removed PPPoL2TP reconnect() function, merged to connect()
Added ppp_open() able to start or restart any session
The word "class" is reserved in IAR's EWARM compiler since it looks like c++.
This causes a failure to compile in the lcp code.
Arguably it is a bug in the compiler, but it is easy to work around with a
name change in the lcp.[ch] code. I fixed it by changing "class" to "class_".
This is now the user choice to re-establish the session in the link status callback
by either calling the ppp_reopen() to re-establish or ppp_delete() to free the PPP
control block. Without user intervention, the PPP control block now stay in the dead
phase, allowing the user to re-establish or delete the control block later.
