On 2022-07-01, Simon Goldschmidt wrote:
>>I'd really appreciate some feedback on this. Would it make sense to
>>extend the http_client.c in such a way so that I can choose whether
>>to create HTTP_GET or HTTP_POST requests?
>
> Yes.
>
>>err_t httpc_get_file_dns(const char* server_name, u16_t por
On 2022-06-21, massimiliano cialdi via lwip-users wrote:
> the setsockopt(SO_RCVTIMEO) POSIX call contemplates the possibility
> of imposing 0 as the 'timeout' parameter, and in that case that
> socket becomes non-blocking (See, for example,
> https://stackoverflow.com/questions/49706883/disable
On 2022-05-31, Indan Zupancic wrote:
> This is probably because the ST driver releases the DMA buffers
> before you have handled the data. It tries to do zero copy, but does
> it wrong.
In my experience, target code provided by Silicon vendors is always
very poor quality and should never be trus
On 2022-04-13, Ian Abbott wrote:
> On 13/04/2022 15:45, Grant Edwards wrote:
>
>> Where are the definitions for other SOL_x values (e.g. SOL_TCP)
>> supposed to come from?
>
> Use IPPROTO_TCP instead of SOL_TCP as the "level".
Thanks, that is indeed the
On 2022-04-13, Grant Edwards wrote:
> It appears that there is code in lwip_getsockopt_impl to handle
> setting tcp keepalive values via the keys TCP_KEEPIDLE, TCP_KEEPINTVL,
> and TCP_KEEPCNT.
>
> Using the Berekely socket API, these are set via calls to setsocktopt():
>
It appears that there is code in lwip_getsockopt_impl to handle
setting tcp keepalive values via the keys TCP_KEEPIDLE, TCP_KEEPINTVL,
and TCP_KEEPCNT.
Using the Berekely socket API, these are set via calls to setsocktopt():
setsockopt(s, SOL_TCP, TCP_KEEP, &n, sizeof n);
However, the on
On 2022-04-12, Grant Edwards wrote:
> Where does msg->op_completed_sem get initialized?
I missed the netconn_apimsg() step. That's where it gets set:
117 static err_t
118 netconn_apimsg(tcpip_callback_fn fn, struct api_msg *apimsg)
119 {
...
I've tracked my problems with TCP netconn_connect() to an
uninitialized semaphore in lwip_netconn_do_connect(). The semaphore
LWIP_API_MSG_SEM(msg) has never been initialized. I checked it at the
entry to the function at line 1357 and immediately before and after
the call to sys_arch_sem_wait() at
On 2022-04-12, Simon Goldschmidt wrote:
>
>>> I'm running into a problem where netconn_connect always returns OK
>>> immediately, even when the connection was refused by the server (it
>>> replies to the SYN with a RST). Subsequent attempts to write to the
>>> connection return -14 (ERR_RST) or -1
On 2022-01-20, Grant Edwards wrote:
> I'm running into a problem where netconn_connect always returns OK
> immediately, even when the connection was refused by the server (it
> replies to the SYN with a RST). Subsequent attempts to write to the
> connection return -14 (ERR_RST)
On 2022-02-19, Massimiliano Cialdi wrote:
> Okay. Could you give me a suggestion on how I can implement an
> equivalent `select` with in netconn. Keep in mind that I use
> FreeRTOS.
You can use netconn callbacks to wake the relevent thread when a
socket has data to be read. I used a semaphore, b
On 2022-01-21, goldsi...@gmx.de wrote:
> Am 21.01.2022 um 15:37 schrieb Grant Edwards:
>> On 2022-01-20, Grant Edwards wrote:
>>
>>> I'm running into a problem where netconn_connect always returns OK
>>> immediately, even when the connection was refused by
On 2022-01-20, Grant Edwards wrote:
> I'm running into a problem where netconn_connect always returns OK
> immediately, even when the connection was refused by the server (it
> replies to the SYN with a RST). Subsequent attempts to write to the
> connection return -14 (ERR_RST)
I'm running into a problem where netconn_connect always returns OK
immediately, even when the connection was refused by the server (it
replies to the SYN with a RST). Subsequent attempts to write to the
connection return -14 (ERR_RST) or -11 (ERR_CONN).
Shouldn't netconn_connect() return an error
On 2022-01-12, Simon Goldschmidt wrote:
> Am 12. Januar 2022 18:45:44 MEZ schrieb Grant Edwards
> :
>>On 2022-01-12, Sylvain Rochet wrote:
>>
>>> Actually, it should do both. Place the packet in the TX queue and return
>>> immediately, BUT if the queue is
On 2022-01-12, Sylvain Rochet wrote:
> Actually, it should do both. Place the packet in the TX queue and return
> immediately, BUT if the queue is full it should wait for a free slot.
So, when using an OS, I can assume that lwIP will never call
linkoutput() from a non-thread context or from a p
What is the expected behavior of the netif linkoutput() function?
Specificallyy, is it expected to
1) Block until the packet has been sent?
or
2) Place the packet in a TX queue/fifo and return immediately?
All of the Ethernet drivers I've worked on for other RTOSes in the
past couple decades
On 2021-11-24, goldsi...@gmx.de wrote:
> Am 24.11.2021 um 16:33 schrieb Grant Edwards:
>> On 2021-11-24, Simon Küppers wrote:
>>
>>> If I understand you correctly, you could also use
>>> LWIP_HOOK_UNKNOWN_ETH_PROTOCOL provided by LWIP, so you do not need to
>
On 2021-11-24, Simon Küppers wrote:
> If I understand you correctly, you could also use
> LWIP_HOOK_UNKNOWN_ETH_PROTOCOL provided by LWIP, so you do not need to
> implement separate receive queues.
That's interesting — it would allow you to receive arbitrary Ethernet
protocols, but there's no
On 2021-11-22, goldsi...@gmx.de wrote:
> Am 22.11.2021 um 18:55 schrieb Grant Edwards:
>>
>> Does lwIP support applications that need to send/receive raw Ethernet
>> packets?
> Not, this is not implemented yet:
Thanks, that's what I thought.
> while it would
Does lwIP support applications that need to send/receive raw Ethernet
packets? It looks like lwIP's raw "connection" type is only for
sending and receiving IP packets.
What I'm looking for would the equivalent to the code below on Linux:
Python:
import socket
eth_proto = 0x12345
s =
On 2021-11-22, goldsi...@gmx.de wrote:
>>
>>> The callback gets copied from the listening connection.
>>
>> I suspected that might be the case, but hadn't been able to find where
>> that happened in the source code. For some reason I thought it had to
>> be happening at the netconn layer, but now
On 2021-11-22, goldsi...@gmx.de wrote:
> Am 19.11.2021 um 22:55 schrieb Grant Edwards:
>> After accepting a tcp connection with netconn_accept(listenconn,
>> &newconn), how does one set the callback function for newconn?
>
> The callback gets copied from the listening
After accepting a tcp connection with netconn_accept(listenconn,
&newconn), how does one set the callback function for newconn?
--
Grant
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
On 2021-11-19, goldsi...@gmx.de wrote:
A short while after I posted that question, it occurred to me that the
race condition should be avoidable by using a counting semaphore to
wake the server thread from the callback functions. The server might
sometimes make more passes through the netconn "li
For the past few days, I've been trying to figure out the netconn API
equivalent for select/poll, and I haven't been able to come up with
anything.
How does a single server thread handle multiple TCP or UDP
"connections" using the netconn API?
If you use a callback to wake the server thread, how
My (newly generated 2.1.3) documentation says that
LWIP_NETCONN_FULLDUPLEX "allows reading from one thread, writing from
a 2nd thread and closing from a 3rd thread". [And the "really alpha"
statement is indeed gone.]
I assume that does not imply that recv/send/write are renntrant such
that two thr
On 2021-11-17, Simon Goldschmidt wrote:
> Yeah, the documentation... I just haven't got around to uploading
> the updated 2.1.3 documentation. However, it is included in the
> release zip in the download section.
I guess I'd better install doxygen. :)
--
Grant
___
On 2021-11-17, goldsi...@gmx.de wrote:
> I just noticed that the new 2.1.3 release already had those comments
> fixed
Is this the wrong web page for 2.1.3 documentation?
https://www.nongnu.org/lwip/2_1_x/group__lwip__opts__netconn.html
The "really alpha" statement and the requirement that mb
On 2021-11-16, Simon Goldschmidt wrote:
>> sys_mbox_free() has to unblock receive tasks waiting on
>> recvmbox/acceptmbox and prevent a task pending on this during/after
>> deletion
>>
>> Is that really required?
>> ...
>
> Yeah, well, that comment is outdated as well. Turned out that
On 2021-11-16, Simon Goldschmidt wrote:
>
>
> On 16.11.2021 18:47, Grant Edwards wrote:
>> I've been reading up on netconn/sockets and thread-safety. At
>> https://www.nongnu.org/lwip/2_1_x/group__lwip__opts__netconn.html
>> it says this about the "fulldupl
I've been reading up on netconn/sockets and thread-safety. At
https://www.nongnu.org/lwip/2_1_x/group__lwip__opts__netconn.html
it says this about the "fullduplex" option:
"ATTENTION: This is currently really alpha!"
Is that accurate?
That presumably applies to the socket api also?
One
On 2021-11-16, goldsi...@gmx.de wrote:
> Am 15.11.2021 um 18:03 schrieb Grant Edwards:
>> Is it required that sys_thread_t be a pointer or integer type?
>>
>> The documentation doesn't state that. The example implementation at
>> https://lwip.fandom.com/wiki/Porti
On 2021-11-15, Ajay Bhargav via lwip-users wrote:
> No, I am not assuming mutext required to be nested either.
but I thought sys_arch_protect/unprotect are required to nest?
> Infact my implementation had only simple lock unlock only. And as
> far as I know, lwip do not use nesting of lock, as
On 2021-11-15, Ajay Bhargav via lwip-users wrote:
> You can define it as integer or pointer based on your system.
Yes, I know I can.
I want to know if it is _required_ to be an integer or pointer.
> Its definately not a structure.
It definitely is a structure in the freeRTOS port which I was
Is it required that sys_thread_t be a pointer or integer type?
The documentation doesn't state that. The example implementation at
https://lwip.fandom.com/wiki/Porting_for_an_OS#Threads shows it as a
struct, and in the freeRTOS port it's a struct.
But the test code assumes it's a pointer or integ
On 2021-11-15, Ajay Bhargav via lwip-users wrote:
> protect/unprotect is totally implementation dependent with only
> intention of providing exclusive access to network related operation
> to be performed without any context switching. You can do this by
> using a mutext in simplest way
Are you
On 2021-11-15, Ajay Bhargav via lwip-users wrote:
> sys_arch_protect() and sys_arch_unprotect() is always called in
> pairs with call order maintained.
So the requirement stated in the documentation that
SYS_ARCH_UNPROTECT Perform a "fast" set of the protection level to "lev".
is incorrect a
A couple questions about sys_arch_protect/unprotect
1. Are protect/unprotect calls required to nest?
2. Does the level passed to unprotect() have to do something?
I think I've found another instance where the original authors of my
sys_arch.c implemented something that meets the requirements
On 2021-11-12, goldsi...@gmx.de wrote:
>
>> Are there ports where an object is still valid after sys_*_free() is
>> called? After a semphore has been free()ed, what operations on an
>> already free()ed object would still be valid?
>
> None.
>
> This is only a helper define to help defining sys_sem
On 2021-11-12, goldsi...@gmx.de wrote:
> Feel free to provide a patch updating the documentation if you think it
> needs improvement!
I'll try...
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
On 2021-11-12, goldsi...@gmx.de wrote:
> Am 12.11.2021 um 16:24 schrieb Grant Edwards:
>> Are the various sys_arch.c functions allowed to return error codes
>> other than those specifically listed in the documentation?
> ...
>> Were I to _guess_, I would assume that funct
Are the various sys_arch.c functions allowed to return error codes
other than those specifically listed in the documentation?
For many of them, only 0 and one other value (e.g. SYS_ARCH_TIMEOUT or
ERR_MEM) are documented as return values. The underlying OS operations
usually have far more that two
On 2021-11-11, Grant Edwards wrote:
> In the code I've inherited, when *_free() is called, my sys_arch.c
> code places the referenced kernel object (semaphore or mailbox) back
> into the free pool and it becomes available to be reallocated and
> placed into use.
> Appare
On 2021-11-11, Grant Edwards wrote:
> [Sorry for all of the porting questions, but the sys_arch.c file I'm
> working with just doesn't seem to make sense.]
>
> I don't understand how *_free() and *_set_invalid() are supposed to
> interact.
>
> In the code I&#
[Sorry for all of the porting questions, but the sys_arch.c file I'm
working with just doesn't seem to make sense.]
I don't understand how *_free() and *_set_invalid() are supposed to
interact.
In the code I've inherited, when *_free() is called, my sys_arch.c
code places the referenced kernel ob
On 2021-11-11, goldsi...@gmx.de wrote:
> Am 11.11.2021 um 17:36 schrieb Grant Edwards:
>> What should the wait queue order be for lwIP mailboxes, mutexes, and
>> semaphores?
>>
>> The port I'm trying to fix-up and get running is configuring all for
>>
What should the wait queue order be for lwIP mailboxes, mutexes, and
semaphores?
The port I'm trying to fix-up and get running is configuring all for
FIFO wait queues.
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/l
Another porting question, I'm afraid.
In deciding how to implement new/free operations for mailboxes,
semaphores, and mutexes, it would be helpful if I had some idea of
when and how often they are called.
Are execution times for these functions going to noticeably affect
performance of things lik
On 2021-11-10, goldsi...@gmx.de wrote:
>
>> I mean can two invocations of the sys_* (mailbox, mutex or semaphore)
>> functions happen "at the same time". For example: can the execution
>> of one call to sys_{sem,mutex,mbox}_set_invalid() be interrupted or
>> suspended by another call to that same
On 2021-11-10, goldsi...@gmx.de wrote:
> Am 10.11.2021 um 20:43 schrieb Grant Edwards:
>> I'm workikng on a port done by somebody else, and they seem to have
>> assumed that functions like sys_mbox_set_invalid() don't need to be
>> thread-safe. But, they did add
I'm workikng on a port done by somebody else, and they seem to have
assumed that functions like sys_mbox_set_invalid() don't need to be
thread-safe. But, they did add mutexes to make sure that some other
functions like like sys_mbox_free() and _new() are thread-safe.
The documentation I've found
Where do I find the sys_arch.txt and rawapi.txt files that are listed
and described in doc/FILES?
https://git.savannah.nongnu.org/cgit/lwip.git/tree/doc/FILES?h=STABLE-2_1_x
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/
On 2021-09-30, goldsi...@gmx.de wrote:
>>
>>> The savannah link you are referring to contains the docs for the
>>> latests git master branch sources. That's simply not applicable to
>>> the 2.1.3 sources you are trying to build.
>>
>> Ah, I see.
>>
>> And there is no equivalent document for 2.1.3?
On 2021-09-30, goldsi...@gmx.de wrote:
> It's not out of date: it is more recent than what you are trying to build.
>
> 2.1.3. is a bugfix release for an older version, where 'contrib' has
> been in a separate git tree. Since that's kind of annyoing, we moved
> the contrib part to a folder in a m
On 2021-09-30, Grant Edwards wrote:
Doh! I quoted the wrong error message. It should have been this one:
[ 99%] Built target lwipallapps
[ 99%] Building C object
CMakeFiles/example_app.dir/home/grante/lwip/contrib/examples/example_app/test.c.o
/home/grante/lwip/contrib/examples
On 2021-09-30, Grant Edwards wrote:
> That appears to attemp to compile source files. But, that fails also:
>
> $ cmake --build .
> [ 1%] Building C object
> CMakeFiles/makefsdata.dir/home/grante/lwip/lwip/src/apps/http/makefsdata/makefsdata.c.o
> /home/grante/
On 2021-09-30, Grant Edwards wrote:
> What apprently needs to be done is:
>
> 1. Move 'contrib' directory up one level.
>
> 2. The shell commands shown in section "Working example" should not
> be done in the lwip root directory as stated. They are
On 2021-09-29, Grant Edwards wrote:
> I'm trying to get started porting lwIP to an RTOS. Having never
> worked with lwip before, I thought I would first just build
> 2_1_3_RC1 for Linux. I'm following the directions in BUILDING:
Can somebody point me to documentation or an
I'm trying to get started porting lwIP to an RTOS. Having never worked
with lwip before, I thought I would first just build 2_1_3_RC1 for
Linux. I'm following the directions in BUILDING:
Working example
===
Working build examples can be found in the
contrib/ports/{win32
ebooks or HTML?
Or are they the property of fandom.com?
Is there some other source for current devleopment documentation?
--
Grant Edwards grant.b.edwardsYow! ... I don't like FRANK
at SIN
61 matches
Mail list logo
