Hello Peter,
On 2022-12-22 00:20, Peter wrote:
Unfortunately the socket is non-blocking so if the data is
arriving too fast, some gets lost.
This is the most common mistake made with TCP socket programming:
Not handling short writes properly.
You also get this with blocking sockets, those al
Hello Luca,
On 2022-12-02 18:38, Luca Ussoli wrote:
Using the master branch I managed to get the SNMPv3 agent running.
However,
TRAPS are managed up to the v2c version. I'm currently trying to
implement
the v3 version as well, but without success so far.
Has anyone successfully implemented th
Hello Jeff,
On 2022-11-03 12:08, 刘跃 Jeff Liu wrote:
I want to know the git development and merging strategy of lwip.
Releases are made when one of the maintainers have time, but they didn't
get to it for a while.
I am currently developing based on the STABLE-2_1_3_RELEASE branch, and
then
Hello Artem,
On 2022-10-31 17:33, Artem Moroz wrote:
Today I got to work this LWIP DHCP server code :
https://github.com/avrxml/asf/blob/master/thirdparty/lwip/lwip-tinyservices/tinydhcpserver.c
It is slightly bigger than the previous one, but it works like a charm.
Sadly, you're not allowed t
Hello Jochem,
On 2022-10-21 10:10, Jochen Strohbeck wrote:
Was the connection closed properly by both sides when this happens?
According to the trace it is only closed by the client (sending FIN,
getting ACK) although the server calls lwip close()...
Did the client ACK all data sent by the se
Hello Jochem,
On 2022-10-20 14:44, Jochen Strohbeck wrote:
The server will sent ACK instead SYN+ACK for 50118 and 50130 because
these port numbers have been previously used less than a second before.
Was the connection closed properly by both sides when this happens?
If the sequence number is
Hello Jochem,
On 2022-10-19 18:51, Jochen Strohbeck wrote:
from time to time I experience a significant network performance drop.
Is this during normal use or during load testing/benchmarking?
I'm running an lwip http 1.0 server on SAME70/FreeRTOS and do http
requests on Windows or Linux.
I
Hello Stefano,
On 2022-09-16 01:52, Stefano Tebaldi wrote:
What can be the problem and how to manage correctly this scenario ?
Try using netif_set_link_down()/netif_set_link_up() instead,
perhaps that helps.
Normally you wouldn't want to close all sockets when interface
goes down though, espe
Hello Hensel,
On 2022-08-31 11:44, Hensel, Christian wrote:
Meaning only one sock_connection is allowed to be served at any time
You probably don't want this for TCP, because of TIME_WAIT and long
time-outs before client is considered to be gone.
If the server ever closes the socket it will g
Hello Hensel,
On 2022-08-29 18:16, Hensel, Christian wrote:
How can I handle the unplug replug on the server side using LWIP?
Make sure you call the lwIP functions from the correct thread.
To tell lwIP cross-task that the link is up or down, you can use:
tcpip_callback((tcpip_callback_fn)neti
Hello Kosma,
On 2022-07-28 13:51, Kosma Moczek wrote:
I am specifically looking for a version compatible with lwip 2.1.2 (due
to my vendor's half-assed port).
I highly recommend to not use your vendor's port, but an up-to-date
version, either released or the latest git. Also double check if yo
Hello Jochen,
On 2022-06-07 15:55, Jochen Strohbeck wrote:
In Wireshark I see that after the data transfer the client sends out
FIN+ACK and the http server responds only with ACK, no further FIN sent
out by the server.
This is normal if the server hasn't sent all data yet. I would expect
it to
On 2022-06-02 12:16, Jochen Strohbeck wrote:
Do you know which timeout value is responsible for keeping recently
used port numbers?
Mostly TCP_MSL. But even better would be to let the client
close the connection first.
Reducing TCP_MSL is needed if you run out of sockets or memory
and want to
Hello Jochem,
Because you talked about performance and load my mind replaced SYN with
FIN,
please disregard my previous e-mail.
On 2022-06-01 12:56, Jochen Strohbeck wrote:
The sender sends an RST to 49564. It make one more retry with the same
result and the request fails with timeout error.
Hello Jochem,
On 2022-06-01 11:08, Jochen Strohbeck wrote:
What kind of problem may force lwip to send ACK instead of SYN+ACK?
When it hasn't seen the SYN yet (it didn't process all received packets
yet). Or when a packet got dropped and a new packet arrives, sending
the ACK is a way to let th
Hello,
On 2022-05-31 15:55, Rogier Wolff wrote:
The other option is that the cache is corrupting things. You need to
properly flush the caches after the DMA-into-a-buffer and before
accessing the data.
Well, I think that was also missing from the original driver, but
can't remember. Maybe they
Hello Halid,
On 2022-05-31 15:11, Halid YESSOUFOU wrote:
I come by this message because I meet it seems to me that the layer
LWIP meets
a problem. Indeed, when I receive small packets of data via TCP, all
goes well.
However, when I receive large data packets, some data are corrupted.
The corru
Hello Paul,
On 2022-03-16 14:43, Matthias Paul wrote:
If the LWIP server sends a long data stream (some megabytes of data)
while receiving the remote disconnect, I'll run into problems because
the server stalls: tcp_sent() is never called afterwards, so the
server cannot push further data to the
Hello,
On 2021-09-15 15:37, Info wrote:
In the attached Wireshark capture file I can see many frames (from the
web browser) with the set ACK RST flags. For me it not clear why the
web browser sends this frames and if it is the reason for the broken
periodic communication ? Any help and maybe som
Hello,
Beware that everything should be cache line aligned!
To be future proof assume cache size is 64 bytes, even if it's 32 bytes.
I recommend making the TX descriptors non-cacheable, bufferable
and the RX descriptors non-cacheable, non-bufferable and the DMA
buffers fully cacheable and use ca
Hello Ali,
On 2021-03-16 16:26, Danish Ali wrote:
But now I want to be able, at the same time, to have LWIP make
connections _from_ its TCP port 5060 _to_ other, different and
currently unconnected, remote devices.
Why do you need to use the same local port number?
Why can't you just use a ra
On 2021-01-21 11:58, Rogier Wolff wrote:
On Thu, Jan 21, 2021 at 10:37:52AM +0100, Indan Zupancic wrote:
You probably also have to call ip_set_option(pcb, SOF_BROADCAST);
and of course tell lwIP that the network interface is up.
The "upping" of the interface, I think that happens
Hello Roger,
On 2021-01-20 23:03, Rogier Wolff wrote:
I would have hoped that even with ip address wronly configured, it
would pass the packet on to my udp-recieve function and that I could
then decide what to do. But it seems that the packet is discarded as
"not for me".
You probably also hav
Hello,
On 2020-12-29 20:07, Klaus Breining wrote:
I have seen the following sequence:
- Receive SYN
- Answer SYN/ACK
- Receive ACK
Up to now everything is normal. Here altcp_tcp_accept() is called.
PCB is ESTABLISHED
- Receive PSH/ACK
- Answer PSH/ACK
- Receive ACK
- Send FIN/PSH/ACK
- Receive R
e provided driver you are using and
to test it under load.
As a rule of thumb, if the driver is trying to be zero copy it's almost for
sure buggy.
Best regards,
Indan Zupancic
TT Vasumweg 150 | 1033 SH Amsterdam | The Netherlands
Phone: + 31 [0]20 482 56 32 | Fax: + 31 [0]20 482
ven't looked at the newest ST code yet.
Best regards,
Indan Zupancic
TT Vasumweg 150 | 1033 SH Amsterdam | The Netherlands
Phone: + 31 [0]20 482 56 32 | Fax: + 31 [0]20 482 00 77 | Email:
<mailto:indan.zupan...@mep-info.com> indan.zupan...@mep-info.com
Fr
d not the server (client certification is also possible, but unusual). If
that server runs
on lwIP then I don't think you want to enable MBEDTLS_SSL_VERIFY_REQUIRED.
Best regards,
Indan Zupancic
TT Vasumweg 150 | 1033 SH Amsterdam | The Netherlands
Phone: + 31 [0]20 482 56 32 | F
sequence (e.g. reverse
order, then it only happens if there is a backlog).
Best regards,
Indan Zupancic
TT Vasumweg 150 | 1033 SH Amsterdam | The Netherlands
Phone: + 31 [0]20 482 56 32 | Fax: + 31 [0]20 482 00 77 | Email:
indan.zupan...@mep-info.com
-Original Message-
From
lly
bring v3 support to traps.
It is very important for us that everything should be supported at the same
time: Agent, manager and traps. Currently there is no context object passed
to all SNMP functions, that would make it simpler for common code to know
how to behave.
Best regards,
Indan Zupa
gine that it is preferable to separate common
code. However, this kind of
cleanups can also be done while adding V3 trap support.
If there is interest I'll hurry up our patch submission. We'd like to have V3
trap support as well, but haven't
had the time to implement it yet.
Best regards,
30 matches
Mail list logo
