[lwip-users] Is tcp_err()-callback optional?

[Karl Karpfen]

Hi,

indepenedent from the fact if it makes sense or if it is bad program style:
is it mandatory to announce a error-callback via tcp_err() or will the
whole thing also work smoothly when there is no error-callback function
available?

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

Re: [lwip-users] Is tcp_err()-callback optional?

[Karl Karpfen]

OK, thanks!

2015-10-12 13:17 GMT+02:00 Simon Goldschmidt :

> Karl Karpfen wrote:
> >indepenedent from the fact if it makes sense or if it is bad program
> style:
> > is it mandatory to announce a error-callback via tcp_err() or will the
> whole
> > thing also work smoothly when there is no error-callback function
> available?
>
> It is kind ofmandatory: without an 'err' callback, your application would
> never know if the pcb got deallocated (and possibly reused) due to a RST
> received or due to local pcb shortage.
>
>
> Simon
>
> ___
> 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] Is tcp_err()-callback optional?

[Simon Goldschmidt]

Karl Karpfen wrote:
>indepenedent from the fact if it makes sense or if it is bad program style:
> is it mandatory to announce a error-callback via tcp_err() or will the whole
> thing also work smoothly when there is no error-callback function available?

It is kind ofmandatory: without an 'err' callback, your application would never 
know if the pcb got deallocated (and possibly reused) due to a RST received or 
due to local pcb shortage.


Simon

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

Re: [lwip-users] lwip_close() doesn't work when lwip_write() hangs

[Joel Cunningham]

LwIP doesn't support this kind of threading model.  Multiple threads can not 
perform simultaneous operations (read+write, write+close, etc.) on the same 
socket.  The main limitation is that the netconn only has a single semaphore 
for blocking the calling thread when entering the core context.

On the master branch there is support for this model but the feature is in 
alpha state (see LWIP_NETCONN_FULLDUPLEX). In LwIP 1.4.1, this is not 
supported.

Joel

On Oct 10, 2015, at 12:29 AM, alhadpalkar  wrote:


I am using branch 1.4.1 of lwip. I have a thread that connects to a remote
server and writes data to it using lwip_write(). Sometimes this hangs
indefinitely. Looks like its waiting on the op->completed semaphore which
never gets signaled.

I tried using the SO_SNDTIMEO socket option, but that just causes panics in
my system. So I tried another approach where I use a watchdog that detects
this hang and calls lwip_close(). But it looks like LWIP doesn't like it. I
hit this assert

netconn_free(struct netconn *conn)
{
LWIP_ASSERT("PCB must be deallocated outside this function", conn->pcb.tcp
== NULL);
...
}

On debugging further it looks like we end up getting the ERR_INPROGRESS in
do_delconn().

do_delconn(struct api_msg_msg *msg)
{
/* @todo TCP: abort running write/connect? */
if ((msg->conn->state != NETCONN_NONE) &&
(msg->conn->state != NETCONN_LISTEN) &&
(msg->conn->state != NETCONN_CONNECT)) {
/* this only happens for TCP netconns */
LWIP_ASSERT("msg->conn->type == NETCONN_TCP", msg->conn->type ==
NETCONN_TCP);
km_printf("err in progress\n");
msg->err = ERR_INPROGRESS;
...
}

so we never end up cleanup up the pcbs which leads to this assert.

Is there a way around this?






--
View this message in context: 
http://lwip.100.n7.nabble.com/lwip-close-doesn-t-work-when-lwip-write-hangs-tp25191.html
Sent from the lwip-users mailing list archive at Nabble.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_close() doesn't work when lwip_write() hangs

[Alhad Palkar]

Thanks. Is there anyway around lwip_write blocking forever?

On Mon, Oct 12, 2015 at 7:44 AM, Joel Cunningham 
wrote:

> LwIP doesn't support this kind of threading model.  Multiple threads can
> not perform simultaneous operations (read+write, write+close, etc.) on the
> same socket.  The main limitation is that the netconn only has a single
> semaphore for blocking the calling thread when entering the core context.
>
> On the master branch there is support for this model but the feature is in
> alpha state (see LWIP_NETCONN_FULLDUPLEX). In LwIP 1.4.1, this is not
> supported.
>
> Joel
>
> On Oct 10, 2015, at 12:29 AM, alhadpalkar  wrote:
>
> I am using branch 1.4.1 of lwip. I have a thread that connects to a remote
> server and writes data to it using lwip_write(). Sometimes this hangs
> indefinitely. Looks like its waiting on the op->completed semaphore which
> never gets signaled.
>
> I tried using the SO_SNDTIMEO socket option, but that just causes panics in
> my system. So I tried another approach where I use a watchdog that detects
> this hang and calls lwip_close(). But it looks like LWIP doesn't like it. I
> hit this assert
>
> netconn_free(struct netconn *conn)
> {
> LWIP_ASSERT("PCB must be deallocated outside this function", conn->pcb.tcp
> == NULL);
> ...
> }
>
> On debugging further it looks like we end up getting the ERR_INPROGRESS in
> do_delconn().
>
> do_delconn(struct api_msg_msg *msg)
> {
> /* @todo TCP: abort running write/connect? */
> if ((msg->conn->state != NETCONN_NONE) &&
> (msg->conn->state != NETCONN_LISTEN) &&
> (msg->conn->state != NETCONN_CONNECT)) {
> /* this only happens for TCP netconns */
> LWIP_ASSERT("msg->conn->type == NETCONN_TCP", msg->conn->type ==
> NETCONN_TCP);
> km_printf("err in progress\n");
> msg->err = ERR_INPROGRESS;
> ...
> }
>
> so we never end up cleanup up the pcbs which leads to this assert.
>
> Is there a way around this?
>
>
>
>
>
>
> --
> View this message in context:
> http://lwip.100.n7.nabble.com/lwip-close-doesn-t-work-when-lwip-write-hangs-tp25191.html
> Sent from the lwip-users mailing list archive at Nabble.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
>
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwip_close() doesn't work when lwip_write() hangs

[Joel Cunningham]

You can use SO_SNDTIMEOUT, which should work on LwIP 1.4.1.  I have used it in 
my port with LwIP 1.4.1, so possibly there's a problem with your port?

I've also written applications that used non-blocking sockets and select to 
achieve a similar behavior of having blocking I/O that can be canceled.  The 
trick here is adding a second socket to the read FD set in select and then set 
select to block until your write or read is ready.  This second socket is bound 
to the loopback address.  When you want to cancel the blocking select from 
another thread, simply send a datagram to the additional socket, which will 
return the select call.  Then you can detect that a cancel/wakeup happened 
because the second socket is marked as ready.

Joel

On Oct 12, 2015, at 12:45 PM, Alhad Palkar  wrote:


Thanks. Is there anyway around lwip_write blocking forever?

On Mon, Oct 12, 2015 at 7:44 AM, Joel Cunningham  wrote:

LwIP doesn't support this kind of threading model.  Multiple threads can 
not perform simultaneous operations (read+write, write+close, etc.) on the same 
socket.  The main limitation is that the netconn only has a single semaphore 
for blocking the calling thread when entering the core context.

On the master branch there is support for this model but the feature is in 
alpha state (see LWIP_NETCONN_FULLDUPLEX). In LwIP 1.4.1, this is not supported.

Joel

On Oct 10, 2015, at 12:29 AM, alhadpalkar  wrote:


I am using branch 1.4.1 of lwip. I have a thread that connects to a remote
server and writes data to it using lwip_write(). Sometimes this hangs
indefinitely. Looks like its waiting on the op->completed semaphore which
never gets signaled.

I tried using the SO_SNDTIMEO socket option, but that just causes panics in
my system. So I tried another approach where I use a watchdog that detects
this hang and calls lwip_close(). But it looks like LWIP doesn't like it. I
hit this assert

netconn_free(struct netconn *conn)
{
LWIP_ASSERT("PCB must be deallocated outside this function", conn->pcb.tcp
== NULL);
...
}

On debugging further it looks like we end up getting the ERR_INPROGRESS in
do_delconn().

do_delconn(struct api_msg_msg *msg)
{
/* @todo TCP: abort running write/connect? */
if ((msg->conn->state != NETCONN_NONE) &&
(msg->conn->state != NETCONN_LISTEN) &&
(msg->conn->state != NETCONN_CONNECT)) {
/* this only happens for TCP netconns */
LWIP_ASSERT("msg->conn->type == NETCONN_TCP", msg->conn->type ==
NETCONN_TCP);
km_printf("err in progress\n");
msg->err = ERR_INPROGRESS;
...
}

so we never end up cleanup up the pcbs which leads to this assert.

Is there a way around this?






--
View this message in context: 
http://lwip.100.n7.nabble.com/lwip-close-doesn-t-work-when-lwip-write-hangs-tp25191.html
Sent from the lwip-users mailing list archive at Nabble.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


___
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_close() doesn't work when lwip_write() hangs

[Sylvain Rochet]

Hi Joel,

On Mon, Oct 12, 2015 at 07:10:39PM +, Joel Cunningham wrote:
> You can use SO_SNDTIMEOUT, which should work on LwIP 1.4.1.  I have used it 
> in my port with LwIP 1.4.1, so possibly there's a problem with your port?
> 
> I've also written applications that used non-blocking sockets and 
> select to achieve a similar behavior of having blocking I/O that can 
> be canceled.  The trick here is adding a second socket to the read FD 
> set in select and then set select to block until your write or read is 
> ready.  This second socket is bound to the loopback address.  When you 
> want to cancel the blocking select from another thread, simply send a 
> datagram to the additional socket, which will return the select call.  
> Then you can detect that a cancel/wakeup happened because the second 
> socket is marked as ready.

I really like this trick. It remembers myself of the well known wake up 
pipe I explained here[1], but using the loopback to do so in lwIP is 
very very clever :-)

Sylvain

[1] http://lists.gnu.org/archive/html/lwip-devel/2015-09/msg00028.html


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

Re: [lwip-users] lwip_close() doesn't work when lwip_write() hangs

[Joel Cunningham]

It's a great trick, hopefully others can leverage it as well :)I'm not sure what I'd do without it.  Having select() and non-blocking sockets operate as the blocking construct of a server's event loop is essential for managing multiple connections in a high performance manner.Joel  On Oct 12, 2015, at 02:19 PM, Sylvain Rochet  wrote:Hi Joel,On Mon, Oct 12, 2015 at 07:10:39PM +, Joel Cunningham wrote:You can use SO_SNDTIMEOUT, which should work on LwIP 1.4.1. I have used it in my port with LwIP 1.4.1, so possibly there's a problem with your port?I've also written applications that used non-blocking sockets andselect to achieve a similar behavior of having blocking I/O that canbe canceled. The trick here is adding a second socket to the read FDset in select and then set select to block until your write or read isready. This second socket is bound to the loopback address. When youwant to cancel the blocking select from another thread, simply send adatagram to the additional socket, which will return the select call.Then you can detect that a cancel/wakeup happened because the secondsocket is marked as ready.I really like this trick. It remembers myself of the well known wake up pipe I explained here[1], but using the loopback to do so in lwIP is very very clever :-)Sylvain[1] http://lists.gnu.org/archive/html/lwip-devel/2015-09/msg00028.html___lwip-users mailing listlwip-users@nongnu.orghttps://lists.nongnu.org/mailman/listinfo/lwip-users

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

[lwip-users] Infinite hang in tcp_slowtmr()

[Stephen Cowell]

Using 1.4.1, no OS, in a ftpd application.
Atmel SAM4E, based on THIRDPARTY_LWIP_RAW_BASIC_HTTP
example, ASF 3.25.

I find that I sometimes get an infinite loop when stepping to
pcb->next... if it is not a new pcb but the same old one, the
system hangs.  In order to get out of this I put the following
two lines of 'if' code at the end:

<>
} else {
  prev = pcb;
  pcb = pcb->next;
  if (prev == pcb)
pcb->next = NULL;// hack to escape infinite loop slc degub
}
  }
}


In talking on other forums I understand that this problem is
related to I/O stress.  Has this issue been dealt with before?
Is there a better solution?
__
Steve


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

Re: [lwip-users] Infinite hang in tcp_slowtmr()

[Sylvain Rochet]

Hi Stephen,

On Mon, Oct 12, 2015 at 02:51:14PM -0500, Stephen Cowell wrote:
> 
> I find that I sometimes get an infinite loop when stepping to
> pcb->next... 

I didn't have to read further. As usual, it looks like a broken port or 
usage which violate lwIP threading model.

Summary:

- Do *NOT* call anything in interrupt context, nothing, never, 
absolutely never, use your OS semaphore signaling to an 
Ethernet/serial/… RX thread

- memp_*, pbuf_*, functions are thread-safe if SYS_LIGHTWEIGHT_PROT is 
set, and again, thread safe does not mean it is interrupt safe

- Do *NOT* call any function from the RAW API outside lwIP thread

- Use Netconn or Socket API in others threads, but keep in mind you 
should not share a Netconn/Socket control block between threads, (or use 
proper locking if you really have to, of course).

- Please read doc/rawapi.txt from the lwIP source which explain that 
more comprehensively

Sylvain


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

Re: [lwip-users] lwip_close() doesn't work when lwip_write() hangs

[Alhad Palkar]

I tried using the SO_SNDTIMEO. Here is what I am seeing.

1. i create a socket using lwip_socket(AF_INET, SOCK_STREAM, 0) and then
connect using lwip_connect()
2. set the SO_SNDTIME0 to 1s using lwip_setsockopt(socket, SOL_SOCKET,
SO_SNDTIMEO, _int, sizeof(timeout_int))
3. then start sending data as follows

 while(err > 0) {
 err = lwip_write(socket, buffer, size);
 }

I see that I hit the timeout condition in the 2nd to last transfer

lwip_send(0, data=0x20A72D78, size=86264, flags=0x0)  <--- this is the
packet that times out
...
*so_sndtimeo <-- added these printouts to check the condition I am hitting*
*partial write*
lwip_send(0) err=0 written=67348

lwip_send(0, data=0x20A8348C, size=86264, flags=0x0) <--- the last packet
that causes the assert
panic: already writing or closing <--- we hit this in do_write() (
api_msg.c:1360)


Some questions;
1. Does that mean I cannot call lwip_write() after timing out on a previous
call to lwip_write()?
2. Can I use the fact that the size returned by lwip_write() < total buffer
size as an indication that our transfer timed out?

Thanks,
Alhad














On Mon, Oct 12, 2015 at 1:16 PM, Joel Cunningham 
wrote:

> It's a great trick, hopefully others can leverage it as well :)
>
> I'm not sure what I'd do without it.  Having select() and non-blocking
> sockets operate as the blocking construct of a server's event loop is
> essential for managing multiple connections in a high performance manner.
>
> Joel
>
> On Oct 12, 2015, at 02:19 PM, Sylvain Rochet 
> wrote:
>
> Hi Joel,
>
> On Mon, Oct 12, 2015 at 07:10:39PM +, Joel Cunningham wrote:
>
> You can use SO_SNDTIMEOUT, which should work on LwIP 1.4.1. I have used it
> in my port with LwIP 1.4.1, so possibly there's a problem with your port?
>
>
> I've also written applications that used non-blocking sockets and
>
> select to achieve a similar behavior of having blocking I/O that can
>
> be canceled. The trick here is adding a second socket to the read FD
>
> set in select and then set select to block until your write or read is
>
> ready. This second socket is bound to the loopback address. When you
>
> want to cancel the blocking select from another thread, simply send a
>
> datagram to the additional socket, which will return the select call.
>
> Then you can detect that a cancel/wakeup happened because the second
>
> socket is marked as ready.
>
>
> I really like this trick. It remembers myself of the well known wake up
> pipe I explained here[1], but using the loopback to do so in lwIP is
> very very clever :-)
>
> Sylvain
>
> [1] http://lists.gnu.org/archive/html/lwip-devel/2015-09/msg00028.html
> ___
> 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] lwip_close() doesn't work when lwip_write() hangs

[Alhad Palkar]

Figured out why I am hitting this issue. In the partial write case, the
write_offset is not reset back to zero. This causes the "already writing or
closing" assert in the next lwip_write() or lwip_close(). Once I set this
back to zero like this

diff --git a/lib/lwip/src/api/api_msg.c b/lib/lwip/src/api/api_msg.c
index 0a7edfe..2160766 100644
--- a/lib/lwip/src/api/api_msg.c
+++ b/lib/lwip/src/api/api_msg.c
@@ -1239,6 +1239,7 @@ do_writemore(struct netconn *conn)
   /* partial write */
   err = ERR_OK;
   conn->current_msg->msg.w.len = conn->write_offset;
+  conn->write_offset = 0; /* reset this back to zero */
   km_printf("partial write\n");
 }
   } else

things look to be working fine. Is this a known bug?

Thanks,
Alhad


On Mon, Oct 12, 2015 at 2:02 PM, Alhad Palkar  wrote:

>
> I tried using the SO_SNDTIMEO. Here is what I am seeing.
>
> 1. i create a socket using lwip_socket(AF_INET, SOCK_STREAM, 0) and then
> connect using lwip_connect()
> 2. set the SO_SNDTIME0 to 1s using lwip_setsockopt(socket, SOL_SOCKET,
> SO_SNDTIMEO, _int, sizeof(timeout_int))
> 3. then start sending data as follows
>
>  while(err > 0) {
>  err = lwip_write(socket, buffer, size);
>  }
>
> I see that I hit the timeout condition in the 2nd to last transfer
>
> lwip_send(0, data=0x20A72D78, size=86264, flags=0x0)  <--- this is the
> packet that times out
> ...
> *so_sndtimeo <-- added these printouts to check the condition I am hitting*
> *partial write*
> lwip_send(0) err=0 written=67348
>
> lwip_send(0, data=0x20A8348C, size=86264, flags=0x0) <--- the last packet
> that causes the assert
> panic: already writing or closing <--- we hit this in do_write() (
> api_msg.c:1360)
>
>
> Some questions;
> 1. Does that mean I cannot call lwip_write() after timing out on a
> previous call to lwip_write()?
> 2. Can I use the fact that the size returned by lwip_write() < total
> buffer size as an indication that our transfer timed out?
>
> Thanks,
> Alhad
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Oct 12, 2015 at 1:16 PM, Joel Cunningham 
> wrote:
>
>> It's a great trick, hopefully others can leverage it as well :)
>>
>> I'm not sure what I'd do without it.  Having select() and non-blocking
>> sockets operate as the blocking construct of a server's event loop is
>> essential for managing multiple connections in a high performance manner.
>>
>> Joel
>>
>> On Oct 12, 2015, at 02:19 PM, Sylvain Rochet 
>> wrote:
>>
>> Hi Joel,
>>
>> On Mon, Oct 12, 2015 at 07:10:39PM +, Joel Cunningham wrote:
>>
>> You can use SO_SNDTIMEOUT, which should work on LwIP 1.4.1. I have used
>> it in my port with LwIP 1.4.1, so possibly there's a problem with your
>> port?
>>
>>
>> I've also written applications that used non-blocking sockets and
>>
>> select to achieve a similar behavior of having blocking I/O that can
>>
>> be canceled. The trick here is adding a second socket to the read FD
>>
>> set in select and then set select to block until your write or read is
>>
>> ready. This second socket is bound to the loopback address. When you
>>
>> want to cancel the blocking select from another thread, simply send a
>>
>> datagram to the additional socket, which will return the select call.
>>
>> Then you can detect that a cancel/wakeup happened because the second
>>
>> socket is marked as ready.
>>
>>
>> I really like this trick. It remembers myself of the well known wake up
>> pipe I explained here[1], but using the loopback to do so in lwIP is
>> very very clever :-)
>>
>> Sylvain
>>
>> [1] http://lists.gnu.org/archive/html/lwip-devel/2015-09/msg00028.html
>> ___
>> 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] lwip_close() doesn't work when lwip_write() hangs

[Alhad Palkar]

ah. I think I found the fix

*Commit:* aecbce283db243ebfc786879e50b0da8d7006ed8 [aecbce2]
*Parents:* b8d798158b 
*Author:* goldsimon 
*Date:* October 21, 2014 at 2:09:07 AM PDT

fixed bug #38219 Assert on TCP netconn_write with sndtimeout set

Alhad.

On Mon, Oct 12, 2015 at 2:50 PM, Alhad Palkar  wrote:

> Figured out why I am hitting this issue. In the partial write case, the
> write_offset is not reset back to zero. This causes the "already writing or
> closing" assert in the next lwip_write() or lwip_close(). Once I set this
> back to zero like this
>
> diff --git a/lib/lwip/src/api/api_msg.c b/lib/lwip/src/api/api_msg.c
> index 0a7edfe..2160766 100644
> --- a/lib/lwip/src/api/api_msg.c
> +++ b/lib/lwip/src/api/api_msg.c
> @@ -1239,6 +1239,7 @@ do_writemore(struct netconn *conn)
>/* partial write */
>err = ERR_OK;
>conn->current_msg->msg.w.len = conn->write_offset;
> +  conn->write_offset = 0; /* reset this back to zero */
>km_printf("partial write\n");
>  }
>} else
>
> things look to be working fine. Is this a known bug?
>
> Thanks,
> Alhad
>
>
> On Mon, Oct 12, 2015 at 2:02 PM, Alhad Palkar 
> wrote:
>
>>
>> I tried using the SO_SNDTIMEO. Here is what I am seeing.
>>
>> 1. i create a socket using lwip_socket(AF_INET, SOCK_STREAM, 0) and then
>> connect using lwip_connect()
>> 2. set the SO_SNDTIME0 to 1s using lwip_setsockopt(socket, SOL_SOCKET,
>> SO_SNDTIMEO, _int, sizeof(timeout_int))
>> 3. then start sending data as follows
>>
>>  while(err > 0) {
>>  err = lwip_write(socket, buffer, size);
>>  }
>>
>> I see that I hit the timeout condition in the 2nd to last transfer
>>
>> lwip_send(0, data=0x20A72D78, size=86264, flags=0x0)  <--- this is the
>> packet that times out
>> ...
>> *so_sndtimeo <-- added these printouts to check the condition I am
>> hitting*
>> *partial write*
>> lwip_send(0) err=0 written=67348
>>
>> lwip_send(0, data=0x20A8348C, size=86264, flags=0x0) <--- the last packet
>> that causes the assert
>> panic: already writing or closing <--- we hit this in do_write() (
>> api_msg.c:1360)
>>
>>
>> Some questions;
>> 1. Does that mean I cannot call lwip_write() after timing out on a
>> previous call to lwip_write()?
>> 2. Can I use the fact that the size returned by lwip_write() < total
>> buffer size as an indication that our transfer timed out?
>>
>> Thanks,
>> Alhad
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Oct 12, 2015 at 1:16 PM, Joel Cunningham 
>> wrote:
>>
>>> It's a great trick, hopefully others can leverage it as well :)
>>>
>>> I'm not sure what I'd do without it.  Having select() and non-blocking
>>> sockets operate as the blocking construct of a server's event loop is
>>> essential for managing multiple connections in a high performance manner.
>>>
>>> Joel
>>>
>>> On Oct 12, 2015, at 02:19 PM, Sylvain Rochet 
>>> wrote:
>>>
>>> Hi Joel,
>>>
>>> On Mon, Oct 12, 2015 at 07:10:39PM +, Joel Cunningham wrote:
>>>
>>> You can use SO_SNDTIMEOUT, which should work on LwIP 1.4.1. I have used
>>> it in my port with LwIP 1.4.1, so possibly there's a problem with your
>>> port?
>>>
>>>
>>> I've also written applications that used non-blocking sockets and
>>>
>>> select to achieve a similar behavior of having blocking I/O that can
>>>
>>> be canceled. The trick here is adding a second socket to the read FD
>>>
>>> set in select and then set select to block until your write or read is
>>>
>>> ready. This second socket is bound to the loopback address. When you
>>>
>>> want to cancel the blocking select from another thread, simply send a
>>>
>>> datagram to the additional socket, which will return the select call.
>>>
>>> Then you can detect that a cancel/wakeup happened because the second
>>>
>>> socket is marked as ready.
>>>
>>>
>>> I really like this trick. It remembers myself of the well known wake up
>>> pipe I explained here[1], but using the loopback to do so in lwIP is
>>> very very clever :-)
>>>
>>> Sylvain
>>>
>>> [1] http://lists.gnu.org/archive/html/lwip-devel/2015-09/msg00028.html
>>> ___
>>> 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] Infinite hang in tcp_slowtmr()

[Stephen Cowell]

On 10/12/2015 3:41 PM, Sylvain Rochet wrote:

Hi Stephen,

On Mon, Oct 12, 2015 at 02:51:14PM -0500, Stephen Cowell wrote:

I find that I sometimes get an infinite loop when stepping to
pcb->next...

I didn't have to read further. As usual, it looks like a broken port or
usage which violate lwIP threading model.

Summary:

- Do *NOT* call anything in interrupt context, nothing, never,
absolutely never, use your OS semaphore signaling to an
Ethernet/serial/… RX thread


I don't think I'm doing that, Sylvain... this is non-OS, so there
are no 'threads'.   Atmel wrote the port.  I'm running sntp and ftpd, they
hook in using their own _init() routines that have not been
modified.

Here's more links describing the problem:

http://savannah.nongnu.org/bugs/?45433
https://lists.gnu.org/archive/html/lwip-users/2004-10/msg00033.html

"

Why would a pcb->next pointer end up pointing to itself (pcb)?

"

Indeed... that's the whole problem.  I solved my problem with a hack that
nobody gets to see here... not sure why.

It looks like this code has had many bugs and problems... I'm glad I could
at least fix my issue.  I won't bother you with any more, since obviously
I'm not making it to the main list.
__
Steve
.



- memp_*, pbuf_*, functions are thread-safe if SYS_LIGHTWEIGHT_PROT is
set, and again, thread safe does not mean it is interrupt safe

- Do *NOT* call any function from the RAW API outside lwIP thread

- Use Netconn or Socket API in others threads, but keep in mind you
should not share a Netconn/Socket control block between threads, (or use
proper locking if you really have to, of course).

- Please read doc/rawapi.txt from the lwIP source which explain that
more comprehensively

Sylvain


___
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