Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
If the device's CPU resources are scarce and unable to execute the
ip_fragin_timerwork callback in a timely manner, this assert will
be triggered. This is a normal scenario that can occur. The logic
should be modified to wait for the ip_fragin_timerwork to be
executed if it has not been executed yet.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
CC: libssh/src/auth.c
1ipfrag/ipv4_frag.c: In function 'ipv4_fragout':
ipfrag/ipv4_frag.c:224:7: error: 'ref' may be used uninitialized in this function [-Werror-maybe-uninitialized]
224 | lmemcpy(ipv4, ref, iphdrlen);
ipfrag/ipv4_frag.c:364:26: note: 'ref' was declared here
364 | FAR struct ipv4_hdr_s *ref;
CC: tls/task initinfo c
Signed-off-by: wangyingdong <wangyingdong@xiaomi.com>
1. Update all CMakeLists.txt to adapt to new layout
2. Fix cmake build break
3. Update all new file license
4. Fully compatible with current compilation environment(use configure.sh or cmake as you choose)
------------------
How to test
From within nuttx/. Configure:
cmake -B build -DBOARD_CONFIG=sim/nsh -GNinja
cmake -B build -DBOARD_CONFIG=sim:nsh -GNinja
cmake -B build -DBOARD_CONFIG=sabre-6quad/smp -GNinja
cmake -B build -DBOARD_CONFIG=lm3s6965-ek/qemu-flat -GNinja
(or full path in custom board) :
cmake -B build -DBOARD_CONFIG=$PWD/boards/sim/sim/sim/configs/nsh -GNinja
This uses ninja generator (install with sudo apt install ninja-build). To build:
$ cmake --build build
menuconfig:
$ cmake --build build -t menuconfig
--------------------------
2. cmake/build: reformat the cmake style by cmake-format
https://github.com/cheshirekow/cmake_format
$ pip install cmakelang
$ for i in `find -name CMakeLists.txt`;do cmake-format $i -o $i;done
$ for i in `find -name *\.cmake`;do cmake-format $i -o $i;done
Co-authored-by: Matias N <matias@protobits.dev>
Signed-off-by: chao an <anchao@xiaomi.com>
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>
1.
ipfrag/ipv4_frag.c: In function ‘ipv4_fragin’:
ipfrag/ipv4_frag.c:184:22: warning: ‘head’ may be used uninitialized in this function [-Wmaybe-uninitialized]
184 | ipv4->len[1] = head->io_pktlen & 0xff;
| ~~~~^~~~~~~~~~~
ipfrag/ipv4_frag.c:123:21: note: ‘head’ was declared here
123 | FAR struct iob_s *head;
| ^~~~
2.
devif/ipv6_input.c: In function ‘ipv6_in’:
devif/ipv6_input.c:60:33: error: ‘TCPIPv6BUF’ undeclared (first use in this function); did you mean ‘UDPIPv6BUF’?
60 | #define PAYLOAD ((FAR uint8_t *)TCPIPv6BUF)
| ^~~~~~~~~~
3.
nat/ipv4_nat.c: In function ‘ipv4_nat_inbound_icmp’:
nat/ipv4_nat.c:67:30: error: ‘TCP_HDRLEN’ undeclared (first use in this function); did you mean ‘UDP_HDRLEN’?
67 | ((proto) == IP_PROTO_TCP ? TCP_HDRLEN : \
| ^~~~~~~~~~
nat/ipv4_nat.c:323:47: note: in expansion of macro ‘L4_HDRLEN’
323 | inner_l4hdrlen = MIN(inner_l4len, L4_HDRLEN(inner->proto));
| ^~~~~~~~~
Signed-off-by: chao an <anchao@xiaomi.com>
wangyingdong