Tomasz Moń | 17 Nov 19:00 2014
Picon

[patch #8572] Do not silence ERR_RTE for tcp write

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

                 Summary: Do not silence ERR_RTE for tcp write
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: desowin
            Submitted on: Mon 17 Nov 2014 06:00:52 PM GMT
                Category: sockets/netconn
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

This makes lwip_send return error if no route is available for example due to
all interfaces being down (for example: after connection was established
someone disconnected network cable).

    _______________________________________________________

File Attachments:

-------------------------------------------------------
(Continue reading)

hanhui | 15 Nov 06:45 2014
Picon

[bug #43617] lwip aodv ad-hoc routing method.

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

                 Summary: lwip aodv ad-hoc routing method.
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: hanhui03
            Submitted on: Sat 15 Nov 2014 05:45:34 AM GMT
                Category: Contrib
                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:

Hello all

This AODV (Ad hoc On-Demand Distance Vector Routing,AODV)is the most
fully featured AODV in the world.

Han.hui China

    _______________________________________________________
(Continue reading)

Simon Goldschmidt | 14 Nov 21:27 2014
Picon

[task #13397] Add optional source-based IPv4 routing

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

                 Summary: Add optional source-based IPv4 routing
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: goldsimon
            Submitted on: Fr 14 Nov 2014 20:27:57 GMT
                Category: IPv4
         Should Start On: Fr 14 Nov 2014 00:00:00 GMT
   Should be Finished on: Fr 14 Nov 2014 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:

There *are* obviously configurations where source-based routing is required.
The core code should not prevent this (while preventing an impact of this
feature on single-netif configurations).

    _______________________________________________________

(Continue reading)

Ben Hastings | 13 Nov 07:48 2014
Picon

[bug #43596] IGMP queries from 0.0.0.0 are discarded

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

                 Summary: IGMP queries from 0.0.0.0 are discarded
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: hastings
            Submitted on: Thu 13 Nov 2014 01:48:36 AM EST
                Category: IPv4
                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:

Experiencing an issue with LwIP in a network with an IGMP snooping switch. 
The switch is not an actual multicast router, so it sends general membership
queries with a source address of 0.0.0.0.  This appears to be in line with RFC
4541, however LwIP discards the packets due to the bogus source address.  This
causes the IGMP code to never respond with a membership report and the switch
to stop forwarding multicast packets on that port.

The attached patch to ip.c allows packets with an all zero source address and
(Continue reading)

Hugo Fiennes | 12 Nov 02:29 2014
Picon

[bug #43583] dhcp_recv() won't work on netifs with multiple hwaddrs

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

                 Summary: dhcp_recv() won't work on netifs with multiple
hwaddrs
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: hugof
            Submitted on: Wed 12 Nov 2014 01:29:05 AM 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:

...as the code will abort receive packet processing on the first mismatch,
whereas it should only abort if the chaddr is not ANY of the netif hwaddrs.

See below from dhcp_recv():

 /* iterate through hardware address and match against DHCP message */
  for (i = 0; i < netif->hwaddr_len; i++) {
(Continue reading)

chrysn | 11 Nov 16:09 2014
Picon

[patch #8570] ppp/ipcp.c: use uint32_t instead of u_int32_t

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

                 Summary: ppp/ipcp.c: use uint32_t instead of u_int32_t
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: chrysn
            Submitted on: Tue 11 Nov 2014 15:09:07 GMT
                Category: PPP
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

> the style u_int32_t is not used anywhere else in the project, and is not
> supported by the c standard (as opposed to uint32_t, which should come
> from stdint.h). it was introduced in 25e398a.

if ipcp.c is tightly coupled with a pppd upstream, it might be a better idea
to typedef u_int32_t at the beginning of the file, but otherwise, this seems
to be the clean solution.

    _______________________________________________________
(Continue reading)

Ivan Delamer | 5 Nov 18:19 2014

Re: Single socket to handle IPv4 and IPv6 traffic

Hi Rahul,

This is not possible at the moment and I think it would be nice to have 
in some cases.

Although I'm not sure about all implications and if it is possible. For 
example, we need to know for an incoming packet if it was received on 
IPv4 or IPv6 to respond using the same protocol. I'm not sure this is 
possible at the moment.

I will add a task to investigate it when I have more time.

For now, we'll have to open 2 netconns. It may be possible using socket 
API but again I'm not 100% sure. I don't generally use sockets just 
netconns.

Cheers
Ivan

> Date: Wed, 5 Nov 2014 10:30:45 +0530
> From: Rahul Gundecha <rahul.gundecha <at> gmail.com>
> To: lwip-devel <lwip-devel <at> nongnu.org>
> Subject: [lwip-devel] Single socket to handle IPv4 and IPv6 traffic
> Message-ID:
> 	<CAPvfif+W+dtCzpJKA2U+oeV+nNOyEAtVyneexmX0b1sT4Fj4GA <at> mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi all,
> 
> Is there a way by which we can have single socket able to handle both 
(Continue reading)

Rahul Gundecha | 5 Nov 06:00 2014
Picon

Single socket to handle IPv4 and IPv6 traffic

Hi all,

Is there a way by which we can have single socket able to handle both IPv4 and IPv6 UDP traffic for a specific port?
I was looking to use a UDP socket to handle both IPv4 and IPv6 traffic. However from src/core/udp.c, it seems that such case is not handled.
Is there plan to handle such case or am I missing something.

Thanks,
Rahul

_______________________________________________
lwip-devel mailing list
lwip-devel <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-devel
Uli Köhler | 2 Nov 00:48 2014
Picon

[bug #43514] SMTP authentication disabled when only LOGIN is enabled

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

                 Summary: SMTP authentication disabled when only LOGIN is
enabled
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: ulikoehler
            Submitted on: Sa 01 Nov 2014 23:48:58 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: 1.4.1

    _______________________________________________________

Details:

In lwip-contrib/apps/smtp/smtp.c (verified in git head and STABLE-1_4_1),
several code blocks including smtp_prepare_auth_or_mail() are enabled/disabled
using the following macro:

#if SMTP_SUPPORT_AUTH_AUTH || SMTP_SUPPORT_AUTH_LOGIN

I believe this is a typo and it should read: 

#if SMTP_SUPPORT_AUTH_PLAIN || SMTP_SUPPORT_AUTH_LOGIN

because SMTP_SUPPORT_AUTH_AUTH is defined nowhere and it clearly makes sense
to enable the code blocks if any of the both auth methods are enabled.

I'm trying to run the SMTP client with LOGIN auth disabled and my mailserver
shows that no authentication attempt is performed. 

Suggested fix:

Replace all occurences of "SMTP_SUPPORT_AUTH_AUTH" with
"SMTP_SUPPORT_AUTH_PLAIN" in smtp.c.

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht gesendet von/durch Savannah
  http://savannah.nongnu.org/
Carlos Galindo | 30 Oct 16:40 2014

next_timeout not working correctly

Dear all,
I am a rookie here but I think it is interesting to comment a problem that I
have already found while implementing the lwip.

My problem was that once initialized the stack with the function
tcpip_init(), my system does not attend any other task with lower priority
than the lwip. It was due to the first timeout in the next_timeout variable
has a the parameter time = 0, thus, the sys_timeouts_mbox_fetch() in the
tcpip_thread never blocks the lwip.

The reason of getting time equal to 0 in next_timeout variable was that
sys_timeout() trusts that when next_timeout has no timeout allocated, the
value is NULL. Problem is that in my system creating a pointer to struct it
does not iniate it as NULL.

My proposal to prevent that is changing the variable declaration from:

static struct sys_timeo *next_timeout;

to:

static struct sys_timeo *next_timeout = NULL;

Does it makes sense to you?

Best regards,
Carlos

--
View this message in context: http://lwip.100.n7.nabble.com/next-timeout-not-working-correctly-tp23444.html
Sent from the lwip-devel mailing list archive at Nabble.com.
goas | 29 Oct 18:29 2014
Picon

[bug #43499] Wrong argument order in src/include/netif/etharp.h defines

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

                 Summary: Wrong argument order in src/include/netif/etharp.h
defines
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: bgab001
            Submitted on: mer. 29 oct. 2014 17:29:45 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:

Hi

In file src/include/netif/etharp.h, there are the macros
#define ETHADDR32_COPY(src, dst)  SMEMCPY(src, dst, ETHARP_HWADDR_LEN)
#define ETHADDR16_COPY(src, dst)  SMEMCPY(src, dst, ETHARP_HWADDR_LEN)

It works fine, but in reality all memcpy() functions I ever saw actually use
(dst, src), as does the one on my ARM board, called after expanding all
macros.
So it's easy to mess up a port or not understand what the code is supposed to
do with this wrong argument order.

Can it be fixed to the following ?
#define ETHADDR32_COPY(dst, src)  SMEMCPY(dst, src, ETHARP_HWADDR_LEN)
#define ETHADDR16_COPY(dst, src)  SMEMCPY(dst, src, ETHARP_HWADDR_LEN)

B.G.

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message posté via/par Savannah
  http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-devel

Gmane