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
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
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
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
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
Hello,
I am trying to fix a strange behavior I have with LWIP...
Quite possibly I am using the LWIP wrongly, but I am not sure. I took over
the maintaining of a embedded project which includes LWIP, and
unfortunately I have some problems with networking (and I now face a steep
learning curve, as