[lwip-users] getaddrinfo returning only IPv4 address

[antonio]

Hi All,
I am using LWIP with LWIPv4/6 (dual-stack enabled).
I used getaddrinfo to resolve some domains, and I am only getting an IPv4.
However, with my .c application on my Laptop connected to the same AP, I get
two addresses 

This is what I get when I use a c application on my Laptop.
./ip6 www.google.se
www.google.se: IPv4 = 216.58.211.131
www.google.se: IPv6 = 2a00:1450:400f:80c::2003

While my LWIP application I only get an IPv4, the IPv6 is zero bytes Only.
 dns_resolve www.google.fr 
www.google.fr @
216.58.207.195/b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
   

Below is the piece of code where I return the addresses, where rsp is a
struct of type
struct rsp{
  u8_t status; //==0 if we got at least one address, else 1
  u8_t addrlen; //if addr=4 only IPv4 is present, addrlen=16(Only IPv6),
addrlen=20, both are present
  u8_t ipaddr[20]; //first 4 bytes for IPv4 and remaining 16 for IPv6
};
rsp->addrlen = 0;
memset(rsp->ipaddr, 0, sizeof rsp->ipaddr);
for (cur = _list[0]; cur != NULL; cur = cur->ai_next){
if (cur->ai_family == AF_INET){
ipaddr_ptr = &(((struct sockaddr_in *)cur->ai_addr)->sin_addr);
if (rsp->addrlen == 0 || (rsp->addrlen == 16)){
rsp->status  = 0;
rsp->addrlen = rsp->addrlen + 4;
memcpy(>ipaddr[0], ipaddr_ptr, 4);
}
}else if(cur->ai_family == AF_INET6 || cur->ai_family == AF_UNSPEC){
#if LWIP_IPV4 && LWIP_IPV6
os_printf("%s: %d IPV6\n",__func__, __LINE__);
ipaddr_ptr = &(((struct sockaddr_in6
*)cur->ai_addr)->sin6_addr);
if (rsp->addrlen <= 4){
rsp->status  = 0;
rsp->addrlen = rsp->addrlen + 16;
memcpy(>ipaddr[4], ipaddr_ptr, 16);
os_printf("IPv6:%s\n", (char*)>ipaddr[4]);
}

#endif
}
if (rsp->addrlen > 16)
break;
}





--
Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html

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

Re: [lwip-users] tcp_active_pcbs corrupt after resetting connection ???

[Terence Darwen]

On Wed, Mar 27, 2019 at 4:13 PM Simon Goldschmidt  wrote:

>
>
> On 27.03.19 22:00, Terence Darwen wrote:
> > Hi Simon - Thanks for the reply.  I've made my own replies below:
> >
> >  > Hi, I'm using lwIP 1.41 with a Texas Instruments Tiva Launchpad
> > development
> >  > board (the TM4C1294).
> >  >>Now that's a really old version of lwIP!
> >
> > Yes, unfortunately 1.41 is the version that is packaged in TI's latest
> > release of Tivaware and not a more recent version.
> >
> >  > [..]
> >  > This code is run in the lwIPHostTimerHandler.  Which of course is
> called
> >  > from the Ethernet interrupt handler.
> >
> >  >>Wait a minute, "of course"? Have you read this (mostly valid for 1.4.x
> >  >>as well):
> >  >>https://www.nongnu.org/lwip/2_1_x/pitfalls.html
> >
> > Yes, I've been working with lwIP on the Tiva for some time now and have
> > been aware of these instructions for quite a while and have taken great
> > care to make sure all lwIP calls (all tcp_* calls) are made on a single
> > "thread", this being the Tiva's Ethernet interrupt.  For example, when
> > needing to send new data outside of the Ethernet interrupt I place the
> > data in a thread safe queue.  This queue is then processed (i.e. the
> > data from the queue is sent using tcp_wtite and tcp_output) only during
> > the Tiva's Ethernet interrupt.
> >
> >  > Based on other examples, I see no problem with this.
> >
> >  >>Ehrm, based on which examples?
> >
> > TI's Tivaware contains examples of using lwIP where the
> > lwIPHostTimerHandler function makes tcp_ calls.  The examples
> > have lwIPEthernetIntHandler() as the ISR, this calls  lwiplib.c's
> > lwIPServiceTimers() which calls lwIPHostTimerHandler()
> >
> >  >>When running code from ETH interrupt
> >  >>handler, you have to *know* what you are doing! Basically this means:
> >  >>*no* access into lwIP from any other interrupt priority or main loop
> >  >>*unless* the ethernet interrupt is disabled.
> >
> > Totally agree.  I've taken great care in my code to always do this and,
> > as far as I can tell, this is indeed what I am doing.  I never do any
> > calls into lwIP from anywhere except the Ethernet interrupt handler.
> >
> >  >> However, intermittently, it appears to corrupt the
> >  >> lwIP's tcp.c's tcp_active_pcbs linked list.
> >
> >  >And I would have written that as an example if you hadn't watched out
> >  >for what I wrote in the lines above ;-)
> >
> > Right, you're saying the tcp_active_pcbs linked list being corrupted
> > like this is a common result of multiple execution contexts in lwIP
> > code.  I could understand that.
> >
> >  >Try to clean up your code (in terms of execution threads) and if you
> >  >can, think about upgrading to a more recent version.
> >
> > The code is quite clean, and, as an experienced developer, I've reviewed
> > it many times to verify the logic is correct and no thread issues
> > exist.  Other than this issue I'm having, the 1.41 lib is performing
> > very well.  I'm doing a lot of communication with a number of clients
> > over long periods of time without any issues.  Unfortunately, using
> > non-Tivaware 3rd party code is probably not an option for me at this
> > point.  I do understand 1.41 is quite an old version of lwIP so if the
> > answer boils down to "upgrade" being the advised solution I could
> > understand this.
>
> Well, I'm sorry to say I cannot tell you what's the reason for the bug
> you're seeing. I cannot recall a specific bug leading to this, but of
> course it could be that it's a bug that has been fixed by now. However,
> using lwIP like that (only in the ETH interrupt) is quite uncommon and
> hard to review, so I wouldn't put concurrency problems aside as a reason
> here...
>

Okay, no problem, Simon.  Thank you for the replies.
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] tcp_active_pcbs corrupt after resetting connection ???

[Simon Goldschmidt]

On 27.03.19 22:00, Terence Darwen wrote:

Hi Simon - Thanks for the reply.  I've made my own replies below:

 > Hi, I'm using lwIP 1.41 with a Texas Instruments Tiva Launchpad
development
 > board (the TM4C1294).
 >>Now that's a really old version of lwIP!

Yes, unfortunately 1.41 is the version that is packaged in TI's latest
release of Tivaware and not a more recent version.

 > [..]
 > This code is run in the lwIPHostTimerHandler.  Which of course is called
 > from the Ethernet interrupt handler.

 >>Wait a minute, "of course"? Have you read this (mostly valid for 1.4.x
 >>as well):
 >>https://www.nongnu.org/lwip/2_1_x/pitfalls.html

Yes, I've been working with lwIP on the Tiva for some time now and have
been aware of these instructions for quite a while and have taken great
care to make sure all lwIP calls (all tcp_* calls) are made on a single
"thread", this being the Tiva's Ethernet interrupt.  For example, when
needing to send new data outside of the Ethernet interrupt I place the
data in a thread safe queue.  This queue is then processed (i.e. the
data from the queue is sent using tcp_wtite and tcp_output) only during
the Tiva's Ethernet interrupt.

 > Based on other examples, I see no problem with this.

 >>Ehrm, based on which examples?

TI's Tivaware contains examples of using lwIP where the
lwIPHostTimerHandler function makes tcp_ calls.  The examples
have lwIPEthernetIntHandler() as the ISR, this calls  lwiplib.c's
lwIPServiceTimers() which calls lwIPHostTimerHandler()

 >>When running code from ETH interrupt
 >>handler, you have to *know* what you are doing! Basically this means:
 >>*no* access into lwIP from any other interrupt priority or main loop
 >>*unless* the ethernet interrupt is disabled.

Totally agree.  I've taken great care in my code to always do this and,
as far as I can tell, this is indeed what I am doing.  I never do any
calls into lwIP from anywhere except the Ethernet interrupt handler.

 >> However, intermittently, it appears to corrupt the
 >> lwIP's tcp.c's tcp_active_pcbs linked list.

 >And I would have written that as an example if you hadn't watched out
 >for what I wrote in the lines above ;-)

Right, you're saying the tcp_active_pcbs linked list being corrupted
like this is a common result of multiple execution contexts in lwIP
code.  I could understand that.

 >Try to clean up your code (in terms of execution threads) and if you
 >can, think about upgrading to a more recent version.

The code is quite clean, and, as an experienced developer, I've reviewed
it many times to verify the logic is correct and no thread issues
exist.  Other than this issue I'm having, the 1.41 lib is performing
very well.  I'm doing a lot of communication with a number of clients
over long periods of time without any issues.  Unfortunately, using
non-Tivaware 3rd party code is probably not an option for me at this
point.  I do understand 1.41 is quite an old version of lwIP so if the
answer boils down to "upgrade" being the advised solution I could
understand this.


Well, I'm sorry to say I cannot tell you what's the reason for the bug
you're seeing. I cannot recall a specific bug leading to this, but of
course it could be that it's a bug that has been fixed by now. However,
using lwIP like that (only in the ETH interrupt) is quite uncommon and
hard to review, so I wouldn't put concurrency problems aside as a reason
here...

Regards,
Simon

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

Re: [lwip-users] tcp_active_pcbs corrupt after resetting connection ???

[Terence Darwen]

Hi Simon - Thanks for the reply.  I've made my own replies below:

> Hi, I'm using lwIP 1.41 with a Texas Instruments Tiva Launchpad
development
> board (the TM4C1294).

>>Now that's a really old version of lwIP!

Yes, unfortunately 1.41 is the version that is packaged in TI's latest
release of Tivaware and not a more recent version.

> [..]
> This code is run in the lwIPHostTimerHandler.  Which of course is called
> from the Ethernet interrupt handler.

>>Wait a minute, "of course"? Have you read this (mostly valid for 1.4.x
>>as well):
>>https://www.nongnu.org/lwip/2_1_x/pitfalls.html

Yes, I've been working with lwIP on the Tiva for some time now and have
been aware of these instructions for quite a while and have taken great
care to make sure all lwIP calls (all tcp_* calls) are made on a single
"thread", this being the Tiva's Ethernet interrupt.  For example, when
needing to send new data outside of the Ethernet interrupt I place the data
in a thread safe queue.  This queue is then processed (i.e. the data from
the queue is sent using tcp_wtite and tcp_output) only during the Tiva's
Ethernet interrupt.

> Based on other examples, I see no problem with this.

>>Ehrm, based on which examples?

TI's Tivaware contains examples of using lwIP where the
lwIPHostTimerHandler function makes tcp_ calls.  The examples
have lwIPEthernetIntHandler() as the ISR, this calls  lwiplib.c's
lwIPServiceTimers() which calls lwIPHostTimerHandler()

>>When running code from ETH interrupt
>>handler, you have to *know* what you are doing! Basically this means:
>>*no* access into lwIP from any other interrupt priority or main loop
>>*unless* the ethernet interrupt is disabled.

Totally agree.  I've taken great care in my code to always do this and, as
far as I can tell, this is indeed what I am doing.  I never do any calls
into lwIP from anywhere except the Ethernet interrupt handler.

>> However, intermittently, it appears to corrupt the
>> lwIP's tcp.c's tcp_active_pcbs linked list.

>And I would have written that as an example if you hadn't watched out
>for what I wrote in the lines above ;-)

Right, you're saying the tcp_active_pcbs linked list being corrupted like
this is a common result of multiple execution contexts in lwIP code.  I
could understand that.

>Try to clean up your code (in terms of execution threads) and if you
>can, think about upgrading to a more recent version.

The code is quite clean, and, as an experienced developer, I've reviewed it
many times to verify the logic is correct and no thread issues exist.
Other than this issue I'm having, the 1.41 lib is performing very well.
I'm doing a lot of communication with a number of clients over long periods
of time without any issues.  Unfortunately, using non-Tivaware 3rd party
code is probably not an option for me at this point.  I do understand 1.41
is quite an old version of lwIP so if the answer boils down to "upgrade"
being the advised solution I could understand this.
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] tcp_active_pcbs corrupt after resetting connection ???

[goldsi...@gmx.de]

Am 27.03.2019 um 20:05 schrieb Terence D:

Hi, I'm using lwIP 1.41 with a Texas Instruments Tiva Launchpad development
board (the TM4C1294).


Now that's a really old version of lwIP!


[..]
This code is run in the lwIPHostTimerHandler.  Which of course is called
from the Ethernet interrupt handler.


Wait a minute, "of course"? Have you read this (mostly valid for 1.4.x
as well):
https://www.nongnu.org/lwip/2_1_x/pitfalls.html


Based on other examples, I see no problem with this.


Ehrm, based on which examples? When running code from ETH interrupt
handler, you have to *know* what you are doing! Basically this means:
*no* access into lwIP from any other interrupt priority or main loop
*unless* the ethernet interrupt is disabled.


However, intermittently, it appears to corrupt the
lwIP's tcp.c's tcp_active_pcbs linked list.


And I would have written that as an example if you hadn't watched out
for what I wrote in the lines above ;-)

Try to clean up your code (in terms of execution threads) and if you
can, think about upgrading to a more recent version.

Regards,
Simon

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

[lwip-users] tcp_active_pcbs corrupt after resetting connection ???

[Terence D]

Hi, I'm using lwIP 1.41 with a Texas Instruments Tiva Launchpad development
board (the TM4C1294).  I'm seeing an odd issue occur when resetting a
connection during stress testing.  The Tiva board is the TCP/IP server.  I
have a client application I made that runs on a Windows machine and connects
automatically when starting up.

My stress test consists of making multiple connections to the board.  A new
connection - a new instance of the Windows client app - is made every two
seconds until there are six connections.  I then wait five seconds, kill all
of the Windows client apps and start over making new connections every two
seconds.

The Tiva dev board does some various send/receive communication between the
client app and the board - which all appears to work fine - but then under
certain logic will reset the client connection using the following code:

tcp_arg(pcb, NULL);
tcp_sent(pcb, NULL);
tcp_recv(pcb, NULL);
tcp_err(pcb, NULL);
tcp_close(pcb);

This code is run in the lwIPHostTimerHandler.  Which of course is called
from the Ethernet interrupt handler.  Based on other examples, I see no
problem with this.  However, intermittently, it appears to corrupt the
lwIP's tcp.c's tcp_active_pcbs linked list.

Maybe one out of five times, at some point after resetting the client
connection using the above code, the firmware code will get stuck usually in
tcp_fasttmr of tcp.c.  This is because one of the pcb "next" pointers will
point to itself or one of the earlier pcb pointers.  This results in an
infinite loop in tcp_fasttmr as it walks the list - it never gets to a null
next pointer.

Anyone have any idea of what may be happening here?



--
Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html

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

Re: [lwip-users] lwip: Scan through the heap searching for a free block that is big enough, beginning with the lowest free block.

[goldsi...@gmx.de]

Am 25.03.2019 um 10:52 schrieb vrnud:

Hi,

I am trying to impelement modbus over TCPIP.
I am using FreeRTOS + lwip +STM32f4 (cube Mx generated code).
Lwip version is 2.0.0.
Freertos version 9.0.0.
heap 4 is used. is it ok?

TCPIP echo server application is used.
while trying to connect from Modscan utility program stucks in
mem.c file . function mem_malloc.


What does "stuck" mean? Endless loop in mem_malloc? If so, that's an
indication that the list is broken, which in turn is an indication for
violating lwIP's threading rules.

Regards,
Simon


/* Scan through the heap searching for a free block that is big enough,
modbus_connect_problem.pcap

  * beginning with the lowest free block.
  */
under this loop.
  for (ptr = (mem_size_t)((u8_t *)lfree - ram); ptr < MEM_SIZE_ALIGNED -
size;
  ptr = ((struct mem *)(void *)[ptr])->next) {
}

I have enabled the modbus_connect_problem.pcap

CHECKSUM_GEN_IP 1
CHECKSUM_GEN_TCP 1
I have attached the wireshark report.


Kindly guide.


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

Re: [lwip-users] Memory error after certain number of connect/disconnects.

[goldsi...@gmx.de]

Am 27.03.2019 um 17:02 schrieb sarp:

Dear members,

I have a TCP client using raw API which switches connection between servers
after data transmission.


Scenario Loop:

Connect to 1st server.
Transmit data.
Disconnect.
.
.
Connect to nth Server.
Transmit data.
Disconnect.

Go to First connection again...


Although using the documentation well (creating the control blocks in the
correct manner and destroying them properly), I get memory error after
certain number of connect/disconnects..


I'm afraid you'll have to be a *little* more precise here if you
actually want an answer: What kind of error, where, when, etc. - try to
be as precise as you can get while staying as short as you can.

Regards,
Simon



What is the reason of having memory error if the control blocks are created
and destroyed equally?

*Is the problem about having the time duration low between new
connection/disconnection?

*I am sure that the number of creation and destroying of the buffers and
control bloks are the same.

-Is there a disconnection timeout to clear memory out?

Any help is appreciated..
Kind Regards




--
Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html

___
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 ping utility was removed ?

[Freddie Chopin]

W dniu śro, 27.03.2019 o godzinie 17∶32 +0200, użytkownik Ranran
napisał:
> Does anyone knows why ping.c utility was removed from lwip ?
> I only found it in older lwip versions.

It is still there.

http://git.savannah.nongnu.org/cgit/lwip.git/tree/contrib/apps/ping/ping.c

Regards,
FCh


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

[lwip-users] Memory error after certain number of connect/disconnects.

[sarp]

Dear members,

I have a TCP client using raw API which switches connection between servers
after data transmission.


Scenario Loop:

Connect to 1st server.
Transmit data.
Disconnect.
.
.
Connect to nth Server.
Transmit data.
Disconnect.

Go to First connection again...


Although using the documentation well (creating the control blocks in the
correct manner and destroying them properly), I get memory error after
certain number of connect/disconnects..

What is the reason of having memory error if the control blocks are created
and destroyed equally?

*Is the problem about having the time duration low between new
connection/disconnection?

*I am sure that the number of creation and destroying of the buffers and
control bloks are the same.

-Is there a disconnection timeout to clear memory out?

Any help is appreciated..
Kind Regards




--
Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html

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

[lwip-users] why ping utility was removed ?

[Ranran]

Hello,

Does anyone knows why ping.c utility was removed from lwip ?
I only found it in older lwip versions.

Thank you,
ran

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