Piotr | 18 Oct 21:12 2014
Picon

[bug #43437] Memory corruption beyound memory pool

URL:
  <http://savannah.nongnu.org/bugs/?43437>

                 Summary: Memory corruption beyound memory pool
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: michcior
            Submitted on: Sat 18 Oct 2014 07:12:23 PM GMT
                Category: pbufs
                Severity: 3 - Normal
              Item Group: Crash Error
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: 1.4.1

    _______________________________________________________

Details:

In the mem_init (mem.c) The code assigns to "ram_end" the top of the pool.
Then, if the pool was declared without spare bytes, the following instructions
corrupt memory, which is located just after memory pool.

  ram_end = (struct mem *)(void *)&ram[MEM_SIZE_ALIGNED];
  ram_end->used = 1;
  ram_end->next = MEM_SIZE_ALIGNED;
  ram_end->prev = MEM_SIZE_ALIGNED;
(Continue reading)

hanhui | 9 Oct 09:38 2014
Picon

[bug #43389] dns_recv() res_idx calculate error.

URL:
  <http://savannah.nongnu.org/bugs/?43389>

                 Summary: dns_recv() res_idx calculate error.
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: hanhui03
            Submitted on: Thu 09 Oct 2014 07:38:57 AM GMT
                Category: DNS
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: git head

    _______________________________________________________

Details:

Hi Simon:

dns_recv()
{
    ...

<line:1086>
    res_idx = SIZEOF_DNS_ANSWER + htons(ans.len);
(Continue reading)

Joel Cunningham | 5 Oct 23:01 2014
Picon

[bug #43361] select() crashes with stale FDs

URL:
  <http://savannah.nongnu.org/bugs/?43361>

                 Summary: select() crashes with stale FDs
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: jcunningham
            Submitted on: Sun 05 Oct 2014 09:01:14 PM GMT
                Category: sockets/netconn
                Severity: 3 - Normal
              Item Group: Crash Error
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: 1.4.1

    _______________________________________________________

Details:

If an application calls select() with FDs set that do not correspond to valid
open sockets, a data abort will occur.

There are two spots where calls to tryget_socket() returns a NULL and it is
dereferenced: when increasing and decreasing the sock->select_waiting value. 
Other uses of tryget_socket() handle the NULL gracefully.

Just handling the NULL wouldn't technically be correct behavior of select
(Continue reading)

Richard Cochran | 25 Sep 20:59 2014
Picon

[PATCH] tcp: fix unused variables when checksum offloading is configured.

When offloading TCP checksum generation to hardware, one sets the macro
CHECKSUM_GEN_TCP to zero. As a side effect, a local variable becomes
orphaned in two functions in the TCP code. This in turn cause compiler
warnings about unused variables.

This patch fixes the issue by placing the appropriate ifdefs, and it
applies to the 1.4.1 branch.

Signed-off-by: Richard Cochran <richardcochran <at> gmail.com>
---
 src/core/tcp_out.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/core/tcp_out.c b/src/core/tcp_out.c
index ee19fe0..0645142 100644
--- a/src/core/tcp_out.c
+++ b/src/core/tcp_out.c
 <at>  <at>  -842,7 +842,9  <at>  <at>  err_t
 tcp_send_empty_ack(struct tcp_pcb *pcb)
 {
   struct pbuf *p;
+#if CHECKSUM_GEN_TCP || LWIP_TCP_TIMESTAMPS
   struct tcp_hdr *tcphdr;
+#endif
   u8_t optlen = 0;

 #if LWIP_TCP_TIMESTAMPS
 <at>  <at>  -856,7 +858,9  <at>  <at>  tcp_send_empty_ack(struct tcp_pcb *pcb)
     LWIP_DEBUGF(TCP_OUTPUT_DEBUG, ("tcp_output: (ACK) could not allocate pbuf\n"));
     return ERR_BUF;
(Continue reading)

Joel Cunningham | 22 Sep 16:18 2014
Picon

[bug #43278] event_callback() handle context switch when calling sys_sem_signal()

URL:
  <http://savannah.nongnu.org/bugs/?43278>

                 Summary: event_callback() handle context switch when calling
sys_sem_signal()
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: jcunningham
            Submitted on: Mon 22 Sep 2014 02:18:05 PM GMT
                Category: sockets/netconn
                Severity: 3 - Normal
              Item Group: Crash Error
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: 1.4.1

    _______________________________________________________

Details:

In event_callback(), the for loop at the bottom that handles signaling waiting
application threads that a select is ready, operates under the assumption that
the call to sys_sem_signal() won't cause a context switch.  The entire loop is
protected by a pair of SYS_ARCH_PROTECT() and SYS_ARCH_UNPROTECT().

On certain ports, the _PROTECT and _UNPROTECT calls just disable/enable
interrupts.  This leaves the possibility of a context switch happening in the
(Continue reading)

Dan Schatzberg | 18 Sep 18:05 2014
Picon

tcp ACK processing out of sequence

Looking through the LWIP source it seems as if incoming segments are
processed for ACKs before checking if if the segment is the next one
in sequence. Have I read the code correctly? Isn't this a violation of
the TCP specification?

---
Dan Schatzberg
Simon Goldschmidt | 16 Sep 20:39 2014
Picon

[bug #43235] Numerous compiler warnings in ppp_new code

URL:
  <http://savannah.nongnu.org/bugs/?43235>

                 Summary: Numerous compiler warnings in ppp_new code
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: goldsimon
            Submitted on: Di 16 Sep 2014 18:39:35 GMT
                Category: PPP
                Severity: 3 - Normal
              Item Group: Compiler Warning
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 1.5.0
            lwIP version: git head

    _______________________________________________________

Details:

I have to admit it's the first time I'm compiling the PPP code with the win32
project with PPP enabled, but I really get many warnings. Is the original code
really in that bad shape? Are these our changes or are the warnings in the
original code?

Also the code uses tabs and spaces mixed, which makes it really hard to
read...

(Continue reading)

rlesko | 16 Sep 18:02 2014

netconn_bind() not working?

I am trying to get the lwIP test apps running in a windows environment.  I'm
not sure if its relevant but I am running Windows 7 via Parallels on a mac. 
The ping test app works and now I've moved on to the httpd server test. 
From what I understand the application should open an http connection on a
port (it is defaulted to port 80) and wait for an incoming connection.  For
debugging I am using TCPView to look at my ports as well as Wireshark.  In
TCPView no connection ever shows up on whatever port I set it to so it is my
hunch the netconn_bind() call is not working?  If anyone has any insight
into what could be happening, please advise.  

--
View this message in context: http://lwip.100.n7.nabble.com/netconn-bind-not-working-tp23272.html
Sent from the lwip-devel mailing list archive at Nabble.com.
Fabian Koch | 11 Sep 10:37 2014
Picon

wrong return in lwip_accept()

Hey all,

 

I noticed something in lwip_accept() that I found odd:

 

Line 404/405 of sockets.c are:

 

sock_set_errno(sock, EOPNOTSUPP);

return EOPNOTSUPP;

 

(see here https://github.com/tabascoeye/lwip/blob/master/src/api/sockets.c#L405 )

 

Now I don’t get why lwip_accept should return a positive integer here (which EOPNOTSUPP arguably is on most systems) when it really should return an error (-1) and it already has the last error value set up in errno.

 

Am I missing something here or is that a tiny bug?

 

Cheers,

Fabian

_______________________________________________
lwip-devel mailing list
lwip-devel <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-devel
Albert Huitsing | 11 Sep 11:22 2014
Picon

[bug #43192] tcp_enqueue_flags() should TCP_SND_QUEUELEN when sending FIN

URL:
  <http://savannah.nongnu.org/bugs/?43192>

                 Summary: tcp_enqueue_flags() should TCP_SND_QUEUELEN when
sending FIN
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: ajhuitsing
            Submitted on: Thu 11 Sep 2014 09:22:11 AM GMT
                Category: TCP
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: git head

    _______________________________________________________

Details:

in tcp_out.c() : tcp_enqueue_flags()

if ((pcb->snd_queuelen >= TCP_SND_QUEUELEN) || (pcb->snd_queuelen >
TCP_SNDQUEUELEN_OVERFLOW)) {
    LWIP_DEBUGF(TCP_OUTPUT_DEBUG | 3, ("tcp_enqueue_flags: too long queue
%"U16_F" (max %"U16_F")\n",
                                       pcb->snd_queuelen, TCP_SND_QUEUELEN));

will cause hangup in some cases, which can be partially fixed by:

if ((pcb->snd_queuelen > TCP_SND_QUEUELEN) || (pcb->snd_queuelen >
TCP_SNDQUEUELEN_OVERFLOW)) {
    LWIP_DEBUGF(TCP_OUTPUT_DEBUG | 3, ("tcp_enqueue_flags: too long queue
%"U16_F" (max %"U16_F")\n",
                                       pcb->snd_queuelen, TCP_SND_QUEUELEN));

but this seems not the entire solution:

quote from Simon on this bug by email:

"This seems like a bug in lwIP, but your fix is not really correct. It might
solve your specific problem, but only because of your current
pcb->snd_queuelen state. A more general fix might have to detect that only a
FIN should be enqueued and ignore the TCP_SND_QUEUELEN counter in this case."

but I'm not deep enough into LWIP for that...

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?43192>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/
Albert Huitsing | 11 Sep 10:34 2014
Picon

is this is a bug ? (inside tcp_out.c)

Hi all,

when a TCP connection is abruptly aborted (remote node has a crash-bug :-), it seems the local connection can't be terminated correctly in my case. I traced it down to :

lwip_netconn_do_close_internal()
tcp_send_fin()
tcp_enqueue_flags: too long queue 8 (max 8)

which keeps on going forever (because of ERR_MEM)

in tcp_out.c: tcp_enqueue_flags()

if ((pcb->snd_queuelen >= TCP_SND_QUEUELEN) || (pcb->snd_queuelen > TCP_SNDQUEUELEN_OVERFLOW)) {
    LWIP_DEBUGF(TCP_OUTPUT_DEBUG | 3, ("tcp_enqueue_flags: too long queue %"U16_F" (max %"U16_F")\n",
                                       pcb->snd_queuelen, TCP_SND_QUEUELEN));

shouldn't that be:

if ((pcb->snd_queuelen > TCP_SND_QUEUELEN) || (pcb->snd_queuelen > TCP_SNDQUEUELEN_OVERFLOW)) {
    LWIP_DEBUGF(TCP_OUTPUT_DEBUG | 3, ("tcp_enqueue_flags: too long queue %"U16_F" (max %"U16_F")\n",
                                       pcb->snd_queuelen, TCP_SND_QUEUELEN));

???

it seems to work fine when I change it accordingly

kindest regards,

Albert Huitsing

-- Albert Huitsing (albert <at> huitsing.nl) Huitsing Embedded Systems Dr. Mondenweg 5 7831 JA Nw. Weerdinge +31-(0)591-521222 http://www.huitsing.nl "conformity is the uncomfortable feeling of wearing somebody else's clothes; even when they don't fit"
_______________________________________________
lwip-devel mailing list
lwip-devel <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-devel

Gmane