Re: [lwip-users] DHCP.h need to include "lwip/prot/dhcp.h" ?

2017-09-08 Thread goldsi...@gmx.de 

antonio wrote:

I have an application that requires including dhcp.h, however, since the
DHCP state messages are in prot/dhcp.h
I got a compile error..
" error: 'DHCP_STATE_BOUND' undeclared (first use in this function)
  if (new_state == DHCP_STATE_BOUND) {"

when I included  "lwip/prot/dhcp.h"  the error was gone..

Maybe in the main repository, dhcp.h needs to include "lwip/prot/dhcp" ...


No. This change is on purpose. Having an application depend on the dhcp 
client's state is not really good design. The state defines are 
deliberately not part of the "public" API of dhcp.h any more. You're 
free of course to override this and include prot/dhcp.h in your application.


Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Fix GCC warnings regarding two macros?

2017-09-08 Thread goldsi...@gmx.de 

Nathan Hartman wrote:

When building lwIP-1.4.1


Honestly, I stopped paying attention here. 1.4.1 is nearly five years 
old. Please do test the new version instead of cross-reading the sources ;-)


Have you found 'ip_addr_isany_val()'?

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Handle received data only partial

2017-09-08 Thread goldsi...@gmx.de 

Paul Plankton wrote:
My problem: I'm running on an embedded system where I can't waste too 
much time with handling network data.


This and the statement about handling "1460 bytes during one interrupt 
call" is somewhat disturbing. Are you sure you don't violate lwIP's 
threading requirements?


Also, Embedded and "too much time" is not really good phrasing. Either 
you need realtime or you need TCP ;-)



[..]
My question: is there a possibility to do one of both? If yes - how 
can this be done?


No. The only thing I can think of is: don't use TCP if you want a 
message-oriented protocol. Use UDP instead! TCP is about data streams, 
not about telegrams.


If you're stuck to TCP and still want it your way, you'll have to 
implement the buffering at your application layer. There's no code in 
the core stack that does this for you.


Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] Fix GCC warnings regarding two macros?

2017-09-08 Thread Nathan Hartman 
When building lwIP-1.4.1 on Linaro GCC v4.9.3 with -Wall, GCC issues
warnings in two places where the macro ip_addr_isany(addr1) is used, saying
the comparison against NULL will always evaluate to false. This warning is
correct in both cases because the macro is given the address of a local
stack variable, which can never be NULL.

It is clear that the macro must test for NULL. We need to build with zero
compiler warnings. I examined the lwIP-2.0.2 code, since the changelog
mentioned fixes to a number of compiler warnings, but I didn't see a change
in this macro.

I am tempted to use a trick like the one mentioned here:

https://stackoverflow.com/questions/27048171/disable-warning-the-address-of-x-will-always-evaluate-as-true

Namely to modify the macro, casting to (void *) to trick the compiler into
not issuing the warning. However I wonder if there is a "better" fix. Has
anyone encountered these warnings before?
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LWIP_MPU_COMPATIBLE set to 1, but still get memory management fault in lwip_select.

2017-09-08 Thread Joel Cunningham 
David,

Would you mind opening a bug report at 
https://savannah.nongnu.org/bugs/?func=additem&group=lwip 
 and attaching the 
patches so we can do the review there?

Also, it would be preferable to have the changes in a git patchset that can be 
applied to the repo (easier to review than looking at individual patch files)

Thanks

Joel


> On Sep 8, 2017, at 9:50 AM, David Lockyer  wrote:
> 
> So something like attached?
> 
> I removed my raise/reset macro's.
> It appears to work for me, I added a new private pool, not sure if this was 
> what you intended or not.
> 
> Let me know what you think.
> 
> BR
> David
> 
> On 07/09/17 19:40, goldsi...@gmx.de  wrote:
>> David Lockyer wrote:
>>> Okay, thank you for the suggestion. Just to be clear are you suggesting 
>>> modifying lwip_select() to allocate select_cb from a pool & free prior to 
>>> return?
>> 
>> Via a define, like Joel wrote, yes. This might need a new memp pool though...
>> We don't have an abstraction for your priviledge raising macro yet, and I'm 
>> not sure it's the best solution for everyone using this mode, either.
>> 
>>> I will have to investigate the speed impact of this, as I have 
>>> MEM_LIBC_MALLOC and MAEP_MEM_MALLOC both defined as 1.
>>> 
>> 
>> Well, you have this pool allocation at some other places already when socket 
>> threads communicate with the tcpip thread for asynchronous things.
>> Having those 2 defines combined with a possibly slow libc malloc() (heap) is 
>> probabably not the fastest solution, anyway.
>> 
>> The best thing to get this fixed would be 
>> 
>> Simon 
>> __
>> This email has been scanned by the Symantec Email Security.cloud service.
>> For more information please visit http://www.symanteccloud.com 
>> 
>> __
>> 
>> 
>> ___
>> lwip-users mailing list
>> lwip-users@nongnu.org 
>> https://lists.nongnu.org/mailman/listinfo/lwip-users 
>> 
> 
> __
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> __
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LWIP_MPU_COMPATIBLE set to 1, but still get memory management fault in lwip_select.

2017-09-08 Thread David Lockyer 

So something like attached?

I removed my raise/reset macro's.

It appears to work for me, I added a new private pool, not sure if this 
was what you intended or not.


Let me know what you think.

BR
David

On 07/09/17 19:40, goldsi...@gmx.de wrote:

David Lockyer wrote:
Okay, thank you for the suggestion. Just to be clear are you 
suggesting modifying lwip_select() to allocate select_cb from a pool 
& free prior to return? 


Via a define, like Joel wrote, yes. This might need a new memp pool 
though...
We don't have an abstraction for your priviledge raising macro yet, 
and I'm not sure it's the best solution for everyone using this mode, 
either.


I will have to investigate the speed impact of this, as I have 
MEM_LIBC_MALLOC and MAEP_MEM_MALLOC both defined as 1.




Well, you have this pool allocation at some other places already when 
socket threads communicate with the tcpip thread for asynchronous things.
Having those 2 defines combined with a possibly slow libc malloc() 
(heap) is probabably not the fastest solution, anyway.


The best thing to get this fixed would be

Simon
__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users




__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__--- lwip-2.0.2/src/api/sockets.c   (original)
+++ lwip-2.0.2/src/api/sockets.c   (patched)
@@ -50,7 +50,6 @@
 
 #include "lwip/sockets.h"
 #include "lwip/api.h"
-#include "lwip/sys.h"
 #include "lwip/igmp.h"
 #include "lwip/inet.h"
 #include "lwip/tcp.h"
@@ -76,6 +75,13 @@
 #undef LWIP_NETCONN
 #define LWIP_NETCONN 0
 #endif
+
+#define API_SELECT_CB_VAR_REF(name)   API_VAR_REF(name)
+#define API_SELECT_CB_VAR_DECLARE(name)   API_VAR_DECLARE(struct lwip_select_cb, name)
+#define API_SELECT_CB_VAR_ALLOC(name) API_VAR_ALLOC(struct lwip_select_cb, MEMP_SELECT_CB, name, ERR_MEM)
+#define API_SELECT_CB_VAR_ALLOC_RETURN_NULL(name) API_VAR_ALLOC(struct lwip_select_cb, MEMP_SELECT_CB, name, NULL)
+#define API_SELECT_CB_VAR_FREE(name)  API_VAR_FREE(MEMP_SELECT_CB, name)
+
 
 #if LWIP_IPV4
 #define IP4ADDR_PORT_TO_SOCKADDR(sin, ipaddr, port) do { \
@@ -218,32 +224,6 @@
   SELWAIT_T select_waiting;
 };
 
-#if LWIP_NETCONN_SEM_PER_THREAD
-#define SELECT_SEM_Tsys_sem_t*
-#define SELECT_SEM_PTR(sem) (sem)
-#else /* LWIP_NETCONN_SEM_PER_THREAD */
-#define SELECT_SEM_Tsys_sem_t
-#define SELECT_SEM_PTR(sem) (&(sem))
-#endif /* LWIP_NETCONN_SEM_PER_THREAD */
-
-/** Description for a task waiting in select */
-struct lwip_select_cb {
-  /** Pointer to the next waiting task */
-  struct lwip_select_cb *next;
-  /** Pointer to the previous waiting task */
-  struct lwip_select_cb *prev;
-  /** readset passed to select */
-  fd_set *readset;
-  /** writeset passed to select */
-  fd_set *writeset;
-  /** unimplemented: exceptset passed to select */
-  fd_set *exceptset;
-  /** don't signal the same semaphore twice: set to 1 when signalled */
-  int sem_signalled;
-  /** semaphore to wake up a task waiting for select */
-  SELECT_SEM_T sem;
-};
-
 /** A struct sockaddr replacement that has the same alignment as sockaddr_in/
  *  sockaddr_in6 if instantiated.
  */
@@ -1375,13 +1355,15 @@
   int nready;
   fd_set lreadset, lwriteset, lexceptset;
   u32_t msectimeout;
-  struct lwip_select_cb select_cb;
+  API_SELECT_CB_VAR_DECLARE(select_cb);
   int i;
   int maxfdp2;
 #if LWIP_NETCONN_SEM_PER_THREAD
   int waited = 0;
 #endif
   SYS_ARCH_DECL_PROTECT(lev);
+
+  API_SELECT_CB_VAR_ALLOC(select_cb);
 
   LWIP_DEBUGF(SOCKETS_DEBUG, ("lwip_select(%d, %p, %p, %p, tvsec=%"S32_F" tvusec=%"S32_F")\n",
   maxfdp1, (void *)readset, (void *) writeset, (void *) exceptset,
@@ -1406,18 +1388,19 @@
list is only valid while we are in this function, so it's ok
to use local variables. */
 
-select_cb.next = NULL;
-select_cb.prev = NULL;
-select_cb.readset = readset;
-select_cb.writeset = writeset;
-select_cb.exceptset = exceptset;
-select_cb.sem_signalled = 0;
+API_SELECT_CB_VAR_REF(select_cb).next = NULL;
+API_SELECT_CB_VAR_REF(select_cb).prev = NULL;
+API_SELECT_CB_VAR_REF(select_cb).readset = readset;
+API_SELECT_CB_VAR_REF(select_cb).writeset = writeset;
+API_SELECT_CB_VAR_REF(select_cb).exceptset = exceptset;
+API_SELECT_CB_VAR_REF(select_cb).sem_signalled = 0;
 #if LWIP_NETCONN_SEM_PER_THREAD
-select_cb.sem = LWIP_NETCONN_T

Re: [lwip-users] udp_send / udp_recv thread safefy

2017-09-08 Thread Ricardo Martins 
Thanks, I'll use the tcpip_callback then.

Kind regards,
Ricardo martins

On Fri, Sep 8, 2017 at 2:52 PM, Dirk Ziegelmeier 
wrote:

> No, its not OK to call raw API functions from another thread.
>
> See http://www.nongnu.org/lwip/2_0_x/pitfalls.html
>
> Dirk
>
> On Fri, Sep 8, 2017 at 12:04 PM, Ricardo Martins 
> wrote:
>
>> Hi,
>>
>> I'm doing some work with LWIP 2.0.2 using the raw API to send and receive
>> UDP datagrams and I have a doubt regarding the thread safety of udp_send
>> and udp_recv. Right now I have a single UDP PCB instance and I'm handling
>> incoming datagrams in one thread using the recv callback (I assume this
>> thread is the tcpip_thread) and sending UDP datagrams in another thread. Is
>> this safe or should I queue my UDP transmissions using the
>> tcpip_callback_with_block ?
>>
>> Kind regards,
>> Ricardo Martins
>>
>> ___
>> lwip-users mailing list
>> lwip-users@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] udp_send / udp_recv thread safefy

2017-09-08 Thread Dirk Ziegelmeier 
No, its not OK to call raw API functions from another thread.

See http://www.nongnu.org/lwip/2_0_x/pitfalls.html

Dirk

On Fri, Sep 8, 2017 at 12:04 PM, Ricardo Martins 
wrote:

> Hi,
>
> I'm doing some work with LWIP 2.0.2 using the raw API to send and receive
> UDP datagrams and I have a doubt regarding the thread safety of udp_send
> and udp_recv. Right now I have a single UDP PCB instance and I'm handling
> incoming datagrams in one thread using the recv callback (I assume this
> thread is the tcpip_thread) and sending UDP datagrams in another thread. Is
> this safe or should I queue my UDP transmissions using the
> tcpip_callback_with_block ?
>
> Kind regards,
> Ricardo Martins
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] Handle received data only partial

2017-09-08 Thread Paul Plankton 
Hello,

within my tcp_recv()-function the "struct pbuf" which hands over the
received data sometimes contains chained buffers pbuf->next where "next"
points to the next buffer of data.

My problem: I'm running on an embedded system where I can't waste too much
time with handling network data. So I would prefer to

a) get tcp_recv() called with only one pbuf-element in order to deal with
1460 bytes at max during one interrupt call

b) return from tcp_recv() without having fetched all data (means I handle
only one pbuf and get the remaining ones during next call of tcp_recv())

My question: is there a possibility to do one of both? If yes - how can
this be done?

Thanks!

Paul
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] udp_send / udp_recv thread safefy

2017-09-08 Thread Ricardo Martins 
Hi,

I'm doing some work with LWIP 2.0.2 using the raw API to send and receive
UDP datagrams and I have a doubt regarding the thread safety of udp_send
and udp_recv. Right now I have a single UDP PCB instance and I'm handling
incoming datagrams in one thread using the recv callback (I assume this
thread is the tcpip_thread) and sending UDP datagrams in another thread. Is
this safe or should I queue my UDP transmissions using the
tcpip_callback_with_block ?

Kind regards,
Ricardo Martins
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] DHCP.h need to include "lwip/prot/dhcp.h" ?

2017-09-08 Thread antonio 
Dear All,

I found a small problem, while porting lwip from 1.4.1 to 2.0.2. 

I have an application that requires including dhcp.h, however, since the
DHCP state messages are in prot/dhcp.h 
I got a compile error.. 
" error: 'DHCP_STATE_BOUND' undeclared (first use in this function)
 if (new_state == DHCP_STATE_BOUND) {"

when I included  "lwip/prot/dhcp.h"  the error was gone.. 

Maybe in the main repository, dhcp.h needs to include "lwip/prot/dhcp" ... 


thanks in advance.. 







--
Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users