Adds support for timestamping received UDP packets, either in
hardware or in kernel. Builds on the existing support of SO_TIMESTAMP
for SocketCAN.
Implementation uses CLOCK_REALTIME for timestamping to match the
behavior of Linux. This could be made configurable in future if needed.
There're some apps trying to set too large SO_SNDBUF and SO_RCVBUF, which may use all IOBs in one socket and block all other network traffic.
Note:
Linux silently limits SO_SNDBUF to be less than `sysctl_wmem_max`, so we can also do this limit without returning any error.
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
This is a refactored version of the SLIP network driver. Updates
include:
1. The original design started two kernel threads per SLIP device.
The refactored version uses file_poll to essentially be driven
by the UART RX and TX interrupts and pushes work to the low
priority work queue.
2. The SLIP byte un-/stuffing is more efficient now, using memcpy
instead of handling each byte individually.
3. The switch of the old SLIP driver to IOBs caused buffer overwrites
if packets were sent that would not fit into a single IOB. This is
fixed now.
Signed-off-by: Michael Jung <michael.jung@secore.ly>
Timestamp location in can message has changed,
In the original logic timestamp is saved at the end of the data segment:
io_data
-------------------------------------------------
| CAN message | Time Stamp |
-------------------------------------------------
|<--------------- io_len ---------------->|
In the new structure timestamps will reuse NET_LL_GUARDSIZE to isolate CAN messages:
io_data io_offset
-------------------------------------------------
| Time Stamp | CAN message |
-------------------------------------------------
|<-------- io_len --------->|
This PR will:
1. Increase NET_LL_GUARDSIZE to 16 (sizeof(struct timeval)) if NET_CAN && NET_TIMESTAMP are enabled
2. Apply timestamp to adapt to the new structure
Signed-off-by: chao an <anchao@xiaomi.com>
Add basic functions for NAT (NAPT), remaining some logic unimplemented (UDP, ICMP, port assignment, etc). NAT for TCP can work now (unless port conflicts).
Outbound: LAN -> Forward -> NAT(only if targeting at WAN) -> WAN
Inbound: WAN -> NAT(only from WAN, change dest) -> Forward -> LAN
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
1.Add cellular link layer enum definition and register flow
2.Add ioctl flow to set cellular NICs parameters
Signed-off-by: luojun1 <luojun1@xiaomi.com>
Signed-off-by: chao an <anchao@xiaomi.com>
add config CONFIG_NET_ALLOC_CONNS to support allocate connect.
Use this feature if the number of connections can not be determined at
compile time. When enabled the stack will be compiled without the static
pre-allocate connection list and all connection instances will be dynamically
allocated from heap at run time.
Signed-off-by: chao.an <anchao@xiaomi.com>
so netdb could reuse these global variable directly
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: Iaa26ddbdaf416f64d43c6e8888a14bbe0c3405eb
* The appropriate size of stack varies among archs.
E.g. for 64-bit sim, 2048 is way too small, especially when the task
happens to use host OS functionalities.
I plan to allow an arch provide its own default.
* I plan to use this to replace hardcoded "STACKSIZE = 2048" in APPDIR.
Historically, the loopback driver used the largest packet size of all enabled link layer protocols. This permitted packets to be forward via the loopbak device with no major loss of performance. However, in experimenting with configurations where no other link layer protocols were enabled, this means the loopback packet size was set to the smallest possible size, to the SLIP minimum of 296 bytes. This resulted in terrible loopback performance.
This commit adds an option to increase the loopback packet size with the option CONFIG_NET_LOOPBACK_PACKETSIZE.
The loopback driver packet buffer should be quite large. The larger the loopback packet buffer, the better will be TCP performance of the loopback transfers. The Linux loopback device historically used packet buffers of size 16Kb, but that was increased in recent Linux versions to 64Kb. Those sizes may be excessive for resource constrained MCUs, however.
The network still enforces the lower limit that is the maximum packet size of all enabled link layer protocols. But this new option permits the loopback packet size to be increased from that.
* net/Kconfig: Adds CONFIG_NET_LOOPBACK_PKTSIZE option
* include/nuttx/net/netconfig.h: Assures that the packet size that is used is at least as large as the largest packet size of other link layer protocols.
* drivers/net/loopback.c: Use that larger packet size.
* boards/sim/sim/sim/configs/tcploop/defconfig: Set the loopback packet size to 1500
Here is the email loop talk about why it is better to remove the option:
https://groups.google.com/forum/#!topic/nuttx/AaNkS7oU6R0
Change-Id: Ib66c037752149ad4b2787ef447f966c77aa12aad
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Squashed commit of the following:
net/netlink: Mark netlink support as EXPERIMENTAL.
net/netlink/netlink_sockif.c: Add netlink_getpeername to the socket interface.
net: Add getpeeername() support for netlink sockets.
include/netpacket/netlink.h: Add a few more definitions and structures used at the NetLink interface. Still missing many.
net/netlink: Add basic framework for Netlink socket support.
include/: Add basic Netlink definitions.
This makes the user interface a little hostile. People thing of an MTU of 1500 bytes, but the corresponding packet is really 1514 bytes (including the 14 byte Ethernet header). A more friendly solution would configure the MTU (as before), but then derive the packet buffer size by adding the MAC header length. Instead, we define the packet buffer size then derive the MTU.
The MTU is not common currency in networking. On the wire, the only real issue is the MSS which is derived from MTU by subtracting the IP header and TCP header sizes (for the case of TCP). Now it is derived for the PKTSIZE by subtracting the IP header, the TCP header, and the MAC header sizes. So we should be all good and without the recurring 14 byte error in MTU's and MSS's.
Squashed commit of the following:
Trivial update to fix some spacing issues.
net/: Rename several macros containing _MTU to _PKTSIZE.
net/: Rename CONFIG_NET_SLIP_MTU to CONFIG_NET_SLIP_PKTSIZE and similarly for CONFIG_NET_TUN_MTU. These are not the MTU which does not include the size of the link layer header. These are the full size of the packet buffer memory (minus any GUARD bytes).
net/: Rename CONFIG_NET_6LOWPAN_MTU to CONFIG_NET_6LOWPAN_PKTSIZE and similarly for CONFIG_NET_TUN_MTU. These are not the MTU which does not include the size of the link layer header. These are the full size of the packet buffer memory (minus any GUARD bytes).
net/: Rename CONFIG_NET_ETH_MTU to CONFIG_NET_ETH_PKTSIZE. This is not the MTU which does not include the size of the link layer header. This is the full size of the packet buffer memory (minus any GUARD bytes).
net/: Rename the file d_mtu in the network driver structure to d_pktsize. That value saved there is not the MTU. The packetsize is the memory large enough to hold the maximum packet PLUS the size of the link layer header. The MTU does not include the link layer header.
Fix a few typo/compilation problems.
net/: Remove all CONFIG_NET_xxx_TCP_RECVWNDO configuration variables. They were used only to initialize the d_recwndo of the network device structure which no longer exists.
net/: Remove the device TCP receive window field (d_recvwndo) from the device structure. That value is no longer retained, but is calculated dynamically.
Remove some dangling references to CONFIG_NET_TCP_RWND_CONTROL.
net/tcp: Take read-ahead throttling into account when calculating the TCP receive window size.
net/tcp: tcp_get_recvwindow() now returns the receive window size directly (vs. indirectly via the device structure).
net/tcp: Remove CONFIG_NET_TCP_RWND_CONTROL. TCP window algorithm is now trigged only by CONFIG_NET_TCP_READAHEAD.
