RFC 1191
When a router is unable to forward a datagram because it exceeds the
MTU of the next-hop network and its Don't Fragment bit is set, the
router is required to return an ICMP Destination Unreachable message
to the source of the datagram, with the Code indicating
"fragmentation needed and DF set". To support the Path MTU Discovery
technique specified in this memo, the router MUST include the MTU of
that next-hop network in the low-order 16 bits of the ICMP header
field that is labelled "unused" in the ICMP specification [7]. The
high-order 16 bits remain unused, and MUST be set to zero. Thus, the
message has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Code = 4 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused = 0 | Next-Hop MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + 64 bits of Original Datagram Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RFC 1185
Packet Too Big Message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as will fit without the ICMPv6 packet +
| exceeding 576 octets |
IPv6 Fields:
Destination Address
Copied from the Source Address field of the invoking
packet.
ICMPv6 Fields:
Type 2
Code 0
MTU The Maximum Transmission Unit of the next-hop link.
Description
A Packet Too Big MUST be sent by a router in response to a packet
that it cannot forward because the packet is larger than the MTU of
the outgoing link. The information in this message is used as part
of the Path MTU Discovery process [RFC-1191].
Signed-off-by: wangchen <wangchen41@xiaomi.com>
SOCK_CTRL is added to provide special control over network drivers
and daemons. Currently, SOCK_DGRAM and SOCK_STREAM perform this control,
but these use socket resources. In the case of usersocket in particular,
this is a waste of the device's limited socket resources.
The priorities for finding a network adapter are as follows:
1. if laddr is not ANY, use laddr to find device;
2. if laddr is ANY, and bound index is not 0, use bound index
to find device;
3. if laddr is ANY and no device is bound, use raddr to find
device.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
SOCK_CTRL is added to provide special control over network drivers
and daemons. Currently, SOCK_DGRAM and SOCK_STREAM perform this control,
but these use socket resources. In the case of usersocket in particular,
this is a waste of the device's limited socket resources.
Allocate the device buffer only if the protocol really need to send data.
not all protocols require the driver to prepare additional iob before
sending, especially UDP, each iob reserves l2/l3 header in advance
after prepare write buffer, net device could reuse this entry to send directly
Signed-off-by: chao an <anchao@xiaomi.com>
When trying to use iperf2, we found it comsumes all the IOB when sending UDP packets, then devif_poll has no IOB to send the packet out, so speed drops to 0 and never recovers.
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
since it is impossible to track producer and consumer
correctly if TCP/IP stack pass IOB directly to netdev
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Net poll teardown is not protected by net lock, if the conn is released
before teardown, the assertion failure will be triggered during free dev
callback, this patch will add the net lock around net poll teardown to
fix race condition
nuttx/libs/libc/assert/lib_assert.c:36
nuttx/net/devif/devif_callback.c:85
nuttx/net/tcp/tcp_netpoll.c:405
nuttx/fs/vfs/fs_poll.c:244
nuttx/fs/vfs/fs_poll.c:500
Signed-off-by: chao.an <anchao@xiaomi.com>
commit 3b69d09c80 corrected the
unreachable handling for net/udp/icmp but introduced an unaligned store.
This splits the uint32_t data field into a two element uint16_t data
field to avoid the unaligned store.
Reference RFC1122:
https://datatracker.ietf.org/doc/html/rfc1122
----------------------------------------------
4.1.3 SPECIFIC ISSUES
4.1.3.1 Ports
If a datagram arrives addressed to a UDP port for which
there is no pending LISTEN call, UDP SHOULD send an ICMP
Port Unreachable message.
Signed-off-by: chao.an <anchao@xiaomi.com>
