Joel Cunningham | 10 Apr 23:20 2015
Picon

[bug #44805] sendmsg implementation to support scatter/gather IO

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

                 Summary: sendmsg implementation to support scatter/gather IO
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: jcunningham
            Submitted on: Fri 10 Apr 2015 09:20:17 PM GMT
                Category: sockets/netconn
                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:

I've developed a sendmsg() addition to the sockets API.  It follows the Open
Group specification to provide support for scatter/gather IO from
applications.

http://pubs.opengroup.org/onlinepubs/009695399/functions/sendmsg.html

My use case was to reduce memory bandwidth utilization in an embedded system
by removing memory copies.  The implementation does not support control
(Continue reading)

Ivan Delamer | 10 Apr 18:09 2015

Re: API change: restructuring ipv4/ipv6 integration (task #12722)

Holy mackerel Batman!

I'll be testing this next week.

I'll also look into task #13480 (lwIP as IPv6 only stack), but as a 
potential user of IPv6-only I'm not too concerned about the few extra 
bytes that basic IPv4 would add...

Cheers!
Ivan

> Date: Thu, 09 Apr 2015 22:19:53 +0200
> From: "goldsimon <at> gmx.de" <goldsimon <at> gmx.de>
> To: lwip-devel <lwip-devel <at> nongnu.org>
> Subject: [lwip-devel] API change: restructuring ipv4/ipv6 integration
> 	(task	#12722)
> Message-ID: <5526DEE9.3080005 <at> gmx.de>
> Content-Type: text/plain; charset=windows-1252; format=flowed
> 
> Hi all,
> 
> for those not reading lwip-users:
> 
> goldsimon wrote:
>> I just wanted to warn you I'm going to push a rather big change
>> regarding ipv4/ipv6 integration where the old 'ip_addr_t' will be
>> renamed to ip4_addr_t and ip_addr_t changed to replace ipX_addr_t,
>> including a version information. This ensures ipv4 and ipv6 addresses
>> are handled equal (more or less).
>> 
(Continue reading)

Simon Goldschmidt | 9 Apr 22:30 2015
Picon

[task #13538] SNMP: implement IPv6 support in standard MIBs

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

                 Summary: SNMP: implement IPv6 support in standard MIBs
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: goldsimon
            Submitted on: Do 09 Apr 2015 20:30:28 GMT
                Category: None
         Should Start On: Do 09 Apr 2015 00:00:00 GMT
   Should be Finished on: Do 09 Apr 2015 00:00:00 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:

In some subtrees, IPv6 support might be integrated, others are marked
deprecated by now and have different subtrees as replacement.

    _______________________________________________________

Reply to this item at:
(Continue reading)

Homyak | 8 Apr 01:00 2015
Picon

[bug #44766] TCP session stop transferring when LWIP_WND_SCALE is enabled

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

                 Summary: TCP session stop transferring when LWIP_WND_SCALE 
is enabled
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: onlyslon
            Submitted on: Tue 07 Apr 2015 11:00:17 PM 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:

Then LWIP_WND_SCALE is enabled tcp session sometimes stops transferring a
data. I do investigation and possibly I found a bug in in Window Update
procedure.
tcp_in.c:969

    if (TCP_SEQ_LT(pcb->snd_wl1, seqno) ||
       (pcb->snd_wl1 == seqno && TCP_SEQ_LT(pcb->snd_wl2, ackno)) ||
(Continue reading)

Michael Waeber | 1 Apr 10:11 2015
Picon

Assertion fails for MEM_ALIGNMENT 2 since Bugfix #39683

In our system we have MEM_ALIGNMENT set to 2 (ColdFire/M68K).

#39683: tcp_out.c tcp_enqueue_flags():
< LWIP_ASSERT("seg->tcphdr not aligned", ((mem_ptr_t)seg->tcphdr %
MEM_ALIGNMENT) == 0);
> LWIP_ASSERT("seg->tcphdr not aligned", ((mem_ptr_t)seg->tcphdr % 4) == 0);

The assertion fails since the buffer is aligned on a 2 Byte boundary.
Why should it aligned to 4?

Regards
Michael
Sylvain Rochet | 30 Mar 18:55 2015
Picon

Approval about using Atmel documentation in lwIP -- [nicolas.ferre <at> atmel.com: lwIP documentation & official project]

Hello,

I asked a few days ago to a friendly Atmel contact on #at91 if we can 
re-use the Atmel documentation on lwIP[1].

YES, WE CAN \o/

As asked, I trimmed a little bit names from Atmel to prevent spam for 
them.

Sylvain

[1] http://www.atmel.com/Images/Atmel-42233-Using-the-lwIP-Network-Stack_AP-Note_AT04055.pdf

----- Forwarded message from Nicolas Ferre <nicolas.ferre <at> atmel.com> -----

Date: Mon, 30 Mar 2015 18:35:13 +0200
From: Nicolas Ferre <nicolas.ferre <at> atmel.com>
To: Sylvain Rochet <sylvain.rochet <at> finsecur.com>
Subject: Fwd: RE: lwIP documentation & official project

Hi Sylvain,

Here is the email from my manager that allows the lwIP project to use
whichever part of the Atmel documentation you find interesting.

BTW, I removed the email addresses of my colleagues and maybe you'll
have to only keep the name of Jean-Christophe and shorten it a little
bit so that you can quote this message, even on a mailing-list (mine is
pretty known by spam engines, so no worries ;-)).
(Continue reading)

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/

Gmane