1 /** 2 * @defgroup lwip lwIP 3 * 4 * @defgroup infrastructure Infrastructure 5 * 6 * @defgroup api APIs 7 * lwIP provides three Application Program's Interfaces (APIs) for programs 8 * to use for communication with the TCP/IP code: 9 * - low-level "core" / "callback" or @ref callbackstyle_api. 10 * - higher-level @ref sequential_api. 11 * - BSD-style @ref socket. 12 * 13 * The raw TCP/IP interface allows the application program to integrate 14 * better with the TCP/IP code. Program execution is event based by 15 * having callback functions being called from within the TCP/IP 16 * code. The TCP/IP code and the application program both run in the same 17 * thread. The sequential API has a much higher overhead and is not very 18 * well suited for small systems since it forces a multithreaded paradigm 19 * on the application. 20 * 21 * The raw TCP/IP interface is not only faster in terms of code execution 22 * time but is also less memory intensive. The drawback is that program 23 * development is somewhat harder and application programs written for 24 * the raw TCP/IP interface are more difficult to understand. Still, this 25 * is the preferred way of writing applications that should be small in 26 * code size and memory usage. 27 * 28 * All APIs can be used simultaneously by different application 29 * programs. In fact, the sequential API is implemented as an application 30 * program using the raw TCP/IP interface. 31 * 32 * Do not confuse the lwIP raw API with raw Ethernet or IP sockets. 33 * The former is a way of interfacing the lwIP network stack (including 34 * TCP and UDP), the latter refers to processing raw Ethernet or IP data 35 * instead of TCP connections or UDP packets. 36 * 37 * Raw API applications may never block since all packet processing 38 * (input and output) as well as timer processing (TCP mainly) is done 39 * in a single execution context. 40 * 41 * @defgroup callbackstyle_api "raw" APIs 42 * @ingroup api 43 * Non thread-safe APIs, callback style for maximum performance and minimum 44 * memory footprint. 45 * Program execution is driven by callbacks functions, which are then 46 * invoked by the lwIP core when activity related to that application 47 * occurs. A particular application may register to be notified via a 48 * callback function for events such as incoming data available, outgoing 49 * data sent, error notifications, poll timer expiration, connection 50 * closed, etc. An application can provide a callback function to perform 51 * processing for any or all of these events. Each callback is an ordinary 52 * C function that is called from within the TCP/IP code. Every callback 53 * function is passed the current TCP or UDP connection state as an 54 * argument. Also, in order to be able to keep program specific state, 55 * the callback functions are called with a program specified argument 56 * that is independent of the TCP/IP state. 57 * The raw API (sometimes called native API) is an event-driven API designed 58 * to be used without an operating system that implements zero-copy send and 59 * receive. This API is also used by the core stack for interaction between 60 * the various protocols. It is the only API available when running lwIP 61 * without an operating system. 62 * 63 * @defgroup sequential_api Sequential-style APIs 64 * @ingroup api 65 * Sequential-style APIs, blocking functions. More overhead, but can be called 66 * from any thread except TCPIP thread. 67 * The sequential API provides a way for ordinary, sequential, programs 68 * to use the lwIP stack. It is quite similar to the BSD socket API. The 69 * model of execution is based on the blocking open-read-write-close 70 * paradigm. Since the TCP/IP stack is event based by nature, the TCP/IP 71 * code and the application program must reside in different execution 72 * contexts (threads). 73 * 74 * @defgroup socket Socket API 75 * @ingroup api 76 * BSD-style socket API.<br> 77 * Thread-safe, to be called from non-TCPIP threads only.<br> 78 * Can be activated by defining @ref LWIP_SOCKET to 1.<br> 79 * Header is in posix/sys/socket.h<br> 80 * The socket API is a compatibility API for existing applications, 81 * currently it is built on top of the sequential API. It is meant to 82 * provide all functions needed to run socket API applications running 83 * on other platforms (e.g. unix / windows etc.). However, due to limitations 84 * in the specification of this API, there might be incompatibilities 85 * that require small modifications of existing programs. 86 * 87 * @defgroup netifs NETIFs 88 * 89 * @defgroup apps Applications 90 */ 91 92 /** 93 * @mainpage Overview 94 * @verbinclude "README" 95 */ 96 97 /** 98 * @page upgrading Upgrading 99 * @verbinclude "UPGRADING" 100 */ 101 102 /** 103 * @page changelog Changelog 104 * 105 * 2.1.0 106 * ----- 107 * * Support TLS via new @ref altcp_api connection API (https, smtps, mqtt over TLS) 108 * * Switch to cmake as the main build system (Makefile file lists are still 109 * maintained for now) 110 * * Improve IPv6 support: support address scopes, support stateless DHCPv6, bugfixes 111 * * Add debug helper asserts to ensure threading/locking requirements are met 112 * * Add sys_mbox_trypost_fromisr() and tcpip_callbackmsg_trycallback_fromisr() 113 * (for FreeRTOS, mainly) 114 * * socket API: support poll(), sendmsg() and recvmsg(); fix problems on close 115 * 116 * Detailed Changelog 117 * ------------------ 118 * @verbinclude "CHANGELOG" 119 */ 120 121 /** 122 * @page contrib How to contribute to lwIP 123 * @verbinclude "contrib.txt" 124 */ 125 126 /** 127 * @page cmake CMake build system 128 * @verbinclude "BUILDING" 129 */ 130 131 /** 132 * @page pitfalls Common pitfalls 133 * 134 * Multiple Execution Contexts in lwIP code 135 * ======================================== 136 * 137 * The most common source of lwIP problems is to have multiple execution contexts 138 * inside the lwIP code. 139 * 140 * lwIP can be used in two basic modes: @ref lwip_nosys (no OS/RTOS 141 * running on target system) or @ref lwip_os (there is an OS running 142 * on the target system). 143 * 144 * See also: @ref multithreading (especially the part about @ref LWIP_ASSERT_CORE_LOCKED()!) 145 * 146 * Mainloop Mode 147 * ------------- 148 * In mainloop mode, only @ref callbackstyle_api can be used. 149 * The user has two possibilities to ensure there is only one 150 * execution context at a time in lwIP: 151 * 152 * 1) Deliver RX ethernet packets directly in interrupt context to lwIP 153 * by calling netif->input directly in interrupt. This implies all lwIP 154 * callback functions are called in IRQ context, which may cause further 155 * problems in application code: IRQ is blocked for a long time, multiple 156 * execution contexts in application code etc. When the application wants 157 * to call lwIP, it only needs to disable interrupts during the call. 158 * If timers are involved, even more locking code is needed to lock out 159 * timer IRQ and ethernet IRQ from each other, assuming these may be nested. 160 * 161 * 2) Run lwIP in a mainloop. There is example code here: @ref lwip_nosys. 162 * lwIP is _ONLY_ called from mainloop callstacks here. The ethernet IRQ 163 * has to put received telegrams into a queue which is polled in the 164 * mainloop. Ensure lwIP is _NEVER_ called from an interrupt, e.g. 165 * some SPI IRQ wants to forward data to udp_send() or tcp_write()! 166 * 167 * OS Mode 168 * ------- 169 * In OS mode, @ref callbackstyle_api AND @ref sequential_api can be used. 170 * @ref sequential_api are designed to be called from threads other than 171 * the TCPIP thread, so there is nothing to consider here. 172 * But @ref callbackstyle_api functions must _ONLY_ be called from 173 * TCPIP thread. It is a common error to call these from other threads 174 * or from IRQ contexts. Ethernet RX needs to deliver incoming packets 175 * in the correct way by sending a message to TCPIP thread, this is 176 * implemented in tcpip_input(). 177 * Again, ensure lwIP is _NEVER_ called from an interrupt, e.g. 178 * some SPI IRQ wants to forward data to udp_send() or tcp_write()! 179 * 180 * 1) tcpip_callback() can be used get called back from TCPIP thread, 181 * it is safe to call any @ref callbackstyle_api from there. 182 * 183 * 2) Use @ref LWIP_TCPIP_CORE_LOCKING. All @ref callbackstyle_api 184 * functions can be called when lwIP core lock is acquired, see 185 * @ref LOCK_TCPIP_CORE() and @ref UNLOCK_TCPIP_CORE(). 186 * These macros cannot be used in an interrupt context! 187 * Note the OS must correctly handle priority inversion for this. 188 * 189 * Cache / DMA issues 190 * ================== 191 * 192 * DMA-capable ethernet hardware and zero-copy RX 193 * ---------------------------------------------- 194 * 195 * lwIP changes the content of RECEIVED pbufs in the TCP code path. 196 * This implies one or more cacheline(s) of the RX pbuf become dirty 197 * and need to be flushed before the memory is handed over to the 198 * DMA ethernet hardware for the next telegram to be received. 199 * See http://lists.nongnu.org/archive/html/lwip-devel/2017-12/msg00070.html 200 * for a more detailed explanation. 201 * Also keep in mind the user application may also write into pbufs, 202 * so it is generally a bug not to flush the data cache before handing 203 * a buffer to DMA hardware. 204 * 205 * DMA-capable ethernet hardware and cacheline alignment 206 * ----------------------------------------------------- 207 * Nice description about DMA capable hardware and buffer handling: 208 * http://www.pebblebay.com/a-guide-to-using-direct-memory-access-in-embedded-systems-part-two/ 209 * Read especially sections "Cache coherency" and "Buffer alignment". 210 */ 211 212 /** 213 * @page mem_err Debugging memory pool sizes 214 * If you have issues with lwIP and you are using memory pools, check that your pools 215 * are correctly sized.<br> 216 * To debug pool sizes, \#define LWIP_STATS and MEMP_STATS to 1. Check the global variable 217 * lwip_stats.memp[] using a debugger. If the "err" member of a pool is > 0, the pool 218 * may be too small for your application and you need to increase its size. 219 */ 220 221 /** 222 * @page bugs Reporting bugs 223 * Please report bugs in the lwIP bug tracker at savannah.<br> 224 * BEFORE submitting, please check if the bug has already been reported!<br> 225 * https://savannah.nongnu.org/bugs/?group=lwip 226 */ 227 228 /** 229 * @page zerocopyrx Zero-copy RX 230 * The following code is an example for zero-copy RX ethernet driver: 231 * @include ZeroCopyRx.c 232 */ 233 234 /** 235 * @defgroup lwip_nosys Mainloop mode ("NO_SYS") 236 * @ingroup lwip 237 * Use this mode if you do not run an OS on your system. \#define NO_SYS to 1. 238 * Feed incoming packets to netif->input(pbuf, netif) function from mainloop, 239 * *not* *from* *interrupt* *context*. You can allocate a @ref pbuf in interrupt 240 * context and put them into a queue which is processed from mainloop.<br> 241 * Call sys_check_timeouts() periodically in the mainloop.<br> 242 * Porting: implement all functions in @ref sys_time, @ref sys_prot and 243 * @ref compiler_abstraction.<br> 244 * You can only use @ref callbackstyle_api in this mode.<br> 245 * Sample code: 246 * @include NO_SYS_SampleCode.c 247 */ 248 249 /** 250 * @defgroup lwip_os OS mode (TCPIP thread) 251 * @ingroup lwip 252 * Use this mode if you run an OS on your system. It is recommended to 253 * use an RTOS that correctly handles priority inversion and 254 * to use @ref LWIP_TCPIP_CORE_LOCKING.<br> 255 * Porting: implement all functions in @ref sys_layer.<br> 256 * You can use @ref callbackstyle_api together with @ref tcpip_callback, 257 * and all @ref sequential_api. 258 */ 259 260 /** 261 * @page sys_init System initialization 262 A truly complete and generic sequence for initializing the lwIP stack 263 cannot be given because it depends on additional initializations for 264 your runtime environment (e.g. timers). 265 266 We can give you some idea on how to proceed when using the raw API. 267 We assume a configuration using a single Ethernet netif and the 268 UDP and TCP transport layers, IPv4 and the DHCP client. 269 270 Call these functions in the order of appearance: 271 272 - lwip_init(): Initialize the lwIP stack and all of its subsystems. 273 274 - netif_add(struct netif *netif, ...): 275 Adds your network interface to the netif_list. Allocate a struct 276 netif and pass a pointer to this structure as the first argument. 277 Give pointers to cleared ip_addr structures when using DHCP, 278 or fill them with sane numbers otherwise. The state pointer may be NULL. 279 280 The init function pointer must point to a initialization function for 281 your Ethernet netif interface. The following code illustrates its use. 282 283 @code{.c} 284 err_t netif_if_init(struct netif *netif) 285 { 286 u8_t i; 287 288 for (i = 0; i < ETHARP_HWADDR_LEN; i++) { 289 netif->hwaddr[i] = some_eth_addr[i]; 290 } 291 init_my_eth_device(); 292 return ERR_OK; 293 } 294 @endcode 295 296 For Ethernet drivers, the input function pointer must point to the lwIP 297 function ethernet_input() declared in "netif/etharp.h". Other drivers 298 must use ip_input() declared in "lwip/ip.h". 299 300 - netif_set_default(struct netif *netif) 301 Registers the default network interface. 302 303 - netif_set_link_up(struct netif *netif) 304 This is the hardware link state; e.g. whether cable is plugged for wired 305 Ethernet interface. This function must be called even if you don't know 306 the current state. Having link up and link down events is optional but 307 DHCP and IPv6 discover benefit well from those events. 308 309 - netif_set_up(struct netif *netif) 310 This is the administrative (= software) state of the netif, when the 311 netif is fully configured this function must be called. 312 313 - dhcp_start(struct netif *netif) 314 Creates a new DHCP client for this interface on the first call. 315 You can peek in the netif->dhcp struct for the actual DHCP status. 316 317 - sys_check_timeouts() 318 When the system is running, you have to periodically call 319 sys_check_timeouts() which will handle all timers for all protocols in 320 the stack; add this to your main loop or equivalent. 321 */ 322 323 /** 324 * @page multithreading Multithreading 325 * lwIP started targeting single-threaded environments. When adding multi- 326 * threading support, instead of making the core thread-safe, another 327 * approach was chosen: there is one main thread running the lwIP core 328 * (also known as the "tcpip_thread"). When running in a multithreaded 329 * environment, raw API functions MUST only be called from the core thread 330 * since raw API functions are not protected from concurrent access (aside 331 * from pbuf- and memory management functions). Application threads using 332 * the sequential- or socket API communicate with this main thread through 333 * message passing. 334 * 335 * As such, the list of functions that may be called from 336 * other threads or an ISR is very limited! Only functions 337 * from these API header files are thread-safe: 338 * - api.h 339 * - netbuf.h 340 * - netdb.h 341 * - netifapi.h 342 * - pppapi.h 343 * - sockets.h 344 * - sys.h 345 * 346 * Additionally, memory (de-)allocation functions may be 347 * called from multiple threads (not ISR!) with NO_SYS=0 348 * since they are protected by @ref SYS_LIGHTWEIGHT_PROT and/or 349 * semaphores. 350 * 351 * Netconn or Socket API functions are thread safe against the 352 * core thread but they are not reentrant at the control block 353 * granularity level. That is, a UDP or TCP control block must 354 * not be shared among multiple threads without proper locking. 355 * 356 * If @ref SYS_LIGHTWEIGHT_PROT is set to 1 and 357 * @ref LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT is set to 1, 358 * pbuf_free() may also be called from another thread or 359 * an ISR (since only then, mem_free - for PBUF_RAM - may 360 * be called from an ISR: otherwise, the HEAP is only 361 * protected by semaphores). 362 * 363 * How to get threading done right 364 * ------------------------------- 365 * 366 * It is strongly recommended to implement the LWIP_ASSERT_CORE_LOCKED() 367 * macro in an application that uses multithreading. lwIP code has 368 * several places where a check for a correct thread context is 369 * implemented which greatly helps the user to get threading done right. 370 * See the example sys_arch.c files in unix and Win32 port 371 * in the lwIP/contrib subdirectory. 372 * 373 * In short: Copy the functions sys_mark_tcpip_thread() and 374 * sys_check_core_locking() to your port and modify them to work with your OS. 375 * Then let @ref LWIP_ASSERT_CORE_LOCKED() and @ref LWIP_MARK_TCPIP_THREAD() 376 * point to these functions. 377 * 378 * If you use @ref LWIP_TCPIP_CORE_LOCKING, you also need to copy and adapt 379 * the functions sys_lock_tcpip_core() and sys_unlock_tcpip_core(). 380 * Let @ref LOCK_TCPIP_CORE() and @ref UNLOCK_TCPIP_CORE() point 381 * to these functions. 382 */ 383 384 /** 385 * @page optimization Optimization hints 386 The first thing you want to optimize is the lwip_standard_checksum() 387 routine from src/core/inet.c. You can override this standard 388 function with the \#define LWIP_CHKSUM your_checksum_routine(). 389 390 There are C examples given in inet.c or you might want to 391 craft an assembly function for this. RFC1071 is a good 392 introduction to this subject. 393 394 Other significant improvements can be made by supplying 395 assembly or inline replacements for htons() and htonl() 396 if you're using a little-endian architecture. 397 \#define lwip_htons(x) your_htons() 398 \#define lwip_htonl(x) your_htonl() 399 If you \#define them to htons() and htonl(), you should 400 \#define LWIP_DONT_PROVIDE_BYTEORDER_FUNCTIONS to prevent lwIP from 401 defining htonx / ntohx compatibility macros. 402 403 Check your network interface driver if it reads at 404 a higher speed than the maximum wire-speed. If the 405 hardware isn't serviced frequently and fast enough 406 buffer overflows are likely to occur. 407 408 E.g. when using the cs8900 driver, call cs8900if_service(ethif) 409 as frequently as possible. When using an RTOS let the cs8900 interrupt 410 wake a high priority task that services your driver using a binary 411 semaphore or event flag. Some drivers might allow additional tuning 412 to match your application and network. 413 414 For a production release it is recommended to set LWIP_STATS to 0. 415 Note that speed performance isn't influenced much by simply setting 416 high values to the memory options. 417 */ 418