Re: [lwip-users] Memory Limitation of lwIP?

[nrichard]

goldsi...@gmx.de wrote
> nrichard wrote:
>> I have been able to get these all running
>> at the same time using the HEAP? method by setting both MEM_LIBC_MALLOC
>> and
>> MEMP_MEM_MALLOC to 1.  However it is not consistent.  Sometimes the
>> system
>> tells me "memp_malloc: out of memory in pool PBUF_POOL" even though I'm
>> using the HEAP method (I thought).
> 
> This is expected.  Although using the heap instead of multiple pools,
> statistics and error messages
> are still kept per pool, as this makes it easier to start with heap and
> use the statistics to size the pools later.
> 
>> Is it bad to have all these applications running off of the HEAP method?
> 
> You should be aware of the possibility of heap fragmentation and the fact
> that memory allocation
> can at some point get really slow depending on the free block count and
> sizes on your heap.
> 
> Other than that, it should work. For the reasons above, pools are
> preferred though.

I'm going to try using pools, just to see if it works better for my system.

I have gathered the following memory results for pools:

MEM HEAP
avail: 43008
used: 0
max: 5144
err: 0

MEM UDP_PCB
avail: 2
used: 1
max: 1
err: 0

MEM TCP_PCB
avail: 4
used: 0
max: 4
err: 0

MEM TCP_PCB_LISTEN
avail: 8
used: 2
max: 2
err: 0

MEM TCP_SEG
avail: 16
used: 0
max: 4
err: 0

MEM REASSDATA
avail: 2
used: 0
max: 0
err: 0

MEM FRAG_PBUF
avail: 6
used: 0
max: 0
err: 0

MEM SYS_TIMEOUT
avail: 3
used: 2
max: 3
err: 0

MEM PBUF_REF/ROM
avail: 4
used: 0
max: 2
err: 0

MEM PBUF_POOL
avail: 32
used: 16
max: 17
err: 0

If I'm using pools now, does it make sense for MEM HEAP to be using 5144 of
43008?  This is definitely a decrease from before (35k down to 5k).

I also see "memp_malloc: out of memory in pool TCP_PCB" being printed each
time I visit a web page.  I have my pbuf pool set to 32, yet it only uses
16.  Is this also normal behavior?

This also broke functionality for SNMP, but I will look into that
afterwards.

Plus side: hasn't crashed yet.



--
View this message in context: 
http://lwip.100.n7.nabble.com/Memory-Limitation-of-lwIP-tp30350p30375.html
Sent from the lwip-users mailing list archive at Nabble.com.

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

Re: [lwip-users] Advice on wifi module

[u123]

Simon Koudijs | Intellifi wrote
> Hello everyone,
> 
> I'm working a project that uses wired Ethernet, lwip is working pretty 
> nice there!
> 
> Now we would like to start using wifi as well. We are now searching for 
> a suitable and cheap wifi module that can be used on the ethernet level. 
> Given the right drivers it should just operate as a second netif in 
> lwip.
> 
> I would really like to know if anyone has already gone down this path, 
> and could advice me on the kind of module that works for him/her. 
> Perhaps an example with working drivers as well?

Hello all,
we are in the same situation and we have the same question but 4 years
later... Are there new ideas and/or solutions?

Thanks to all



--
View this message in context: 
http://lwip.100.n7.nabble.com/Advice-on-wifi-module-tp22092p30369.html
Sent from the lwip-users mailing list archive at Nabble.com.

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

Re: [lwip-users] Limiting the number of connections: Possible bug with MEMP_NUM_TCP_PCB?

[Tony]

So, I found the problem on my end:
The initialization code was called twice...

The first time when NETIF was UP, the second time when DHCP got an
IP-address... (And the initialization the second time obviously was badly
written and screwed up the list of lpcbs)

I guess this behaved differently in 1.3.2, as in 2.0.2 there was a split
between link and netif.

Sorry to have bothered you with such a rookie mistake...


(Now I have still problem with reset packages for the n+1 connections...
But this time I will debug more before posting...)


On 4 August 2017 at 11:55, Tony  wrote:

>
>
> _tcppcb = tcp_new();
> ...
>
> tcp_bind(_tcppcb, IP_ADDR_ANY, _port);
>
> // tcp deallocates _pcb, see wiki of lwIP
> struct tcp_pcb * listen_pcb = tcp_listen(_tcppcb);
> ...
>
> _tcppcb = listen_pcb;
>
> tcp_accept(_tcppcb, _netsrv_accept_cb);
>
> On 4 August 2017 at 11:43, Tony  wrote:
>
>> One more observation from a debugging session (with n=2) with these
>> settings
>>
>> #define MEMP_NUM_TCP_PCB2
>> #define MEMP_NUM_TCP_PCB_LISTEN 2
>>
>> (Hex numbers are addresses of pcbs or lpcbs)
>>
>> Two listening lpcb initially:
>> 0xb78c
>> 0xb76c
>>
>> The first two connections use the following pcbs:
>> 0xbab4(pcb first connection)
>> 0xba18(pcb second connection)
>>
>> n+1 (third connection in this example) gets this pcb
>> 0xbab4(reuses pcb from first connection)
>> => Now we have "lost" the lpcb 0xb76c !!!
>>
>> n+2 gets this pcb
>> 0xb76c (this was the starting address of first "listening pcb", this
>> "normal pcb will overlap with second lpcb !!!)
>> => This overwrites the "last remaining" listening pcb !!!
>>
>> If I leave MEMP_NUM_TCP_PCB at 2, but increase the
>> MEMP_NUM_TCP_PCB_LISTEN to 6 I get almost identical behavior (different
>> addresses obviously) with the same failure at n+2 connection (one lpcb
>> dropped at n+1, last remaining lpcb overwritten at n+2).
>>
>> I will not rule out that some LWIP settings (maybe pcb memory allocation
>> settings?) are wrong in my project. Is there any setting I could try?
>>
>>
>>
>>
>
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Limiting the number of connections: Possible bug with MEMP_NUM_TCP_PCB?

[Tony]

And one more thing:

In our app, when the network starts, the following code is how the
listening is initialized. This was working OK in 1.3.2, but I suspect this
breaks 2.0.2 and could cause the problems I see now. Is this a correct way
to initialize the listening connection, or is this code wrong?

_tcppcb = tcp_new();
...

tcp_bind(_tcppcb, IP_ADDR_ANY, _port);

// tcp deallocates _pcb, see wiki of lwIP
struct tcp_pcb * listen_pcb = tcp_listen(_tcppcb);
...

_tcppcb = listen_pcb;

tcp_accept(_tcppcb, _netsrv_accept_cb);

On 4 August 2017 at 11:43, Tony  wrote:

> One more observation from a debugging session (with n=2) with these
> settings
>
> #define MEMP_NUM_TCP_PCB2
> #define MEMP_NUM_TCP_PCB_LISTEN 2
>
> (Hex numbers are addresses of pcbs or lpcbs)
>
> Two listening lpcb initially:
> 0xb78c
> 0xb76c
>
> The first two connections use the following pcbs:
> 0xbab4(pcb first connection)
> 0xba18(pcb second connection)
>
> n+1 (third connection in this example) gets this pcb
> 0xbab4(reuses pcb from first connection)
> => Now we have "lost" the lpcb 0xb76c !!!
>
> n+2 gets this pcb
> 0xb76c (this was the starting address of first "listening pcb", this
> "normal pcb will overlap with second lpcb !!!)
> => This overwrites the "last remaining" listening pcb !!!
>
> If I leave MEMP_NUM_TCP_PCB at 2, but increase the MEMP_NUM_TCP_PCB_LISTEN
> to 6 I get almost identical behavior (different addresses obviously) with
> the same failure at n+2 connection (one lpcb dropped at n+1, last remaining
> lpcb overwritten at n+2).
>
> I will not rule out that some LWIP settings (maybe pcb memory allocation
> settings?) are wrong in my project. Is there any setting I could try?
>
>
>
>
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Limiting the number of connections: Possible bug with MEMP_NUM_TCP_PCB?

[Tony]

One more observation from a debugging session (with n=2) with these settings

#define MEMP_NUM_TCP_PCB2
#define MEMP_NUM_TCP_PCB_LISTEN 2

(Hex numbers are addresses of pcbs or lpcbs)

Two listening lpcb initially:
0xb78c
0xb76c

The first two connections use the following pcbs:
0xbab4(pcb first connection)
0xba18(pcb second connection)

n+1 (third connection in this example) gets this pcb
0xbab4(reuses pcb from first connection)
=> Now we have "lost" the lpcb 0xb76c !!!

n+2 gets this pcb
0xb76c (this was the starting address of first "listening pcb", this
"normal pcb will overlap with second lpcb !!!)
=> This overwrites the "last remaining" listening pcb !!!

If I leave MEMP_NUM_TCP_PCB at 2, but increase the MEMP_NUM_TCP_PCB_LISTEN
to 6 I get almost identical behavior (different addresses obviously) with
the same failure at n+2 connection (one lpcb dropped at n+1, last remaining
lpcb overwritten at n+2).

I will not rule out that some LWIP settings (maybe pcb memory allocation
settings?) are wrong in my project. Is there any setting I could try?
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] TCP problems using pppos on stm32

[Роман Торопов]

Hi, Sylvain, I am grateful for your advice and help. I found hardware
problem in my project.

27 июля 2017 г. 19:40 пользователь "Sylvain Rochet" 
написал:

Hi Roman,

On Wed, Jul 26, 2017 at 06:08:55AM -0700, Roman wrote:
> Hi, lwip. I still can't solve my problem, it has been going on for a long
> time, and I feel very stupid.
> When I stopped using sys_timeout / sys_untimout and started using the
> FreeRTOS timers, the average transmission time was about 15 minutes when I
> removed the FreeRTOS timer and started using pppos_input_tcpip () in the
> while cycle, the average transmission time was approximately 5 minutes.
What
> do I mean when I say "average transmission time": through sockets I
> continuously send a small message to the server with a specified period,
and
> the server answers me.
> As can be understood from what I said above, the situation only worsened,
> but I hope this will help to localize the problem.
> When I tried to debug a program, I noticed that when the transfer stops in
> the tcp_out () function, the tcp_out_segment () function is no longer
> called.
> My modified modem driver: modem.c
> 

I'm no TCP expert. But, since it involve PPP, could you at least check
that PPP is not the issue here by testing the throughput over a long
period of time using simple ICMP or UDP packets ?  You really have to
troubleshoot layer by layer.

Sylvain

___
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] Limiting the number of connections: Possible bug with MEMP_NUM_TCP_PCB?

[Tony]

On 3 August 2017 at 21:16, goldsi...@gmx.de  wrote:

> Tony wrote:
>
>> The aim is to only allow n open TCP connection at a time, and reject all
>> further connection requests. This worked reasonably well in 1.3.2, but now
>> fails in 2.0.2.
>> [..]
>> HOWEVER: this n+1 connection terminates the very 1st connection (takes
>> over the 1st PCB?).
>>
>
> Although it's strange it's like that, this is expected behaviour of
> tcp_alloc(). I compared 2.0.2 to 1.3.2 and I don't really see a difference
> though...
> Anyway, the pcb limitation might not be the correct solution. A listen
> backlog might better do what you want.
> If you want to stay with your pcb limitation, try calling
> "tcp_setprio(newpcb, TCP_PRIO_MAX);" after you allocate the first n pcbs.
> That should prevent tcp_alloc from reusing them.
>

Good! This fixes the "n+1 behavior"!

For testing I removed the call to tcp_kill_prio(prio); from tcp_alloc(),
which should have the same effect (if I am not mistaken). And this seems to
do the trick. I need to find the correct position for setting the priority
without breaking anything...

(I had already removed the tcp_kill_prio(prio) call in 1.3.2 if I am not
mistaken, and there was some bug in our app or LWIP which caused the app to
crash when LWIP send the reset packages for the n+1 connection - I failed
to try it 2.0.2. as well, my bad)

However for one time I still managed to hit the "n+2 behavior"... (more
below about n+2 below)


>
>
>> Now, if I leave all previous connections open and make a n+1 connection
>> (the 6th connection in this example) I hit an exception (the processor
>> tries to access memory that does not exists and I hit the exception handler
>> in the MCU).
>>
>
>
I narrowed down the origin of the fatal exception in tcp_alloc() to the
>> code following this comment:
>> /* zero out the whole pcb, so there is no need to initialize members to
>> zero */
>>
>> The problem at that point seems to be that a struct tcp_pcb_listen (that
>> is still in use) is reused and overwritten as a struct tcp_pcb...
>>
>
> Ehrm, the pcb that is used there should *NOT* be a listen pcb. It comes
> from the MEMP_TCP_PCB pool, so it's a standard pcb. Why do you think it's a
> listen pcb which is still in use? This lets me think you have a port
> problem...
>

I simplified a bit too much the n+2 problem ... my apologies. This is what
happens:
tcp_alloc() initializes an existing struct tcp_pcb_listen (which is in use)
for use as a struct tcp_pcb.

tcp_alloc() finishes without problems.

But once tcp_input() accesses this pcb (as a listen pcb), the values the
pcb used to have are all whacked (the specific problem is the next pointer,
which now points to 0x04000400 if I am not mistaken). The exception happens
when tcp_input iterates over the listen pcbs after the comment:
/* Finally, if we still did not get a match, we check all PCBs that
are LISTENing for incoming connections. */

(It is actually the initializing of the "rcv_wnd" in the "normal pcb" in
tcp_alloc() that overwrites the next pointer in the "listen pcb" - which
seems strange, as they should not line up... I suspect there are more
things going on, which I don't grasp...)

The function tcp_input() was clearly not properly informed that one listen
pcb had been recycled. (Is there a reference counter for PCBs? Or how is
this handled?)

Unfortunately I lack insight into LWIP (and at the moment into our own
application code in that area) to pinpoint where the fault lies.

I will investigate further! I found some weirdness in our application which
I need to fix first.

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