etharp_query() queues packets, instead of sending, if a relevant arp-request is
pending.
Code walks the packet (a pbuf chain) to determine whether any pbufs are marked
'volatile': If so, we cannot simply enqueue the packet, and instead allocate a
new pbuf from RAM, copying the original packet, and enqueueing this new pbuf.
The bug here is that the allocation refers to the tot_len field of a temp pbuf*,
'p', instead of the head, 'q'.
In the case where the first pbuf of the chain is non-volatile but the second pbuf
*is* volatile, then we'll request an allocation that uses the tot_len field of
the second pbuf. If the first pbuf is non-zero length, the allocated pbuf (chain)
will be too small to allow the copy.
Signed-off-by: goldsimon <goldsimon@gmx.de>
while ((q != NULL) && (options[offset] != DHCP_OPTION_END) && (offset < offset_max)) {
should be
while ((q != NULL) && (offset < offset_max) && (options[offset] != DHCP_OPTION_END)) {
See https://jira.reactos.org/browse/CORE-8978 for more info.
Create new function dhcp_release_and_stop() that stops DHCP statemachine and sends release message if needed. Also stops AUTOIP if in coop mode.
Old dhcp_release() and dhcp_stop() function internally call dhcp_release_and_stop() now.
lwIP aims to support zero-copy TX, and thus, must internally handle
all cases that pbufs are referenced rather than copied upon low-level
output. However, in the current situation, the arp/ndp packet queuing
routines conservatively copy entire packets, even when unnecessary in
cases where lwIP is used in a zero-copy compliant manner. This patch
moves the decision whether to copy into a centralized macro, allowing
zero-copy compliant applications to override the macro to avoid the
unnecessary copies. The macro defaults to the safe behavior, though.
- Code duplication with etharp_raw()
- No great effect on perfomance
- May make reworking PBUF handling code more complicated (see bug #49914)
- The check for p->type == PBUF_REF is a strange special case, too
- Simon also voted to remove it
Eliminate ETHADDR32_COPY macro - it cannot be used in ETH_PAD_SIZE case. I could have kept it by defining it to ETHADDR16_COPY in case of ETH_PAD_SIZE, but I did not consider it worth another #ifdef mess.
The code in the for loop checks tmp_group->next == group, so current code
actually checks from the 3rd entry in the linked groups list. Fix it.
Fixes: 5c1dd6a4c6 ("Optimization in igmp_remove_group() pointed out by Axel Lin")
Signed-off-by: Axel Lin <axel.lin@ingics.com>
This commit increments the ip.drop statistic when an IP packet is
dropped due to no matching netif found and forwarding is disabled
This adds parity to the other places where mib2.ipinaddrerrors and
mib2.ipindiscards are incremented which also increment ip.drop
Generally speaking, packets with a loopback destination address -
127.0.0.1 for IPv4 and ::1 for IPv6 - should not be accepted on
non-loopback interfaces. For IPv4, this is implied by RFC 1122
Sec. 3.2.1.3. For IPv6, it is mandated by RFC 4291 Sec. 2.5.3.
Failure to perform this filtering may have security implications, as
applications that bind sockets to loopback addresses may not expect
that nodes on the local external network be able to produce traffic
that will arrive at such sockets.
With this patch, lwIP drops packets that are sent to a loopback
address but do not originate from the interface that has the loopback
address assigned to it. This approach works regardless of whether it
is lwIP or the system using it that implements a loopback netif. The
only exception that must be made is for configurations that enable
netif packet loopback but disable the lwIP loopback netif: in that
case, loopback packets are routed across non-loopback netifs and would
thus be lost by the new filter as well.
For IPv6, loopback-destined packets are also no longer forwarded; the
IPv4 forwarding code already had a check for that.
As a small performance improvement, the IPv6 link-local/loopback
address check is now performed only once per packet rather than
repeatedly for every candidate netif.
In general, netif_default may be NULL, and various places in the code
already check for this case before attempting to dereference the
netif_default pointer. Some places do not perform this check though,
and may cause null pointer dereferences if netif_default is not set.
This patch adds NULL checks to those places as well.
