Existing functions are based on IP address, but the address is used
only to look up which netif to act on. The netif-based core code is
extracted to new exported functions.
If you have a netif handle, this makes it easier to join/leave
groups, without the need to convert to IP address first only for the
mld6 code to convert back to netif.
Existing functions are based on IP address, but the address is used
only to look up which netif to act on. The netif-based core code is
extracted to new exported functions.
If you have a netif handle, this makes it easier to join/leave
groups, without the need to convert to IP address first only for the
IGMP code to convert back to netif.
Jiffies isn't really a humanly readable value and it means the default
PPP_MAXIDLEFLAG period depends on the platform "jiffies" frequency,
which isn't nice.
Change PPP_MAXIDLEFLAG to use ms instead of jiffies, the current
PPP_MAXIDLEFLAG default (100 ms), looks like a sane value and is
left unchanged.
Adds sendmsg implementation for TCP and UDP sockets. Control messages
are not supported at this point, but could be added in the future
https://savannah.nongnu.org/bugs/?44805
Change-Id: Iddb287fd4b693f7563f8c923f76785cdde782d2f
The overall lwIP design on data flows (netif,udp,tcp) is to use a user
defined callback to get data from stack and a static function to send
data to stack, which makes perfect sense. The SIO port was an exception,
the PPP stack never really used the SIO port by only using the
sio_send() function (and the ignominious sio_read_abort() function a
while back).
The way the SIO port is currently designed adds a tight coupling between
the lwIP port and the user code if the user need to do specific user
code if the current uart used is the PPPoS uart, which is not nice,
especially because all the lwIP stack is quite clean at this subject.
While we are at stabilizing the PPP API, change this behavior before
it's too late by replacing the static sio_write() calls to a user
defined callback.
The only API difference with and without the PPP_MD5_RANDM support is the
availability of the random_bytes() function. Added a random_bytes()
function on top of magic() when PPP_MD5_RANDM support is not enabled,
thus allowing builds for both cases.
PPP_MD5_RANDM is still enabled by default (it was mandatory) if a protocol
using encryption is enabled, such as CHAP, EAP, or L2TP auth support.
