[lwip-users] lwIP 2.2.0 released

[goldsi...@gmx.de]

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 added (most
notably full ACD support).

Additionally, the contents of the contrib repository has been moved to
the main repository ('contrib' directory on top level) to make things
more consistent, especially with git. The old contrib repository should
not be used any more.

The 2.1.x branch will not be continued, so eventually, all users of
2.1.x might want to upgrade to get bugfixes.

Thanks for all contributions!

Simon

[1] https://savannah.nongnu.org/projects/lwip/

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 bytes. I am using
standard C memory allocation functions: malloc, free.


With LWIP_STATS enabled, you can always break in your debugger and check
the 'lwip_stats' variable. Under 'mem' and 'memp' you'll see the heap
usage and pool usage. Heap usage is not tracked per allocation source
(so no way to see which part allocates how many bytes), but the memp
part holds allocation counts, which you can multiply by the object size
to get an allocation size sum. This should even work with
MEMP_MEM_MALLOC enabled (like you have).

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 cases, the user can set a time as he wants).

Consider an embedded device without a battery. At startup there's no
notion of current time, so we can start from an epoch (1970, 2020 or
whatever) and consider it the correct time. Another approach is
considering the time not initialized at all.

lwip has a SNTP client implementation that magically calls a function


Absolutely no magic in there: when a response from a server is received,
it is parsed and this callback is called with the time received.


SNTP_SET_SYSTEM_TIME_NTP(s, f) when a response from a SNTP server is
received. Now the question is what to do with s, seconds from 1970 epoch
(ignore fractional part, just to simplify).


This is one level upwards from lwIP. We provide the protocol
implementations, not your system design.



One possibility is to have a system counter clocked at 1s that counts
seconds from 1970. So SNTP_SET_SYSTEM_TIME_NTP() could simply overwrite
the counter value. However this simple approach brings to a counter that
isn't monotonic and continuous. I know the best approach is to slowed
down or accelerate the reference clock of the system counter that tracks
seconds from epoch.

Do you really implement something similar or are you happy with
replacing the counter with the new value reported by NTP?


That totally depends on what you desire for your product (what you use
the timestamp for). For example, if you only use it for logging, it
might be enough to add a line to your log that states the received time
and the delta.

Linux, on the other hand has at least 2 clocks, one "monotinic" clock
(e.g. ticks since boot) and one "wall" clock. Timsync daemons may still
vote to add a syslog line if the received SNTP time differs too much
from what they would expect.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Core locking with NO_SYS

[goldsi...@gmx.de]

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
(https://www.nongnu.org/lwip/2_1_x/group__lwip__opts__lock.html#ga6a30040db307b3459fc11906bd433f75
 

 ) says:

Not in ISR (this should be checked for NO_SYS==1, too!)

 From this I infer that core locking with NO_SYS==1 is possible and
indeed a good idea.

However, when I enable core locking (#define LWIP_TCPIP_CORE_LOCKING 1),
the LOCK_TCPIP_CORE macro is undefined. I figured I’ll just lock it
myself via sys_mutex_lock(_tcpip_core), but it appears that
sys_mutex_lock is defined to do nothing at all (sys.h, #if NO_SYS).

So, has support for core locking + NO_SYS been removed, and the
documentation is lagging behind, or is there a different way to enable this?

(Context: I’m using MQTT and it appears that it has a hard requirement
for core locking…)


No, core locking for NO_SYS==1 has not yet been implemented in a
portable way (because we do not have portability defines for executiong
contexts in that case). The comment simply wants to say that it would be
a good idea to do so.

But you can implement the macros on your own. You could, for example,
implement it by using an atomic instruction to set and/or check which
execution context is active in lwip.

Using that, you could then e.g. mark the main loop being active in lwIP.
Now when an interrupt tries core-locking, it would fail (since by
design, it cannot wait for the main-loop to release the lock).

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 below.

I'm banging it real hard using DaqFactory to create two simultaneous
threads sending modbus requests to the same port/address.  As I do this
I can see the pbuf_pool pbufs being created higher and higher up the
pool... I can debug on the pbuf deallocation and see that the ->next is
NULL, so there is no connection to the rest of the chain.  If I let this
go on for long enough the processor will hard fault.

I had this behavior happen very quickly before I moved from LWiP mem
management to GNU C library malloc()... now it takes a long time to
die.  Also, after I spliced in the pbuf code from the latest-greatest it
did seem to become more robust... but I can still watch the allocated
pbufs climb up the pool, leaving behind orphan pbufs as a memory leak.

I guess my main question is... should LWiP be able to survive this kind
of abuse?  I'm able to hit it with requests about every two
milliseconds... and it takes about an hour before it runs out of
memory.  Would I notice any improvement by completing the port to 2.1.3
(a significant effort)?  Is LWiP tested in this way?  It's worth noting
that DaqFactory is glitching the inputs it receives sometimes... but
Wireshark shows them to be rock solid (when there's not a timeout or
port locked complaint).  Am I abusing it too hard? Thanks for your
time... Steve.


No, I have been stressing lwIP equally or more. There should be no
problem. You may run out of memory, but not get a hard fault.

Most problems like that have come from a buggy port or driver, or from
invalid usage of lwIP regarding threading (and even with NO_SYS, you can
be active in the code from main loop and from interrupts and thus need
to pay attention to the threading requirements!).

Rergards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 finalizing the pcb. Otherwise
(tcp_close() succeeded), the pcb is finalized right away.

The pcb is finalized by setting tcp_arg and all of the callbacks to NULL.


See these comments on tcp_abort:

"The pcb is deallocated"

and

"ATTENTION: When calling this from one of the TCP callbacks, make
sure you always return ERR_ABRT (and never return ERR_ABRT otherwise
or you will risk accessing deallocated memory or memory leaks!"

This might indicate a use-after-free error after your tcp_abort calls?

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 Simmons:

Hello,

I'm a new subscriber, and am working on my first "serious" LWIP project
(meaning more than just a sample). This is an HTTP server for the
Raspberry Pi PicoW, using the raw TCP API, accessed via the Pico C SDK
(in which LWIP is a git submodule):

https://gitlab.com/slimhazard/picow_http

It's going well, except for one problem that has me stumped after trying
to fix it for days. If a client attempts to connect shortly after a
number of connections were closed, then intermittently (not always, but
fairly often), the accept process stalls for a long time -- seems to be
as long as 10 seconds, maybe more.

So I'm hoping that someone on the list can help spot the error.

When this happens, I see sequences like this in debug output:

TCP connection request 40270 -> 80.
tcp_enqueue_flags: queueing 27040:27041 (0x12)
tcp_output_segment: 27040:27040
tcp_slowtmr: processing active pcb
tcp_slowtmr: polling application
tcp_output: nothing to send ()
tcp_slowtmr: processing active pcb
tcp_slowtmr: polling application
tcp_output: nothing to send ()
tcp_output_segment: 27040:27040
tcp_slowtmr: processing active pcb
tcp_slowtmr: polling application
tcp_output: nothing to send ()
tcp_slowtmr: processing active pcb
tcp_slowtmr: polling application
tcp_output: nothing to send ()
tcp_slowtmr: processing active pcb
tcp_slowtmr: polling application
tcp_output: nothing to send ()
tcp_slowtmr: processing active pcb
tcp_output_segment: 27040:27040
tcp_slowtmr: polling application
tcp_output: nothing to send ()
tcp_output_segment: 27040:27040
TCP connection established 40270 -> 80.

The pattern is always:

- "TCP connection request"
- tcp_enqueue_flags with a range of 1 ("queueing n:(n+1)"), always with
the hex value 0x12
- this sequence, repeated many times:
- "tcp_slowtmr: processing active pcb"
- "tcp_slowtmr: polling application"
- "tcp_output: nothing to send ()",

tcp_output_segment with range 0 ("n:n") is interspersed in the repeating
sequence. After the stall comes "TCP connection established", and then
everything proceeds normally. With long timeouts on the client side, all
of the requests succeed, despite the long stall.

All of this happens before the tcp_accept callback is invoked. When the
stalls happen, I see the client side sending SYN retransmissions in
wireshark. I haven't noticed anything else unusual in wireshark (of
course it's easy to overlook something).

I usually see this when repeating a test script that sends a few dozen
requests. There's no stall on the first connection after server startup.
There's also no stall if I wait long enough between sending batches of
requests. But if I run the test script and then start it again shortly
afterward, it can stall for quite a while on the second run.

During a stall, I see MEM TCP_PCB stats showing "used" == "max", i.e.
all tcp_pcbs in the pool are used. I assume that after all connections
are closed following a series of requests, they *should* be in
TIME_WAIT, and then for the next connection, the oldest PCB in TIME_WAIT
gets re-used. I have seen debug tcp debug output saying exactly that.

But I suspect that my application code is not doing everything right
about closing connections. Bearing in mind that there's a lot I don't
know about LWIP, so this hypothesis may be nonsense -- the feeling is
that I have discarded a connection, thinking that is fully closed and
should be in TIME_WAIT; but it isn't. Then on the next client
connection, the PCB thinks it still needs to send something like an ACK
or FIN, and stalls while doing so, accounting for the long sequence
"processing active pcb" and "nothing to send". Eventually (because a
timeout elapses?) the PCB gives up and accept can proceed.

Does (0x12) in the tcp_enqueue_flags debug output refer to a PCB's tcp
flags? If so, then the value is TF_RXCLOSED | TF_ACK_DELAY. Is that
significant? It doesn't "sound right" for a PCB to be used for an
incoming connection.

Some things I've tried to fix the problem, none of which have succeeded:

- Wait until all bytes of a sent response have been ACKed (using the
tcp_sent callback). This may mean that HTTP request pipelining is not
possible. And it hasn't helped.

- Increase MEMP_NUM_TCP_PCB. But it doesn't seem to matter, if there
have been enough requests so that all of them are used (and should be in
TIME_WAIT), then the same thing happens. When I "wait long enough"
between batches of requests, 6 PCBs are enough (I've tried up to 24).

- Increase MEM_SIZE. MEM HEAP stats show very consistently that it never
needs more than 4800 bytes.

- Increase MEMP_NUM_TCP_SEG from 32 to 64. A bit of a desperation 

Re: [lwip-users] LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT

[goldsi...@gmx.de]

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 mem_malloc there's a point where LWIP_MEM_ALLOC_PROTECT is called,
before the "scan through the heap searching for a free block". Why
during the scan, for each loop, UNPROTECT/PROTECT are called? The
comment says /* allow mem_free or mem_trim to run */.

Maybe this is done because the scan could take a long time to finish
(for big and fragmented heap) and having interrupts disabled for so long
time is not good? So the interrupts are enabled and disabled for each
loop to give them opportunity to run?


Exactly:
- Heap allocation takes a mutex as it should not block interrupts while
scanning for memory (takes too long).
- Heap free is fast as it does not need to scan.

Therefore, heap allocation uses double protection: mutex to block
against other allocations, PROTECT/UNPROTECT to protect against
concurrent free.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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,
https://stackoverflow.com/questions/49706883/disable-socket-timeout-via-setsockopt).



Sorry, but stackoverflow is *not* a good source to cite when talking
about POSIX standard.

Instead, I prefer to search opengroup.com and on the 'setsockopt' page
google gives me
(https://pubs.opengroup.org/onlinepubs/95399/functions/setsockopt.html),
I find this in the description of SO_RCVTIMEO:

"The default for this option is zero, which indicates that a receive
operation shall not time out."

BTW, even the stackoverflow page you cited says: "If the timeout is set
to zero (the default) then the operation will never timeout".

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 few
seconds, by reading the code I found out this functionality is
implemented with a sys_timeout() at line 1066 in mqtt.c . This is the
line in particular:
/sys_timeout(MQTT_CYCLIC_TIMER_INTERVAL * 1000, mqtt_cyclic_timer, client);/

But the problem is, that the /mqtt_cyclic_timer /function isn't
triggered at all, not even once. I put a breakpoint into it and it was
never hit.

The tick source given to the /sys_now()/ works fine and increases by one
every millisecond so I have no idea why the sys_timeout() function
doesn't run the handler function even once. Can anyone help me? Thanks
for your time.


Do other timeout handlers get triggered at all? Is your port's timeout
handling working correctly? For that, you either have to use
tcpip_init() to get multithreading running, or call sys_timeouts_check()
yourself when using lwIP in main-loop style.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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() function to be
blocking for a maximum time corresponding to timeout_ms milliseconds.
I see this piece of code, though:

   if (!timeout_ms) {
     /* wait infinite */
     ret = xQueueReceive(mbox->mbx, &(*msg), portMAX_DELAY);
     LWIP_ASSERT("mbox fetch failed", ret == pdTRUE);
   } else {

I wonder why I should wait infinitely if I set the timeout to 0 (so I
want it non-blocking)? is this a bug?


See the documentation of that parameter in sys.h:
@param timeout maximum time (in milliseconds) to wait for a message (0 =
wait forever)

It's a bit unfortunate, but it has been like that since forever (0 =
wait forever). The code uses sys_arch_mbox_tryfetch() when it does not
want to block at all.



In fact, it happens to me occasionally (I have yet to figure out the
conditions) that even though I have the timeout set to 0, re-read with
lwip_getsockopt(SO_RCVTIMEO), the task blocks indefinitely while waiting
for a message in the queue.


That would be odd. Please report a fix if you find one.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 could replace the socket API of the project I'm
porting with the netconn API. The only issue is that such project also
makes use of the `select` API. How can I replace it or implement it
with the netconn API?


Well, there's still an undone task in our tracker to convert the socket
API to just be a "copying" wrapper around the netconn API.
Unfortunately, it's not like that now and select is not available for
netconns, yet.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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
https://savannah.nongnu.org/bugs/?55078
This way I can "enrich" the pbuf structure with metadata fields of my own.

The question is: how do I retrieve my metadata using the socket API?
For example how do I get a read pbuf? Or how do I convert the socket
to a netconn?


Since the socket standard does not know your custom data, you cannot
access it through that API. There's no predefined way to access unknown
data :-)

And I'm sorry to dissapoint you, but there's currently no way to convert
a socket to a netconn, either. It could probably implemented, but you
cannot just use the netconn behind the socket, as the socket itself has
internal state that might get confused when then underlying netconn is
accessed directly.

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.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 buffer
has been sent and acknowledged by the recipient. When acknowledged, my
callback registered by tcp_sent() is called:

static err_t

TCPSERVER_sentCallback(

     void                        * arg,

     struct tcp_pcb                * tcpPcb,

     uint16_t                    length) {

    // remove pbuf which are reported as "sent"
...
}

Is "length" always matching a single pbuf length or could it happen that
TCPSERVER_sentCallback() reports multiple pbuf objects at once?

Also, can I assume, that TCPSERVER_sentCallback() is called in the order
the packets have been sent?


You have to understand the tcp protocol to understand the sent callback:
a host acknowledges the bytes received from a the other side. It is free
to send an ACK for an arbitrary byte count between 1 and the maxiumum
outstanding bytes. But since tcp is a streaming protocol, you'll always
know when to free the next buffer from the from of your list when you
sum up the 'length' parameter of all 'sent' calls.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 options and starting using pools, 
but I am unsure about how much memory to reserve for that purpose. At the 
moment, I am just using malloc for everything with these settings:

#define MEM_LIBC_MALLOC 1
#define MEMP_MEM_MALLOC 1


That's a valid configuration, but not the one most often used, as malloc
is often much slower than our pool allocation.



I often keep an eye on malloc() usage, because it can be a source of problems: 
excessive heap usage, potential memory leaks, performance degradation, memory 
exhaustion due to fragmentation...

I have realised that lwIP allocates and releases memory often even if it has 
nothing to do. This is the call stack:

#2  malloc()
#3  mem_malloc()
#4  do_memp_malloc_pool_fn()
#5  memp_malloc_fn()
#6  sys_timeout_abs()
#7  lwip_cyclic_timer()
#8  sys_check_timeouts()

Routine lwip_cyclic_timer() has the following comment:

"Timer callback function that calls cyclic->handler() and reschedules itself."

I have looked at the lwIP code, and it seems that every time a timer expires, 
it releases its memory, and every time that a timer wants to reschedule itself, 
it allocates memory again.

Is there a way to prevent that? I would have thought that a timer that always 
reschedules itself could just reuse its allocated memory over and over.


That could be implemented, but it's not so far. We're open to patches
doing that though.

However, when using pool allocation, performance is not a real issue
here. And the number of timers used is pretty static. You'll know how
much you need. Even if you allocate a few more, timers aren't the high
memory consuming factor in your system.

I can see that you wouldn't want one full-malloc call per timer though...

Regards,
Simon



This is not just an issue with malloc usage. I think that, even if I switched 
lwIP to memory pools, allocating and releasing memory from some pool so often 
is probably not desirable either, because at the end of the day, it is more or 
less equivalent to malloc/free. I could probably create a separate pool for 
timers with MEMP_SYS_TIMEOUT, but then you would have to know how many timers 
lwIP will be needing, and that can be tricky to predict. In any case, setting 
memory aside only for timers may increase memory waste for those scenarios 
where lwIP may not be actually used much if another communication channel is 
available. Or did I miss some cool trick in lwIP pool management?

Thanks in advance,
rdiez


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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
connection return -14 (ERR_RST) or -11 (ERR_CONN).

Shouldn't netconn_connect() return an error if the connection was
refused?  If the server accepts the conneciton, it seems to work OK.


There's actually another strange netconn_connect() behavior I've
noticed. I have a test app with 4 client threads that repeatedly
connect to a server, exchange data for a few seconds, then disconnect.

The first three threads that call netconn_connect() get error codes
2,3,4 (always in that order).


I'm not sure what you mean here. err_t error codes should be negative.
With "2,3,4", do you mean ERR_BUF, ERR_TIMEOUT, ERR_RTE? That would be
strange.

Regards,
Simon


The fourth thread always connects and
returns OK.  A couple seconds later, the first three connect
OK. Subsequent connects always work.

Obvserving the network traffic for the three "failures" show that the
SYN/SYN-ACK/ACK handshake was completed, then the lwIP side
immediately closed the connection with a FIN.

Any ideas on what would cause that sort of behavior?


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 (ERR_CONN).

Shouldn't netconn_connect() return an error if the connection was
refused?  If the server accepts the conneciton, it seems to work OK.


The only way I would think this could happen is if you are using
nonblocking netconns. Normal blocking netconns should wait for the
remote side to ACK the SYN and only then return ERR_OK.

Regards,
Simon



Here's the relevent code:


   conn = netconn_new(NETCONN_TCP);
   if (!conn)
 {
   printf("conn NULL\n");
   return;
 }
   e = netconn_connect(conn, , 7000);
   if (e != ERR_OK)
 {
   printf("%s[%d] netconn_connect e=%d\n",__func__,exinf,e);
   netconn_delete(conn);
   return;
 }
   printf("connected\n");
   ...
   e = netconn_write_partly(conn, data, dsize, NETCONN_COPY, );
   if (e != ERR_OK)
 printf("%s[%d] netconn_write e=%d\n",__func__,exinf,e);




___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Bridge Port with DHCP

[goldsi...@gmx.de]

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 sent out to ports instead.
Which frame is this? I.e. which DST MAC does it have?

Normally, 'bridgeif_is_local_mac()' should only return 1 for local MAC
addresses of the bridge or its ports (if they have any at all). This is
by design of a (managed) switch. You cannot use a port's MAC address to
get the bridge to send out on a selected port. That's not the way
bridges work, if that's what you're trying?

Are you sure you're looking for a bridge? In the end, this bridge just
mimics a hardware switch.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Bridge Port with DHCP

[goldsi...@gmx.de]

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 host machine.
> In linux, bridge and tap device is needed to create a bridge network
environment, the network frames will be switched to different tap device
by filtering MAC address and notify vm to process these network frames
by virtio-net.
>
> So with lwip, the bridge can help me judge the MAC address, however
every network frame still goes into bridge’s input func (usually
tcpip_input).
> If I use tapif in lwip-contrib, I should netif_add a netif port and
the port’s state should be the ptr of tapif structure. But after I call
bridgeif_add_port, the input func of netif port will be changed to
bridgeif_input or bridge_tcpip_input.
Please help me to understand why that is a problem.

> If I want to attach a tap device to lwip bridge, what should I do?
I'm not sure, I haven't used that combination.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Bridge Port with DHCP

[goldsi...@gmx.de]

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 to submit 
the data.

When I use DHCP to get an IP, the network frame will be forwarded to bridge_netif->input 
func which is reasonable. But when the `tcpip_thread` calls 
`msg->msg.inp.input_fn(msg->msg.inp.p, msg->msg.inp.netif)`, the netif inside is 
`bridge_netif`.
The func call chain is like `ethernet_input` -> `ip4_input`

In `ip4_input`, `ip_data.current_input_netif` will be set to bridge_netif, 
which will be used in `dhcp_recv`.
`dhcp_recv` will call `ip_current_input_netif` to get a netif, and read dhcp 
data from it.
This is the key problem, when I calls `ip4_input`, the 
`ip_data.current_input_netif` will be set to `bridge_netif`, so I cannot use 
port_netif’s dhcp data to get IP.
Now I can assign IP to the bridge_netif, not the port_netif.

How can I assign IP per port by DHCP?


Well, the key concept of a bridge (i.e. compare to Linux) is that you
have an IP per bridge, not per port.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LWIP Git different branches

[goldsi...@gmx.de]

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 debugging of the software?

Are developments in the master branch also transferred to the STABLE
branch and vice versa?

Why are releases not continuously forked from the master branch and the
STABLE branch seemingly developed independently from the master branch,
if you look at the GIT source tree?

Sure it has a simple and logical explanation, but it's not transparent
to me yet.


Originally, there were no branches. The STABLE_2_1_x branch only started
because git has this cool feature called cherry picking, where you can
selectively add some commits from the master branch to that stable
branch, which gives us a very quick possibility to create smaller bugfix
releases even though the master branch is not in a state where we would
release it.

I'm planning on getting the next release based on master, though. That
will probably be the end of the STABLE_2_1_x branch.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 to
implement separate receive queues.


That's interesting — it would allow you to receive arbitrary Ethernet
protocols, but there's no way to send them?


It's an integration for raw lwIP, not for the socket API. Sending raw
packets from raw lwIP is easy: just call netif->linkoutput() with the
pbuf to send on the netif you want to send on (or use ip_route() to get
one).


That would be fine. On the non-Linux systems in the past, it's been
done using non-sockets functions like that.


When using core locking (LOCK_TCPIP_CORE()), you can even use this from
any application thread for TX.




You were previously asking about a linux-ish socket way to do that
though.


It doesn't actually need to be the socket API signature or to use
socket file descriptors.


Well, if this threading model is ok for you, than the hook provided by
Simon should work, yes. You just have to watch out for which packet your
driver actually delivers to lwIP.

However, in situations where I have used other ETH protocols, I also
needed to use a hiegher priority for these packets, so I had to divert
them before passing packets to the tcpip_thread and handle the packets
in a higher priority thread. But for this scenario, there is no help in
the lwIP code available, it was implemented at driver level.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 arbitrary Ethernet
protocols, but there's no way to send them?


It's an integration for raw lwIP, not for the socket API. Sending raw
packets from raw lwIP is easy: just call netif->linkoutput() with the
pbuf to send on the netif you want to send on (or use ip_route() to get
one).

You were previously asking about a linux-ish socket way to do that though.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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:
 import socket
 eth_proto = 0x12345
 s = socket.socket(socket.AF_PACKET, socket.SOCK_RAW, eth_proto)

C:
 #include 
 eth_proto = 0x12345;
 s = socket(AF_PACKET, SOCK_RAW, htons(eth_proto));


Not, this is not implemented yet: while it would probably be easy to add
that, it seemed overkill for the systems using lwIP in the past: every
matching packet needs to be copied (unless noone else is interested in
the pbuf) and sent to another thread. In the past, the answer to request
like this was to add a hook into input processing to check for matching
packets. However, this then runs in the tcpip_thread, not in an
application thread.

That's not to say I would mind accepting a patch that implemented this,
it just hasn't really been requested yet...

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 the listening connection.


I suspected that might be the case, but hadn't been able to find where
that happened in the source code. For some reason I thought it had to
be happening at the netconn layer, but now I see it happens in
api_msg.c::accept_function()


Well, that file *is* one half the netconn layer (the half running in
tcpip_thrad, not in the application threads).

Regards,
Simon




While it would probably not be a big problem to change the
netconn->callback member at that point, it's not currently
implemented.


There's no real need to change it. I assume that if I ignore events on
a netconn instance it can still be used in a normal blocking manner.


However, there would be a race condition: the callback may be called
right after accepting the underlying connection, but before an
application thread has pulled the new connection out of the
listener's acceptmbox. So there might be a time span where the
underlying TCP connection can receive data but you wouldn't have
changed the callback yet.

Being like that, we live with having one callback for all types of
connections in the socket layer.


There's nothing wrong with that, I just couldn't find any information
on how to set up callbacks for netconn server sockets.

--
Grant





___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users




___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 netconn->callback member at
that point, it's not currently implemented.

However, there would be a race condition: the callback may be called
right after accepting the underlying connection, but before an
application thread has pulled the new connection out of the listener's
acceptmbox. So there might be a time span where the underlying TCP
connection can receive data but you wouldn't have changed the callback yet.

Being like that, we live with having one callback for all types of
connections in the socket layer.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 you use a callback to wake the server thread, how do you avoid a
race condition when data arrives just after it has serviced all the
connections but before the server thread blocks?

Handling the recv data in the callback seems like a bad idea, since
that presumably is done in the tcpip thread's context. Handling the
recv data may take a considerable amount of time and needs to be done
at a low priority so that it doesn't interfere with other
time-critical traffic.

Isn't there some way to handle this without switching to the socket
API?


Of course there is a way: "just" implement the same callback + select
behaviour as in the socket API. This is, however, not included in the
lwIP code, you'll have to do that yourself.

In theory, we could probably move the callback/select code from the
socket layer to the netconn layer. However, since noone has requested
this yet, noone worked on this, yet.

Regards,
Simon



One answer is to create a server thread for each new connection, and
then use blocking recv calls. But, that's not possible in my RTOS:
threads can't be created dynamically. They have to be declared
statically at compile time. [Yes, that's a pain.]

In my system sys_thread_new() doesn't actually "create" a thread. It
searches the static table of threads and starts the thread with a
matching entry point.

Thanks...

--
Grant


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users




___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 that recv/send/write are renntrant such
that two threads could write to a socket/netconn at the same time? Two
sockets reading at the same time is less common, but would be another
example.

This situation doesn't really make much sense for TCP, but I have seen
applications where it is done for UDP and raw Ethernet.


I'd have to re-check the sources, but it should not be a problem for UDP
and raw I guess (as long as CORE_LOCKING is enabled): the problems
mainly come from TCP writes that can't be executed in one batch (so
you'll have to wait for more window or buffers being available). UDP TX
is lock, send, unlock, so that should work. And if it doesn't, it should
be easy to fix.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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
https://www.nongnu.org/lwip/2_1_x/group__lwip__opts__netconn.html
it says this about the "fullduplex" option:

   "ATTENTION: This is currently really alpha!"

Is that accurate?


No, that comment is outdated and should be deleted by now.


Thanks, that's good news. :)

On that same page it says that for the fullduplex option to work...

 sys_mbox_free() has to unblock receive tasks waiting on
 recvmbox/acceptmbox and prevent a task pending on this during/after
 deletion

Is that really required? I can't see how the freeRTOS port does that,
and AFAICT from reading freeRTOS docs and info, deleting a queue that
has a non-empty wait list is not allowed/undefined.

>From what I've gleaned from the bugtracker, that mbox_free() behavior
might not be needed because a "closing" message is now sent through
the mailbox and the mailbox is not freed until later?


Yeah, well, that comment is outdated as well. Turned out that nearly no
OS supports this, so it got implemented in a different way.

Sorry for all the outdated comments.


I just noticed that the new 2.1.3 release already had those comments
fixed (of course they also have been fixed on the master branch) some
time ago.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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.

But the test code assumes it's a pointer or integer type:

430  static void
431  sockets_stresstest_conn_client(void *arg)
432  {
...
456if (LWIP_RAND() & 1) {
457  sys_thread_t t;
...
463  t = sys_thread_new("sockets_stresstest_conn_client_r", 
sockets_stresstest_conn_client_r, data, 0, 0);
464  LWIP_ASSERT("thread != NULL", t != 0);


That should probably be changed to use 'sys_thread_valid()' (which does
not exist yet). The ' != 0' test is clearly not portable: any type
should work.

Regards,
Simon


...
466}

The expression 't != 0' at line 464 is legal only if sys_thread_t is a
pointer or integer type.




___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 of the protection level to "lev".

is incorrect and the parameter passed to sys_arch_unprotect() may be
ignored.


No and yes: it's not incorrect as the lwIP source calls it that way.
However, for some systems it's just easier to write 'lev' to some
register instead of enabling interrupts or something.

This whole macro set started out a very long time ago and has been
changed over time. If I remember correctly, at some point someone came
to the conclusion that nesting theses locks is not a good idea since it
makes porting lwIP harder. So by now, nesting is not used any more.
However, it seems this never got formalized.

Regards,
Simon




 From rtos prospective, you can consider sys_arch_protect() as
enter_critical_section() and sys_arch_unprotect() as
exit_critical_section().


That's only true if enter_critical_section() and
exit_critical_section() enforce nesting/paired calls.


These calls might already be provided by rtos you're using.


They are, but they do not nest. In the uItron RTOS I'm using the "exit
critical section" function re-enables context switching no matter how
many times "enter critical section" has been called. I'm working on a
nesting equivalent.

Thanks much for the clarification.

Once I'm satisfied I understand the real requirements, I'll submit a
patch for the documentation. Hopefully that will avoid in the future
the problems created when the original authors of my sys_arch.c code
interpreted the existing documentation literally.



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 underlying OS operations
usually have far more that two possible outcomes.  Is it appropriate
to return ERR_* values other than those documented?

Is sys_mbox_trypost() allowed to return errors other than ERR_MEM?
For example, can I return ERR_ARG from sys_arch_mbox_trypost() if one
of the arguments is illegal?

Is sys_arch_mbox_fetch() allowed to return error codes other than
SYS_ARCH_TIMEOUT?

Were I to _guess_, I would assume that functions returning err_t can
return any error codes they want, but functions returning millisecond
counts can't?


You're right with your guess. Although I would have thought the
documentation is clear here, so there would be no need to guess...

Feel free to provide a patch updating the documentation if you think it
needs improvement!

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 I've inherited, when *_free() is called, my sys_arch.c
code places the referenced kernel object (semaphore or mailbox) back
into the free pool and it becomes available to be reallocated and
placed into use.

The lwIP documentation states:

void sys_sem_set_invalid(sys_sem_t *sem)

Invalidate a semaphore so that sys_sem_valid() returns 0.
ATTENTION: This does NOT mean that the semaphore shall be
deallocated: sys_sem_free() is always called before calling this
function!

Apparently the sequence is

   new(sem)
   free(sem)
   invalid(sem)

If invalid() is called for a particular semaphore _after_ that
semaphore has been free()ed, that semaphore may have already been
reallocated and might be in use by a different thread, socket,
whatever. Is the semaphore not supposed to be availble for
reallocation after being free()ed?

Are signal/wait calls on a mutex allowed between the free() call and
the set_invalid() call?


I've been looking at the freeRTOS port for edification, and that
hasn't really helped. In the freeRTOS port, the semaphore (for
example) becomes invalid when sys_sem_free() is called, so the call to
sys_sem_set_invalid() call will never have any effect [assuming the
documentation is correct and sys_sem_free() is always called before
sys_sem_set_invalid()].

In the freeRTOS port, the only time sys_sem_invalid() could have any
effect is if it were called before sys_sem_free(), and AFAICT that
would cause the underlying OS semaphore to be leaked.

Is an object's behavior supposed to change when
sys_object_set_invalid() is called?

Are there ports where an object is still valid after sys_*_free() is
called? After a semphore has been free()ed, what operations on an
already free()ed object would still be valid?


None. This is only a helper define to help defining sys_sem_free() to
something that might not make sys_sem_valid() return true.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 queues.


I'm not sure I understand your question. Do you mean 'if multiple
threads are waiting, which one gets woken first'?


Yes.


In that case, it's nothing we as lwIP developers can answer:


But they're the ones that actually know what those kernel objects are
used for.


"for": yes. But to me, your "FIFO or priority" question is a performance
question: the core of lwIP is not really using those objects (in the way
you want to know about), only the application threads using sockets etc.




it's mainly a question of how you want your system to behave. Using
a decent embedded RTOS, I would say the answer is "the thread with
the highest priority should be woken first", but that's really up to
how your OS shall behave.


So the lwIP stack will work correctly with either FIFO or priority
queueing for the kernel objects used internally by lwIP?


Yes, the only impact I can see is performance: using a FIFO mechanism,
you will probably not be able to implement a true priority based thread
system.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 waiting, which one gets woken first'? In that case, it's
nothing we as lwIP developers can answer: it's mainly a question of how
you want your system to behave. Using a decent embedded RTOS, I would
say the answer is "the thread with the highest priority should be woken
first", but that's really up to how your OS shall behave.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 going to noticeably affect
performance of things like a small web server and MQTT client?

Or should I do things using a simple and obviously correct method.

I tend toward the latter unless warned beforehand that something is in
a time-critical path.


- allocation of mutexes is only done when initializing lwIP
- allocation/deallocation of mboxes is done when initializing lwIP *and*
when creating/closing a socket
- allocation/deallocation of semaphores is done when creating/closing a
socket and when calling sys_msleep()

BUT: allocation/deallocation of sempahores is also done:
- for many API calls (from an application thread into the tcpip-thread)
or tcpip_calback when LWIP_TCPIP_CORE_LOCKING==0
- for select and for DNS API calls (like gethostbyname etc) when
LWIP_NETCONN_SEM_PER_THREAD==0

Note that LWIP_NETCONN_SEM_PER_THREAD==1 needs thread-local storage
support. Also, sys_msleep() isn't really broadly used but could probably
be somehow converted to use LWIP_NETCONN_SEM_PER_THREAD, too.

Overall, this doesn't look time-critical to me (unless you are making
heavy use of netconn/sockets and explicitly change
LWIP_TCPIP_CORE_LOCKING from its default setting 1 to 0).

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 object is otherwise unused.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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.  But, they did add mutexes to make sure that some
other functions like like sys_mbox_free() and _new() are
thread-safe.


Thread-safe related to what? Globally (all mboxes) or local to the mbox?


Globally (mostly), and globally doesn't mean just objects of the same
type. On my platform, there could be race conditions between mutex
and semaphore functions. I'm not concerned about race conditions among
signal/wait/lock/unlock functions. It's generally new/free/set_invalid
that can cause problems.


I don't think thread-safety is required. It should just work. If you
need guidance, take a look at our FreeRTOS port, which should work
(without additional thread-safety):

https://git.savannah.nongnu.org/cgit/lwip.git/tree/contrib/ports/freertos/sys_arch.c


Thanks, I'll use that as a model, but FreeRTOS is different enough
from my RTOS that it doesn't answer some questions.


The documentation I've found at https://www.nongnu.org/lwip/2_1_x/
seems to be mute on that subject.

Do the varios sys_* functions for mutex, semaphore, mailbox functions
in the "OS abstraction layer" need to be thread safe?

Or are they only called under some sort of mutex/protection?


I'm still not sure which specific thread-safety you mean:


I mean can two invocations of the sys_* (mailbox, mutex or semaphore)
functions happen "at the same time".  For example: can the execution
of one call to sys_{sem,mutex,mbox}_set_invalid() be interrupted or
suspended by another call to that same function? [The second
invocation would be for a different object obviously.] After the second
invocation finished, the first one would then resume.


Yes, ok, that can of course happen. There's no restriction between
calling those functions on different objects. The only guarantee you get
with lwIP is probably that allocation and deallocation points are safe...

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 _new() are thread-safe.


Thread-safe related to what? Globally (all mboxes) or local to the mbox?

I don't think thread-safety is required. It should just work. If you
need guidance, take a look at our FreeRTOS port, which should work
(without additional thread-safety):

https://git.savannah.nongnu.org/cgit/lwip.git/tree/contrib/ports/freertos/sys_arch.c



The documentation I've found at https://www.nongnu.org/lwip/2_1_x/
seems to be mute on that subject.

Do the varios sys_* functions for mutex, semaphore, mailbox functions
in the "OS abstraction layer" need to be thread safe?

Or are they only called under some sort of mutex/protection?


I'm still not sure which specific thread-safety you mean:
- allocation is per definition thread-safe since noone knows the object
at that state
- using the mbox/semaphore is normally thread-safe because you normally
just pass on some variables to OS core functions
- deallocation is only done when the stack knows the object is not used
any more



Is this documented somewhere I should have looked and didn't?


Noone before you has expressed a need for documentation on this topic,
so no, it's not documented yet.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 not been updated.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] lwIP 2.1.3 released

[goldsi...@gmx.de]

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:

https://git.savannah.nongnu.org/cgit/lwip.git/log/?h=STABLE-2_1_3_RELEASE

As always, all users are strongly suggested to upgrade (should be a
matter of copying the new files only, no changes required)!

Contrib has still not been changed since 2.1.0, so 'contrib-2.1.0.zip'
is still valid.

Thanks for all contributions!

Simon

[1] https://savannah.nongnu.org/projects/lwip/

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LOCK/UNLOCK TCIP_CORE

[goldsi...@gmx.de]

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 this assertion?

It means that you're either calling this from the wrong thread (there's
not enough information in your email to tell) or you haven't implemented
LWIP_MARK_TCPIP_THREAD() correctly (the counterpart of
LWIP_ASSERT_CORE_LOCKED()).

However, there must be something wrong in your callstack:
tcpip_timeouts_mbox_fetch() is not called from ethernet_input(). It is
only called from the main loop in tcpip_thread(). If your callstack
above is really like you wrote, I suspect you have coded something
yourself, probably without fully understanding lwIP's threading
requirements?

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 IPv6 at the same time.
Depending on how your application is written, running one application
serving IPv4 and IPv6 at the same time might be difficult though.
There's at least one bug open that reports 'getaddrinfo()' behaving
different than on other stacks/OS.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 the sending, so I need to copy
> pbuf to another mpbuf, but mpBuf length has to be p->len + 1, because I
> need to add data end of the datagram. 
> If I use in above link I have an error. But If I use original low_level
> _output function like in below link:
>
> https://paste.ofcode.org/QJhuGAjDqVsghQKqj6SyJf
> 
>
> I dont have any error, but I have to use first link. How can I solve the
> problem with copy pbuf to another pbuf ?

So you have the code right before you. What keeps you from copying it
into your favourite dev IDE (windows, linux, whatever), mocking all the
lwIP/hardware parts and single-stepping through it to see where the bug
is? Obviously, it's neither lwIP nor hardware related?

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 pcap netif driver:

https://git.savannah.nongnu.org/cgit/lwip.git/tree/contrib/ports/win32/pcapif.c#n838

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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. But does not make sense.  I couldnt do
> successful handshaking. Lwip takes care of the IP part if I send the
> another IP based packet (like icmp) packet with different sizes. I didnt
> get IPv4 packet length error.
> I only have this error when I used mbedtls. How can I find the problem?

One error I can think of here is that your driver might send packets
using 'p->len' instead of iterating over all pbufs ('p->tot_len',
iterate over all 'p->next').

Or your driver might be sending zero-copy but the packets get changed
between being enqueued and actually sending them?

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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.3 sources you are trying to build.
>>>
>>> Ah, I see.
>>>
>>> And there is no equivalent document for 2.1.3?
>>
>> Apparently not. The documentation and most of the cmake build system has
>> been added for the master branch only. We're currently not porting it
>> back to the 2.1.x tree.
>
> I see.
>
>> ...
>
>> I'm not really using the linux/cmake things myself very often: instead,
>> I'm mostly developing/debugging things in an old (community) version of
>> MS Visual Studio. But in the end, that's not really relevant: our
>> repository provides portable code as source, not as an end product
>> that's meant to be compilable into a binary out of the box with no
>> additional work.
>
> I was under the impression that the win32 and Linux example
> applications were meant to be exactly that.

OK, maybe "not really relevant" was'nt the righ expression. The example
applications are "nice to have" addons. Being like that, they obviously
don't get the same amount of attention as the "real" code, because most
users run the code in their own product but don't use the example
applications.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 separate git tree. Since that's kind of annyoing, we moved
>> the contrib part to a folder in a main tree by now.
>>
>> 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.3 sources you are trying to build.
>
> Ah, I see.
>
> And there is no equivalent document for 2.1.3?

Apparently not. The documentation and most of the cmake build system has
been added for the master branch only. We're currently not porting it
back to the 2.1.x tree.

Traditionally, there has been *no* possibility to build lwIP as is:
that's simply not our focus. We're not a linux/unix library, we provide
source code to compile on small embedded systems. And since these most
often use proprietary or other weird build systems, noone bothered to
add make or cmake files.

I'm not really using the linux/cmake things myself very often: instead,
I'm mostly developing/debugging things in an old (community) version of
MS Visual Studio. But in the end, that's not really relevant: our
repository provides portable code as source, not as an end product
that's meant to be compilable into a binary out of the box with no
additional work. From reading your mails, it seems like you though
differently, and that might have lead to frustration. Bothe the makefile
lists and cmake files really only started as a tiny helper for ourselves
(e.g. travis).

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 beeing trying to follow 
> https://git.savannah.nongnu.org/cgit/lwip.git/tree/BUILDING
> as a starting point, but it appears to be out-of-date and not

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 separate git tree. Since that's kind of annyoing, we moved the
contrib part to a folder in a main tree by now.

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.3
sources you are trying to build.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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.

Regards,
Simon

> Might also be a good place to discuss which config options we do and
> don't want to add for getaddrinfo.
>
> Best Regards
> Simon
>


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 should behave like other
stacks. Adding too many config options is not a good thing.

However, this won't make it into the 2.1.3 relase but should be a patch
against the master branch (which isn't too far from being released as
well, but will be numbered 2.2.0 because of some not-so-small changes).

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 not sure.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 is a TCP frame from the
> web browser with the [SYN] flag set. Normally the web server would
> answer with [SYN, ACK]. But for some reason the web server answer only
> with [ACK] (line number 246 in the capture file). And from this point on
> the communication with the web server is disturbed.
>
> Any help would really be very welcome.
>
> Kind regards
> Roland
>
>
> Am 15.09.21 um 15:37 schrieb Info:
>> Hi
>>
>> I'm using lwIP (2.1.3-RC1) with the httpd web server from the apps
>> directory in my embedded application. After loading a web content from
>> the web server a periodic communication starts from the web browser
>> that opened the website. This all works, but after a view minutes the
>> periodic communication gets broken (the web server/lwIP stack itself
>> does not crash). After a reload of the web site the periodic
>> communication is established again for a view minutes.
>>
>> In the attached Wireshark capture file I can see many frames (from the
>> web browser) with the set ACK RST flags. For me it not clear why the
>> web browser sends this frames and if it is the reason for the broken
>> periodic communication ? Any help and maybe some explanation would be
>> very welcome.
>>
>> I also activated the debugging output and the internal lwIP asserts,
>> but this did not help me to track down the problem. The web server
>> does not support encryption.
>>
>> The lwIP uses FreeRTOS with the sys_arch files found in the contrib
>> package.
>>
>> IPs used in the Wireshark capture : The web server uses 192.168.3.131
>> and the client (web browser) 192.168.10.103 .
>>
>> Thank you very much for any help
>> Roland
>>
>> ___
>> lwip-users mailing list
>> lwip-users@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

Am 22.09.2021 um 11:38 schrieb Marco Giammarini:
> Dear all,
> in attach you can find new capture.
> The lwip device is: 192.168.1.123 for OSX acquisition, and 192.168.10.123 for 
> windows acquisition.

This clearly looks like a memory/configuration problem in lwIP, as (at
least in the windows trace), the lwIP device is not sending more than
one frame without receiving an ACK. And since windows doesn't expect
this (but wants to send an ACK for every 2nd packet), a timer for
sending the ACK has to expire in windows. This results in 200ms before
the ACK is received.

Normally, the TCP sliding window mechanism should speed things up, but
that doesn't happen here. You need to find out why by checking
lwip_stats and/or enable logging in the tcp modules.

Regards,
Simon

> Anyway, if I put the OSX device into the same network of Win device, the 
> result for OSX device 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.
>>
>> Regards,
>> Marco
>>
>>> Il giorno 20 set 2021, alle ore 12:16, goldsi...@gmx.de ha scritto:
>>>
>>> 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
>>>> and where you think the problem is.
>>>
>>> BTW, the config you sent before said "TCP_WND = (3*TCP_MSS)", but in the
>>> pcaps, the lwIP device (or what I think it is, you didn't tell) sends a
>>> windows size of 2920 (which is 2 * MSS, not 3 * MSS). Something can't be
>>> right here.
>>>
>>> Regards,
>>> Simon
>>>
>>> ___
>>> lwip-users mailing list
>>> lwip-users@nongnu.org
>>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Improving UDP responses.

[goldsi...@gmx.de]

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 defined as 6, but increasing it to 12 has
> had no effect. 
>
> Can you make any other recommendations as to how to increase our throughput?

I'm not aware of anything in lwIP limiting you here. It could be any
memory shortage (debug this using lwip_stats) or it could be a driver
issue somehow limiting the number of frames you can pull off your netif.

The STM drivers were somewhat buggy when I worked with them. Now some
years have passed since then, but I don't know if they have been fixed
by now.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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
> and where you think the problem is.

BTW, the config you sent before said "TCP_WND = (3*TCP_MSS)", but in the
pcaps, the lwIP device (or what I think it is, you didn't tell) sends a
windows size of 2920 (which is 2 * MSS, not 3 * MSS). Something can't be
right here.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[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
and where you think the problem is.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

Am 17.09.2021 um 10:34 schrieb Tomas Mudrunka:
> Recently there was somebody reporting simillar issue and it turned out
> that some (or most?) browsers use several concurent TCP/HTTP connections
> to load single webpage. Number of these connections was bigger than
> LWIPs default maximum number of concurent TCP connections, so you might
> try to increase that as well...

That's true, but the 10 connections configured below should be enough I
think.

Anyway, if he's reading the pcap and seeing delays due to delayed ACK,
new connections are probably not the problem.

Having access to a trace of this might help, though!

Regeards,
Simon

>
> Tom
>
>
> Dne 2021-09-16 08:49, Marco Giammarini napsal:
>> Dear Simon,
>> Thanks for your reply.
>> I have set 40kB of heap, and every time I stop the microcontroller in
>> debug mode during web site request, the free memory is over 70%.
>> This is my configuration:
>>
>> #DEFINE MEM_SIZE(40*1024)
>>
>> #DEFINE MEMP_NUM_PBUF   28
>>
>> #DEFINE MEMP_NUM_TCP_PCB10
>>
>> #DEFINE MEMP_NUM_TCP_PCB_LISTEN 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_MSS
>>
>> #DEFINE TCP_WND (3*TCP_MSS)
>>
>> Is there anything I can change?
>>
>> Regards,
>> Marco
>>
>>> Il giorno 15 set 2021, alle ore 09:55, goldsi...@gmx.de ha scritto:
>>>
>>> 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, that multiplied for 40ms reach 20 seconds each file.
>>>> I found that this problem is very common for Windows PC:
>>>> *
>>>> https://developpaper.com/lets-talk-about-the-magical-40-ms-of-tcp/
>>>>
>>> <https://developpaper.com/lets-talk-about-the-magical-40-ms-of-tcp/>
>>>> *
>>>>
>>>
>> https://docs.microsoft.com/it-it/troubleshoot/windows-server/networking/registry-entry-control-tcp-acknowledgment-behavior
>>>>
>>>
>> <https://docs.microsoft.com/it-it/troubleshoot/windows-server/networking/registry-entry-control-tcp-acknowledgment-behavior>
>>>>
>>>> Is there any way to solve the problem (or a workaround) by modify
>>>> some
>>>> parameters of lwIP?
>>>
>>> You should not have a speed problem even if the ACKs get delayed
>>> further. Having a problem here suggests that your lwIP (memory)
>>> options
>>> limit the send window in such amount that transmission stalls until
>>> the
>>> next ACK is received.
>>>
>>> Unless you're really short on memory, you should probably review
>>> your
>>> TCP and memory related options in lwipopts.h
>>>
>>> Regards,
>>> Simon
>>>
>>> ___
>>> lwip-users mailing list
>>> lwip-users@nongnu.org
>>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>> ___
>> lwip-users mailing list
>> lwip-users@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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, that multiplied for 40ms reach 20 seconds each file.
> I found that this problem is very common for Windows PC:
> *  https://developpaper.com/lets-talk-about-the-magical-40-ms-of-tcp/
> 
> * 
> https://docs.microsoft.com/it-it/troubleshoot/windows-server/networking/registry-entry-control-tcp-acknowledgment-behavior
> 
>
> Is there any way to solve the problem (or a workaround) by modify some
> parameters of lwIP?

You should not have a speed problem even if the ACKs get delayed
further. Having a problem here suggests that your lwIP (memory) options
limit the send window in such amount that transmission stalls until the
next ACK is received.

Unless you're really short on memory, you should probably review your
TCP and memory related options in lwipopts.h

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Issue with SO_BINDTODEVICE

[goldsi...@gmx.de]

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 "netif_idx" of course.
>
>
> I'm wondering if STABLE-2_1_x branch also needs this fix for v2.1.3?

Why not. I've cherry-picked the fix.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LWIP next stable release

[goldsi...@gmx.de]

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 release candidate tagged and it will be
released in the next days unless someone objects.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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
> transfer packet data into pbuf and then call netif->input.
> Thread-2: lwIP core thread: tcpip_thread.
>
> If I run both threads on one core, they work fine. But if I run both on
> separate cores using pthread_setaffinity_np() it gives an error after ~5
> minutes. The error is :
> /Assertion "memp sanity" failed at line 389 in
> ../lwip/contrib/../src/core/memp.c /

Sorry for taking so long to answer this, but I hope the answer still helps:

I suspect that the sys_arch_protect/unprotect macros are not correctly
set up for multiprocessing. For a single core, the default behaviour is
to lock interrupts and therefore to prevent a task switch (as we don't
call OS functions leading to a task switch in locked sections).

When you have multiple CPUs, multiple threads can run concurrently on
your system. That means locking interrupts is not enough and you will
have to convert sys_arch_protect/unprotect to lock by using a mutex.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] lwIP 2.1.3-rc1

[goldsi...@gmx.de]

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 test and report bugs if you find any!
Many thanks to all contributors!!


Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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' in the lwIP apps in our repo.
I'm not 100% sure that it works with older lwIP versions, but you can try.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 mqtt_incoming_publish_cb_t() and
> the mqtt_incoming_data_cb_t(). Looking at the MQTT Client code a single
> MQTT_MSG_TYPE_PUBLISH packet comes into the mqtt_message_recieved()
> function and gets split between the two callbacks. Why is this split
> instead of sending the topic+data in one callback?

I cannot really answer this. It's just the way the author wrote the code...

> If we have multiple
> subscriptions is it guaranteed that we'll receive an incoming Topic
> callback, then the matching incoming data callback? I think this is the
> case as we're in a single-threaded RAW API context.

From my knowledge of the code, this is guaranteed, yes. Reading the
code, you cannot identify the topic from the 'arg' parameter, or can you?

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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.
> git.savannah.nongnu.org/cgit/*lwip*.git  Simon Goldschmidtmight be able
> to help.

That's right. 2.1.2is the newest release. There is a git branch in
preparation for 2.2.0, but 2.2.0 has not yet been released.

Please ask NXP which version they are really shipping.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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).
> - both are over dimensioned for stack and heap (because I'm still
> developing, I'll reduce to decent amounts when I need to)
> - uart2 rx/tx are connected to LTE modem. Both rx and tx is used in
> interrupt mode.
> - uart3 tx is used for logging to PC (where some simple C# app reads all
> data and logs to file)
> 
> I am connecting to a web-server where I want to download a "512.KB.zip"
> (zip contains \0 characters, I took it from some download speed test
> server).
> 
> I experimented with lwftp , but it

I don't know that one.

> seems to leak memory the way I use it. So I thought, why not just
> download files using http get and use the lwip provided http_client.
> 
> The following code is used to initiate the download :
> 
> LogLineToUart("connecting to server...\n");
> 
> ip_addr_t ip;
> uint16_t port= 80;
> httpc_connection_t settings;
> 
> IP4_ADDR(, 31,21,236,6);
> settings.result_fn = result_fn;
> 
> err_t err = httpc_get_file(
> , 
> port, 
> "/512KB.zip", 
> , 
> rec_fn, 
> nullptr, 
> nullptr);
> 
> if ( err != ERR_OK ) 
> {
> LogLineToUart("httpc_get_file failed (%d)", err);
> }
> 
> for now, I only log when I am receiving data:
> 
> err_t rec_fn(void *arg, struct altcp_pcb *conn, struct pbuf *p, err_t err)
> {
> LogLineToUart("sinking: %d\n", p->len);

You should be freeing the pbuf here or you'll run out of pbufs eventually.

> }
> 
> void result_fn(void *arg, httpc_result_t httpc_result, u32_t rx_content_len, 
> u32_t srv_res, err_t err)
> {
> LogLineToUart("download finished\n");
> }
> 
> Both functions are called. So data is being received. 
> 
> The questions arise when I look at wireshark. 
> 
> 1278302.433400192.168.1.113185.99.25.76TCP5880 → 62510 [SYN, ACK] Seq=0
> Ack=1 Win=29200 Len=0 MSS=1460
> 1282302.871908185.99.25.76192.168.1.113HTTP205GET /ftp_100kb_5.log HTTP/1.1 

This is not requesting "/512KB.zip" as in the code above?

> 1283302.872167192.168.1.113185.99.25.76TCP5480 → 62510 [ACK] Seq=1
> Ack=152 Win=29736 Len=0
> 1284302.873849192.168.1.113185.99.25.76TCP52680 → 62510 [ACK] Seq=1
> Ack=152 Win=29736 Len=472 [TCP segment of a reassembled PDU]
> 1285302.874100192.168.1.113185.99.25.76TCP52680 → 62510 [ACK] Seq=473
> Ack=152 Win=29736 Len=472 [TCP segment of a reassembled PDU]
> 1286302.874253192.168.1.113185.99.25.76TCP52680 → 62510 [ACK] Seq=945
> Ack=152 Win=29736 Len=472 [TCP segment of a reassembled PDU]
> 1287302.874394192.168.1.113185.99.25.76TCP52680 → 62510 [ACK] Seq=1417
> Ack=152 Win=29736 Len=472 [TCP segment of a reassembled PDU]
> 1288302.874535192.168.1.113185.99.25.76TCP52680 → 62510 [ACK] Seq=1889
> Ack=152 Win=29736 Len=472 [TCP segment of a reassembled PDU]
> 1289302.874688192.168.1.113185.99.25.76TCP52680 → 62510 [PSH, ACK]
> Seq=2361 Ack=152 Win=29736 Len=472 [TCP segment of a reassembled PDU]
> 1290302.874835192.168.1.113185.99.25.76TCP52680 → 62510 [ACK] Seq=2833
> Ack=152 Win=29736 Len=472 [TCP segment of a reassembled PDU]
> 1291302.874975192.168.1.113185.99.25.76TCP52680 → 62510 [ACK] Seq=3305
> Ack=152 Win=29736 Len=472 [TCP segment of a reassembled PDU]
> 1292302.875118192.168.1.113185.99.25.76TCP52680 → 62510 [ACK] Seq=3777
> Ack=152 Win=29736 Len=472 [TCP segment of a reassembled PDU]
> 1293302.875261192.168.1.113185.99.25.76TCP526[TCP Window Full] 80 →
> 62510 [ACK] Seq=4249 Ack=152 Win=29736 Len=472 [TCP segment of a
> reassembled PDU]
> 1295303.465207185.99.25.76192.168.1.113TCP6062510 → 80 [ACK] Seq=152
> Ack=473 Win=4248 Len=0
> 1304304.795607192.168.1.113185.99.25.76TCP526[TCP Retransmission] 80 →
> 62510 [ACK] Seq=473 Ack=152 Win=29736 Len=472
> 1305305.354254185.99.25.76192.168.1.113TCP60[TCP Dup ACK 1295#1] 62510 →
> 80 [ACK] Seq=152 Ack=473 Win=4248 Len=0
> 1311307.485583192.168.1.113185.99.25.76TCP526[TCP Retransmission] 80 →
> 62510 [ACK] Seq=473 Ack=152 Win=29736 Len=472
> 1312307.903785185.99.25.76192.168.1.113TCP60[TCP Dup ACK 1295#2] 62510 →
> 80 [ACK] Seq=152 Ack=473 Win=4248 Len=0
> 1324312.855604192.168.1.113185.99.25.76TCP526[TCP Retransmission] 80 →
> 62510 [ACK] Seq=473 Ack=152 Win=29736 Len=472
> 1326313.354377185.99.25.76192.168.1.113TCP60[TCP Dup ACK 1295#3] 62510 →
> 80 [ACK] Seq=152 Ack=473 Win=4248 Len=0
> 1334317.187014185.99.25.76192.168.1.113TCP6062510 → 80 [RST, ACK]
> Seq=152 Ack=473 Win=28690 Len=0
> 
> The data sent by the server doesn't add up to 512KB by a long shot. And
> my STM doesn't seem to send acks fast enough, resulting in window full +
> retransmits.

Please share pcap files, not text summaries. You can see in the pcap
which data is being sent by the server. That 

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

[goldsi...@gmx.de]

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,
>
> I think you already perfectly answered my question(s). I'm really
> grateful for that. This wasn't blocking me from proceeding, but it's
> really annoying for me to not understand half of what I am doing. You
> helped me to understand 51% of what I am doing which is good enough for
> now not to sink and drown ;-). 
>
> I will google for the ISO 3309 spec and search for the information you
> mentioned. I noticed that wikipedia reveals interesting things if I type
> in the correct keywords :)
>
> Thanks again for clarifying some bits and pieces for me!!
>
> Best regards, bas
>
> Op ma 7 jun. 2021 om 23:13 schreef  >:
>
> Send lwip-users mailing list submissions to
>         lwip-users@nongnu.org 
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> or, via email, send a message with subject or body 'help' to
>         lwip-users-requ...@nongnu.org
> 
>
> You can reach the person managing the list at
>         lwip-users-ow...@nongnu.org 
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of lwip-users digest..."
>
>
> Today's Topics:
>
>    1. Re: pppos sent packets optionally start with 0x7e, why?
>       (Rüdiger Asche)
>
>
> --
>
> Message: 1
> Date: Mon, 7 Jun 2021 23:12:08 +0200
> From: Rüdiger Asche  >
> To: "Mailing list for lwIP users"  >
> Subject: Re: [lwip-users] pppos sent packets optionally start with
>         0x7e, why?
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"
>
> Hi Bas,
>
> if you have access to the ISO 3309 spec which defines HDLC, look for
> the statement
>
> "A single flag may be used as both the closing flag for one frame
> and the opening flag for the next frame."
>
> in chapter 4.1.
>
> I suspect that this explains the observation you make. The closing
> frame character of the last frame is recycled as the frame start
> character for the next frame, remembered by the peer.
>
> The easiest way to verify this is to look at the HDLC frame parser
> and -generator in lwip. I can't tell you where to look since it's
> been decades I worked with PPP (never under lwip), but it shouldn't
> be too hard to find in the code base.
>
> Thanks Rüdiger
>   - Original Message -
>   From: Bas Prins
>   To: lwip-users@nongnu.org 
>   Sent: Monday, June 07, 2021 10:43 PM
>   Subject: Re: [lwip-users] lwip-users Digest, Vol 214, Issue 6
>
>
>   Dear Rüdiger ,
>
>
>   Thanks for the detailed answer and the link (haven't read that,
> learned a lot from reading).
>
>
>   When I read this, I understand what you mentioned, and that the
> sender is allowed to omit the TRAILING 0x7e byte. But in my case,
> it's not really the trailing byte (or I am still missing the obvious
> here... :))
>
>
>   It might be hard to digest from the CSV data, but this is what I
> can see in my logic analyzer:
>
>
>   STM starts (after modem reaches data mode):
>   0x7e . 0x7e - send first packet, wrapped in 0x7e bytes.
>
>
>   After roughly 500us the peer replies:
>   0x7e .. 0x7e - again a ppp packet wrapped in 0x7e bytes
>
>
>   STM responds and sends a second packet:
>   0xFF .. 0x7e : This is what struck me. Shouldn't this BEGIN with a
> 0x7e?
>
>
>
>   It already sent it's "omitable leading 0x7e byte" to enclose the
> first packet. So it should start with a 0x7e byte now, right? Or
> does the peer accept the trailing 0x7e byte of the FIRST sent packet
> as leading 0x7e for the second packet??
>
>
>   I interpreted this part as the FIRST 0x7e byte of the second sent
> PPP packet is omitted.
>
>
>   What am I still missing?
>
>
>   Best regards, bas
>
>
>
>
>
>
>
>
>
>
>   Op ma 7 jun. 2021 om 21:28 schreef  >:
>
>     Send lwip-users mailing list submissions to
>             lwip-users@nongnu.org 
>
>     To subscribe or unsubscribe via the World Wide Web, visit
>             https://lists.nongnu.org/mailman/listinfo/lwip-users
> 

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

[goldsi...@gmx.de]

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

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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
> {
>     int aCurrentCount = recv(, buffer>,aCharsRequested,theTimeout?MSG_DONTWAIT:0);
>     if (aCurrentCount>0)
>     {
>     
>     }
>     else
>     {
>     socklen_t aReturnSize = sizeof(aError);
>     int aError;
>     getsockopt(, SOL_SOCKET, SO_ERROR,(void
> *),);
>     if (!aCurrentCount || (aCurrentCount<0 && (aError!= EWOULDBLOCK)))
>     {
>     < connection gone down, close the socket, return failure or
> partial read if applicable>
>     }
>     }
> } < until timeout occurred or all requested characters have been received>
>
>  
>
> On 1.4.1 this worked fine. On 2.1.2, every recv() falls into the close
> socket case.
>
>  
>
> I debugged this and found that in 2.1.2, sock_set_errno() has been
> rewritten to not set the connection specific error code member
> pending_err but the global variable errno.
>
> The getsockopt funtion, though, retrieves the pending_err member which
> hasn't been set by sock_set_errno.
>
>  
>
> Needless to say, in a multi tasking, multiple socket environment it is
> not feasible to use a global variable for connection specific errors, so
> I can't look at the global errno to determine the failure code for this
> socket.
>
>  
>
> 1.4.1 implemented the sock_set_errno macro to store the error in a
> socket specific variable.
>
>  
>
> If there is a thread safe and per-socket way to implement the above
> sequence, how do I need to rewrite the code? If not, I consider the
> implementation a bug, how to report this?

The actual bug was in 1.4.1 to not store such error codes in 'errno'.
The socket API is not under our control, we try to stay to the opengroup
spec as close as possible.

Of course, you cannot use a simple global variable for 'errno' when
using multithreading. You need something like "thread local storage",
which I believe FreeRTOS should support.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] WS_send data pointer

[goldsi...@gmx.de]

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.
>
> I wonder how to guarantee that the pointer is still valid after sending
> a message via WS_send. Now, my data is placed on the stack just before
> calling WS_send, but since the function returns (possibly) before using
> the data, I'm very unsure on how to implement this.
>
> Do you have feedback on this issue?

My only feedback is that this whole file "httpsrv_ws_api.c" is not part
of lwIP, but probably part of what your vendor has added.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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. When a client connects to my listening socket the accept callback is
> called with a NEW session PCB. The listening PCB is still in existence.
> 3. When I "close" the active TCP connection, I should close the New
> Session PCB that was allocated in 2.
> 4. The listening PCB created in step 1 is still listening and will
> accept any new connections.
> 5. When I want to stop listening, I need to call tcp_close() on the
> listening PCB allocated by tcp_listen() in 1.
>
> So I'm going to have to manage both the listening PCB and an active
> connection PCB for a "listening" socket?

Yes, that's just the same as if you had sockets instead of our pcbs...

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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);
>>>}
>>> + UNLOCK_TCPIP_CORE();
>>>
>>
>> I'm not sure you even need this. What's the function behind the
>> netif->input pointer?
>
> It is tcpip_input(), but LWIP_TCPIP_CORE_LOCKING is globaly disabled by
> defines.
> Only SYS_LIGHTWEIGHT_PROT is enabled.
>

But you don't need LWIP_TCPIP_CORE_LOCKING. Traditionally, all code runs
inside a single thread. If you want to call lwIP core functions, you'd
set up a message that gets some function called in this thread context.
This way, you don't need locking, as everything is called sequentially
from only one thread.

LWIP_TCPIP_CORE_LOCKING is a different mechanism: instead of queueing a
call to be done in another thread, you grab a global mutex and do the
call right away. Most times, this better fits to realtime requirements
than the traditional mechanism.

However, you don't need a lock when netif->input is tcpip_input.
tcpip_input is a function dedicated to be called from other stacks to
queue input pbufs for the lwIP thread.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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) {
>  ESP_LOGE(TAG, "Input failed!");
>  pbuf_free(p);
>}
> + UNLOCK_TCPIP_CORE();
>

I'm not sure you even need this. What's the function behind the
netif->input pointer?

Regards,
Simon


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 >= pbuf_clen(next->p)" failed: file
> "/opt/Espressif/esp-idf/components/lwip/lwip/src/core/tcp_in.c", line
> 1112, function: tcp_free_acked_segments
>
> My netif has FreeRTOS task which handles communication and then passes
> received L2 frames to LWIP like this:
>
> p = pbuf_alloc(PBUF_RAW,rx_len,PBUF_POOL);
> pbuf_take(p, rx_buf, rx_len);
> if(netif->input(p, netif) != ERR_OK) {
>ESP_LOGE(TAG, "Input failed!");
>pbuf_free(p);
> }
>
> Netif task runs with same priority as LWIP task.
> (Both run at ESP_TASK_TCPIP_PRIO defined in esp_task.h, but that is
> ESP32 specific)
> When i was running task with higher priority it was causing deadlocks.
> Now when i run both task on the same priority it gives me assertion
> mentioned before...
>
> Any idea what might be causing this?
> I am not sure how should i handle the case with netif having its own
> task sending data to netif->input()
> Is there some explicit locking required?

This is a special case where locking is taken care of. However:
- SYS_LIGHTWEIGHT_PROT needs to be set (this takes care of locking the
memp pools)
- pbuf_alloc/pbuf_take/pbuf_free are ok to call from your own thread as
long as you don't use the heap (e.g. don't use PBUF_RAM, don't enable
MEMP_MEM_MALLOC)
- netif->input must point to tcpip_input() to ensure the actual packet
processing takes place in lwIP thread context, not in your RX thread. To
do that, pass tcpip_input (not ethernet_input) to netif_add().

Regards,
Simon

>
> Thanks for your help.
>


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Recovering from network outage

[goldsi...@gmx.de]

Am 13.04.2021 um 13:31 schrieb Thompson, Jeff:
> Regarding the connection timeout, I tried setting timeout values for the 
> socket immediately after creating it:
>
>   struct timeval sendToVal =
>   {
>   .tv_sec = HTTPS_SOCKET_TIMEOUT,
>   .tv_usec = 0
>   };
>
>   lwip_setsockopt(*(int *)sockFd, SOL_SOCKET, SO_SNDTIMEO, , 
> sizeof(sendToVal) );
>   lwip_setsockopt(*(int *)sockFd, SOL_SOCKET, SO_RCVTIMEO, , 
> sizeof(sendToVal) );

For a starter, check the return value of setsockopt. Maybe you haven't
enabled support for this in lwIP code...

Regards,
Simon

>
> but the call to lwIP_recv does not return after I pull the cable on the 
> network side of my switch and wait for much longer than the timeout value I 
> set.
>
> Jeff Thompson  |  Senior Electrical Engineer-Firmware
> +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 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 or bring
>> networking up when Phy is connected.
>
> While you can check if the phy is reconnected (hint: use the link status 
> callback provided by lwIP), this will not be of much use, as you could well 
> get disconnected behind the first (or any) switch (so your own link status 
> always stays up).
>
> In this case, there's really no other option than to poll for a connection 
> and wait for it to succceed. Ideally, you'd combine this with a low-enough 
> (but not too low) connection timeout.
>
> Regards,
> Simon
>
>>
>>
>> Hope that helps.
>>
>> Rod
>>
>>
>> On 12/04/2021 21:03, Thompson, Jeff wrote:
>>>
>>> How can I recover from a network outage? I leave the cable from my
>>> system to the network switch connected, but pull the cable from the
>>> network switch to the cloud. Detecting that the server I was talking
>>> to is no longer talking is easy enough, but how do I recover? I’m
>>> using a plain old socket to make the connection, and
>>> lwIP_send/lwIP_recv) for data transfer of an HTTPS GET request.
>>>
>>>  
>>>
>>> I start up a timer that expires if there is no server response after
>>> a minute; much more than enough, I’m told. But what then? Can the
>>> timer callback do anything to make lwIP_send or lwIP_recv return to
>>> the calling task, preferably with an error?
>>>
>>>  
>>>
>>> *Jeff Thompson* |  Senior Electrical Engineer-Firmware
>>> +1 704 752 6513 x1394
>>> www.invue.com 
>>>
>>>  
>>>
>>>
>>> ___
>>> lwip-users mailing list
>>> lwip-users@nongnu.org
>>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>> ___
>> lwip-users mailing list
>> lwip-users@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Recovering from network outage

[goldsi...@gmx.de]

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 or bring networking up
> when Phy is connected.

While you can check if the phy is reconnected (hint: use the link status
callback provided by lwIP), this will not be of much use, as you could
well get disconnected behind the first (or any) switch (so your own link
status always stays up).

In this case, there's really no other option than to poll for a
connection and wait for it to succceed. Ideally, you'd combine this with
a low-enough (but not too low) connection timeout.

Regards,
Simon

>
>
> Hope that helps.
>
> Rod
>
>
> On 12/04/2021 21:03, Thompson, Jeff wrote:
>>
>> How can I recover from a network outage? I leave the cable from my
>> system to the network switch connected, but pull the cable from the
>> network switch to the cloud. Detecting that the server I was talking
>> to is no longer talking is easy enough, but how do I recover? I’m
>> using a plain old socket to make the connection, and
>> lwIP_send/lwIP_recv) for data transfer of an HTTPS GET request.
>>
>>  
>>
>> I start up a timer that expires if there is no server response after a
>> minute; much more than enough, I’m told. But what then? Can the timer
>> callback do anything to make lwIP_send or lwIP_recv return to the
>> calling task, preferably with an error?
>>
>>  
>>
>> *Jeff Thompson* |  Senior Electrical Engineer-Firmware
>> +1 704 752 6513 x1394
>> www.invue.com 
>>
>>  
>>
>>
>> ___
>> lwip-users mailing list
>> lwip-users@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 (you'll
normally only access a descriptor once unless its contents change),
putting data there will make the whole TX/RX frame processing in lwIP
slower and the flush/invalidate operations are orobably faster (except
for rare cases).

Being like that, it's a pity this problem still exists in vendor
drivers. I already rewrote the drivers for STM32 and ATSAM because of
that myself a wile ago (sadly, the result is not open source).

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 failure.  During the transmission tcp_sndbuf() (in api_msg.c)
> returns zero and the connection falls over.  From what I’ve read, a
> common cause is that it’s waiting for an outstanding ACK.  I’m no
> expert, but it looks like the ACK has been sent (see Wireshark attachment).
>
>  
>
> When I enable certain debug settings it works every time (don’t you hate
> that).

That's an indication that there's something wrong that's hidden by
either longer runtime (more debug code enabled) or by heavier cache
usage (more code/data in the caches).

In any case, I'd suggest thoroughly review the OS port and the netif
driver regarding caching issues and/or threading issues (where interrupt
vs. thread/main loop also counts in).

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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
fixed by now.

Keeping possible cache issues aside (see Danish's response), there were
also other bugs (I think like losing RX packets). Although cache is the
problem I'd look into first (given the fact that this problem only
appears when using cached memory).

Regards,
Simon

>
> These MCU have two contiguous memory areas: a section close coupled to
> the core (DTCM) and a normal RAM section.
> When I use the standard linker script the bss section and the LwIP
> buffers ( "memp_memory_PBUF_POOL_base" (21K) ,"ram_heap" (9K) and other
> buffers as memp_memory_PBUF_base 3K and some other with lower size) fall
> into the DTCM memory and aberything is fine.
>
> When I change the linker script and the bss section is allocated in the
> normal RAM, the LwIP stack works badly, sometimes the device is not
> reachable from network, sometimes (with other board e.g. Nucleo-F767ZI)
> the ping loses more than half of the packets.
>
> I don't think the LwIP needs the DTCM to work. I can't figure out the
> reason of this behaviour, some idea would be very appreciated.
>
> Thank you.
>
> Mario
>


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Sharing TCP port

[goldsi...@gmx.de]

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: Why?!

That pretty much sums it up. Something with SO_REUSEADDR or SO_REUSEPORT
might work in the socket API (and thus somhow in the netconn API), but
I'm not sure. That's just not what TCP is used like nowadays.

The TCP standard even handles "simultaneous open" but this is another
thing we don't support as noone seems to care...

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Sharing TCP port

[goldsi...@gmx.de]

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 sockets, there are *much* more exampes and places to ask.

I assume what you're missing is: 1 listener -> accept -> multiple
connection sockets?

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Sending raw IP packets

[goldsi...@gmx.de]

Am 08.03.2021 um 21:43 schrieb Jon:
> Thanks Simon for the input.  After reading your response, I feel I
> might be using lwip for its unintended purpose which might result in
> an exhausting uphill battle :)
>
> As mentioned in my previous email, I was hoping to implement a local
> VPN on Android using lwip.  The way the APIs work on Android is that
> when you register as a VPN service, the platform provides you a file
> descriptor which is attached to the device's TUN interface.  When you
> read from this file descriptor, you get all the raw IP packets that
> are being sent by the device, and whenever you write to the file
> descriptor (which also needs to be formatted as a raw IP packet), it
> gets routed back to the application on the device that sent the data.
> The reason the Android platform provides you the raw IP packets is
> that they intend for you to use this as a "remote" VPN where you would
> encapsulate the IP packets in UDP for example, then forward it to your
> own remote VPN server, then open a raw socket and have your server
> send the packet.
>
> However, since I am trying to implement this as a local VPN, this will
> not work for me.  This is where I was hoping lwip might be able to
> help me out.  Since lwip is a complete tcp/ip stack implementation, I
> thought there was a way I can just feed lwip the raw IP packet, and it
> would "magically" just send it over the wire for me.  I know this can
> be done using traditional socket programming by manually parsing the
> raw IP packets for the destination IP, then parsing the transport
> layer for the source/destination ports, manually create a TCP or UDP
> socket myself and then send out the data, but this seems like a lot of
> work.   If it helps explain in more detail, one search term that
> commonly comes up for what I am trying to accomplish is "tun2socks".

I still think I don't fully understand what you're doing. Do you want to
send those IP packets on to ethernet? In that case, you might just want
to extract IP information from the packet by casting it to 'struct
ip_hdr', allocat a pbuf for the packet (copy it, or by ref) and pass it
to 'etharp_output' (providing a matching netif where lowlevel_output
sens the ethernet packet).

You'd have to ensure to keep the ARP cache 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.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 pull out only the
>>> TCP/UDP transport layer data and then send it over a TCP/UDP socket
>>> myself but if this is already done by lwip, then I'd prefer to use it
>>> instead.
>>
>> I'm afraid I don't really underdstand what you mean. You should be able
>> to get a whole packet out of the stack by implementing a non-ethernet
>> netif. For this, set netif->output to your own function instead of
>> etharp_output and don't set the flags NETIF_FLAG_ETHARP and
>> NETIF_FLAG_ETHERNET. This way, your netif->output functions should get
>> pbufs starting with the IP header. If that's what you wanted (as I said,
>> I'm not sure).
>>
>>>
>>> I found the raw APIs
>>> (https://www.nongnu.org/lwip/2_1_x/group__raw__raw.html
>>> <https://www.nongnu.org/lwip/2_1_x/group__raw__raw.html>), but wasn't
>>> sure if this is what I needed to use.  Since I am running in user-space
>>> as a regular Android application, I am unable to run as root so not sure
>>> if the raw APIs require that I create a raw socket (which requires root).
>>
>> This question doesn't seem to have anything to do with lwIP or does it?
>> There's no such thing as 'root' in lwIP.
>>
>> Regards,
>> Simon
>>
>>>
>>> Also, if you can provide any sample code, this would be greatly
>>> appreciated. Thanks!
>>>
>>>
>>> ___
>>> lwip-users mailing list
>>> lwip-users@nongnu.org
>>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>>
>>
>>
>> ___
>> lwip-users mailing list
>> lwip-users@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Sending raw IP packets

[goldsi...@gmx.de]

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 pull out only the
> TCP/UDP transport layer data and then send it over a TCP/UDP socket
> myself but if this is already done by lwip, then I'd prefer to use it
> instead.

I'm afraid I don't really underdstand what you mean. You should be able
to get a whole packet out of the stack by implementing a non-ethernet
netif. For this, set netif->output to your own function instead of
etharp_output and don't set the flags NETIF_FLAG_ETHARP and
NETIF_FLAG_ETHERNET. This way, your netif->output functions should get
pbufs starting with the IP header. If that's what you wanted (as I said,
I'm not sure).

>
> I found the raw APIs
> (https://www.nongnu.org/lwip/2_1_x/group__raw__raw.html
> ), but wasn't
> sure if this is what I needed to use.  Since I am running in user-space
> as a regular Android application, I am unable to run as root so not sure
> if the raw APIs require that I create a raw socket (which requires root).

This question doesn't seem to have anything to do with lwIP or does it?
There's no such thing as 'root' in lwIP.

Regards,
Simon

>
> Also, if you can provide any sample code, this would be greatly
> appreciated. Thanks!
>
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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?

[goldsi...@gmx.de]

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
constants, not their values.

If you're looking at compiler errors because some file includes both
Linux and lwIP defines, have a look at LWIP_SOCKET_EXTERNAL_HEADERS. But
at least O_RDWR might not work as it is now...

Regards,
Simon

>
> #define O_RDONLY
> #define O_WRONLY0001
> #define O_RDWR0002
>
> *but in src/include/lwip/sockets.h , the value is:*
>
> #ifndef O_NONBLOCK
> #define O_NONBLOCK  1 /* nonblocking I/O */
> #endif
> #ifndef O_NDELAY
> #define O_NDELAY    O_NONBLOCK /* same as O_NONBLOCK, for compatibility */
> #endif
> #ifndef O_RDONLY
> #define O_RDONLY    2
> #endif
> #ifndef O_WRONLY
> #define O_WRONLY    4
> #endif
> #ifndef O_RDWR
> #define O_RDWR      (O_RDONLY|O_WRONLY)
> #endif
>
> *any reason of the difference?> *
> *
> *
> *
> BRs//tangyao
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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?

[goldsi...@gmx.de]

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 define
> anything. So it does not matter what the values are.

While it probably should be like that, the values cited below do not
work: the lwIP code currently relies on "O_RDWR == (O_RDONLY|O_WRONLY)"
and on none of them being zero...

Regards,
Simon

>
>  
>
> Regards,
>
> Ajay Bhargav
>
>  
>
>  
>
> *From: *唐尧 
> *Sent: *Friday, March 5, 2021 9:35 AM
> *To: *lwip-users 
> *Cc: *jlledom 
> *Subject: *[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?
>
>  
>
> *In posix fcntl.h , the definations is:*
>
>  
>
> #define O_RDONLY 
>
> #define O_WRONLY    0001
>
> #define O_RDWR    0002
>
>  
>
> *but in src/include/lwip/sockets.h , the value is:*
>
>  
>
> #ifndef O_NONBLOCK
>
> #define O_NONBLOCK  1 /* nonblocking I/O */
>
> #endif
>
> #ifndef O_NDELAY
>
> #define O_NDELAY    O_NONBLOCK /* same as O_NONBLOCK, for compatibility */
>
> #endif
>
> #ifndef O_RDONLY
>
> #define O_RDONLY    2
>
> #endif
>
> #ifndef O_WRONLY
>
> #define O_WRONLY    4
>
> #endif
>
> #ifndef O_RDWR
>
> #define O_RDWR      (O_RDONLY|O_WRONLY)
>
> #endif
>
>  
>
> *any reason of the difference?*
>
>  
>
>  
>
> BRs//tangyao
>
>  
>
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] post a question

[goldsi...@gmx.de]

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  not receiving any data.
>
> Could you please help me to make the communication work. I was trying to
> set a fixed VLAN ID to my mbed but it didn't work with me.

The core lwIP code has support for VLAN (see ETHARP_SUPPORT_VLAN,
ETHARP_VLAN_CHECK, LWIP_VLAN_PCP and LWIP_HOOK_VLAN_SET), however,
yourquestion seems out of place here, as it seems related to the mbed
configuration.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 and properly
> receive an IP address, followed by ARP announcements. The device seems
> to survive an initial disconnect, sending a Request to validate it’s IP
> and an ACK from the DHCP server once reconnected. However, further
> disconnects and reconnections appear to confuse the device.
>
>  
>
> I have a PHY interrupt callback which calls netif_set_link_down() and
> netif_set_link_up() when the PHY link status changes. Since the dhcp
> state was bound dhcp_reboot() is called from dhcp_network_changed().
> This all seems to work fine until we hit the dhcp_timeout() and my dhcp
> tries are greater than or equal to REBOOT_TRIES, at which point it calls
> dhcp_discover() and I get stuck in a loop where the device sends a
> discovery message and is offered an IP address back but it gets ignored.
>
>  
>
> By increasing REBOOT_TRIES I am able to get a few more reconnections
> without problem, but at some point it always seems to get stuck in that
> dhcp discovery loop.
>
>  
>
> I am unsure if I have done something incorrectly or if I am confusing
> the DHCP state machine, but from everything I have read with regards to
> LWIP > 2.x.x
>
> calling netif_set_link_up/down() should be sufficient for maintaining
> DHCP once dhcp_start() has been called.
>
>  
>
> Any help would be greatly appreciated.

I'm not aware of a bug here, but I'm not sure. It would probably be best
if you could reproduce this with a unit test?

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 download
> 'https://urldefense.com/v3/__http://contrib-2.1.0.zip__;!!GW_tK9tuM96ueW3v!gSRUmA8Qpg8k30x6dO3ad22-SKpjR9sa5rCxU87u4ymCLLq28_jTkC978tccUeA00MLCeQ$
>  ' from the savannah download section. You'll find the Linux and Windows 
> 'arch' ports there.

I did not send that link. It got scrambled, probably by some "secuirty"
feature in your mailing system?

See my original mail here:

https://lists.nongnu.org/archive/html/lwip-users/2021-02/msg00022.html

Well, if you also cannot read this link, go to our archives on savannah.
Or get a better mail account... :-)

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 were in another git tree.
>
> I looked through our email thread but I can't find where you suggested that.

Well, the default 'tree' in the gitweb URL I wrote is always master, so
that's why you would have looked at the master branch.

However, my bad, I though I remembered you could download a snapshot of
the master branch there, but I failed to find it now...

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 download
'contrib-2.1.0.zip' from the savannah download section. You'll find the
Linux and Windows 'arch' ports there.

>
> Where can I find the 'master' git branch?

If you clone our git repo, master is default. Also, in the gitweb view,
selecting 'tree' will bring you to the master branch by default:

https://git.savannah.nongnu.org/cgit/lwip.git/tree/

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

Am 10.02.2021 um 20:49 schrieb Curtiss, Robert:
> Simon,
>
> I downloaded the file  'lwip-2.1.2.zip'  from this page:
> http://download.savannah.nongnu.org/releases/lwip/
>
> I could not find an 'arch' or 'priv' directory in that archive.

Well, I do see a priv directory there.

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 were in another git tree.

Regards,
Simon

>
> Bob
> _
> 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 Of goldsi...@gmx.de
> Sent: Monday, February 8, 2021 19:52
> To: Mailing list for lwIP users 
> Subject: Re: [lwip-users] Incorporating lwIP Into VisualGDB Project
>
>  External Email
>
> 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 the project's include paths. When I build I get 
>> errors such as these:
>>
>> lwIP\include\lwip\arch.h(48,10): error :  arch/cc.h: No such file or 
>> directory
>
> That's part of the port to your compiler. It's not part of what we
> normally provide. We do provide example ports to Linux and Windows. Just
> browse or sources in gitweb or download them from there:
>
> https://urldefense.com/v3/__https://git.savannah.nongnu.org/cgit/lwip.git__;!!GW_tK9tuM96ueW3v!imrqQ5xBKqZA72c-ZT5-WS8sLpbUXcIxw22f9J5J2YUSmGSAPBcZYiuwWTBKjeCtYSGs4g$
>
> Since you're doing this for an STM32, why don't you try to create a
> project for that SoC using their tool (stm cube)? That might give you at
> least a start.
>
>>
>> ...and...
>> lwIP\include\lwip\memp.h(49,10): error :  lwip/priv/memp_std.h: No such file 
>> or directory
>>
>> I can't find directories named 'arch' or 'priv' anywhere in the 'src' 
>> directory.
>
> Now that's strange. That file should reside in 'src/include/lwip/priv'.
> Again, you might want to check your sources in comparison to our
> sources. Seems like something is missing?
>
>>
>> Are these required for a bare metal build? If so, where can I find them; if 
>> not, how can I get around this?
>
> Yes, these are required.
>
> Regards,
> Simon
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://urldefense.com/v3/__https://lists.nongnu.org/mailman/listinfo/lwip-users__;!!GW_tK9tuM96ueW3v!imrqQ5xBKqZA72c-ZT5-WS8sLpbUXcIxw22f9J5J2YUSmGSAPBcZYiuwWTBKjeDQSGvrjQ$
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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 the project's include paths. When I build I get errors 
> such as these:
>
> lwIP\include\lwip\arch.h(48,10): error :  arch/cc.h: No such file or directory

That's part of the port to your compiler. It's not part of what we
normally provide. We do provide example ports to Linux and Windows. Just
browse or sources in gitweb or download them from there:

https://git.savannah.nongnu.org/cgit/lwip.git

Since you're doing this for an STM32, why don't you try to create a
project for that SoC using their tool (stm cube)? That might give you at
least a start.

>
> ...and...
> lwIP\include\lwip\memp.h(49,10): error :  lwip/priv/memp_std.h: No such file 
> or directory
>
> I can't find directories named 'arch' or 'priv' anywhere in the 'src' 
> directory.

Now that's strange. That file should reside in 'src/include/lwip/priv'.
Again, you might want to check your sources in comparison to our
sources. Seems like something is missing?

>
> Are these required for a bare metal build? If so, where can I find them; if 
> not, how can I get around this?

Yes, these are required.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwip stack

[goldsi...@gmx.de]

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 *default
> TCP/IP* stack from *Linux* kernel so that only *lwIP* will be left to
> handle all IP networking traffic ?

Why would you want that? And how should the result look like?

You should know that this is not an easy task: lwIP has not been written
for multiprocessing. In other words, unless using lwIP in a single
process only, you'd end up writing a *lot* of code. This can be done
(e.g. like lwIP has been included into Minix), but it's a lot of work.

I guess the easiest thing to do would be to disable TCP/IP support in
your kernel to make sure it doesn't implement IP at all. Then you can
just run lwIP in a single process, interfacing the network stack through
PF_PACKET sockets...

But the question remains: why would you want to do that?

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

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'. Obviously, you
only need to include .c files, so nothing from 'include'.

Additionally, you need to add 'src/include' to your project's include
paths. For the core files, that should be it.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Lwip 10Gbit

[goldsi...@gmx.de]

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 connection speed. Being like that, you need to
make sure your PHY and MAC drivers support it.

Then, you need to know at which actual data rate you want to transfer.
I'd assume getting full UDP througput at 10 Gigabit will be quite tough.

But this largely depends on both the MAC driver and the optimizations
you do for lwIP (e.g. enable hw checksum features, improve memcpy code,
ensure you use zero copy transfers, improve cache invalidation or use
coherent access, etc.).

Lastly, the speed of both CPU and RAM will have an impact.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

Am 01.02.2021 um 18:14 schrieb Marco Giammarini:
> You mean genfiles_example
> /genfiles_example.c
> ?
> But, how can I use this code with CGI reply?

Have you actually had a look at the code? Did you see the comment in
line 109?

/* instead of doing memcpy, you would generate e.g. a JSON here */

https://github.com/lwip-tcpip/lwip/blob/12b45506dd667a05aa198f0592625901e54267bc/contrib/examples/httpd/genfiles_example/genfiles_example.c#L109

Just create your response there instead of doing a memcpy and you should
be good.


Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

Am 29.01.2021 um 13:30 schrieb Thompson, Jeff:
> There is also SharkTap, which I use.

Right. I also use that (the USB version) sometimes. It has the same
downside of stripping priority-only VLAN tags, though, which can be a
pain if you're debugging that. Also, if I remember correctly, I think it
breaks LLDP as it contains a switch, so it's not a real tap.

But for this issue, it should probably be good enough.

Regards,
Simon

>
> http://www.midbittech.com/index.html
>
> Jeff Thompson  |  Senior Electrical Engineer-Firmware
> +1 704 752 6513 x1394
> www.invue.com
> -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 reset to be able to send mqtt msg bigger than 1460 bytes
>
> Am 29.01.2021 um 12:26 schrieb Dejan Spasovski:
>> From: *Dejan Spasovski* > <mailto:spasovski.de...@gmail.com>>
>> Date: Fri, Jan 29, 2021 at 12:23 PM
>> Subject: Re: [lwip-devel] [bug #59966] After several hours of working,
>> need router reset to be able to send mqtt msg bigger than 1460 bytes
>> To: mailto:goldsi...@gmx.de>>
>>
>>
>> Many thanks for the reply,
>>
>> Can you tell me please how to setup wireshark between a hardware
>> device and router, do I need a switch working in promiscuous mode?
>>
>> I have microtik router in hand I am checking to see if it has this
>> mode... in between any other ideas?
>
> I guess what you're looking for is a "mirror port" on a swich?
>
> You might want to invest in a TAP if you do this more often. A mirror port on 
> a switch is not that ideal as it migth get the timing wrong (or even migth 
> drop packets, you never know).
>
> So, either by an expensive TAP (e.g. search for ProfiTAP), a cheap TAP ( 
> tested one for ~150 EUR and it worked quite nice, although it strips VLAN 
> tags) or build one yourself (with the downside that you need 2 network cards 
> to monitor, one for TX and one for RX) like here:
> https://www.securityforrealpeople.com/2014/09/how-to-build-10-network-tap.html
> (only works for 100 mbit/s, not for gigabit).
>
> The cheapest solution might be to create a software bridge using a windows or 
> Linux PC (just google it) and then using wireshark on the bridge netif.
>
> Regards,
> Simon
>
>>
>> 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 Macedonia
>>
>>    
>>
>> On Fri, Jan 29, 2021, 11:09 goldsi...@gmx.de <mailto:goldsi...@gmx.de>
>> mailto:goldsi...@gmx.de>> wrote:
>>
>> [Moved here from an invalid bug report]
>>
>> Am 29.01.2021 um 10:56 schrieb Dejan:
>> > [..]
>> > Hi,
>> >
>> > We are company producing seismic sensors based on STM32H7 mcu's
>> running lwip
>> > and we use mqtt to connect to our own cloud server. On starrup
>> devices send a
>> > series of short messages and then after this usual handshake with
>> the server
>> > they start streaming bigger packets of sensor data on a specific
>> mqtt topic.
>> > The message size is usually from 4KB up to 32 KB sent each second.
>> Everything
>> > seems to work fine until after several hours (usually 12 to 24
>> hrs), we find
>> > that we need to restart the main router, otherwise the streaming
>> of mentioned
>> > packets will be blocked from the router to the server. However the
>> device is
>> > still able to send tcp mqtt packets that fit in one TCP frame.
>> Once the TCP
>> > message is to be fragmented in more than one frame (is bigger than
>> 1460 buyes)
>> > the router will not let it through untill we reset it and we get
>> another day
>> > of a working device.
>> >
>> > This behaviour is our several months nightmare and we cannot wrap
>> our heads
>> > arroud it...
>> >
>> > If any of you experts have an idea what could be the problem
>> please reply.
>> >
>> > We tried:
>> > New server/ broker, different port numbers, different MCU series.
>> &g

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

[goldsi...@gmx.de]

Am 29.01.2021 um 12:26 schrieb Dejan Spasovski:
> From: *Dejan Spasovski*  <mailto:spasovski.de...@gmail.com>>
> Date: Fri, Jan 29, 2021 at 12:23 PM
> Subject: Re: [lwip-devel] [bug #59966] After several hours of working,
> need router reset to be able to send mqtt msg bigger than 1460 bytes
> To: mailto:goldsi...@gmx.de>>
>
>
> Many thanks for the reply,
>
> Can you tell me please how to setup wireshark between a hardware device
> and router, do I need a switch working in promiscuous mode?
>
> I have microtik router in hand I am checking to see if it has this
> mode... in between any other ideas?

I guess what you're looking for is a "mirror port" on a swich?

You might want to invest in a TAP if you do this more often. A mirror
port on a switch is not that ideal as it migth get the timing wrong (or
even migth drop packets, you never know).

So, either by an expensive TAP (e.g. search for ProfiTAP), a cheap TAP (
tested one for ~150 EUR and it worked quite nice, although it strips
VLAN tags) or build one yourself (with the downside that you need 2
network cards to monitor, one for TX and one for RX) like here:
https://www.securityforrealpeople.com/2014/09/how-to-build-10-network-tap.html
(only works for 100 mbit/s, not for gigabit).

The cheapest solution might be to create a software bridge using a
windows or Linux PC (just google it) and then using wireshark on the
bridge netif.

Regards,
Simon

>
> 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 Macedonia
>
>    
>
> On Fri, Jan 29, 2021, 11:09 goldsi...@gmx.de <mailto:goldsi...@gmx.de>
> mailto:goldsi...@gmx.de>> wrote:
>
> [Moved here from an invalid bug report]
>
> Am 29.01.2021 um 10:56 schrieb Dejan:
> > [..]
> > Hi,
> >
> > We are company producing seismic sensors based on STM32H7 mcu's
> running lwip
> > and we use mqtt to connect to our own cloud server. On starrup
> devices send a
> > series of short messages and then after this usual handshake with
> the server
> > they start streaming bigger packets of sensor data on a specific
> mqtt topic.
> > The message size is usually from 4KB up to 32 KB sent each second.
> Everything
> > seems to work fine until after several hours (usually 12 to 24
> hrs), we find
> > that we need to restart the main router, otherwise the streaming
> of mentioned
> > packets will be blocked from the router to the server. However the
> device is
> > still able to send tcp mqtt packets that fit in one TCP frame.
> Once the TCP
> > message is to be fragmented in more than one frame (is bigger than
> 1460 buyes)
> > the router will not let it through untill we reset it and we get
> another day
> > of a working device.
> >
> > This behaviour is our several months nightmare and we cannot wrap
> our heads
> > arroud it...
> >
> > If any of you experts have an idea what could be the problem
> please reply.
> >
> > We tried:
> > New server/ broker, different port numbers, different MCU series.
> >
> > Can it be that our low level protocol for TCP is doing something
> wrong so the
> > router remembers this device mac address and wont let it send
> fragmented
> > msgs?
> >
> > The last thing we tried is to change the MAC address of the device
> during the
> > blockage mode and then communication went through until several
> hours later to
> > fall in the same state.
> >
> > Please throw any ideas you have in mind we need to deliver this
> product soon
> > but its obviously no good as it is.
>
> Have you tried monitoring the connection between your device and the
> router using wireshark? That should be the first thing to do, so you
> know what actually happens. Without that, you're practically sitting in
> the dark, doing blind accusations ;-)
>
> Regards,
> Simon
>


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users