hanhui | 30 Aug 17:30 2014
Picon

[bug #43110] call getpeername() before listen() will cause a error.

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

                 Summary: call getpeername() before listen() will cause a
error.
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: hanhui03
            Submitted on: Sat 30 Aug 2014 03:30:46 PM GMT
                Category: sockets/netconn
                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:

Hello All

     If call getpeername() before call listen(), this socket can NOT change to
listen mode. 

     For example:

(Continue reading)

Alex | 29 Aug 08:30 2014
Picon

[bug #43105] IGMP Membership General Query being ignored

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

                 Summary: IGMP Membership General Query being ignored
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: arudzki
            Submitted on: Fri 29 Aug 2014 06:30:11 GMT
                Category: IPv4
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: 1.3.1

    _______________________________________________________

Details:

In my project I join a single multicast group

I have noticed since adding a switch with IGMP Snooping onto my network that
IGMPv2 Membership General Queries on All hosts (224.0.0.1) addresses are being
ignored from my project devices running lwIP.

I managed to track the problem down to igmp.c - igmp_lookfor_group.
The if statement should be (group->interface == ifp) &&
(Continue reading)

yuanbin | 29 Aug 04:55 2014
Picon

[bug #43103] conditional compilation about ipv6 header file

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

                 Summary: conditional compilation about ipv6 header file
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: ffddybz
            Submitted on: Fri 29 Aug 2014 02:55:49 AM GMT
                Category: IPv6
                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:

I use git head because of the support of ipv6 , but in many occasions, I only
want to use ipv4. So I hope that it does not compile any source file and
header file about ipv6. But in many files it did not use conditional
compilation to handle ipv6 header. So, I submit the patch.
And also, when will it release lwip-1.5.0?

    _______________________________________________________

(Continue reading)

任海波 | 28 Aug 04:10 2014
Picon

[bug #43095] IPv6 Neighbor Discovery Protocol need to be change

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

                 Summary: IPv6  Neighbor Discovery Protocol  need to be change
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: hichard
            Submitted on: Thu Aug 28 02:10:13 2014
                Category: IPv6
                Severity: 3 - Normal
              Item Group: Change Request
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: CVS Head

    _______________________________________________________

Details:

Hello Ivan:
      I use lwip in 802.15.4, Its mac address is 8 bytes. IPv6  Neighbor
Discovery Protocol, which is in the file nd6.c. lladdr_option length need to
be Variable,but it is handled as a const. I strongly recommended add some
callback when add or delete the neighbor.

    _______________________________________________________

(Continue reading)

任海波 | 28 Aug 04:02 2014
Picon

[bug #43094] The function tcpip_input() forget to handle IPv6

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

                 Summary:  The function tcpip_input() forget to handle IPv6
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: hichard
            Submitted on: Thu Aug 28 02:02:07 2014
                Category: IPv6
                Severity: 3 - Normal
              Item Group: Change Request
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: CVS Head

    _______________________________________________________

Details:

Hello Ivan:
      I found a bug the function tcpip_input(). This function forget to handle
IPv6. I has change it as follow. In the thread tcpip_thread(), it is handled
as this. 
err_t
tcpip_input(struct pbuf *p, struct netif *inp)
{
#if LWIP_TCPIP_CORE_LOCKING_INPUT
(Continue reading)

任海波 | 28 Aug 03:56 2014
Picon

[bug #43093] The function tcpip_input() forget to handle IPv

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

                 Summary: The function tcpip_input() forget to handle IPv
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: hichard
            Submitted on: Thu Aug 28 01:56:48 2014
                Category: IPv6
                Severity: 3 - Normal
              Item Group: Change Request
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: CVS Head

    _______________________________________________________

Details:

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
(Continue reading)

Przemyslaw Bejtan | 26 Aug 19:06 2014
Picon

[bug #43081] The crash error for the active LWIP_NETBUF_RECVINFO option in api_msg.c (lwip-1.4.1)

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

                 Summary: The crash error for the  active LWIP_NETBUF_RECVINFO
option in api_msg.c (lwip-1.4.1)
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: przemyslawbejtan
            Submitted on: Tue 26 Aug 2014 05:06:11 PM GMT
                Category: Network drivers
                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:

The crash error for the active LWIP_NETBUF_RECVINFO option in api_msg.c
(lwip-1.4.1).

Last time, I worked with the lwIP stack and I have found a critical bug when
the LWIP_NETBUF_RECVINFO option is active. 

In the module “api_msg.c”, line number 184 we have:
(Continue reading)

Federico Casares | 26 Aug 14:10 2014

LWIP port for RTEMS.

Hi,

In the past weeks we were working on porting the last LWIP version to RTEMS for
the LPC1768 microcontroller. Our main goal was to accomplish this with the
minimum number of changes for both projects. Fortunately, the result was
positive.

Now, we are capable of providing to the community with this new version of the
RTEMS+LWIP port.

Our changes/adds conducted on LWIP were few, but we think that those could be
helpful for the community. Furthermore, we think some of this modifications
could help developers in porting LWIP to new platforms.


In details (including changes in RTEMS - for better understanding):

- RTEMS OS: No changes were needed here. Despite this we will be posting a
possible improvement in the newlib maillist soon. It consist in adding the gcc
function attribute "warn_unused_result" to the pthread_*_init functions. As a
result, developers will be warned about checking the return value. NOTE: a
common error here could be not checking the return value, assuming a successful
result, and trying to, for example, lock a mutex which init function has
returned ENOMEM. (We found this exact mistake in the current LWIP OS layer
implementation for Unix)

- RTEMS LPC1768_MBED BSP: We added a new section to the linker script, so we
were able to put the LWIP and driver buffers in an exact memory location (useful
when working with DMA devices).

- RTEMS LPC1768_MBED Ethernet Driver: Based on an existing driver from MBED, we
ported it to RTEMS. NOTE: we will be creating our own driver in the near future.

- LWIP: As mentioned previously, we needed to put all LWIP buffers in DMA memory
locations. Consequently, we added the "section" attribute to LWIP ram_heap and
memp_memory buffers. Furthermore, as this is a common strategy in embedded
devices with DMA, we made it generic and we will send these changes to the LWIP
project. Additionally, we will provide some minor adds/changes to the lwip log
system and statistics system.

- LWIP-contrib: Some of the changes/adds were: fixing some issues related with
posix initialization checks and allow set threads stack size.

- LWIP-test-app: A simple TCP echo server with debugging functionality
(rtems malloc statistics, rtems stack checker, lwip statistics, driver
statistics and registers dump) available.


In order to provide you with the patches so you can review the changes/adds,
Should we upload those to the "patches" section of the web page? or should
we send those to the list?

Regards.


--

Casares, Federico
Sr. Software Engineer
Taller Technologies Argentina

San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina

_______________________________________________
lwip-devel mailing list
lwip-devel <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-devel
jhinkle | 23 Aug 20:49 2014

Your opinion - zero copy transmit - Freescale Kinetis

I'm developing my own device driver for Freescales K60 - Kinetis ARM cpu - on
a Crossworks platform.

I've reviewed the ones that Freescale provide but they all copy data from
the pbuf chain into predefined transmit buffers.  Not a Zero-Copy
implementation.

The ENET on this micro requires a memory alignment of 8 bytes when using the
internal dma and placing the pbuf data pointers directly into the ENET's
Transmit Buffer.

To implement this, I would need to make changes to the pbuf allocate
routines to make the 8 byte alignment only associated with pbufs and not
non-pbuf mem_alloc().

The trade of to the code modification is zero-copy data on transmit.

I suspect this is a good trade-off (custom pbuf alloc) for the time saved
doing mem_copy for every transmission.

I would appreciate any comments on this topic.

Thanks

--
View this message in context: http://lwip.100.n7.nabble.com/Your-opinion-zero-copy-transmit-Freescale-Kinetis-tp23061.html
Sent from the lwip-devel mailing list archive at Nabble.com.
Joel Cunningham | 19 Aug 21:59 2014
Picon

[bug #43028] IP_MULTICAST_TTL affects unicast datagrams

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

                 Summary: IP_MULTICAST_TTL affects unicast datagrams
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: jcunningham
            Submitted on: Tue 19 Aug 2014 07:59:55 PM GMT
                Category: UDP
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: 1.4.1

    _______________________________________________________

Details:

When setting the IP_MULTICAST_TTL socket option via setsockopt(), all
transmitted datagrams from that socket now use the TTL value specified in the
setsockopt() call regardless of whether the destination of the datagram is
unicast or multicast.  My understanding of the socket option is that it should
only affect datagrams sent (on that socket) to a multicast group.

Taking a look at the implementation, IP_MULTICAST_TTL sets the 
sock->conn->pcb.udp->ttl which is used for every call to ip_output_if from
udp.c

Further, the getsockopt() returns sock->conn->pcb.ip->ttl (as opposed to
pcb.udp->ttl for the setter)

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/
Alec Davis | 19 Aug 10:53 2014
Picon

[bug #43022] arp reply Target Protocol Address is corrupt

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

                 Summary: arp reply Target Protocol Address is corrupt
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: alecdavis
            Submitted on: Tue 19 Aug 2014 08:53:04 AM GMT
                Category: ARP
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: CVS Head

    _______________________________________________________

Details:

Using tcpdump captures;

The '810b 40e8' in the arp-reply should be 'c0a8 7cfe' being 192.168.124.254

19:29:21.599677 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.124.32 tell 192.168.124.254, length 28
        0x0000:  0001 0800 0604 0001 000d 6133 e54e c0a8  ..........a3.N..
        0x0010:  7cfe 0000 0000 0000 c0a8 7c20            |.........|.
19:29:21.612438 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.124.32
is-at ac:cf:23:23:5e:4c, length 46
        0x0000:  0001 0800 0604 0002 accf 2323 5e4c c0a8  ..........##^L..
        0x0010:  7c20 000d 6133 e54e <b>810b 40e8</b> fb90 f66d 
|...a3.N.. <at> ....m
        0x0020:  01f2 8673 7f04 0000 0004 6b07 02ff       ...s......k...

-      ETHADDR16_COPY(&hdr->shwaddr, ethaddr);
-      ETHADDR16_COPY(&ethhdr->src, ethaddr);
+      ETHADDR16_COPY(&hdr->shwaddr, &ethaddr);
+      ETHADDR16_COPY(&ethhdr->src, &ethaddr);

After patch;
20:17:19.535674 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.124.32 tell 192.168.124.254, length 28
        0x0000:  0001 0800 0604 0001 000d 6133 e54e c0a8  ..........a3.N..
        0x0010:  7cfe 0000 0000 0000 c0a8 7c20            |.........|.
20:17:19.537019 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.124.32
is-at 4b:82:01:20:c0:a8, length 112
        0x0000:  0001 0800 0604 0002 4b82 0120 c0a8 c0a8  ........K.......
        0x0010:  7c20 000d 6133 e54e c0a8 7cfe 0000 0000  |...a3.N..|.....

    _______________________________________________________

Reply to this item at:

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

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

Gmane