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
(Continue reading)

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            |.........|.
(Continue reading)

任海波 | 16 Aug 08:11 2014
Picon

[bug #42998] The netif hardware adddress length need to be changed.

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

                 Summary: The netif hardware adddress length need to be
changed.
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: hichard
            Submitted on: Sat Aug 16 06:11:30 2014
                Category: None
                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:
     I have used lwip IPv6 for a long time. I find some problem which strongly
recommended to make modification.
     Some code in the file netif.h as follow:
/** must be the maximum of all used hardware address lengths
    across all types of interfaces in use */
#define NETIF_MAX_HWADDR_LEN 6U
(Continue reading)

Todd Lewellen | 14 Aug 16:54 2014
Picon

[bug #42987] lwIP is vulnerable to DNS cache poisoning due to non-randomized TXIDs

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

                 Summary: lwIP is vulnerable to DNS cache poisoning due to
non-randomized TXIDs
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: tblewellen
            Submitted on: Thu 14 Aug 2014 02:54:05 PM GMT
                Category: DNS
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Private
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: git head

    _______________________________________________________

Details:

Subject: [VU#210620] lwIP vulnerability

Greetings,

While reviewing our vulnerability reports we were notified of a vulnerability
in lwIP.  We are tracking this issue as VU#210620. Our policy is to publish a
public vulnerability note within 45 days depending on the circumstances. An
(Continue reading)

Andreas Bachmann | 8 Aug 15:10 2014
Picon

Re: [patch #7993] Add support for transmitting packets with VLAN headers


> Right. Done as in the patch, thanks for it.

I'm using this patch resp. the git master repository 
git://git.sv.gnu.org/lwip.git
I wrote check- and set-functions in lwipopts.h:

#define LWIP_HOOK_VLAN_CHECK(netif, eth_hdr, vlan_hdr)  
etherarp_vlan_check(netif, eth_hdr, vlan_hdr)
#define LWIP_HOOK_VLAN_SET(netif, eth_hdr, vlan_hdr)    
etherarp_vlan_set(netif, eth_hdr, vlan_hdr)

Receiving VLAN-tagged frames and reply to it works fine, for example 
ICMP echo requests and replies.
When receiving non-VLAN-tagged frames, it allocated a new pbuf in RAM 
[icmp.c:icmp_input()] (should not!!) and gets an error when making room 
for the Ethernet header [etharp.c:etharp_output()].
I think SIZEOF_VLAN_HDR is hard coded and doesn't allow handling 
non-VLAN-tagged frames and therefore can't be used for both, VLAN-tagged 
and non-VLAN-tagged frames.

Regards,

Andreas Bachmann

VLAN-tagged frame:
enet_input:
     AA BB CC DD EE FF 00 1B  21 5C 22 01 81 00 00 01         
........!\".....
     08 00 45 00 00 4C 00 00  00 00 FF 01 9D 53 0A 29         
(Continue reading)

Philipp Tölke | 31 Jul 12:13 2014
Picon

[bug #42885] nd6_reachability_hint() accepts an address of an unknown neighbour

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

                 Summary: nd6_reachability_hint() accepts an address of an
unknown neighbour
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: philipptoelke
            Submitted on: Thu 31 Jul 2014 10:13:35 AM GMT
                Category: IPv6
                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 our application devices use multicast to discover each other.

We erroneously called nd6_reachability_hint() after successful communication
even when using multicast which can lead to an neighbour-cache entry being
made "REACHABLE" that has no valid LL-address.

While this clearly was our mistake, I propose the attached patch. It changes
(Continue reading)

Erik Ekman | 25 Jul 10:10 2014
Picon

[patch #8501] DHCP unit test fix

URL:
  <http://savannah.nongnu.org/patch/?8501>

                 Summary: DHCP unit test fix
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: yarrick
            Submitted on: Fri 25 Jul 2014 08:10:33 AM GMT
                Category: None
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

As reported on the mailing list, the test_dhcp_relayed unit tests fails with
an error. It worked for me when as it was originally, but not after commit
e1225cec5f4817248 in which some packet numbers were changed together with lots
of proper fixes.

The renumbering of packets is not mentioned in the commit message, so it is
not clear why it was done. Was it required for it to pass for you Simon?

In case it is broken for you too, please apply this patch that fixes it for
(Continue reading)

Valery Ushakov | 12 Jul 03:04 2014
Picon

[bug #42737] TCP_SND_QUEUELEN check in init.c (and comment in opt.h) are slighlty wrong

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

                 Summary: TCP_SND_QUEUELEN check in init.c (and comment in
opt.h) are slighlty wrong
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: uwe
            Submitted on: Sat 12 Jul 2014 01:04:44 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:

init.c checks that

#if TCP_SND_QUEUELEN < (2 * (TCP_SND_BUF / TCP_MSS))

since for each mss-sized pbuf with data there's another pbuf with header,
hence the factor of two.

(Continue reading)

katta dhanujanrao | 11 Jul 07:53 2014
Picon

(no subject)

HI All,
Greeting for the day,

I am Dhanunjay, i am regularly using netperf for testing various processors ethernet performance.

presently i have a project request,Port netperf to lwip.

Do we have alredy ported netperf to lwip?,ifwe have can you provide information.

Or if we dont have please suggest me how to port?,This need for one of my project request.

Thanks in advance,

Thanks,
Dhanunjay.
_______________________________________________
lwip-devel mailing list
lwip-devel <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-devel
Julian Alden-Salter | 10 Jul 17:50 2014
Picon

[bug #42726] reception of TCP ack becomes very slow after a period of time

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

                 Summary: reception of TCP ack becomes very slow after a
period of time
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: julian2002
            Submitted on: Thu 10 Jul 2014 03:50:17 PM GMT
                Category: IPv4
                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:

Hi,
I have an issue where a socket is opened to a server and remains open for long
periods of time. Data is sent and recieved over this socket. After an
indeterminate amount of time the connection becomes very slow.
I am only just starting to trace into this and have just implemented the
percipio tracalyzer to help in debugging.

under normal operation I can see 
RX 1120 bytes
tx 54 bytes
tx 91 bytes
repeat 

under the fail case i see
RX 1120 bytes
tx 54 bytes
tx 91 bytes
rx 60 bytes
tx 91 bytes
repeat

does anyone have any clue as to where to go from here or perhaps a reason for
the issue.

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/
Ivan Delamer | 10 Jul 18:10 2014

Re: Multicast over IPv6

Rahul: check all flags and API related to MLD6.

It is working well for me, use HEAD revision.

Cheers
Ivan

> Date: Wed, 9 Jul 2014 17:16:43 +0530
> From: Rahul Gundecha <rahul.gundecha <at> gmail.com>
> To: lwip-devel <lwip-devel <at> nongnu.org>
> Subject: [lwip-devel] Multicast over IPv6
> Message-ID:
> 	<CAPvfif+AJRpZWorJvjmpQ6ONLwWmAx9VqPieqCbA54_KcHe4LQ <at> mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi all,
> 
> Has anyone tried multicast over IPv6 in lwip?
> It seems the IPv6 multicast related options like IPV6_JOIN_GROUP,
> IPV6_MULTICAST_IF and data structures like ipv6_mreq have not been
> implemented yet.
> 
> I will appreciate the clues/pointers to existing stuff/plans for this
> feature
> 
> Thanks,
> Rahul
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.nongnu.org/archive/html/lwip-devel/attachments/20140709/c7d5c1af/attachment.html>
> 
> ------------------------------

Gmane