o not fragment (DF) in a UDP transmission.
Am 09.03.2020 um 18:08 schrieb Roger Cover:
> Greetings Simon,
>
> The Linux man pages mention the IP_PMTUDISC_DO flag that "forces the
> don't-fragment flag to be set on all outgoing packets" in the setsockopt()
> descriptio
f goldsi...@gmx.de
Sent: Saturday, March 7, 2020 2:02 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Do not fragment (DF) in a UDP transmission.
Am 06.03.2020 um 21:37 schrieb Roger Cover:
> Greetings,
>
> I am writing a video transmitter. The protocol I am using requires tha
Greetings,
I am writing a video transmitter. The protocol I am using requires that a "test
packet" has its do not fragment bit set. This is used to determine the maximum
usable MTU of the intervening network nodes.
I would like to know the recommended method for setting this bit in my UDP
tran
Greetings,
Is there an example of how to use AUTOIP and DHCP at the same time? I have had
DHCP in my application for some time, but a customer now requires that I add
AUTOIP as well.
I am having difficulty making them operate as I would like. Both are
functioning, but I would like to have the
-
From: lwip-users [mailto:lwip-users-bounces+rcover=specinst@nongnu.org] On
Behalf Of Simon Goldschmidt
Sent: Thursday, September 29, 2016 11:14 PM
To: lwip-users@nongnu.org
Subject: Re: [lwip-users] Unusual termination of a TCP connection.
Roger Cover wrote:
> Thank you all for y
Of Roger Cover
Sent: Wednesday, September 28, 2016 1:34 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Unusual termination of a TCP connection.
Greetings,
In the Wireshark capture that I sent in my original post, the data sent from
the server is ACKed by the same packet that
. schrieb Roger Cover :
> Greetings,
>
> I have a server application using lwIP 1.4.1. When I use a Python
> program to connect to my server, the server always terminates the TCP
> connection with a RST instead of a FIN packet. The RST appears to be
> negatively impacting the
Greetings,
I am using the callback API. Sorry I did not mention that. What more details do
you want?
The content-length=0 is due to the old server not supporting the command to
report its version in the same way. There is no additional data waiting to be
sent. This is a side effect of using th
Greetings,
I have a server application using lwIP 1.4.1. When I use a Python program to
connect to my server, the server always terminates the TCP connection with a
RST instead of a FIN packet. The RST appears to be negatively impacting the
performance of my communications. I have attached a Wi
Greetings List,
My compiler does not substitute macros inside quotes. The proposed change would
not work for me at all, since the example in the original message would result
in a final string of "tcp_bind: bind to port %U16_F\n".
Regards,
Roger
From: lwip-users
list for lwIP users
Subject: Re: [lwip-users] ARP during UDP transfers
On Tue, 2011-03-29 at 08:14 -0700, Roger Cover wrote:
> Greetings List,
>
> After researching the source code for a while I have determined that
> lwIP will queue one UDP packet when the ARP table entry for its
&
Greetings List,
After researching the source code for a while I have determined that lwIP will
queue one UDP packet when the ARP table entry for its destination times out,
and then drop subsequent UDP packets until the ARP reply is processed (I have
ARP_QUEUEING set to 1). My question is: what
Greetings List,
A customer of mine has encountered a problem. The problem only occurs rarely. I
have not seen it in my testing. The system is a few years old, so it was built
using lwIP 1.2. I need some information to help with my debugging efforts. The
symptoms are as follows:
Host computer s
Howdy Folks,
In terms of the message, perhaps a more clear message would be in order.
Something like:
No free PCBs. Using a TIME_WAIT PCB.
Regards,
Roger
-Original Message-
From: lwip-users-bounces+rcover=specinst@nongnu.org
[mailto:lwip-users-bounces+rcover=specinst@nongnu.org]
t an OUI?
John
John Kennedy
Idaho Technology Inc.
390 Wakara Way
Salt Lake City, UT 84108, USA
USA: 1-800-735-6544
Bus:+1 (801)736-6354 x448
Fax:+1 (801)588-0507
http://www.idahotech.com/
-Original Message-----
From: Roger Cover [mailto:rco...@specinst.com]
Sent: F
Howdy Folks,
Here is a bit of information about MAC addresses that might be
applicable to this discussion:
MAC addresses can either be "universally administered" or "locally
administered."
A universally administered address is assigned to a device by its
manufacturer. The first three octets are
Greetings folks,
A few months ago, someone raised a question about the long-term
reliability of the lwIP stack. I started a long-term test to see how my
system measured up. Here are my results:
Time in continuous operation: 9,075,951.767 seconds (105 days, 1 hour, 5
minutes, 51.767 seconds)
To
Hi Nathan,
I am using the Xilinx Virtex 4 for my lwIP projects also. I am using the
callback (raw) API with lwIP 1.2.0. I had similar performance to what
you are reporting when I started. My solution was to modify the make
file for lwIP and the driver provided by Xilinx. I now get 8 megabytes
per
Greetings,
I have uncovered the cause of lost packets on systems using the Xilinx
TEMAC with link-layer FIFO. I also have a work-around.
The problem stems from the fact that the TEMAC to link-layer FIFO IP
(ll_temac) does not always place a start of frame marker on the
beginning of the packet. I
Sorry, 8 megabytes.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jacob Gorm Hansen
Sent: Tuesday, April 24, 2007 1:53 PM
To: Mailing list for lwIP users
Subject: RE: [lwip-users] LWIP on a gigabit LAN
On Tue, 2007-04-24 at 13:52 -0700, Roger Cover
Howdy Jacob,
I have been using lwIP on a gigabit LAN for a while now. The highest
sustained throughput I can get is just over 8 gigabytes per second. My
application is sending UDP datagrams. The slow speed is not the fault of
lwIP. My application spends about 27% of its time operating my hardware
Greetings All,
I have made a discovery about my problem. I upgraded to version 9.1 of the
Xilinx EDK at the same time I upgraded to lwIP 1.2.0. This EDK upgrade changed
the GNU compiler suite that I am using. The new version of the compiler is the
source of my problem. It generates much less ef
Greetings Simon,
I have not looked very far into what lwIP is doing internally. I know
that the function ip_output_if() is where my CPU is spending over 80% of
its time during my UDP transfers. I am using a Gigabit MAC/PHY, so
lwIP's transmission speed is no where near what the hardware can
sustai
Greetings Simon,
The 80% includes the netif->output() call. My system uses both UDP and
TCP. I have probed the UDP code more, so I know a bit more about it. The
measured performance change is about the same for UDP and TCP. As I
mentioned earlier, I am using the same driver code with minor API
alt
m?
I think most of the CPU cycles related to TCP or UDP communication are consumed
in the checksum calculation.
/Timmy
Roger Cover wrote:
Greetings Frédéric,
The performance decrease I measured was relative to version 0.6.3 of
lwIP. The measurement is the total tran
Greetings Frédéric,
The performance decrease I measured was relative to version 0.6.3 of lwIP. The
measurement is the total transfer time for a 33560192 byte data set from my
instrument to an application on my PC using TCP/IP. The time was 13.98 seconds
for lwIP 0.6.3 and 19.56 seconds for lwIP
Greetings,
I have completed my upgrade to version 1.2.0 (from 0.6.3). The
reliability of my system is much improved. The developers have done a
good job increasing the robustness of the library.
Now that I have version 1.2.0 running, I have noticed a decrease in
performance (about 40%). Part of t
Greetings,
I would like to propose that the hostname not be a compile-time constant. I am
developing a system that will be distributed in a product. Every instance of my
product will have a different hostname. It would be inconvenient to have to
recompile my application for each item shipped.
28 matches
Mail list logo
