No, the problem is to be able to do a clean full duplex, i.e., tx and rx at the
same time
as available on the BSD TCP sockets.
I suppose the third (closing) thread has been added for completeness and
symmetry, to illustrate
true concurrent capability (when finished).
-Z
From:
Hi there,
I have not watched the lwip development for a while, so I just need a quick
update.
I know that lwip did not support full duplex mode on sockets. Is that still the
case?
That is, can a thread send() while sharing a socket with another thread waiting
in recv()?
Thanks.
-Z
-Original Message-
From: lwip-users-bounces+zradouch=irobot@nongnu.org [mailto:lwip-
users-bounces+zradouch=irobot@nongnu.org] On Behalf Of
goldsi...@gmx.de
Sent: Tuesday, May 12, 2015 3:19 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Single connection with
Ø Wireshark does not work - it crashes on capturing. This is for sure a
Windows-problem…
I seriously doubt it. I don’t use Windows, but I use Wireshark all the time and
the versions that came
with the last couple Ubuntu Linux releases crash all the time, in quite random
ways.
I have been
Yes, lwIP/FreeRTOS/M3 can do that and much more. You can run an HTTP client
pulling your
NAS files in one thread, an HTTP server in another thread, a UDP server in yet
another thread,
plus whole bunch of other stuff.
I have limited experience of embedded TCP/IP
Then use the lwIP socket
-
Von: lwip-users-bounces+simon.richner=psi...@nongnu.org [mailto:lwip-
users-bounces+simon.richner=psi...@nongnu.org] Im Auftrag von Radouch,
Zdenek
Gesendet: Dienstag, 9. September 2014 19:20
An: Mailing list for lwIP users
Betreff: Re: [lwip-users] packet order with tcp_recv
Packets
Packets will be received in the order they were sent.
No, TCP packets are IP datagrams that can be lost, duplicated, or
that can arrive out of order. That is, they won't necessarily
arrive in the order they were sent. The TCP input module (tcp_in.c)
does the necessary ordering (it either passes
with regards to what connection goes where. It is just a matter of
convincing the stack to cooperate.
Mark
On Tue, Aug 19, 2014 at 1:35 AM, Radouch, Zdenek zrado...@irobot.com
wrote:
Hi Mark,
I think I understand your situation. Here are a few additional
comments.
Those networks might
, but not logically!) private network.
Hope that makes sense,
Mark
On Sat, Aug 16, 2014 at 11:37 PM, Radouch, Zdenek zrado...@irobot.com wrote:
Hi Mark,
I am completely missing what this has to do with DNS.
We obviously must make sure, that the DNS query is
made through the ethernet interface.
No. A DNS
Hi Mark,
I am completely missing what this has to do with DNS.
We obviously must make sure, that the DNS query is
made through the ethernet interface.
No. A DNS query is not made through an interface. A query
is made to a configured name server, wherever the name server is,
on whatever
Can you pass a nameserver to use to resolving functions normally?
No. As you suspect the name server is never passed to these functions.
The reason for that is that in context of a DNS query the name server address
is static, independent of the query.
Of course for debugging purposes, when
15, 2014 2:04 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] broken DHCP/ARP interaction
Radouch, Zdenek wrote:
However, in this case the ARP does something that is outright wrong -
-
it answers an ARP query for an IP address that has not been assigned
yet -- the DHCP
Of
Radouch, Zdenek
Sent: Tuesday, May 13, 2014 1:20 PM
To: lwip-users@nongnu.org
Subject: [lwip-users] broken DHCP/ARP interaction
I am having an LwIP problem where the local ARP erroneously answers its own
who-has request
and by doing that prevents DHCP from working correctly. I would appreciate
Well, as far as seeing something else, I, too, can see something else when I
configure my network
differently with respect to where the DHCP server is, and I, too, can see
things working.
But in my current configuration (which happens to be our corporate network with
hundreds of different
14 matches
Mail list logo
