PPP_MRU is now free to be used for what it should have been. Now using
it at PPP init stage to set the wanted MRU value, triggering a MRU
negotiation at the LCP phase.
I doubt anyone needs it anyway, but, well, at least it is fixed and the
MRU/MTU config mess is cleaned.
And while we are at it, better document PPP MRU config values.
RFC1661 mandates that default MRU value, that must be used prior
negotiation of MRU value and if MRU value is not negotiated later, must
be 1500.
That is, any PPP host must accept control frames of at least 1500 when
the PPP session start (there are no way to split them in multiples
frames anyway) and must use a value of 1500 if MRU is no negotiated
during LCP exchanges.
Therefore, having it configurable in ppp_opts is a mistake. It was wrong
and never worked because changing the value never triggered a MRU value
negotiation because it changed both the wanted MRU value and the RFC
default value to which the wanted value is compared to trigger a MRU
negotiation if values are not equal.
Those are private functions, using the netif_ prefix here is not really
nice, especially with functions named netif_set_mtu and netif_get_mtu
for obvious reasons.
Having it configurable does not really make sense anymore, we already
need PBUF_RAM in all transmit paths. There are no real reason to keep
allocating PPP response buffers from the PBUF_POOL which should be now
reserved for receive paths only.
We need PBUF_RAM for quite a while for PPP, e.g. through pbuf_coalesce
and for all PPP transmit paths. There are no real reason to keep
allocating packets from PBUF_POOL for PPP control packets transmit path
by default today.
If we fail to receive a full packet, for exemple if a memory allocation
fail for some reason, we currently do not wait for next packet flag
character and we start filling a new packet at next received byte. Then
we expect the checksum check to discard the packet.
The behavior seem to have been broken one or two decades ago when adding
support for PFC (Protocol-Field-Compression) and ACFC
(Address-and-Control-Field-Compression).
Rework to drop any character until we receive a flag character at init
and when we drop a packet before it is complete.
VJ support is known to be broken when built with some compiler
optimizations enabled, disabling it by default until someone needs it
and fixes it.
It was mostly used with dial-up modems, it is useless with PPPoE and
PPPoL2TP and is probably useless as well with cellular modems, so
disabling it by default makes sense anyway.
In theory, if provided username or password is over 0x80000000 byte long
(err...), casts to signed integer of strlen() return values is going to
return negative values breaking lengths checks.
Fix it by only using unsigned integer or size_t (guaranteed to be
unsigned) comparisons.
Generating docs for file src/incl/home/travis/build/lwip-tcpip/lwip/src/include/lwip/ip4_addr.h:151:s
error: unable to resolve reference to `ip4_addr_eq' for \ref command (warning treated as error, aborting now)
Like pbuf_copy, but can copy part of a pbuf to an offset in another.
pbuf_copy now uses this function internally.
Replace pbuf_take_at loop in icmp6 with pbuf_copy_partial_pbuf().
Fuzz tests need reproducible code, so we need an "unsafe" version of
LWIP_RAND() in this case...
Also, to reproduce fuzz tests cases from Linux on Windows,
LWIP_RAND_FOR_FUZZ_SIMULATE_GLIBC provides the first 20 random numbers that
glibc would have...
When we have multiple netifs where at least one has checksum offloading
capabilities, IP forwarding needs to set various checksum fields to 0
to prevent HW algorithms on calculating an invalid checksum.
-> set checksum fields of IP/UDP/TCP/ICMP to 0 in ip4_forward().
See bug #56288
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
This is just to keep the code clean and prevent using the "echo" header
where any ICMP header is meant.
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
Use 'PBUF_IP_HLEN+PBUF_TRANSPORT_HLEN' instead of '40' to calculate
PBUF_POOL_BUFSIZE (the size of each PBUF_POOL buffer) since the former
can be 60 when IPv6 is enabled.
See bug #56355
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
This converts all ppp_*() debug functions to ppp_*(()) macros that
ensure the code is left out by the linker if the corresponding debug
setting is disabled.
Downside is that many lines of code are touched, but since these
already differ to upstream PPP sources, I figured that's ok...
See bug #55199
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
In order to reuse the debug-enable checks for PPP debug macros,
move the flag and level checks from LWIP_DEBUGF to a new macro
that can be used elsewhere.
According to mbedTLS source code and documentation, calls to
`mbedtls_ssl_conf_session_cache` and `mbedtls_ssl_conf_session_tickets_cb`
are only available if mbedTLS is configured for server mode (ie. MBEDTLS_SSL_SRV_C
is defined). This cannot be used on client mode to resume a previous session.
To allow session reuse in client mode, application must save session parameters
(including tickets provided by the server if any) after successfull connection
and restore them before attemting to reconnect. Since `alctp_close()` free the
structure, it cannot be used to store the required information.
So, two new API were added, directly wrapped to mbedTLS functions, allow application
to do that by itself.
Also added full declaration of `struct altcp_tls_session` in altcp_tls.h to allow
easier usage in application when using mbedTLS port.
In some noisy WiFi environment, it may be necessary to increase this value to
300ms to accomodate WiFi latencies which may result in less than the required
250ms between two probe frames received by the Apple BCT application.
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
This allow Apple Bonjour Conformance Test to not fail with the following tests:
- DISTRIBUTED DUPLICATE SUPPRESSION
- MULTIPLE QUESTIONS - DISTRIBUTED DUPLICATE SUPPRESSION
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
Called with `MDNS_INITIAL_PROBE_DELAY_MS` or `MDNS_PROBE_DELAY_MS` according to
needs.
When `mdns_resp_restart_delay()` called by `mdns_resp_rename_(netif|service)()`
functions, it is assumed this is because a conflict. So we should not use
`MDNS_INITIAL_PROBE_DELAY_MS` because the Bonjour Conformance Test will
complain like this:
```
START (PROBING)
NOTICE 16:40:09.501911: conflicting probe:
smarTrEMotE-f8d0a4.Local.
ERROR 16:40:09.607288: Device did not provide a sufficient time gap between receiving a conflicting probe and reprobing.
ERROR 16:40:09.607333: expected_time_gap=237,actual_time_gap=105
```
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
- Send service slot index to the mdns result function. In case of conflict, the user
will have to remove the service or rename it.
- Break after hostname conflict in order to managed it first, and managed service name
conflict after.
- Provide a function to get the TXT userdata for a service (allowing app to match with
its own data).
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
When more than one service (just 2) need to be probed for conflict, generation
of the probe packet fail because pbuf is too small!
So OUTPACKET_SIZE renamed to MDNS_OUTPUT_PACKET_SIZE and moved to mdns_opts.h
to allow configuration. Default configuration raise it to 1450 to have enough
space when MDNS_MAX_SERVICES > 1 else it remain 512.
Extract from RFC 6762, chapter 17, Multicast DNS Message Size:
The 1987 DNS specification [RFC1035] restricts DNS messages carried
by UDP to no more than 512 bytes (not counting the IP or UDP
headers). For UDP packets carried over the wide-area Internet in
1987, this was appropriate. For link-local multicast packets on
today's networks, there is no reason to retain this restriction.
Given that the packets are by definition link-local, there are no
Path MTU issues to consider.
Multicast DNS messages carried by UDP may be up to the IP MTU of the
physical interface, less the space required for the IP header (20
bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes).
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
* Socket functions definitions moved out of the
#define LWIP_SOCKET_EXTERNAL_HEADERS as all users who
set LWIP_SOCKETS to 1 will need them regardless they use
lwip's or external socket headers.
* Lwip declares msghdr->msg_iovlen as int, but when
using external socket headers, some systems declare
msg_iovlen as size_t or others.
* This patch creates a new type msg_iovlen_t and
expects users to typedef it to the type they need
for their system.
Lwip's struct sockaddr includes sa_len, but some systems
like Linux doesn't have this filed, which produces many
compilation problems when using external headers.
A set of macros has benn added to detect the absence of
sa_len and adapt sockets.c
* LWIP_MARK_TCPIP_THREAD moved to include/lwip/sys.h
* Unix port macro definitions moved to sys_arch.h
* LWIP_MARK_TCPIP_THREAD
* LOCK_TCPIP_CORE
* UNLOCK_TCPIP_CORE
(goldsimon@gmx.de: fixed unix Makefile build and win32 build)
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
In timeouts.c commit 7d1c26cc0c18d02cc72f348f9189dd1c3a06bfca replaced
timeout for AUTOIP with a timeout for ACD, however the value of
LWIP_NUM_SYS_TIMEOUT_INTERNAL was not updated and still counts
LWIP_AUTOIP instead of LWIP_ACD. If user has AUTOIP disabled (or not
explicitly enabled) and DHCP enabled, then ACD gets automatically
enabled too. In this case there will be one timeout too little for lwIP
and first TCP packet received causes an assertion.
Also add LWIP_IPV6_DHCP6 to the value of LWIP_NUM_SYS_TIMEOUT_INTERNAL,
as it was also not accounted for.
This reuses the member 'int socket' by making it a union containing
both int and void pointer.
See bug #56593.
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
Suggested-by: Wilfred <wilfrednilsen@hotmail.com>
