[lwip-users] lwIP 2.2.0 released

lwIP 2.2.0 is now available from the lwIP download area on savannah [1] or via git (using the STABLE-2_2_0_RELEASE tag) or via this gitweb link: https://git.savannah.nongnu.org/cgit/lwip.git/snapshot/lwip-STABLE-2_2_0_RELEASE.tar.gz There have been some bugs fixed, and some new features were

Re: [lwip-users] Get overall memory usage of LWIP

Am 17.01.2023 um 19:41 schrieb Artem Moroz: My lwipopts.h file attached On Tue, Jan 17, 2023 at 8:40 PM Artem Moroz mailto:artem.mo...@gmail.com>> wrote: Hi everybody! I have some issues with memory management on my device. I want to know which parts of LWIP allocate how many

Re: [lwip-users] [OT] Sync local time to NTP

Am 30.12.2022 um 17:10 schrieb Giuseppe Modugno: The typical scenario of lwip is an embedded platform. When a wall clock is needed and the device is network connected, NTP is usually used to retrieve automatically the correct time at startup and stay in sync with an accurate reference (in other

Re: [lwip-users] Core locking with NO_SYS

Am 30.12.2022 um 20:36 schrieb Christoph M. Wintersteiger: I’m getting some mixed signals about core locking and I wonder whether someone could clarify this. The documentation for LWIP_ASSERT_CORE_LOCKED

Re: [lwip-users] Memory leak due to synthesized DDoS

Am 26.10.2022 um 03:46 schrieb Stephen Cowell: My product is a modbus TCPIP board, using the Atmel SAM4E16E based off of the SAM4E-EK.  It is using LWiP 1.4.1 with pbuf.c and pbuf.h from version 2.1.3.  I know... cringe... but I did this recently, during troubleshooting... helped some, see

Re: [lwip-users] Raw TCP, intermittent long delays in accept after after close

Am 20.10.2022 um 20:22 schrieb Geoff Simmons: [..] When the server is ready to close, it calls tcp_close(); if tcp_close() does not return ERR_OK, it calls tcp_abort(). If it was tcp_abort(), then tcp_arg and the tcp_poll and tcp_err callbacks are retained. tcp_poll or tcp_err then initiate

Re: [lwip-users] Raw TCP, intermittent long delays in accept after after close

Sorry, nothing comes to mind except for maybe you don't close your TCP pcbs correctly. Normally, pcbs in time-wait should just be reused. If you experience you need some kind of delay, maybe your pcbs are stuck in a state != time-wait? Regards, Simon Am 04.10.2022 um 19:16 schrieb Geoff

Re: [lwip-users] LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT

Am 11.10.2022 um 17:11 schrieb Giuseppe Modugno: Another thing I can't understand is why the code around LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT is needed if: * NO_SYS=1 * MEM_USE_POOLS=0 * MEM_LIBC_MALLOC=0 * SYS_LIGHTWEIGHT_PROT=1 * sys_arch_protect() simply disables interrupts In

Re: [lwip-users] sys_arch_mbox_fetch() implementation for FreeRTOS

Am 21.06.2022 um 12:37 schrieb massimiliano cialdi via lwip-users: hello, the setsockopt(SO_RCVTIMEO) POSIX call contemplates the possibility of imposing 0 as the 'timeout' parameter, and in that case that socket becomes non-blocking (See, for example,

Re: [lwip-users] sys_timeout() handler never being triggered in mqtt.c

Am 19.06.2022 um 22:05 schrieb inceljoe via lwip-users: Good day everybody, I was trying to use the mqtt functionality which is included in LwIP at LwIP/src/apps/mqtt. I am using LwIP alongside FreeRTOS on a STM32 microcontroller. The MQTT server requires the client to send a ping packet every

Re: [lwip-users] sys_arch_mbox_fetch() implementation for FreeRTOS

Am 20.06.2022 um 11:22 schrieb massimiliano cialdi via lwip-users: hello, I am using lwip 2.1.3 and contrib 2.1.0. in the ports/freertos/sys_arch.c file there is the sys_arch_mbox_fetch() function, in which there is the timeout_ms parameter. Given the name I expect the sys_arch_mbox_fetch()

Re: [lwip-users] using LWIP_PBUF_CUSTOM_DATA together with socket api

Am 19.02.2022 um 21:50 schrieb Massimiliano Cialdi: On Sat, Feb 19, 2022 at 9:38 PM goldsi...@gmx.de wrote: The easiest way probably might be to implement a socket read function that returns netbufs instead of the standard socket read function. But that's not implemented yet. Alternatively I

Re: [lwip-users] using LWIP_PBUF_CUSTOM_DATA together with socket api

Am 19.02.2022 um 20:12 schrieb Massimiliano Cialdi: I'm trying to port a project to lwip. This project uses BSD sockets calls, so first, I used lwip's socket APIs. The project I'm trying to port has to deal with packet timestamping, that's why I used LWIP_PBUF_CUSTOM_DATA as explained here

Re: [lwip-users] tcp_sent() callback: Called once per sent packet or for multiple packets at once?

Am 03.02.2022 um 15:51 schrieb Matthias Paul: Hello all, I'm using lwip 2.1.2 in non-OS / non-threaded mode (main loop mode) with raw API to send/receive TCP packets. When sending packets with tcp_write() I'd like to use zero copy mechanism. Therefore I need to keep the pbuf objects until the

Re: [lwip-users] lwip_cyclic_timer() repeatedly calling malloc/free

Am 01.02.2022 um 15:39 schrieb R. Diez via lwip-users: Hi all: I have a few embedded bare-metal applications that use lwIP. The microcontrollers tend to have limited SRAM, but it is usually enough to use malloc() with care for non-critical tasks. I guess I could investigate about lwIP memory

Re: [lwip-users] netconn_connect returns OK when connection refused?

Am 21.01.2022 um 15:37 schrieb Grant Edwards: On 2022-01-20, Grant Edwards wrote: I'm running into a problem where netconn_connect always returns OK immediately, even when the connection was refused by the server (it replies to the SYN with a RST). Subsequent attempts to write to the

Re: [lwip-users] netconn_connect returns OK when connection refused?

Am 20.01.2022 um 17:55 schrieb Grant Edwards: I'm running into a problem where netconn_connect always returns OK immediately, even when the connection was refused by the server (it replies to the SYN with a RST). Subsequent attempts to write to the connection return -14 (ERR_RST) or -11

Re: [lwip-users] Bridge Port with DHCP

Am 13.12.2021 um 12:29 schrieb Shaofeng Cen: Please help me to understand why that is a problem. [..] I don’t know if you can understand what I said. My English is not so good. Sorry, I still don't really get it. You say a frame is being sent to the bridge (tcpip_input) that you want to get

Re: [lwip-users] Bridge Port with DHCP

Am 13.12.2021 um 09:15 schrieb Shaofeng Cen: > Thanks for your reply! > > I just wonder that how could I use lwip bridge to forward network frames to different destinations. That should just work. I'm not sure I understand the question. > > For example, a vm using bridge network running on a

Re: [lwip-users] Bridge Port with DHCP

Am 13.12.2021 um 07:36 schrieb sjtu: Hi I am trying to use lwip bridge to replace vswitch which is implemented by myself. And I follow the usage here http://www.nongnu.org/lwip/2_1_x/group__bridgeif.html to use lwip bridge. Now I just add one port to the bridge, I use port_netif->input() func

Re: [lwip-users] LWIP Git different branches

Am 25.11.2021 um 17:41 schrieb Ali Naseri: Hello, I am using LWIP in a project to implement a ModbusTCP interface. Now I see that there are 2 branches in GIT, namely the master branch and the STABLE branch. Now how do these branches relate to each other in the further development and

Re: [lwip-users] Support for raw Ethernet packets?

Am 25.11.2021 um 17:02 schrieb Grant Edwards: On 2021-11-24, goldsi...@gmx.de wrote: Am 24.11.2021 um 16:33 schrieb Grant Edwards: On 2021-11-24, Simon Küppers wrote: If I understand you correctly, you could also use LWIP_HOOK_UNKNOWN_ETH_PROTOCOL provided by LWIP, so you do not need

Re: [lwip-users] Support for raw Ethernet packets?

Am 24.11.2021 um 16:33 schrieb Grant Edwards: On 2021-11-24, Simon Küppers wrote: If I understand you correctly, you could also use LWIP_HOOK_UNKNOWN_ETH_PROTOCOL provided by LWIP, so you do not need to implement separate receive queues. That's interesting — it would allow you to receive

Re: [lwip-users] Support for raw Ethernet packets?

Am 22.11.2021 um 18:55 schrieb Grant Edwards: Does lwIP support applications that need to send/receive raw Ethernet packets? It looks like lwIP's raw "connection" type is only for sending and receiving IP packets. What I'm looking for would the equivalent to the code below on Linux: Python:

Re: [lwip-users] How to set callback for accepted netconn connection?

Am 22.11.2021 um 15:21 schrieb Grant Edwards: On 2021-11-22, goldsi...@gmx.de wrote: Am 19.11.2021 um 22:55 schrieb Grant Edwards: After accepting a tcp connection with netconn_accept(listenconn, ), how does one set the callback function for newconn? The callback gets copied from

Re: [lwip-users] How to set callback for accepted netconn connection?

Am 19.11.2021 um 22:55 schrieb Grant Edwards: After accepting a tcp connection with netconn_accept(listenconn, ), how does one set the callback function for newconn? The callback gets copied from the listening connection. While it would probably not be a big problem to change the

Re: [lwip-users] Handle multiple connections using netconn API?

Am 19.11.2021 um 17:38 schrieb Grant Edwards: For the past few days, I've been trying to figure out the netconn API equivalent for select/poll, and I haven't been able to come up with anything. How does a single server thread handle multiple TCP or UDP "connections" using the netconn API? If

Re: [lwip-users] Are recv/send/write reentrant if LWIP_NETCONN_FULLDUPLEX enabled?

Am 17.11.2021 um 18:16 schrieb Grant Edwards: My (newly generated 2.1.3) documentation says that LWIP_NETCONN_FULLDUPLEX "allows reading from one thread, writing from a 2nd thread and closing from a 3rd thread". [And the "really alpha" statement is indeed gone.] I assume that does not imply

Re: [lwip-users] Is netconn/socket fullduplex still "really alpha"?

Am 16.11.2021 um 19:55 schrieb Simon Goldschmidt: On 16.11.2021 19:44, Grant Edwards wrote: On 2021-11-16, Simon Goldschmidt wrote: On 16.11.2021 18:47, Grant Edwards wrote: I've been reading up on netconn/sockets and thread-safety. At

Re: [lwip-users] Requirement that sys_thread_t is integer (or pointer)?

Am 15.11.2021 um 18:03 schrieb Grant Edwards: Is it required that sys_thread_t be a pointer or integer type? The documentation doesn't state that. The example implementation at https://lwip.fandom.com/wiki/Porting_for_an_OS#Threads shows it as a struct, and in the freeRTOS port it's a struct.

Re: [lwip-users] Are sys_arch_protect/unprotect required to nest?

Am 15.11.2021 um 15:53 schrieb Grant Edwards: On 2021-11-15, Ajay Bhargav via lwip-users wrote: sys_arch_protect() and sys_arch_unprotect() is always called in pairs with call order maintained. So the requirement stated in the documentation that SYS_ARCH_UNPROTECT Perform a "fast" set

Re: [lwip-users] Can sys_arch.c functions return ERR_* codes?

Am 12.11.2021 um 16:24 schrieb Grant Edwards: Are the various sys_arch.c functions allowed to return error codes other than those specifically listed in the documentation? For many of them, only 0 and one other value (e.g. SYS_ARCH_TIMEOUT or ERR_MEM) are documented as return values. The

Re: [lwip-users] Question about sys_arch.c *_free() vs. *_~set_invalid()

Am 11.11.2021 um 22:38 schrieb Grant Edwards: On 2021-11-11, Grant Edwards wrote: [Sorry for all of the porting questions, but the sys_arch.c file I'm working with just doesn't seem to make sense.] I don't understand how *_free() and *_set_invalid() are supposed to interact. In the code

Re: [lwip-users] Wait queue order for mutex, semaphore, mailbox?

Am 11.11.2021 um 21:46 schrieb Grant Edwards: On 2021-11-11, goldsi...@gmx.de wrote: Am 11.11.2021 um 17:36 schrieb Grant Edwards: What should the wait queue order be for lwIP mailboxes, mutexes, and semaphores? The port I'm trying to fix-up and get running is configuring all for FIFO wait

Re: [lwip-users] Wait queue order for mutex, semaphore, mailbox?

Am 11.11.2021 um 17:36 schrieb Grant Edwards: What should the wait queue order be for lwIP mailboxes, mutexes, and semaphores? The port I'm trying to fix-up and get running is configuring all for FIFO wait queues. I'm not sure I understand your question. Do you mean 'if multiple threads are

Re: [lwip-users] When and how often are mtx/sem/mox new() and free() called?

Am 10.11.2021 um 22:45 schrieb Grant Edwards: Another porting question, I'm afraid. In deciding how to implement new/free operations for mailboxes, semaphores, and mutexes, it would be helpful if I had some idea of when and how often they are called. Are execution times for these functions

Re: [lwip-users] Do functions like sys_mbox_invalid() need to be thread safe?

Am 10.11.2021 um 22:34 schrieb Grant Edwards: [..] I don't quite understand: what does "points are safe" mean? I mean for one object, lock/unlock, post/fetch or signal/wait can be called by multiple threads simultaneously, but deallocation is ensured to be called from one thread only, when the

Re: [lwip-users] Do functions like sys_mbox_invalid() need to be thread safe?

Am 10.11.2021 um 22:04 schrieb Grant Edwards: On 2021-11-10, goldsi...@gmx.de wrote: Am 10.11.2021 um 20:43 schrieb Grant Edwards: I'm workikng on a port done by somebody else, and they seem to have assumed that functions like sys_mbox_set_invalid() don't need to be thread-safe

Re: [lwip-users] Do functions like sys_mbox_invalid() need to be thread safe?

Am 10.11.2021 um 20:43 schrieb Grant Edwards: I'm workikng on a port done by somebody else, and they seem to have assumed that functions like sys_mbox_set_invalid() don't need to be thread-safe. But, they did add mutexes to make sure that some other functions like like sys_mbox_free() and

Re: [lwip-users] Where are sys_arch.txt and rawapi.txt?

Am 03.11.2021 um 18:15 schrieb Grant Edwards: Where do I find the sys_arch.txt and rawapi.txt files that are listed and described in doc/FILES? Their content got moved to doxygen documentation back in 2017 which can be found here: http://www.nongnu.org/lwip/ However, the doc/FILES file has

[lwip-users] lwIP 2.1.3 released

lwIP 2.1.3 is now available from the lwIP download area on savannah [1] or via git (using the STABLE-2_1_3_RELEASE tag). This is again a bugfix-only release on the 2.1.x branch fixing numerous smaller bugs. For a changelog, see the git log here:

Re: [lwip-users] LOCK/UNLOCK TCIP_CORE

Am 19.10.2021 um 13:25 schrieb André Lenoir: > I have an assertion “Function called without core lock failed” at line > 602 in LwIP/system/OS/sys_arch. > > Apparently this occur on calls from > ethernet_input (…) > tcpip_timeouts_mbox_fetch(..) > sys_timeouts_sleeptime(..) > > What could explain

Re: [lwip-users] A question about running IPv4 and IPv6 on one ENET port at the same time.

Am 09.10.2021 um 10:56 schrieb Jia Guo: > Hi, LWIP experts: > > Does LWIP support to run IPv4 and IPv6 on one ENET port at the same time? > > One I can run IPv4 or IPv6 on one ENET port, but when I try to run IPv4 > and IPv6 at the same time, failed. There should be no problem running IPv4 and

Re: [lwip-users] LWIP - mbedtls -altcp IPv4 length exceeds packet length

Am 04.10.2021 um 12:54 schrieb Duygu D.: > Hello, > I found the problem where is; > > low_level_output function was in below when I get Ipv4 error: > > https://paste.ofcode.org/3afkM3cHbZTMmX7rLQuyznX > > > I need to change pbuf with mpbuf before

Re: [lwip-users] LWIP - mbedtls -altcp IPv4 length exceeds packet length

Am 01.10.2021 um 16:31 schrieb Duygu D.: > Hello, > After your comment I checked p->tot_len in low_level_output function and > I get the 590 value but p->len = 136 byte.  > How can I solve this problem? You have to iterate the pbuf chain and ensure to send all parts in one packet. See the win32

Re: [lwip-users] LWIP - mbedtls -altcp IPv4 length exceeds packet length

Am 01.10.2021 um 13:40 schrieb Duygu D.: > [..] > When I checked the low_level_output functions I get sending data bytes > 150 byte but Ipv4 length shows us 576 byte, opt.h file set as default > but if I changed TCP_MSS as a 250 byte so I can send 136 byte and Ipv4 > packet lenght shows me 136.

Re: [lwip-users] Can't build "Working example" from BUILDING

Am 30.09.2021 um 22:13 schrieb Grant Edwards: > On 2021-09-30, goldsi...@gmx.de wrote: >>> >>>> The savannah link you are referring to contains the docs for the >>>> latests git master branch sources. That's simply not applicable to >>>> the 2.1.

Re: [lwip-users] Can't build "Working example" from BUILDING

Am 30.09.2021 um 21:04 schrieb Grant Edwards: > On 2021-09-30, goldsi...@gmx.de wrote: > >> It's not out of date: it is more recent than what you are trying to build. >> >> 2.1.3. is a bugfix release for an older version, where 'contrib' has >> been in a separa

Re: [lwip-users] Can't build "Working example" from BUILDING

Am 30.09.2021 um 17:11 schrieb Grant Edwards: > On 2021-09-29, Grant Edwards wrote:0 > >> I'm trying to get started porting lwIP to an RTOS. Having never >> worked with lwip before, I thought I would first just build >> 2_1_3_RC1 for Linux. I'm following the directions in BUILDING: > [..] > I've

Re: [lwip-users] Behavior of lwip_getaddrinfo(NULL, 1234, AI_PASSIVE) in dual-stack environment

Am 27.09.2021 um 08:33 schrieb Simon Küppers: > Thanks for your quick response! Good to know, that there will be a 2.2.0 > release in the foreseeable future. > > I will keep it in mind and see if I can whip something up. Should I open > an issue in the bug-tracker in the meantime? Yes please.

Re: [lwip-users] Behavior of lwip_getaddrinfo(NULL, 1234, AI_PASSIVE) in dual-stack environment

Am 25.09.2021 um 12:54 schrieb Simon Küppers: > [..] > What do you think? I see there is currently a new release-candidate > open. Any chance to get something like this included? I could probably > be persuaded into providing code if there is a chance. I think getaddrinfo as a standard function

Re: [lwip-users] LWIP slow web server only with Windows OS request

Am 24.09.2021 um 13:28 schrieb Marco Giammarini: > I enabled lwip_stat and print the data every 10 seconds. > The result is: > [..] You have TCP memerr and HEAP err counters != 0, which indicates you are running out of memory at some point. That might be due to parallel HTPP connections but I'm

Re: [lwip-users] Browser finishes every HTTP GET request with a ACK RST, why ?

Am 22.09.2021 um 08:52 schrieb Info: > Does nobody have the time to give me some advise where the problem could > be ? Sorry, I don't have an idea what's wrong here. Regards, Simon > > At least to understand the main problem I need some help. > In the Wireshark capture file at line number 245

Re: [lwip-users] LWIP slow web server only with Windows OS request

e is the same (3/4 seconds to obtain the webpage). > > Regards, > Marco > > > > >> Il giorno 20 set 2021, alle ore 12:30, Marco Giammarini >> ha scritto: >> >> Sorry, you are right. This acquisition are wrong. I’ll capture new ones. >> >> Regar

Re: [lwip-users] Improving UDP responses.

Am 21.09.2021 um 14:59 schrieb Luciano Moretti: > I've got an STM32F7 (SPL, not HAL) based project using LwIP RAW. We've > got it working fairly well, but it seems to handle 6 UDP packets very > quickly and then start dropping packets. I thought it was because of > the MEMP_NUM_UDP_PCB which was

Re: [lwip-users] LWIP slow web server only with Windows OS request

Am 20.09.2021 um 11:54 schrieb goldsi...@gmx.de: > Am 20.09.2021 um 11:23 schrieb Marco Giammarini: >> In attach you can find two trace captured with Wireshark. One with Windows, >> and one with OSX. > > There are multiple streams in there. Please explain what we're seeing

Re: [lwip-users] LWIP slow web server only with Windows OS request

Am 20.09.2021 um 11:23 schrieb Marco Giammarini: > In attach you can find two trace captured with Wireshark. One with Windows, > and one with OSX. There are multiple streams in there. Please explain what we're seeing and where you think the problem is. Regards, Simon

Re: [lwip-users] LWIP slow web server only with Windows OS request

EN 3 >> >> #DEFINE MEMP_NUM_TCP_SEG40 >> >> #DEFINE PBUF_POOL_SIZE 15 >> >> #DEFINE TCP_MSS (1500 - 40) >> >> #DEFINE TCP_SND_BUF (3*TCP_MSS) >> >> #DEFINE TCP_SND_QUEUELEN(6 * TCP_SND_BUF)/TCP_

Re: [lwip-users] LWIP slow web server only with Windows OS request

Am 15.09.2021 um 08:55 schrieb Marco Giammarini: > Dear All,  > I’m studying this problem more in-depth (with Wireshark), and I found > that sometimes Windows reply with ACK after 40ms at every packet. In > this case, with a file of 800kB, a packet of 1460B, we have more or less > 500 packets,

Re: [lwip-users] Issue with SO_BINDTODEVICE

Am 14.09.2021 um 04:30 schrieb Axel Lin: > Oliver Hitz 於 2020年10月27日 週二 下午7:33寫道： >> >> On 27 Oct 2020, Oliver Hitz wrote: >>> I have found the problem: It seems that lwip_listen() creates a new pcb >>> but doesn't copy the netbuf_idx field from the original pcb. If >> >> Sorry, this should read

Re: [lwip-users] LWIP next stable release

Am 08.09.2021 um 07:16 schrieb Marker, Kuldeep D: > HI, > >   > > I would like to know as when is the next stable release for lwip(2.1.3). > I have gone through lwip git and it says that the new stable release is > out but nothing is mentioned on the main home page. It's not out yet. There is a

Re: [lwip-users] Two lwIP threads working fine on one core but giving error on two separate cores

Am 26.07.2021 um 14:31 schrieb Ibtisam Tariq: > Hi, > > I am creating an app by integrating lwIP with DPDK. I am using > socket-level APIs. For receiving packets from the interface and > processing, there are two threads. > Thread-1: Receiving packets from the interface, call pbuf_alloc to >

[lwip-users] lwIP 2.1.3-rc1

The 1st release candidate version for lwIP 2.1.3 is now available via git (using the STABLE-2_1_3_RC1 tag) or via this gitweb link: https://git.savannah.nongnu.org/cgit/lwip.git/snapshot/lwip-STABLE-2_1_3_RC1.tar.gz The contrib repository remains unchanged, contrib-2.1.0 is still valid. Please

Re: [lwip-users] iperf for lwip 1.4x

Am 19.07.2021 um 02:57 schrieb l...@leif.2y.net: > Hi all > > > Iam looking for a iperf-server, TCP only is ok, that is using RAW api, > and can run on lwip1.4. Are there any such a beast? Just for testing an > implementation of lwip on a embedded board. There is a port to lwIP called 'lwiperf'

Re: [lwip-users] MQTT: Matching data to topic for InPub?

Am 01.07.2021 um 22:28 schrieb Luciano Moretti: > Hi: > Looking at getting MQTT working and while Outgoing Publishes and > Subscription Requests are working I have a question trying to resolve > the Incoming Publishes. The MQTT client uses 2 callbacks to split the > Incoming Publish: The 

Re: [lwip-users] [EXTERNAL] Release Notes

Am 21.06.2021 um 19:59 schrieb Zayzay, Edman G: > The latest stable release for LwIP is 2.1.2 as far as I can tell. So > maybe NXP might be doing something different. The official support seems > to all have 2.1.2 as the current version as of November 2018. >

Re: [lwip-users] httpc_get_file doesn't seem to download entire file?

Am 10.06.2021 um 17:27 schrieb Bas Prins: > Hi Simon, > > Thanks, that's a very likely explanation already. I just added the > pbuf_free(p) but run into an assert occasionally. You might have to check for 'p != NULL' just like in tcp recv callback functions. Regards, Simon

Re: [lwip-users] httpc_get_file doesn't seem to download entire file?

Am 09.06.2021 um 12:42 schrieb Bas Prins: > Hi > > I am having a hard time understanding the http_client.h interface.  > > My setup: > - freertos latest version > - lwip 2.1.2 (over pppos) > - the only tasks running are lwip related (tcpip thread (task prio=2 + > rx thread (task prio=2). > -

Re: [lwip-users] lwip-users Digest, Vol 214, Issue 8

Please don't respond to digest mails. If you want to respond to a mail, ensure to reply in the same thread by replying to the specific email, not to the digest mail. Failing to do so will mess up threading view of emails. Thanks, Simon Am 07.06.2021 um 23:23 schrieb Bas Prins: > Dear Rüdiger, >

Re: [lwip-users] Out of memory in PCP_PCB pool after 2^32 milliseconds

Am 31.05.2021 um 08:09 schrieb Adam Baron: > [..] > Timer is increased over maximum sys_now(), which overflows at (2^32)/10. You're right that this is a bug in your port: sys_now() has to be a free running counter overflowing at the 32 bit boundary, not earlier. Regards, Simon

Re: [lwip-users] sock_set_errno semantics in lwip 2.1.2

Am 19.05.2021 um 12:01 schrieb ruediger_as...@t-online.de: > Hi there, we have been using lwip in a FreeRTOS based firmware for many > years now and are upgrading from lwip 1.4.1 to 2.1.2. > >   > > We are using the following (pseudo)code to encapsulate recv() in a C++ > class: > >   > > do > { >  

Re: [lwip-users] WS_send data pointer

Am 04.05.2021 um 10:10 schrieb Jonathan Vervaeke: > Hello, > Using LwIP stack, shipped with the NXP SDK on a imxrt1062 SoM. > in httpsrv_ws_api.c, the WS_send function is defined, which passes a > datapointer (from the context parameter), via a message system > (sys_mbox_post), to the api_queue. >

Re: [lwip-users] Understanding Raw TCP PCB allocations.

Am 26.04.2021 um 21:24 schrieb Luciano Moretti: > Hello, > I'm trying to make sure I understand what's going on. > > Here's my understanding: > > When I create a listening connection: > 1. I pass a PCB to tcp_listen(). The passed PCB gets deallocated and a > new listening PCB is returned. > 2.

Re: [lwip-users] Assertion "pcb->snd_queuelen >= pbuf_clen(next->p)" failed after TCP handshake

Am 21.04.2021 um 13:30 schrieb Tomas Mudrunka: > pcb->snd_queuelen >= pbuf_clen(next->p) This means that the counter of pbufs outstanding to be ACKed is smaller than the actual number of the pbufs we take off the list. I can't tell you why that would happen though. Regards, Simon

Re: [lwip-users] Assertion "pcb->snd_queuelen >= pbuf_clen(next->p)" in tcp_free_acked_segments()

Am 22.04.2021 um 09:53 schrieb Tomas Mudrunka: >>>p = pbuf_alloc(PBUF_RAW,rx_len,PBUF_POOL); >>>pbuf_take(p, rx_buf, rx_len); >>> + LOCK_TCPIP_CORE(); >>>if(netif->input(p, netif) != ERR_OK) { >>> ESP_LOGE(TAG, "Input failed!"); >>> pbuf_free(p); >>>} >>> +

Re: [lwip-users] Assertion "pcb->snd_queuelen >= pbuf_clen(next->p)" in tcp_free_acked_segments()

Am 21.04.2021 um 15:21 schrieb Tomas Mudrunka: > I even tried to lock the TCPIP core like this, but it didn't helped at > all: > > >p = pbuf_alloc(PBUF_RAW,rx_len,PBUF_POOL); >pbuf_take(p, rx_buf, rx_len); > + LOCK_TCPIP_CORE(); >if(netif->input(p, netif) != ERR_OK) { >

Re: [lwip-users] Assertion "pcb->snd_queuelen >= pbuf_clen(next->p)" failed after TCP handshake

Am 21.04.2021 um 10:38 schrieb Tomas Mudrunka: > Hello, > i have written my own netif driver on FreeRTOS+LWIP. > Pings work reliably, TCP handshake works reliably, > but once i start sending data to the established TCP connection it > crashes on this: > > assertion "pcb->snd_queuelen >=

Re: [lwip-users] Recovering from network outage

1 704 752 6513 x1394 > www.invue.com > -----Original Message- > From: lwip-users On > Behalf Of goldsi...@gmx.de > Sent: Tuesday, April 13, 2021 05:17 > To: Mailing list for lwIP users > Subject: Re: [lwip-users] Recovering from network outage > > Am 13.04.2021 um 0

Re: [lwip-users] Recovering from network outage

Am 13.04.2021 um 08:08 schrieb Rod Boyce: > Jeff, > > It sounds like you are using Ethernet this being the case you can detect > link-up and link-down from the Ethernet PHY. > > This means that you can poll the Ethernet PHY for link status and either > take networking down when Phy is disconnected

Re: [lwip-users] Why does enabling Debug fix this tcp_sndbuf()

Am 25.03.2021 um 12:44 schrieb Trampas Stern: > Rather than flushing cache you can create a non-cached section of RAM in > the linker script and put buffers there. But be aware that using non-cached buffers might be slow. While putting the DMA descriptors into uncached memory is a good solution

Re: [lwip-users] Why does enabling Debug fix this tcp_sndbuf()

Am 24.03.2021 um 16:32 schrieb Osborne, David: > Hi All, > >   > > I’m using LwIP + FreeRTOS + Sockets on STM32H7 with external SDRAM and > FLASH (Ethernet buffers are internal).  It works well until the server > has to send a very large message (> 18Kbytes).  One in five attempts > ends in

Re: [lwip-users] LwIP and memory section relocation

Am 19.03.2021 um 16:40 schrieb MÅrîØ Raƒƒin: > Dear All, >     I am using LwIP with FreeRTOS on STM32F7 MCU and I am experimentig > an odd behaviour. First thing that comes to mind when reading "STM32" here: The drivers that come with Cube were known to be buggy, and I don't know if they are

Re: [lwip-users] Sharing TCP port

Am 16.03.2021 um 16:45 schrieb Indan Zupancic: > But I doubt lwIP had in mind anyone wanting to share a listen > port with TCP outgoing connecting sockets on the same port. > It may or may not work by accident, but you may need to tweak > some checks in lwIP's code before it works. > > But again:

Re: [lwip-users] Sharing TCP port

Am 15.03.2021 um 16:15 schrieb Danish Ali: > I would like to be able to have multiple simultaneous TCP links to a > single port (in my case 5060 for SIP). Try to write the same thing for standard sockets. If you know that API, transforming the code to use the netconn API pretty simple. And for

Re: [lwip-users] Sending raw IP packets

ache working, of course, by calling etharp_tmr() at regular intervals. Is that what you're looking for? The RX side might be a bit harder to do though... Regards, Simon > > Thanks again! > > On Mon, Mar 8, 2021 at 11:33 AM goldsi...@gmx.de wrote: >> >> Am 07.03.20

Re: [lwip-users] Sending raw IP packets

Am 07.03.2021 um 12:50 schrieb JonathonS: > Hello, I am attempting to implement an Android VPN service which > provides me raw IP packets on the TUN interface.  What I'd like to do is > simply send the whole IP packet (including IP header) to its > destination.  I know I can parse the IP packet to

Re: [lwip-users] [lwip] Why value of O_NONBLOCK/O_RDONLY/O_WRONLY/O_RDWR in src/include/lwip/sockets.h are not equal to the posix?

Am 05.03.2021 um 04:32 schrieb 唐尧: > *In posix fcntl.h , the definations is:* Which "posix" fcntl.h do you mean? Do you mean Linux instead? Because as far as I'm aware, posix is a standard for source code compatibility, not for binary compatibility. And being like that, it defines the named

Re: [lwip-users] [lwip] Why value of O_NONBLOCK/O_RDONLY/O_WRONLY/O_RDWR in src/include/lwip/sockets.h are not equal to the posix?

Am 05.03.2021 um 06:18 schrieb Ajay Bhargav via lwip-users: > If you’re using a posix style system of any system which already define > O_RDONLY/WRONLY/RDWR then you can include that file in your arch.h or > cc.h probably > >   > > The sockets.h definition is only for the system which does not

Re: [lwip-users] post a question

Am 21.02.2021 um 14:11 schrieb Nada Ali: > Hello LWIP Team, > > I have a project to send a GPS data from my mbed Through a radio system. > > The radio is already connected to a VLAN 10. I was able to communicate > between my mbed and my laptop via the VLAN but my issue that the radio > is seems 

Re: [lwip-users] DHCP not surviving multiple reconnections

Am 16.02.2021 um 15:55 schrieb matt swindell: > Hello, > >   > > I am new to LWIP currently I am using LWIP 2.1.2 with no OS (NO_SYS = 1) > in lwipopts.h. > >   > > My question is about the connection/disconnection from the DHCP server. > Using Wireshark I am able to see the initial DHCP request

Re: [lwip-users] Incorporating lwIP Into VisualGDB Project

Am 12.02.2021 um 09:00 schrieb Curtiss, Robert: > Simon, > > Unfortunately the link that you sent doesn't work, and I can't figure out > what's wrong with it: > > Anyway, even the 2.1.2 release contains the 'priv' folder. And if you > don't want to 'git clone' the master branch, you can also

Re: [lwip-users] Incorporating lwIP Into VisualGDB Project

Am 11.02.2021 um 09:28 schrieb Curtiss, Robert: > Am 10.02.2021 um 21:33 schrieb Goldschmidt, Simon: >> And if you had followed what I wrote, you would have grabbed a copy of >> the 'master' git branch. By downloading the 2.1.2 zip, you downloaded >> older code where the Linux and Windows ports

Re: [lwip-users] Incorporating lwIP Into VisualGDB Project

__ > Robert Curtiss > Control Systems ManagerBalfour Beatty Rail, a division of Balfour Beatty > US > 845-688-1502  rcurt...@balfourbeattyus.com > 205 W Dewey St, Goldsboro, NC 27530 > > > -Original Message- > From: lwip-users > On Behalf O

Re: [lwip-users] Incorporating lwIP Into VisualGDB Project

Am 08.02.2021 um 12:52 schrieb Curtiss, Robert: > Hey Simon, > > Thank you for your response; it got me off to a good start. However, I'm > still fumbling with trying to get a successful build. > > So far, I've included all the files in 'core' and 'netif' directories and > added 'src/include' to

Re: [lwip-users] lwip stack

Am 03.02.2021 um 16:48 schrieb Pınar K: > Hello everyone, > > I am very new to lwip. > I couldn't find previous messages for forum.How can I use lwip stack > instead of linux ip stack? I guess that's because noone ever bother to do this. > Could anybody, please, tell us how to get rid of the 

Re: [lwip-users] Incorporating lwIP Into VisualGDB Project

Am 02.02.2021 um 15:47 schrieb Curtiss, Robert: > [..] > Question: > > What files do I need to incorporate into my project and do they need to > reside in a specific hierarchy of directories, or can they all reside in > my project directory? Just look at Filelists.cmake or Filelists.mk in 'src'.

Re: [lwip-users] Lwip 10Gbit

Am 02.02.2021 um 10:19 schrieb giuseppe di marco: > Dear all, > > I am using LWIP on a Zynq UltraScale+ for a 1 Gigabit UDP connection. I would > use it at 10 Gigabit. Is this speed supported? That largely depends on what you mean by "supported". lwIP itself knows nothing about the actual

Re: [lwip-users] REST API on microcontroller with lwIP

Am 01.02.2021 um 18:14 schrieb Marco Giammarini: > You mean genfiles_example > /genfiles_example.c >

Re: [lwip-users] [lwip-devel] [bug #59966] After several hours of working, need router reset to be able to send mqtt msg bigger than 1460 bytes

t; -Original Message- > From: lwip-users On > Behalf Of goldsi...@gmx.de > Sent: Friday, January 29, 2021 06:39 > To: Mailing list for lwIP users > Cc: Dejan Spasovski > Subject: Re: [lwip-users] [lwip-devel] [bug #59966] After several hours of > working, need router

Re: [lwip-users] [lwip-devel] [bug #59966] After several hours of working, need router reset to be able to send mqtt msg bigger than 1460 bytes

> Dejan Spasovski > > > Senior Embedded Software & Electronics Systems Design Engineer,  > > CEO at eXtremeEmbedded, > > https://www.xembed.com <https://www.xembed.com> > > phone: +389 75 215 449 > > st. Mariovska 3, 20-1/8 > Skopje, Republic of North

  1   2   3   4   5   6   7   8   9   10   >