This patch adds support for RFC3542-style checksum computation on raw,
IPv6 sockets via the IPV6_CHECKSUM socket option.
This allows the development of application-layer utilities such as
ping6 which are unable to compute the raw packet checksum without a
prior knowledge of the source address selection.
The LWIP_MALLOC_MEMPOOL macro needs to use the aligned size of the
memp_malloc_helper structure, since mem_alloc() uses it to calculate
the required pool element size. If LWIP_MEM_ALIGN_SIZE(x) is redefined
to align to something larger than 4, then in some cases
the current code can lead to unexpected mem_alloc() failures.
For example:
#define LWIP_MEM_ALIGN_SIZE(size) (((size) + 31) & ~31)
and the largest MALLOC pool is of size 60 bytes, e.g.:
#define LWIP_MALLOC_MEMPOOL(256, 60)
then the following call:
mem_malloc(58)
will cause an assertion.
Using the pbuf_clen() function to calculate the number of pbufs
for the first packet in the queue is not correct here, as pbuf_clen()
will return the total number of pbufs in the loopback I/F queue.
although timeouts are relative to timeouts_last_time (transitively by
addition to the time values of their predecessors, if there are any),
sys_timeout does not compensate for that; as a result, timeouts fire too
early unless invoked from within a timeout handler (when
timeouts_last_time == now).
- 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 */
}
}
Removed one unecessary allocated PBUF per PPPoS RX packet if PPP_INPROC_MULTITHREADED is set by adding the necessary data for
pppos_input_callback() in front of the first pbuf instead of allocating a new buffer.
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).
