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>
When CONFIG_NETDB_RESOLVCONF is enabled, CONFIG_NETDB_DNSSERVER_NAMESERVERS
will undefined, could cause net/icmpv6/icmpv6_input.c build error.
just add one nameserver to avoid overwrite ipv4 nameserver.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
Otherwise, the IP address is always considered to conflict, and the ipv6
address cannot be effectively obtained.
Later we will look at how to perform conflict detection on L3 network cards
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
Fix minor problems when reading codes:
- icmpv6_autoconfig: Call net_unlock before return
- pkt_sendmsg: Return error for types other than SOCK_RAW
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
The `xxx_ipv6multicast` function in each driver is not adapted to
multiple IPv6 addresses yet, and they're redundant, so try to take them
into common code.
Change:
1. Add MAC `g_ipv6_ethallnodes` and `g_ipv6_ethallrouters` in
`icmpv6_devinit` and call them in `netdev_register`
2. Add multicast MAC for Neighbor Solicitation when adding any IPv6
address, and remove them when IPv6 address is removed
3. Select `NET_MCASTGROUP` when `NET_ICMPv6` because now we need
`d_addmac` when we have ICMPv6
Note:
We want modules outside net stack to call functions like
`netdev_ipv6_add` and never touch the related MAC address, so these MAC
functions are added as internal functions to `net/netdev/netdev.h`
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
Previously ipv6 multi-address support decided packet source
address based on its destination. This doesn't work if NuttX
device has multiple addresses within same subnet.
Instead when a packet is a response to existing connection,
the source address should be based on the destination address
used in the received packet.
- When receiving Router Advertisement Message, if Managed Address
Configuration flag is set, we should ignore the Autonomous
Address-configuration flag, and obtain the IPv6 address via the
stateful process.
Signed-off-by: liqinhui <liqinhui@xiaomi.com>
When implementing IPv6-related logic, we found the `net_ipv6_pref2mask`
and `net_ipv6addr_copy` are using different argument order:
```
net_ipv6addr_copy(ifaddr->addr, addr);
net_ipv6_pref2mask(preflen, ifaddr->mask);
```
Change the order to:
```
net_ipv6addr_copy(ifaddr->addr, addr);
net_ipv6_pref2mask(ifaddr->mask, preflen);
```
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
Note that user-space related code, like procfs and lifreq related ioctl commands, are not touched in this commit.
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
1. Both IPv6 addresses and net masks should be stored in network byte
order
2. Fix last 2 bytes of mask applying (although it seldom triggers)
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
Allows setting the advertised route lifetime, and also to set
it to 0 for advertising only the prefix.
From RFC4861:
A router might want to send Router Advertisements without advertising
itself as a default router. For instance, a router might advertise
prefixes for stateless address autoconfiguration while not wishing to
forward packets. Such a router sets the Router Lifetime field in
outgoing advertisements to zero.
The netdev of link-local address cannot be auto decided, and the link-local address should always be reguarded as address on local network.
The problem we met:
When using `icmpv6_autoconfig` with multiple netdev, the `icmpv6_neighbor` may take out wrong netdev with ip address already set, then it may send solicitation with wrong address (`dev->d_ipv6draddr`) on wrong device, and regard the link-local address as conflict (because `dev->d_ipv6draddr` exists on this network).
Signed-off-by: Zhe Weng <wengzhe@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>
added IPV6_RECVHOPLIMIT support so that fd of SOCK_RAW ICMPV6 can obtain ttl
information, some network related tools use this feature.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
The third-party library we are porting will send and receive ICMPV6 messages
(router_advert / router_solicit / neighbor_advert / neighbor_solicit etc.)
from the user mode itself, so we added the SOCK_RAW related implementation
for ICMPV6.
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.
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.
Alin Jerpelea