lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-devel] PING_USE_SOCKETS==0 causes abort()


From: address@hidden
Subject: Re: [lwip-devel] PING_USE_SOCKETS==0 causes abort()
Date: Thu, 22 Sep 2011 21:14:40 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2

Already fixed, thanks for reporting. Most of these apps are meant as an example of how to use the API only, which explains why some of them have undiscovered bugs (and also why ping_recv was so careless about input checks).

BTW, since it uses a RAW pcb (which means an IP pcb with a custom next-protocol), it does know the incoming packet is an IP packet (the raw recv-callbacks are called from ip4.c). However, it is not adapted for use with IPv6, yet.

Simon


Gisle Vanem wrote:
I've build latest lwIP (from Git) and built the src\contrib\app\test-app
program using MSVC. After some time using the port-scanner nmap against
it, the app calls abort() via LWIP_ERROR() in pbuf_header():

   if (header_size_increment<  0){
     increment_magnitude = -header_size_increment;
     /* Check that we aren't going to move off the end of the pbuf */
     LWIP_ERROR("increment_magnitude<= p->len", (increment_magnitude<= p->len), 
return 1;);


Assertion "increment_magnitude<= p->len" failed at line 524 in pbuf.c
Got SIGABRT. Backtrace:
   stackwalker.cpp (1046): StackWalker::ShowCallstack
   exc-abort.cpp (99): new_abort_handler
   winsig.c (586): raise
   abort.c (74): abort
   pbuf.c (525): pbuf_header
   ping.c (239): ping_recv
   raw.c (123): raw_input
   ip4.c (532): ip_input
   etharp.c (1351): ethernet_input
   tcpip.c (114): tcpip_thread

The nice traceback is produces by inserting a line in
src\contrib\ports\win32\test.c:
   LoadLibrary("exc-abort.dll");

added before lwip_init(). It's available here:
http://home.broadpark.no/~gvanem/misc/exc-abort.zip

All this is with '#define PING_USE_SOCKETS 0". Hence the raw API
is used. Using PING_USE_SOCKET=1, everything is okay. Isn't
ping supporsed to use the raw API?

Seems the handling of ICMP_ECHO in ping_recv() is too careless.
Not knowing the details of the raw API, how does ping_recv() know
it's even receiving a IP-packet? Seems it's just assuming the packet
is>  PBUF_IP_HLEN.

--gv

_______________________________________________
lwip-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-devel





reply via email to

[Prev in Thread] Current Thread [Next in Thread]