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
LCP is stealing a bit from fsm->flags struct member for LCP delayed up feature.
Bit stealed used to be the 9th bit (0x100) but fsm->flags was reduced to u8_t to save memory,
we are now stealing the 8th bit (0x80).
these are the compiler warnings I get with the head of ppp-new. All
of them are trivial, [...] (I'm using IAR EWARM 6.4).
ppp.c
Warning[Pe550]: variable "c" was set but never used
lwip\src\netif\ppp\ppp.c 1012
Warning[Pe111]: statement is unreachable
lwip\src\netif\ppp\ppp.c 1132
Warning[Pe111]: statement is unreachable
lwip\src\netif\ppp\ppp.c 1377
Warning[Pe111]: statement is unreachable
lwip\src\netif\ppp\ppp.c 1412
utils.c
Warning[Pe186]: pointless comparison of unsigned integer with zero
lwip\src\netif\ppp\utils.c 210
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_".
PPP stack does not handle chained pbuf, but PPP negociation packets
are at most ~40 bytes long, so we are only checking if the payload
can fit into the allocated pbuf (p->tot_len == p->len).
The lwIP PPP support is based from pppd 2.4.5 (http://ppp.samba.org) with
huge changes to match code size and memory requirements for embedded devices.
Anyway, pppd has a mature codebase for years and the average commit count
is getting low on their Git repositories, meaning that we can follow what
is happening on their side and merge what is relevant for lwIP.
So, here is the pppd follow up, so that we don't get away too far from pppd.
The only way PPPoE or PPPoL2TP disconnect it through ppp_link_terminated(),
therefore PPP is always already down, so we don't need to ask PPP to hup or stop.
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.
