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
Ivan Delamer | 8 Sep 19:16 2014
Picon

[bug #43173] pppos_input() corrupts memory if IP_FORWARD is enabled

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

                 Summary: pppos_input() corrupts memory if IP_FORWARD is
enabled
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: idelamer
            Submitted on: Mon 08 Sep 2014 11:16:08 AM MDT
                Category: PPP
                Severity: 4 - Important
              Item Group: Crash Error
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 1.5.0
            lwIP version: git head

    _______________________________________________________

Details:

This was introduced in commit 4283ecf7748ccf7ab41fc09b7d6d4acb1f7f4444

If IP forward is enabled, a PBUF_POOL with PBUF_LINK offset is allocated.

In my setup, this is a 256-byte buffer with 16-byte offset.

But the code still writes until len == 256, which with 16-byte offset is out
of bounds. In pcrx->in_head this is off by 10 bytes (due to helper header
inserted) and the rest is off by 16.

It is also unnecessary to allocate PBUF_LINK offset for pbufs other than the
first one (pcrx->in_head ).

Won't Etharp or netif->output pre-pend an extra pbuf for link-layer headers?

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/
Simon Goldschmidt | 4 Sep 14:26 2014
Picon
Picon

Changed email notifications

Hi all,
 
I've just changed email notifications to be sent to lwip-members <at> nongnu.org only (instead of lwip-devel <at> nongnu.org) when bug/task/patch entries are marked as private. This is to keep confidentiality of private bugs.
 
This means that every interested developer/member should subscribe the "lwip-members" list, too, to be notified of private bugs/tasks/patches!
 
 
Simon
_______________________________________________
lwip-devel mailing list
lwip-devel <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-devel
Simon Goldschmidt | 4 Sep 14:20 2014
Picon

[bug #43142] test private

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

                 Summary: test private
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: goldsimon
            Submitted on: Do 04 Sep 2014 12:20:34 GMT
                Category: DHCP
                Severity: 3 - Normal
              Item Group: Feature Request
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: Other

    _______________________________________________________

Details:

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht gesendet von/durch Savannah
  http://savannah.nongnu.org/
Simon Goldschmidt | 4 Sep 14:20 2014
Picon

[bug #43141] test public

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

                 Summary: test public
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: goldsimon
            Submitted on: Do 04 Sep 2014 12:20:11 GMT
                Category: Documentation
                Severity: 3 - Normal
              Item Group: Feature Request
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: git head

    _______________________________________________________

Details:

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht gesendet von/durch Savannah
  http://savannah.nongnu.org/
Noam Weissman | 3 Sep 09:25 2014
Picon

[task #13312] Add poll callback to server pcb

URL:
  <http://savannah.nongnu.org/task/?13312>

                 Summary: Add poll callback to server pcb
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: noam_w
            Submitted on: Wed 03 Sep 2014 07:25:38 AM GMT
                Category: None
         Should Start On: Wed 03 Sep 2014 12:00:00 AM GMT
   Should be Finished on: Wed 03 Sep 2014 12:00:00 AM GMT
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
        Percent Complete: 0%
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
                  Effort: 0.00

    _______________________________________________________

Details:

Hi,

Every connection has a poll callback handler. This is great 
when there is a live connection.

There are times we need some kind of server timing. I found one situation that
this is very much needed but I am sure it can be very useful in other
situations as well.

In cases were we need to keep track over user session ID's like in HTTP
sessions we cannot use the connection pcb as it will be closed after the
transaction is closed. I had to create a separate task that handles those
session ID's !

Adding poll callback to server own pcb will give a simple mechanism to keep
track over session ID's timeouts.

If not too much to to ask please add a poll callback to the server pcb as
well.

BR,
Noam.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?13312>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/

Gmane