Marco Jakobs wrote:
> It's not that easy as we are using NAT which needs to be modified as some
> structures seems to have changed between LwIP 1.4.1 and 2.0.2.
Oh, yeah. Well, NAT should not be *that* different from any callback API
application...?
> I wanted to test the difference, but after
Hi Simon,
>Yes, but have you actually tested 2.0.x to see it increased?
Not yet. It's not that easy as we are using NAT which needs to be modified as
some structures seems to have changed between LwIP 1.4.1 and 2.0.2. I wanted to
test the difference, but after >100 compile errors I gave up for
Marco Jakobs wrote:
The memory issue is serious. A customer was asking for VJ compression
support, tried this today and BOOM, 3kB of RAM missing.
Yes, but have you actually tested 2.0.x to see it increased?
That's not fun, that's my daily business.
You're not the only one there ;-)
Just t
Hi,
On Tue, May 16, 2017 at 09:13:56PM +0200, goldsi...@gmx.de wrote:
> Sylvain Rochet wrote:
> >I checked if the issue was still there is the current master/2.0 branch,
> >you are right, this bug was fixed in commit fb07a28c99 ("fixed bug
> >#36388 (PPP: checksum-only in last pbuf leads to pbuf
Hi Simon,
>Marco, I know you always say you don't have the time to re-evaluate new
>verisons, but you could save us *and* yourself much time hunting those
>old bugs by just taking the time to upgrage ;-) There have been *many*
>bugs fixed since 1.4.1!
>The possibility of code size increaseme
Sylvain Rochet wrote:
I checked if the issue was still there is the current master/2.0 branch,
you are right, this bug was fixed in commit fb07a28c99 ("fixed bug
#36388 (PPP: checksum-only in last pbuf leads to pbuf with zero
length)") *FIVE* years ago.
:-))
Thanks, for jumping in, Sylvain!
Ma
Hi,
On Tue, May 16, 2017 at 10:48:26AM +0200, Simon Goldschmidt wrote:
> Marco Jakobs wrote:
> > That one deals with this:
> >
> > LWIP_ERROR("p_to != NULL", (p_to != NULL) || (p_from == NULL) ||
> > (p_from->len == NULL) , return ERR_ARG;);
>
> WTF? "-len == NULL"???
>
> > The assert comes fr
Marco Jakobs wrote:
> That one deals with this:
>
> LWIP_ERROR("p_to != NULL", (p_to != NULL) || (p_from == NULL) || (p_from->len
> == NULL) , return ERR_ARG;);
WTF? "-len == NULL"???
> The assert comes from the ICMP routine ;-) :
I rather guess the bug is in PPP (from 1.4.1) allocating a pbuf
>Have you checked the definition of LWIP_ERROR()?
>That line should return ERR_ARG if to is NULL but from is not (in other words,
>to is not large enough).
Good point! :-) Thanks for getting me to it.
Indeed, coming from PPP and the length does exactly fills the last from_pbuf up
to the last by
Marco Jakobs wrote:
> [..] but the bug is in the LWIP_ERROR line:
> The error kicks in when there is no next p_from pbuf (which is fine) or when
> there *is* a next p_to pbuf.
> In my opinion the error should kick in if there is either no active "p_from"
> or no active "p_to" at this place.
Have
Hi Simon,
I think I have found the issue but I don't deeply understand why this does not
crash the Ethernet version as this seems to be a bug in pbuf_copy ... but as
this is in a common used routine I want have your opinion on my fix.
I saw that the issue only happens when a pbuf is filled righ
Hi Simon,
>That suggests the pbuf chain is invalid, i.e. tot_len of the pbuf was more
>than the pbuf chain (via ->next) provided. I assume a pbuf allocation error
>somewhere.
>My suggestion would be to upgrade to 2.0.x and benefit of Sylvain's great work
>on PPP improvements!
Unfortunately tha
I wonder if that allocate is correct...
This is the pbuf debug output of the crashing 92 bytes ping via PPP:
pbuf_alloc(length=0)
pbuf_alloc: allocated pbuf 0021a5cc
pbuf_alloc(length=0) == 0021a5cc
pbuf_alloc(length=0)
pbuf_alloc: allocated pbuf 0021a53c
pbuf_alloc(length=0) == 0021a53c
pbuf_hea
Marco Jakobs wrote:
> In a test scenario we ran a ping test with various byte sizes via the PPP
> netif. With exactly the ping packet size of 92 bytes, our LwIP task crashes
> repeatedly into an assert:
>
> 15.05.17 11:07:17 ASSERT:
> C:/Projekte/TMO-100/Libraries/lwIP/src/core/pbuf.c:888:p_to
Hi,
during a test we ran into a serious issue and I'd be more than happy to get
some hints how to track that down.
In a test scenario we ran a ping test with various byte sizes via the PPP
netif. With exactly the ping packet size of 92 bytes, our LwIP task crashes
repeatedly into an assert:
15 matches
Mail list logo
