Mateusz Klatecki | 27 Mar 12:35 2015
Picon

[bug #44649] lwip_socket_drop_registered_memberships

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

                 Summary: lwip_socket_drop_registered_memberships
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: klatecki
            Submitted on: Fri 27 Mar 2015 11:35:30 AM 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: git head

    _______________________________________________________

Details:

I think in lwip_socket_drop_registered_memberships is error

netconn_join_leave_group has parameters:
 struct netconn *conn,
 const ip_addr_t *multiaddr,
 const ip_addr_t *netif_addr,
 enum netconn_igmp join_or_leave

(Continue reading)

Rahul Gundecha | 26 Mar 11:06 2015
Picon

Single TCP socket to handle IPv4 and IPv6 traffic

Hi all,

I need to support IPv6 connections with an existing IPv4 socket based HTTP server. There are two possibilities to accomplish this:
1) Have 2 sockets, one for IPv4, other for IPv6.
2) Have single socket handling both IPv4 and IPv6. Such support do not seem to be present in lwip at this moment.

However I observed that the existing socket which is configured for IPv4 is also able to accept and process IPv6 traffic, without any extra configuration. Hence HTTP server is able to process both IPv4 and IPv6 traffic seamlessly. Is this the recommended way?
If this is approach is right then, one issue is observed. SYN flood from IPv6 hosts results in TCP backlog queue getting full, which results further TCP connections getting rejected forever. Reasoning behind this is as follows: while purging TCP pcbs it is verified that the value of isipv6 member is same for pcb to be purged and the listening pcb (for which the accepts_pending count to be decremented. Since we created the listening socket with IPv4 options, isipv6 value of listening pcb is 'false'
On the other hand, isipv6 value of pcb created for incoming IPv6 based SYN is 'true' Hence accepts_pending count for listening pcb is not decremented.
Following is the patch which kind of fixes the issue. My question is whether the following patch is the right approach, or whether the IPv6 traffic for a specific port should not be redirected to a IPv4 socket with matching port?

diff --git a/src/core/tcp.c b/src/core/tcp.c

index cdd08ae..1a87085 100644

--- a/src/core/tcp.c

+++ b/src/core/tcp.c

<at> <at> -1575,7 +1575,6 <at> <at> tcp_pcb_purge(struct tcp_pcb *pcb)

         tcp_listen_pcbs.listen_pcbs != NULL);

       for (lpcb = tcp_listen_pcbs.listen_pcbs; lpcb != NULL; lpcb = lpcb->next) {

         if ((lpcb->local_port == pcb->local_port) &&

-            IP_PCB_IPVER_EQ(pcb, lpcb) &&

             (ipX_addr_isany(PCB_ISIPV6(lpcb), &lpcb->local_ip) ||

              ipX_addr_cmp(PCB_ISIPV6(lpcb), &pcb->local_ip, &lpcb->local_ip))) {

             /* port and address of the listen pcb match the timed-out pcb */


Thanks,
Rahul

_______________________________________________
lwip-devel mailing list
lwip-devel <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-devel
Arjuna S | 24 Mar 16:59 2015
Picon

Questions about timers.c and sys_timeout/sys_untimeout

Hello,

I've been digging through some code in our FreeRTOS+LwIP-based platform where I see some of our code sitting above LwIP, running on its own thread, using LwIP timers for its own purposes. 

Looking at timers.c, I see no locks being taken in any access to the global timer list, so I suspect that timers.c is strictly for internal LwIP use, or at least from the context of the LwIP thread. 

There's a bit of a long story behind why native FreeRTOS timers aren't being used the code in question so I'm writing to primarily confirm the intent of LwIP timers. 

Thanks,
_______________________________________________
lwip-devel mailing list
lwip-devel <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-devel
Adam | 23 Mar 16:54 2015
Picon

[bug #44608] connectionless UDP dst address not being checked within udp_input

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

                 Summary: connectionless UDP dst address not being checked
within udp_input
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: anewman
            Submitted on: Mon 23 Mar 2015 03:54:08 PM GMT
                Category: UDP
                Severity: 3 - Normal
              Item Group: Change Request
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: 1.4.1

    _______________________________________________________

Details:

In udp_input (udp.c) the dst address is not being checked vs. the pcb when the
pcb is connectionless. Arriving UDP is only checked for matching port number.

If two Multicast UDP sockets are open using different addresses but the same
port number then the frame will arrive on both.

My application requires that the UDP frame is only copied to the PCB with the
matching multicast address.

May I propose an enhancement to include an option to check for a match vs.
pcb.multicast_ip when current_iphdr_dest is multicast? I've implemented the
following in udp.c and it works for me:

//FROM LINE 239
/* compare PCB local addr+port to UDP destination addr+port */
      if (pcb->local_port == dest) {
#if MC_MATCH_DSTADDRESS
        bool mc_match_dstaddress = true;

        if (ip_addr_ismulticast(&current_iphdr_dest))
        {
            if (!ip_addr_cmp(&(pcb->multicast_ip), &current_iphdr_dest))
            {
                mc_match_dstaddress = false;
            }
        }

        if (mc_match_dstaddress)
        {
#endif          
        if (
           (!broadcast && ip_addr_isany(&pcb->local_ip)) ||
           ip_addr_cmp(&(pcb->local_ip), &current_iphdr_dest) ||
#if LWIP_IGMP
           ip_addr_ismulticast(&current_iphdr_dest) ||
#endif /* LWIP_IGMP */
#if IP_SOF_BROADCAST_RECV
            (broadcast && ip_get_option(pcb, SOF_BROADCAST) &&
             (ip_addr_isany(&pcb->local_ip) ||
              ip_addr_netcmp(&pcb->local_ip, ip_current_dest_addr(),
&inp->netmask)))) {
#else /* IP_SOF_BROADCAST_RECV */
            (broadcast &&
             (ip_addr_isany(&pcb->local_ip) ||
              ip_addr_netcmp(&pcb->local_ip, ip_current_dest_addr(),
&inp->netmask)))) {
#endif /* IP_SOF_BROADCAST_RECV */ 
          local_match = 1;
          if ((uncon_pcb == NULL) && 
              ((pcb->flags & UDP_FLAGS_CONNECTED) == 0)) {
            /* the first unconnected matching PCB */
            uncon_pcb = pcb;
          }
        }
#if MC_MATCH_DSTADDRESS              
        }
#endif

I also added "#define MC_MATCH_DSTADDRESS 1" to opt.h. multicast_ip is set
using setsockopt with the IP_MULTICAST_IF option.

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/
Simon Goldschmidt | 21 Mar 21:30 2015
Picon

[bug #41494] TCP possibly violates RFC793

Update of bug #41494 (project lwip):

                Severity:              3 - Normal => 2 - Minor              
                  Status:                    None => Postponed              

    _______________________________________________________

Follow-up Comment #1:

From comparing the spec and the sources, I see this too. However, I don't
think it's a simple change: at least with TCP_QUEUE_OOSEQ enabled, when not
handling ACKs of ooseq segments, we'd have to send these segments through the
ACK handling code once they get inseq or we might risk losing ACK updates (or
getting them later as we could).

Since I don't think that this is currently a serious issue, I'm postponing
this until someone finds the time to fix it :-)

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht gesendet von/durch Savannah
  http://savannah.nongnu.org/
Ivan Delamer | 20 Mar 21:50 2015
Picon

[bug #44595] netconn_recv does not set last_err on CLOSE_WAIT

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

                 Summary: netconn_recv does not set last_err on CLOSE_WAIT
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: idelamer
            Submitted on: Fri 20 Mar 2015 02:50:07 PM MDT
                Category: sockets/netconn
                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 a half closed netconn (we have received FIN), recvmbox is set to invalid.

If we call netconn_recv, it will return ERR_CONN on one of the first lines:

  LWIP_ERROR("netconn_recv: invalid recvmbox",
sys_mbox_valid(&conn->recvmbox), return ERR_CONN;);

This should actually pass, and then netconn_recv_data is called. In there, we
check:

    if (!sys_mbox_valid(&conn->recvmbox)) {
      /* This happens when calling this function after receiving FIN */
      return sys_mbox_valid(&conn->acceptmbox) ? ERR_CONN : ERR_CLSD;
    }

But in neither of both cases do we set last_err. So when I call
netconn_err(pxNetconn) I still get ERR_OK.

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/
Valery Ushakov | 20 Mar 13:19 2015
Picon

[bug #44589] Typo in comment for tcp_receive()

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

                 Summary: Typo in comment for tcp_receive()
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: uwe
            Submitted on: Fri 20 Mar 2015 12:19:45 PM GMT
                Category: Documentation
                Severity: 3 - Normal
              Item Group: Change Request
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: git head

    _______________________________________________________

Details:

Function comment for tcp_receive() has "Next, IS places the segment...".  It
should read "Next, IT places ...".

Sorry, can't generate a proper patch at the moment.

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/
hanhui | 20 Mar 09:32 2015
Picon

[bug #44587] PPPoL2TP l2tp->remote_ip error!

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

                 Summary: PPPoL2TP l2tp->remote_ip error!
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: hanhui03
            Submitted on: Fri 20 Mar 2015 08:32:24 AM GMT
                Category: PPP
                Severity: 3 - Normal
              Item Group: Change Request
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: git head

    _______________________________________________________

Details:

&ipX_2_ip(l2tp->remote_ip)

should be:

ipX_2_ip(&l2tp->remote_ip)

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/
hanhui | 20 Mar 09:26 2015
Picon

[bug #44586] nd6_send_rs() pbuf size error!

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

                 Summary: nd6_send_rs() pbuf size error!
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: hanhui03
            Submitted on: Fri 20 Mar 2015 08:26:39 AM GMT
                Category: IPv6
                Severity: 3 - Normal
              Item Group: Crash Error
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: git head

    _______________________________________________________

Details:

  nd6_send_rs() 

  p = pbuf_alloc(PBUF_IP, sizeof(struct rs_header) + lladdr_opt_len,
PBUF_RAM);
  if ((p == NULL) || (p->len < (sizeof(struct rs_header) + lladdr_opt_len)))
{

should be:

  p = pbuf_alloc(PBUF_IP, sizeof(struct rs_header) + (lladdr_opt_len << 3),
PBUF_RAM);
  if ((p == NULL) || (p->len < (sizeof(struct rs_header) + (lladdr_opt_len <<
3)))) {

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/
Clint Sbisa | 20 Mar 01:44 2015
Picon

[bug #44583] Sequence number overrun mishandling for out-of-sequence TCP packets

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

                 Summary: Sequence number overrun mishandling for
out-of-sequence TCP packets
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: csbisa
            Submitted on: Fri 20 Mar 2015 12:44:57 AM GMT
                Category: Contrib
                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:

Checks for receive window overruns aren't handling overflows properly in the
case of out-of-sequence TCP packets. LWIP does not crash, but the TCP
connection typically falls out of sync until a timeout resets the connection.

The fix is fairly simple-- the offending code was not using macros that are
used everywhere else in the file. A patch that fixes this is attached.

The patch also includes a test case that was failing without the fix.

    _______________________________________________________

File Attachments:

-------------------------------------------------------
Date: Fri 20 Mar 2015 12:44:57 AM GMT  Name:
0001-tcp-Fix-ooseq-processing-when-seqno-is-near-2-32.patch  Size: 5kB   By:
csbisa

<http://savannah.nongnu.org/bugs/download.php?file_id=33408>

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/
Philipp Tölke | 19 Mar 10:17 2015
Picon

[bug #44578] Build fails for IPv6-only configuration

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

                 Summary: Build fails for IPv6-only configuration
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: philipptoelke
            Submitted on: Thu 19 Mar 2015 09:17:17 AM GMT
                Category: IPv6
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: git head

    _______________________________________________________

Details:

In ethernet_input the variable ip_hdr_offset is only declared when LWIP_ARP is
enabled; this patch enables it for IPv6 as it is needed in line 1463 (case
PP_HTONS(ETHTYPE_IPV6): /* IPv6 */).

    _______________________________________________________

File Attachments:

-------------------------------------------------------
Date: Thu 19 Mar 2015 09:17:17 AM GMT  Name:
0001-fix-ethernet_input-for-IPv6-Only.patch  Size: 731B   By: philipptoelke

<http://savannah.nongnu.org/bugs/download.php?file_id=33396>

    _______________________________________________________

Reply to this item at:

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

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

Gmane