thiyagu1989 | 3 May 15:17 2016
Picon

steps to compile Lwip !

 Hello All ,

      I am really struggling to proceed further because open source and
communication stack are new for me .Initially my plan is to configure LwIP
and create a small application to communicate with the Hardware . As a
starter , I know I shouldn't be so jealous :) . So as a first step, I am
planning to compile the downloaded Lwip source in eclipse IDE with my
application but I couldnt find any Makefile. I had seen the some examples
but that are ported to particular MCU. Is there any one created a project
with an easy application and stub Ethernet driver so that it will be easy
for me understand ?
Any kind of help will be very useful for me .
Thanks in Advance . 

--
View this message in context: http://lwip.100.n7.nabble.com/steps-to-compile-Lwip-tp26274.html
Sent from the lwip-devel mailing list archive at Nabble.com.
Andrey Butok | 28 Apr 09:20 2016
Picon

[bug #47797] Version 2.0.0 RC1 has old 1.5 version in init.h

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

                 Summary: Version 2.0.0 RC1 has old 1.5 version in init.h
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: butok
            Submitted on: Thu 28 Apr 2016 07:20:05 AM GMT
                Category: None
                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:

init.h:
/** X.x.x: Major version of the stack */
#define LWIP_VERSION_MAJOR      1U
/** x.X.x: Minor version of the stack */
#define LWIP_VERSION_MINOR      5U

Best regards,
Andrey Butok
(Continue reading)

Simon Goldschmidt | 27 Apr 12:40 2016
Picon

[bug #47792] Cache neighbor_index per destination_cache entry

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

                 Summary: Cache neighbor_index per destination_cache entry
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: goldsimon
            Submitted on: Mi 27 Apr 2016 10:40:57 GMT
                Category: IPv6
                Severity: 2 - Minor
              Item Group: Feature Request
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: git head

    _______________________________________________________

Details:

The current nd6 caching mechanism uses HWADDRHINT to cache destination index
per pcb, but the corresponding neighbor cache entry is cached globally.

This means when we have 2 concurrent connections, the cache-index does not
work often.

By adding a 'cached_neighbor_idx' to struct nd6_destination_cache_entry, this
could be improved (the u8_t of this cache would not even increase the struct's
(Continue reading)

Simon Goldschmidt | 27 Apr 12:05 2016
Picon

[task #13983] Combine packet queueing for etharp & nd6

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

                 Summary: Combine packet queueing for etharp & nd6
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: goldsimon
            Submitted on: Mi 27 Apr 2016 10:05:15 GMT
                Category: None
         Should Start On: Mi 27 Apr 2016 00:00:00 GMT
   Should be Finished on: Mi 27 Apr 2016 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:

They seem to do the same...
Maybe we could use a pbuf packet list instead?

    _______________________________________________________

Reply to this item at:
(Continue reading)

Simon Goldschmidt | 27 Apr 10:12 2016
Picon

[bug #47790] Random delay missing in some places

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

                 Summary: Random delay missing in some places
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: goldsimon
            Submitted on: Mi 27 Apr 2016 08:12:08 GMT
                Category: IPv6
                Severity: 2 - Minor
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: git head

    _______________________________________________________

Details:

The RFCs specify random delay at startup in some places (e.g. first packet
after netif initialization, NS after receiving RA). Even for a lightweight
stack, this should be implemented, as it is required to prevent network load
peaks with many devices connected (and at least I did not find this
implemented, yet).

    _______________________________________________________

(Continue reading)

Ambroz Bizjak | 26 Apr 20:53 2016
Picon

[bug #47789] Hazard with netif_remove sending packets

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

                 Summary: Hazard with netif_remove sending packets
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: abizjak
            Submitted on: Tue 26 Apr 2016 06:53:14 PM GMT
                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: git head

    _______________________________________________________

Details:

Hey,
I've hit an issue in my application where I call netif_remove, and my code
asserted because netif_remove tried to transmit packets, due to TCP
connections being aborted. What do you think about ensuring within lwIP that
this does nott happen? It will probably save a few applications with similar
bugs lurking, and also I don't see any valid reason why packets would need to
be sent to a netif that is being removed.

(Continue reading)

Stephen Hersey | 26 Apr 16:46 2016
Picon

[bug #47787] DHCP client quits after 256 tries

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

                 Summary: DHCP client quits after 256 tries
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: shersey
            Submitted on: Tue 26 Apr 2016 02:46:54 PM GMT
                Category: DHCP
                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:

There's a weird corner case in LwIP where, if the DHCP client is unable to get
a response from a DHCP server after 256 tries, the DHCP retry counter (which
is a u8_t) will roll over to zero, and the DHCP timout will stop invoking
dhcp_timeout(). This is in a configuration where DHCP is enabled but AUTOIP is
not.

Now, most users will never see this, because it normally takes a LONG time to
reach 256 tries with the default exponential DHCP  backoff. However, I'm using
(Continue reading)

richardhu | 25 Apr 11:08 2016
Picon

[bug #47781] does lwIP support listen/bind on multiple IP and multiple port?

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

                 Summary: does lwIP support listen/bind on multiple IP and
multiple port?
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: hyr666
            Submitted on: Mon 25 Apr 2016 09:07:59 AM GMT
                Category: IPv4
                Severity: 3 - Normal
              Item Group: Feature Request
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: 1.4.1

    _______________________________________________________

Details:

My senario should be a little special and I want to confirm if it's feasible.
What I have done by using lwIP receive IP packets, and lwIP use lwIP socket
API to bind and listen on one specific IP and port. And receive according
layer7 data and do something on it. And this already worked.
What I want to do is based on above solution to receive IP packets with
different target IP.
That's means lwIP socket API need to bind/listen on multiple IPs and ports
(Continue reading)

Martin Kortmann | 21 Apr 07:42 2016
Picon

[bug #47749] #define ETHARP_TRUST_IP_MAC does not compile

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

                 Summary: #define ETHARP_TRUST_IP_MAC does not compile
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: mkortmann
            Submitted on: Do 21 Apr 2016 05:42:27 GMT
                Category: None
                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:

After definition of the option ETHARP_TRUST_IP_MAC lwip does not compile
anymore.
Reason: ethernet.c calls etharp_ip_input() but etharp_ip_input() is local to
atharp.c and there is no public declaration.

    _______________________________________________________

Reply to this item at:
(Continue reading)

Jan Breuer | 20 Apr 20:07 2016
Picon

[bug #47743] Closing listening tcp pcb is not posible without assert

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

                 Summary: Closing listening tcp pcb is not posible without
assert
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: jan_breuer
            Submitted on: Wed 20 Apr 2016 06:07:27 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:

Closing listening tcp pcb is not posible without assert.

tcp_listen_closed could not satisfy pcb->state == LISTEN

In function tcp_close_shutdown
there is section 
case LISTEN:
(Continue reading)

Ryan Mullen | 18 Apr 20:44 2016
Picon

[bug #47731] IGMP state transition missing

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

                 Summary: IGMP state transition missing
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: rmull
            Submitted on: Mon 18 Apr 2016 06:44:11 PM 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: git head

    _______________________________________________________

Details:

I was browsing the code in core/ipv4/igmp.c and I am a bit confused by the
means by which the multicast group state gets set to IGMP_GROUP_IDLE_MEMBER.

For reference, here is the IGMPv2 RFC section that describes the state diagram
for an IGMP host: https://tools.ietf.org/html/rfc2236#section-6 (scroll down
for an ASCII-art diagram).

The RFC says that state should transition from IGMP_GROUP_DELAYING_MEMBER to
(Continue reading)


Gmane