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

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

Vlad Lungu | 29 Oct 14:34 2014
Picon

[patch #8560] DHCP is not notified of link down events, admin status remains "up"

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

                 Summary: DHCP is not notified of link down events, admin
status remains "up"
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: vlungu
            Submitted on: Wed 29 Oct 2014 01:34:02 PM GMT
                Category: DHCP
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

    _______________________________________________________

File Attachments:

-------------------------------------------------------
Date: Wed 29 Oct 2014 01:34:02 PM GMT  Name:
0001-Fix-DHCP-handling-of-link-state.patch  Size: 966B   By: vlungu

(Continue reading)

Simon Goldschmidt | 28 Oct 22:29 2014
Picon

[bug #41495] Possible threading issue in select()

Update of bug #41495 (project lwip):

                  Status:                    None => Fixed                  
             Assigned to:                    None => goldsimon              
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #1:

Fixed.

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht gesendet von/durch Savannah
  http://savannah.nongnu.org/
Simon Goldschmidt | 28 Oct 22:03 2014
Picon

[bug #41497] lwip_select accessing bytes past the (maxfdp1+7)/8 of the fd_sets

Update of bug #41497 (project lwip):

                  Status:                    None => Works For Me           

    _______________________________________________________

Follow-up Comment #1:

Can't see how this can happen: with the default implementation, only the FD_*
macros are accessing the bits. And I consider them as safe as they are...

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht gesendet von/durch Savannah
  http://savannah.nongnu.org/
Simon Goldschmidt | 28 Oct 21:09 2014
Picon

[bug #43490] win32 port does not work with PPP (-new)

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

                 Summary: win32 port does not work with PPP (-new)
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: goldsimon
            Submitted on: Di 28 Okt 2014 20:09:29 GMT
                Category: PPP
                Severity: 3 - Normal
              Item Group: Compiler Warning
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 1.5.0 beta
            lwIP version: git head

    _______________________________________________________

Details:

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht gesendet von/durch Savannah
(Continue reading)

Daniel Gutson | 27 Oct 16:40 2014

LWIP in multithreaded environments - reloaded

Hi,

   I read the wiki and the email threads about
writing and reading through the same sockets by 2 different threads.

If I could consider a project to add this capability to LWIP (e.g. as
an R&D project), could someone please
 help me to estimate what amount of work are we talking about? It's a
2-, or 3-months project?
Assuming someone familiar with multithreading but not necessarily with
LWIP internals.

Linux initially, RTEMS later.

Thanks!

   Daniel.

ps: I assume that this is a desired feature.

--

-- 

Daniel F. Gutson
Chief Engineering Officer, SPD

San Lorenzo 47, 3rd Floor, Office 5

Córdoba, Argentina

Phone: +54 351 4217888 / +54 351 4218211
(Continue reading)

Sergio R. Caprile | 27 Oct 16:05 2014
Picon

[bug #43481] MEMP_SYS_TIMEOUTS is not for NO_SYS=0 only

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

                 Summary: MEMP_SYS_TIMEOUTS is not for NO_SYS=0 only
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: scaprile
            Submitted on: Mon 27 Oct 2014 12:05:24 PM ART
                Category: Documentation
                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,
the description in opt.h states that NO_SYS=0 is required:
/**
 * MEMP_NUM_SYS_TIMEOUT: the number of simultaneously active timeouts.
 * (requires NO_SYS==0)
 * The default number of timeouts is calculated here for all enabled modules.
 * The formula expects settings to be either '0' or '1'.
 */
(Continue reading)

MarkMcM | 21 Oct 18:01 2014

LLDP (Link Layer Discovery Protocol) for PoE?

Has anyone implemented LLDP (Link Layer Discovery Protocol) for configuring
PoE (Power over Ethernet) with the LwIP stack?  Are there any pointers that
anyone can provide for doing this?

We have an Ethernet IP device (based around an ARM Cortex-M4 processor) that
requires more power than standard PoE provides, and will need to use the
higher power available with PoE+.  But the device will have to negotiate the
higher power allotment from the PoE switch through LLDP.

Thanks for any guidance that anyone can provide.

--
View this message in context: http://lwip.100.n7.nabble.com/LLDP-Link-Layer-Discovery-Protocol-for-PoE-tp23418.html
Sent from the lwip-devel mailing list archive at Nabble.com.
Piotr | 18 Oct 21:12 2014
Picon

[bug #43437] Memory corruption beyound memory pool

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

                 Summary: Memory corruption beyound memory pool
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: michcior
            Submitted on: Sat 18 Oct 2014 07:12:23 PM GMT
                Category: pbufs
                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:

In the mem_init (mem.c) The code assigns to "ram_end" the top of the pool.
Then, if the pool was declared without spare bytes, the following instructions
corrupt memory, which is located just after memory pool.

  ram_end = (struct mem *)(void *)&ram[MEM_SIZE_ALIGNED];
  ram_end->used = 1;
  ram_end->next = MEM_SIZE_ALIGNED;
  ram_end->prev = MEM_SIZE_ALIGNED;
(Continue reading)

hanhui | 9 Oct 09:38 2014
Picon

[bug #43389] dns_recv() res_idx calculate error.

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

                 Summary: dns_recv() res_idx calculate error.
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: hanhui03
            Submitted on: Thu 09 Oct 2014 07:38:57 AM GMT
                Category: DNS
                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:

Hi Simon:

dns_recv()
{
    ...

<line:1086>
    res_idx = SIZEOF_DNS_ANSWER + htons(ans.len);
(Continue reading)


Gmane