"chenyintao" wrote:
> Hi！
> I have a questino with the funciton tcpip_apimsg.
> when the mbox if full and sys_mbox_post(mbox, &msg) is failed so the msg
> would lost,but the sys_arch_sem_wait(apimsg->msg.conn->op_completed, 0) is
> still called.Will it caused the application thread susp
Hi！
I have a questino with the funciton tcpip_apimsg.
when the mbox if full and sys_mbox_post(mbox, &msg) is failed so the msg
would lost,but the sys_arch_sem_wait(apimsg->msg.conn->op_completed, 0) is
still called.Will it caused the application thread suspended forever because
it's wa
Am 14.02.11 15:30, schrieb mhor...@ddci.com:
What I'm unsure of is whether the IP fragmentation code can tolerate
this misconfiguration of the MTU, or whether there is likely an error
in the fragmentation code, or perhaps in one of our drivers.
The MTU is correct (set to 1500), only the MSS is "m
On Mon, 2011-02-14 at 07:30 -0700, mhor...@ddci.com wrote:
>
> We have been using lwip version 1.2
I would strongly suggest upgrading. 1.2 is years out of date and even
more unsupported than the current version (we're about to release
1.4.0).
> At this point, we are not using any TCP options, s
We have been using lwip version 1.2 with some applied patches for our
embedded networks stack. Our two components ethernet devices are directly
connected and both are executing our stack. The MTU is as expected on
ethernet, 1500, however, our TCP MSS value is set to 1476. My reading of
RFC's an
