[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-5850":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":19,"stars90d":16,"forks30d":16,"starsTrendScore":20,"compositeScore":21,"rankGlobal":10,"rankLanguage":10,"license":22,"archived":23,"fork":23,"defaultBranch":24,"hasWiki":23,"hasPages":23,"topics":25,"createdAt":10,"pushedAt":10,"updatedAt":28,"readmeContent":29,"aiSummary":30,"trendingCount":16,"starSnapshotCount":16,"syncStatus":31,"lastSyncTime":32,"discoverSource":33},5850,"smoltcp","smoltcp-rs\u002Fsmoltcp","smoltcp-rs","a smol tcp\u002Fip stack","",null,"Rust",4481,531,57,79,0,4,8,43,12,30.18,"BSD Zero Clause License",false,"main",[26,27],"embedded","networking-stack","2026-06-12 02:01:15","# smoltcp\n\n[![docs.rs](https:\u002F\u002Fdocs.rs\u002Fsmoltcp\u002Fbadge.svg)](https:\u002F\u002Fdocs.rs\u002Fsmoltcp)\n[![crates.io](https:\u002F\u002Fimg.shields.io\u002Fcrates\u002Fv\u002Fsmoltcp.svg)](https:\u002F\u002Fcrates.io\u002Fcrates\u002Fsmoltcp)\n[![crates.io](https:\u002F\u002Fimg.shields.io\u002Fcrates\u002Fd\u002Fsmoltcp.svg)](https:\u002F\u002Fcrates.io\u002Fcrates\u002Fsmoltcp)\n[![crates.io](https:\u002F\u002Fimg.shields.io\u002Fmatrix\u002Fsmoltcp:matrix.org)](https:\u002F\u002Fmatrix.to\u002F#\u002F#smoltcp:matrix.org)\n[![codecov](https:\u002F\u002Fcodecov.io\u002Fgithub\u002Fsmoltcp-rs\u002Fsmoltcp\u002Fbranch\u002Fmaster\u002Fgraph\u002Fbadge.svg?token=3KbAR9xH1t)](https:\u002F\u002Fcodecov.io\u002Fgithub\u002Fsmoltcp-rs\u002Fsmoltcp)\n\n_smoltcp_ is a standalone, event-driven TCP\u002FIP stack that is designed for bare-metal,\nreal-time systems. Its design goals are simplicity and robustness. Its design anti-goals\ninclude complicated compile-time computations, such as macro or type tricks, even\nat cost of performance degradation.\n\n_smoltcp_ does not need heap allocation *at all*, is [extensively documented][docs],\nand compiles on stable Rust 1.91 and later.\n\n_smoltcp_ achieves [~Gbps of throughput](#examplesbenchmarkrs) when tested against\nthe Linux TCP stack in loopback mode.\n\n[docs]: https:\u002F\u002Fdocs.rs\u002Fsmoltcp\u002F\n\n## Features\n\n_smoltcp_ is missing many widely deployed features, usually because no one implemented them yet.\nTo set expectations right, both implemented and omitted features are listed.\n\n### Media layer\n\nThere are 3 supported mediums.\n\n* Ethernet\n  * Regular Ethernet II frames are supported.\n  * Unicast, broadcast and multicast packets are supported.\n  * ARP packets (including gratuitous requests and replies) are supported.\n  * ARP requests are sent at a rate not exceeding one per second.\n  * Cached ARP entries expire after one minute.\n  * 802.3 frames and 802.1Q are **not** supported.\n  * Jumbo frames are **not** supported.\n* IP\n  * Unicast, broadcast and multicast packets are supported.\n* IEEE 802.15.4\n  * Only support for data frames.\n\n### IP layer\n\n#### IPv4\n\n  * IPv4 header checksum is generated and validated.\n  * IPv4 time-to-live value is configurable per socket, set to 64 by default.\n  * IPv4 default gateway is supported.\n  * Routing outgoing IPv4 packets is supported, through a default gateway or a CIDR route table.\n  * IPv4 fragmentation and reassembly is supported.\n  * IPv4 options are **not** supported and are silently ignored.\n\n#### IPv6\n\n  * IPv6 hop-limit value is configurable per socket, set to 64 by default.\n  * Routing outgoing IPv6 packets is supported, through a default gateway or a CIDR route table.\n  * IPv6 hop-by-hop header is supported.\n  * ICMPv6 parameter problem message is generated in response to an unrecognized IPv6 next header.\n  * ICMPv6 parameter problem message is **not** generated in response to an unknown IPv6\n    hop-by-hop option.\n\n#### 6LoWPAN\n\n  * Implementation of [RFC6282](https:\u002F\u002Ftools.ietf.org\u002Frfc\u002Frfc6282.txt).\n  * Fragmentation is supported, as defined in [RFC4944](https:\u002F\u002Ftools.ietf.org\u002Frfc\u002Frfc4944.txt).\n  * UDP header compression\u002Fdecompression is supported.\n  * Extension header compression\u002Fdecompression is supported.\n  * Uncompressed IPv6 Extension Headers are **not** supported.\n\n### IP multicast\n\n#### IGMP\n\nThe IGMPv1 and IGMPv2 protocols are supported, and IPv4 multicast is available.\n\n  * Membership reports are sent in response to membership queries at\n    equal intervals equal to the maximum response time divided by the\n    number of groups to be reported.\n\n### ICMP layer\n\n#### ICMPv4\n\nThe ICMPv4 protocol is supported, and ICMP sockets are available.\n\n  * ICMPv4 header checksum is supported.\n  * ICMPv4 echo replies are generated in response to echo requests by default.\n  * ICMP sockets can listen to ICMPv4 Port Unreachable messages, or any ICMPv4 messages with\n    a given IPv4 identifier field.\n  * ICMPv4 protocol unreachable messages are **not** passed to higher layers when received.\n  * ICMPv4 parameter problem messages are **not** generated.\n\n#### ICMPv6\n\nThe ICMPv6 protocol is supported, and ICMP sockets are available.\n\n  * ICMPv6 header checksum is supported.\n  * ICMPv6 echo replies are generated in response to echo requests by default.\n  * ICMPv6 protocol unreachable messages are **not** passed to higher layers when received.\n\n#### NDISC\n\n  * Neighbor Advertisement messages are generated in response to Neighbor Solicitations.\n  * Router Advertisement messages are read, but **not** generated.\n  * Router Solicitation messages are generated, but **not** read.\n  * Redirected Header messages are **not** generated or read.\n\n### UDP layer\n\nThe UDP protocol is supported over IPv4 and IPv6, and UDP sockets are available.\n\n  * Header checksum is always generated and validated.\n  * In response to a packet arriving at a port without a listening socket,\n    an ICMP destination unreachable message is generated.\n\n### TCP layer\n\nThe TCP protocol is supported over IPv4 and IPv6, and server and client TCP sockets are available.\n\n  * Header checksum is generated and validated.\n  * Maximum segment size is negotiated.\n  * Window scaling is negotiated.\n  * Multiple packets are transmitted without waiting for an acknowledgement.\n  * Reassembly of out-of-order segments is supported, with no more than 4 or 32 gaps in sequence space.\n  * Keep-alive packets may be sent at a configurable interval.\n  * Retransmission timeout starts at at an estimate of RTT, and doubles every time.\n  * Time-wait timeout has a fixed interval of 10 s.\n  * User timeout has a configurable interval.\n  * Delayed acknowledgements are supported, with configurable delay.\n  * Nagle's algorithm is implemented.\n  * Selective acknowledgements are **not** implemented.\n  * Silly window syndrome avoidance is **not** implemented.\n  * Congestion control is optional, `CUBIC` and `Reno` are implemented.\n  * Timestamping is **not** supported.\n  * Urgent pointer is **ignored**.\n  * Probing Zero Windows is implemented.\n  * Packetization Layer Path MTU Discovery [PLPMTU](https:\u002F\u002Ftools.ietf.org\u002Frfc\u002Frfc4821.txt) is **not** implemented.\n\n## Installation\n\nTo use the _smoltcp_ library in your project, add the following to `Cargo.toml`:\n\n```toml\n[dependencies]\nsmoltcp = \"0.10.0\"\n```\n\nThe default configuration assumes a hosted environment, for ease of evaluation.\nYou probably want to disable default features and configure them one by one:\n\n```toml\n[dependencies]\nsmoltcp = { version = \"0.10.0\", default-features = false, features = [\"log\"] }\n```\n\n## Feature flags\n\n### Feature `std`\n\nThe `std` feature enables use of objects and slices owned by the networking stack through a\ndependency on `std::boxed::Box` and `std::vec::Vec`.\n\nThis feature is enabled by default.\n\n### Feature `alloc`\n\nThe `alloc` feature enables use of objects owned by the networking stack through a dependency\non collections from the `alloc` crate. This only works on nightly rustc.\n\nThis feature is disabled by default.\n\n### Feature `log`\n\nThe `log` feature enables logging of events within the networking stack through\nthe [log crate][log]. Normal events (e.g. buffer level or TCP state changes) are emitted with\nthe TRACE log level. Exceptional events (e.g. malformed packets) are emitted with\nthe DEBUG log level.\n\n[log]: https:\u002F\u002Fcrates.io\u002Fcrates\u002Flog\n\nThis feature is enabled by default.\n\n### Feature `defmt`\n\nThe `defmt` feature enables logging of events with the [defmt crate][defmt].\n\n[defmt]: https:\u002F\u002Fcrates.io\u002Fcrates\u002Fdefmt\n\nThis feature is disabled by default, and cannot be used at the same time as `log`.\n\n### Feature `verbose`\n\nThe `verbose` feature enables logging of events where the logging itself may incur very high\noverhead. For example, emitting a log line every time an application reads or writes as little\nas 1 octet from a socket is likely to overwhelm the application logic unless a `BufReader`\nor `BufWriter` is used, which are of course not available on heap-less systems.\n\nThis feature is disabled by default.\n\n### Features `phy-raw_socket` and `phy-tuntap_interface`\n\nEnable `smoltcp::phy::RawSocket` and `smoltcp::phy::TunTapInterface`, respectively.\n\nThese features are enabled by default.\n\n### Features `socket-raw`, `socket-udp`, `socket-tcp`, `socket-icmp`, `socket-dhcpv4`, `socket-dns`\n\nEnable the corresponding socket type.\n\nThese features are enabled by default.\n\n### Features `proto-ipv4`, `proto-ipv6` and `proto-sixlowpan`\n\nEnable [IPv4], [IPv6] and [6LoWPAN] respectively.\n\n[IPv4]: https:\u002F\u002Ftools.ietf.org\u002Frfc\u002Frfc791.txt\n[IPv6]: https:\u002F\u002Ftools.ietf.org\u002Frfc\u002Frfc8200.txt\n[6LoWPAN]: https:\u002F\u002Ftools.ietf.org\u002Frfc\u002Frfc6282.txt\n\n## Configuration\n\n_smoltcp_ has some configuration settings that are set at compile time, affecting sizes\nand counts of buffers.\n\nThey can be set in two ways:\n\n- Via Cargo features: enable a feature like `\u003Cname>-\u003Cvalue>`. `name` must be in lowercase and\nuse dashes instead of underscores. For example. `iface-max-addr-count-3`. Only a selection of values\nis available, check `Cargo.toml` for the list.\n- Via environment variables at build time: set the variable named `SMOLTCP_\u003Cvalue>`. For example\n`SMOLTCP_IFACE_MAX_ADDR_COUNT=3 cargo build`. You can also set them in the `[env]` section of `.cargo\u002Fconfig.toml`.\nAny value can be set, unlike with Cargo features.\n\nEnvironment variables take precedence over Cargo features. If two Cargo features are enabled for the same setting\nwith different values, compilation fails.\n\n### `IFACE_MAX_ADDR_COUNT`\n\nMax amount of IP addresses that can be assigned to one interface (counting both IPv4 and IPv6 addresses). Default: 2.\n\n### `IFACE_MAX_MULTICAST_GROUP_COUNT`\n\nMax amount of multicast groups that can be joined by one interface. Default: 4.\n\n### `IFACE_MAX_SIXLOWPAN_ADDRESS_CONTEXT_COUNT`\n\nMax amount of 6LoWPAN address contexts that can be assigned to one interface. Default: 4.\n\n### `IFACE_NEIGHBOR_CACHE_COUNT`\n\nAmount of \"IP address -> hardware address\" entries the neighbor cache (also known as the \"ARP cache\" or the \"ARP table\") holds. Default: 4.\n\n### `IFACE_MAX_ROUTE_COUNT`\n\nMax amount of routes that can be added to one interface. Includes the default route. Includes both IPv4 and IPv6. Default: 2.\n\n### `IFACE_MAX_PREFIX_COUNT`\n\nMax amount of IPv6 prefixes that can be added to one interface via SLAAC.\nShould be lower or equal to `IFACE_MAX_ADDR_COUNT`.\n\n### `FRAGMENTATION_BUFFER_SIZE`\n\nSize of the buffer used for fragmenting outgoing packets larger than the MTU. Packets larger than this setting will be dropped instead of fragmented. Default: 1500.\n\n### `ASSEMBLER_MAX_SEGMENT_COUNT`\n\nMaximum number of non-contiguous segments the assembler can hold. Used for both packet reassembly and TCP stream reassembly. Default: 4.\n\n### `REASSEMBLY_BUFFER_SIZE`\n\nSize of the buffer used for reassembling (de-fragmenting) incoming packets. If the reassembled packet is larger than this setting, it will be dropped instead of reassembled. Default: 1500.\n\n### `REASSEMBLY_BUFFER_COUNT`\n\nNumber of reassembly buffers, i.e how many different incoming packets can be reassembled at the same time. Default: 1.\n\n### `DNS_MAX_RESULT_COUNT`\n\nMaximum amount of address results for a given DNS query that will be kept. For example, if this is set to 2 and the queried name has 4 `A` records, only the first 2 will be returned. Default: 1.\n\n### `DNS_MAX_SERVER_COUNT`\n\nMaximum amount of DNS servers that can be configured in one DNS socket. Default: 1.\n\n### `DNS_MAX_NAME_SIZE`\n\nMaximum length of DNS names that can be queried. Default: 255.\n\n### IPV6_HBH_MAX_OPTIONS\n\nThe maximum amount of parsed options the IPv6 Hop-by-Hop header can hold. Default: 4.\n\n## Hosted usage examples\n\n_smoltcp_, being a freestanding networking stack, needs to be able to transmit and receive\nraw frames. For testing purposes, we will use a regular OS, and run _smoltcp_ in\na userspace process. Only Linux is supported (right now).\n\nOn \\*nix OSes, transmitting and receiving raw frames normally requires superuser privileges, but\non Linux it is possible to create a _persistent tap interface_ that can be manipulated by\na specific user:\n\n```sh\nsudo ip tuntap add name tap0 mode tap user $USER\nsudo ip link set tap0 up\nsudo ip addr add 192.168.69.100\u002F24 dev tap0\nsudo ip -6 addr add fe80::100\u002F64 dev tap0\nsudo ip -6 addr add fdaa::100\u002F64 dev tap0\nsudo ip -6 route add fe80::\u002F64 dev tap0\nsudo ip -6 route add fdaa::\u002F64 dev tap0\n```\n\nIt's possible to let _smoltcp_ access Internet by enabling routing for the tap interface:\n\n```sh\nsudo iptables -t nat -A POSTROUTING -s 192.168.69.0\u002F24 -j MASQUERADE\nsudo sysctl net.ipv4.ip_forward=1\nsudo ip6tables -t nat -A POSTROUTING -s fdaa::\u002F64 -j MASQUERADE\nsudo sysctl -w net.ipv6.conf.all.forwarding=1\n\n# Some distros have a default policy of DROP. This allows the traffic.\nsudo iptables -A FORWARD -i tap0 -s 192.168.69.0\u002F24 -j ACCEPT\nsudo iptables -A FORWARD -o tap0 -d 192.168.69.0\u002F24 -j ACCEPT\n```\n\n### Bridged connection\n\nInstead of the routed connection above, you may also set up a bridged (switched)\nconnection. This will make smoltcp speak directly to your LAN, with real ARP, etc.\nIt is needed to run the DHCP example.\n\nNOTE: In this case, the examples' IP configuration must match your LAN's!\n\nNOTE: this ONLY works with actual wired Ethernet connections. It\nwill NOT work on a WiFi connection.\n\n```sh\n# Replace with your wired Ethernet interface name\nETH=enp0s20f0u1u1\n\nsudo modprobe bridge\nsudo modprobe br_netfilter\n\nsudo sysctl -w net.bridge.bridge-nf-call-arptables=0\nsudo sysctl -w net.bridge.bridge-nf-call-ip6tables=0\nsudo sysctl -w net.bridge.bridge-nf-call-iptables=0\n\nsudo ip tuntap add name tap0 mode tap user $USER\nsudo brctl addbr br0\nsudo brctl addif br0 tap0\nsudo brctl addif br0 $ETH\nsudo ip link set tap0 up\nsudo ip link set $ETH up\nsudo ip link set br0 up\n\n# This connects your host system to the internet, so you can use it\n# at the same time you run the examples.\nsudo dhcpcd br0\n```\n\nTo tear down:\n\n```\nsudo killall dhcpcd\nsudo ip link set br0 down\nsudo brctl delbr br0\n```\n\n### Fault injection\n\nIn order to demonstrate the response of _smoltcp_ to adverse network conditions, all examples\nimplement fault injection, available through command-line options:\n\n  * The `--drop-chance` option randomly drops packets, with given probability in percents.\n  * The `--corrupt-chance` option randomly mutates one octet in a packet, with given\n    probability in percents.\n  * The `--size-limit` option drops packets larger than specified size.\n  * The `--tx-rate-limit` and `--rx-rate-limit` options set the amount of tokens for\n    a token bucket rate limiter, in packets per bucket.\n  * The `--shaping-interval` option sets the refill interval of a token bucket rate limiter,\n    in milliseconds.\n\nA good starting value for `--drop-chance` and `--corrupt-chance` is 15%. A good starting\nvalue for `--?x-rate-limit` is 4 and `--shaping-interval` is 50 ms.\n\nNote that packets dropped by the fault injector still get traced;\nthe  `rx: randomly dropping a packet` message indicates that the packet *above* it got dropped,\nand the `tx: randomly dropping a packet` message indicates that the packet *below* it was.\n\n### Packet dumps\n\nAll examples provide a `--pcap` option that writes a [libpcap] file containing a view of every\npacket as it is seen by _smoltcp_.\n\n[libpcap]: https:\u002F\u002Fwiki.wireshark.org\u002FDevelopment\u002FLibpcapFileFormat\n\n### examples\u002Ftcpdump.rs\n\n_examples\u002Ftcpdump.rs_ is a tiny clone of the _tcpdump_ utility.\n\nUnlike the rest of the examples, it uses raw sockets, and so it can be used on regular interfaces,\ne.g. `eth0` or `wlan0`, as well as the `tap0` interface we've created above.\n\nRead its [source code](\u002Fexamples\u002Ftcpdump.rs), then run it as:\n\n```sh\ncargo build --example tcpdump\nsudo .\u002Ftarget\u002Fdebug\u002Fexamples\u002Ftcpdump eth0\n```\n\n### examples\u002Fhttpclient.rs\n\n_examples\u002Fhttpclient.rs_ emulates a network host that can initiate HTTP requests.\n\nThe host is assigned the hardware address `02-00-00-00-00-02`, IPv4 address `192.168.69.1`, and IPv6 address `fdaa::1`.\n\nRead its [source code](\u002Fexamples\u002Fhttpclient.rs), then run it as:\n\n```sh\ncargo run --example httpclient -- --tap tap0 ADDRESS URL\n```\n\nFor example:\n\n```sh\ncargo run --example httpclient -- --tap tap0 93.184.216.34 http:\u002F\u002Fexample.org\u002F\n```\n\nor:\n\n```sh\ncargo run --example httpclient -- --tap tap0 2606:2800:220:1:248:1893:25c8:1946 http:\u002F\u002Fexample.org\u002F\n```\n\nIt connects to the given address (not a hostname) and URL, and prints any returned response data.\nThe TCP socket buffers are limited to 1024 bytes to make packet traces more interesting.\n\n### examples\u002Fping.rs\n\n_examples\u002Fping.rs_ implements a minimal version of the `ping` utility using raw sockets.\n\nThe host is assigned the hardware address `02-00-00-00-00-02` and IPv4 address `192.168.69.1`.\n\nRead its [source code](\u002Fexamples\u002Fping.rs), then run it as:\n\n```sh\ncargo run --example ping -- --tap tap0 ADDRESS\n```\n\nIt sends a series of 4 ICMP ECHO\\_REQUEST packets to the given address at one second intervals and\nprints out a status line on each valid ECHO\\_RESPONSE received.\n\nThe first ECHO\\_REQUEST packet is expected to be lost since arp\\_cache is empty after startup;\nthe ECHO\\_REQUEST packet is dropped and an ARP request is sent instead.\n\nCurrently, netmasks are not implemented, and so the only address this example can reach\nis the other endpoint of the tap interface, `192.168.69.100`. It cannot reach itself because\npackets entering a tap interface do not loop back.\n\n### examples\u002Fserver.rs\n\n_examples\u002Fserver.rs_ emulates a network host that can respond to basic requests.\n\nThe host is assigned the hardware address `02-00-00-00-00-01` and IPv4 address `192.168.69.1`.\n\nRead its [source code](\u002Fexamples\u002Fserver.rs), then run it as:\n\n```sh\ncargo run --example server -- --tap tap0\n```\n\nIt responds to:\n\n  * pings (`ping 192.168.69.1`);\n  * UDP packets on port 6969 (`socat stdio udp4-connect:192.168.69.1:6969 \u003C\u003C\u003C\"abcdefg\"`),\n    where it will respond with reversed chunks of the input indefinitely;\n  * TCP connections on port 6969 (`socat stdio tcp4-connect:192.168.69.1:6969`),\n    where it will respond \"hello\" to any incoming connection and immediately close it;\n  * TCP connections on port 6970 (`socat stdio tcp4-connect:192.168.69.1:6970 \u003C\u003C\u003C\"abcdefg\"`),\n    where it will respond with reversed chunks of the input indefinitely.\n  * TCP connections on port 6971 (`socat stdio tcp4-connect:192.168.69.1:6971 \u003C\u002Fdev\u002Furandom`),\n    which will sink data. Also, keep-alive packets (every 1 s) and a user timeout (at 2 s)\n    are enabled on this port; try to trigger them using fault injection.\n  * TCP connections on port 6972 (`socat stdio tcp4-connect:192.168.69.1:6972 >\u002Fdev\u002Fnull`),\n    which will source data.\n\nExcept for the socket on port 6971. the buffers are only 64 bytes long, for convenience\nof testing resource exhaustion conditions.\n\n### examples\u002Fclient.rs\n\n_examples\u002Fclient.rs_ emulates a network host that can initiate basic requests.\n\nThe host is assigned the hardware address `02-00-00-00-00-02` and IPv4 address `192.168.69.2`.\n\nRead its [source code](\u002Fexamples\u002Fclient.rs), then run it as:\n\n```sh\ncargo run --example client -- --tap tap0 ADDRESS PORT\n```\n\nIt connects to the given address (not a hostname) and port (e.g. `socat stdio tcp4-listen:1234`),\nand will respond with reversed chunks of the input indefinitely.\n\n### examples\u002Fbenchmark.rs\n\n_examples\u002Fbenchmark.rs_ implements a simple throughput benchmark.\n\nRead its [source code](\u002Fexamples\u002Fbenchmark.rs), then run it as:\n\n```sh\ncargo run --release --example benchmark -- --tap tap0 [reader|writer]\n```\n\nIt establishes a connection to itself from a different thread and reads or writes a large amount\nof data in one direction.\n\nA typical result (achieved on a Intel Core i5-13500H CPU and a Linux 6.9.9 x86_64 kernel running\non a LENOVO XiaoXinPro 14 IRH8 laptop) is as follows:\n\n```\n$ cargo run -q --release --example benchmark -- --tap tap0 reader\nthroughput: 3.673 Gbps\n$ cargo run -q --release --example benchmark -- --tap tap0 writer\nthroughput: 7.905 Gbps\n```\n\n## Bare-metal usage examples\n\nExamples that use no services from the host OS are necessarily less illustrative than examples\nthat do. Because of this, only one such example is provided.\n\n### examples\u002Floopback.rs\n\n_examples\u002Floopback.rs_ sets up _smoltcp_ to talk with itself via a loopback interface.\nAlthough it does not require `std`, this example still requires the `alloc` feature to run, as well as `log`, `proto-ipv4` and `socket-tcp`.\n\nRead its [source code](\u002Fexamples\u002Floopback.rs), then run it without `std`:\n\n```sh\ncargo run --example loopback --no-default-features --features=\"log proto-ipv4 socket-tcp alloc\"\n```\n\n... or with `std` (in this case the features don't have to be explicitly listed):\n\n```sh\ncargo run --example loopback -- --pcap loopback.pcap\n```\n\nIt opens a server and a client TCP socket, and transfers a chunk of data. You can examine\nthe packet exchange by opening `loopback.pcap` in [Wireshark].\n\nIf the `std` feature is enabled, it will print logs and packet dumps, and fault injection\nis possible; otherwise, nothing at all will be displayed and no options are accepted.\n\n[wireshark]: https:\u002F\u002Fwireshark.org\n\n### examples\u002Floopback\\_benchmark.rs\n\n_examples\u002Floopback_benchmark.rs_ is another simple throughput benchmark.\n\nRead its [source code](\u002Fexamples\u002Floopback_benchmark.rs), then run it as:\n\n```sh\ncargo run --release --example loopback_benchmark\n```\n\nIt establishes a connection to itself via a loopback interface and transfers a large amount\nof data in one direction.\n\nA typical result (achieved on a Intel Core i5-13500H CPU and a Linux 6.9.9 x86_64 kernel running\non a LENOVO XiaoXinPro 14 IRH8 laptop) is as follows:\n\n```\n$ cargo run --release --example loopback_benchmark\ndone in 0.558 s, bandwidth is 15.395083 Gbps\n```\n\nNote: Although the loopback interface can be used in bare-metal environments,\nthis benchmark _does_ rely on `std` to be able to measure the time cost.\n\n## License\n\n_smoltcp_ is distributed under the terms of 0-clause BSD license.\n\nSee [LICENSE-0BSD](LICENSE-0BSD.txt) for details.\n","smoltcp 是一个轻量级的、事件驱动的 TCP\u002FIP 协议栈，专为裸机和实时系统设计。该项目使用 Rust 语言编写，具有无需堆内存分配的特点，并且在稳定版 Rust 1.91 及以上版本中可编译。smoltcp 支持以太网 II 帧、IPv4 和 IPv6 的基本功能，以及 IEEE 802.15.4 数据帧处理。它还支持 ARP、IP 分片重组等功能，但不支持复杂的编译时计算或宏技巧。适用于资源受限环境下的网络通信需求，如嵌入式设备中的联网应用。",2,"2026-06-11 03:05:12","top_language"]