Cellule Numerique wrote:
And i have change the Time when tcptmr() is call. The new Time is: 10uS.
What is that supposed to mean? Are you calling tcp_tmr() every 10
microseconds?? Or every 10 seconds? I thought the comments in the code
make it quite clear that you are supposed to call this
Matias Mandell wrote:
I would like to suggest that e.g. the error constant defines would be
prefixed with LWIP_
to make them more unique. Easier porting into existing platforms and
would perhaps avoid possible mix-ups?
I think that's a good idea. We already started to add the LWIP_ prefix
to
Cellule Num wrote:
I have a lot of error message with ERR4N -1 so a ERR MEM but i have
verified the snd_buf.
Have you checked the statistics? If not, have a look at the various
'err' members of the below the global 'lwip_stats.mem' or one of the
'lwip_stats.memp' array members. If you have a
w...@brolinembedded.se wrote:
I have rewritten our VLAN PCP implementation, taking advantage of the
ARP entry cache feature.
In short, these are the modifications I have done. [..]
What do you think about this solution?
Looking good. Can you send us the patch?
Simon
FreeRTOS Info wrote:
Just in case anybody is watching this thread:
As unlikely as this all seems, having previously isolated one file, I
have now isolated it to a single function: lwip_standard_chksum().
I have the entire applicatino running at maximum optimisation, except
this function, and
Per Klint wrote:
I'd rather not change the lwip stack code. But perhaps it is possible
to replace all calls to sys_mbox_trypost with sys_mbox_post instead?
Why would you need that?
To avoid to lose any messages!
But if it needs to work from ISR it's ofcourse not an option to do that.
And let
Sanchayan wrote:
Thanks Kieran and Stephen for helping out. I changed the value of
PBUF_POOL_BUFSIZE from 256 to 512. The problem was resolved.
If that fixes your problem, you might want to dig in to see why. Every
application and netif driver *should* be able to work correctly with a
w...@brolinembedded.se wrote:
Yes, it is. It is a mandatory feature for certain protocols, such as
the industrial control protocol EtherNet/IP
http://en.wikipedia.org/wiki/Ethernet/IP
That's interesting. Since I know of at least one Ethernet/IP stack being
ported to linux, do you know
w...@brolinembedded.se wrote:
This works as it should, I can receive broadcast UDP requests directed
at a specific port.
I am however unable to respond to the request. (I use broadcast
response of course)
udp_sendto() calls ip_route(), which takes a look at
netif_is_up(netif_default) and
mcondare...@soft-in.com wrote:
I need to use slipif, but all examples seem to be quite old (do not use
slipif_init()).
Which examples are you talking about? slipif_init should always be
needed, since the init function passed to netif_init() cannot be NULL.
Since I'm quite new to lwIP I'm also
Anirudha, please do NOT use the reply-to button to start a new thread:
email programs like mine that sort threads by using the mail ID cannot
separate threads when doing this!
Anirudha Sarangi wrote:
Recently I upgraded to lwip140 and I am getting issues. With
everything else remaining same
vincent cui wrote:
So , I will report lwip1.4.0 again ? but I need support IPV6..it is critical ..
I'm afraid you won't get IPv6 support from us before 1.5.0 unless you
are willing to use a version checked out from git or backport it
yourself or are lucky enough to find someone doing the
w...@brolinembedded.se wrote:
In pbuf.c, function pbuf_free()[..]:
if (type == PBUF_POOL) {
if( !DMA_RING_REPLENISH( p ) ) {
memp_free(MEMP_PBUF_POOL, p);
}
I like the idea. Would you mind adding a patch so that this doesn't get
forgotten?
Thanks,
Simon
w...@brolinembedded.se wrote:
Sure,
For which version of LwIP should I make the patch?
Against git head, normally. However, for such a small change, I think
it's even enough to just past the contents of your last mail. The patch
entry is mainly there to ensure this doesn't get forgotten. The
kenneth.jack...@q.com wrote:
Independently (only one of them has been compiled in), they both
work. However when I complied both in, one will work and the other
will return a
ERR_MEM ( Out of memory error) code after calling
*netconn_listen(structnetconn*conn ).*
That pretty much sounds
Amir Shalem wrote:
Yes, I think that would be better than adding it in every
lwipopts.h (like it is now).
Can you push this fix in lwip-contrib.git, /ports/unix/include/cc.h?
Since I'm developing on windows, not linux, I'll need some time to get
my colinux system running again to
Am 18.10.11 15:03, schrieb Mason:
I propose simply using HOST_NOT_FOUND to fix the problem:
Thanks for the excellent report! I'll apply the fix (as bug #34592).
Simon
___
lwip-users mailing list
lwip-users@nongnu.org
Mason wrote:
The STB can now process 2.4 million packets in 5 minutes, which
corresponds to 97.8 Mbps.
Good news! Although (as I said before), some things might not work, yet,
with PBUF_REF used for RX packets.
I'm trying to optimize this a bit further, first by attacking
the memcpy for
mcondare...@soft-in.com wrote:
I understand lwIP webserver is essentially static and thus useless to implement
a configuration menu.
By now, the lwIP server can handle SSI, CGI and POST, so it is perfectly
fit for a web-based configuration menu (which is what I use it for,
anyway).
Mason wrote:
Well, given a correctly DMA-enabled driver, you could avoid one task
switch by checking RX packets from tcpip_thread instead of using another
thread for RX (as suggest your Task breakdown by the name RxTask).
Correct; the OS panics when I call tcpip_input from the ISR,
Hmm,
Mason wrote:
Bill Auerbach wrote:
That 7.4% for memcpy is a direct hit on throughput. You're seeing a
breakdown of total CPU time. How much of that 7+% for memcpy comes out of
the total time used by lwIP? I think you'll find that to be a much larger
hit and a large contributor to lower
Gene Cumm wrote:
For the past several months, Syslinux has been trying to integrate
lwIP into PXELINUX. At the moment, there appears to be a bug of some
sort when using VMware platforms or some KVM platforms. Over the last
few weeks, I've been working with hpa and trying to add additional
You're right, that won't get too easy.
For the RX side, using a *custom* PBUF_REF would be the best solution.
That's a pbuf that has a 'freed' callback and references external
memory. However, that doesn't work, yet (though I planned to add support
for it as I can see it's one possible
First, please *don't* CC me, I'm getting mails twice that way!
Mason wrote:
[..]
I've defined a new struct packet_info_t which stores a pbuf
(for lwip) and an OS descriptor.
typedef struct { struct pbuf_custom pbuf; ethernet_async_t desc; }
packet_info_t;
Where's the actual memory (i.e.
Kieran Mansley wrote:
but I would also hope that 1.4.0 would perform as well if not better without
zero-copy.
I certainly would hope so, too. Although there have been fixes which
might add some opcodes, I wouldn't have expected it to be noticably
slower than 1.3.2...
I think your packet
hope someone could give some advice regarding this, how to proceed
from this point.
/Magnus
2011/9/13 Simon Goldschmidt goldsi...@gmx.de mailto:goldsi...@gmx.de
Magnus S magnusde...@gmail.com mailto:magnusde...@gmail.com wrote:
I use Atmel AVR32 Studio version 2.6.0
OK, got
First, please don't just post the same thing multiple times. Not getting
an answer most often means noone has an idea what's wrong. By just
posting multiple times you risk annoying people and then not getting any
answer at all...
As to your problem, if not freeing the pbuf helps, that might
Richie Bonventre wrote:
[..] In addition, the state the struct returns to is identical to the
state of a brand new tcp_pcb, CLOSED. This caused me to believe that
I could tcp_connect() again on the same tcp_pcb. As you've said, this
is not actually ok. After tcp_close returns, lwip no longer
FreeRTOS Info wrote:
That would be excellent - and exactly the feedback I would look for.
Alright, so it turns out the lwipopts.h *was* the reason for the poor
performance. Using the LPC17xx one, I had the same poor performance with
my win32 port. I got it working by changing the following
FreeRTOS Info wrote:
Umm. I can describe the set up I have, if that helps. Actually, the
code is all available here if you want to look at that...
http://interactive.freertos.org/entries/20290712-freertos-win32-project-with-lwip-web-server
...but as far as I recall, the only modification I
Kieran Mansley wrote:
3) Then call tcp_connect()
- this will either succeed and call the connected callback passed to
tcp_connect, or fail and call the error callback specified by tcp_err()
- if the error callback is called because of a timeout I think you
could immediately call
Am 01.09.11 10:14, schrieb narke:
I am not sure that if this is a problem with my web browser. But when
I open the link, I just see titles without contents. Only when I
clicked the 'edit' link right left to the title, I can see a few words.
Works fine for me (like the rest of the wiki).
Simon
Paul Archer wrote:
Done
http://lwip.wikia.com/wiki/PPP#PPP_from_an_application_perspective
Cool, thanks for that!
I hope that is in the correct place. if anyone wants to have a read an
comment/fix any mistakes feel free to.
I'm not too sure about multithreading, regarding thread-safety:
Mason wrote:
I'm not sure how to do this within the pbuf infrastructure?
Normally, for a DMA-enabled MAC, you would just pre-allocate 120
PBUF_POOL pbufs (each 1536 bytes big) and pass the payload pointer to
the DMA engine. By substracting the difference between 'struct pbuf' and
its member
narke wrote:
#define LWIP_PLATFORM_DIAG(message) do { printf(message); } while(0)
Have you bothered looking at the example ports in contrib? Seems like I
can't repeat often enough that these ports are meant to be an example
for people creating new ports :-)
Both the unix and the win32 ports
I've added this as bug #34121, already fixed:
https://savannah.nongnu.org/bugs/index.php?34121
Thanks for reporting.
Simon
Kieran Mansley wrote:
On Thu, 2011-08-04 at 15:00 +0200, Mason wrote:
Therefore, it seems natural for netif_add to accept NULL
for the addr, mask, and gw parameters.
Rahul Gundecha wrote:
However now the problem is that the link-local IP address is not
correctly assigned to the interface. The packets are sent with source
address as IP6_ADDR_ANY. Debugging this issue further.
Did you call netif_create_ip6_linklocal_address() after adding the
netif? I think
vincent cui:
Semin:
Hope your new commit !
Done.
Simon (not Semin :)
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Yugal Kishore Gupta wrote:
Lwip tcp stack with http server hangs up when we do a QUALYS free scan
on the system. HTTP server stops responding while ARP is working fine.
Could you please elaborate more on this? I'm interested in hardening the
httpd (or whatever goes wrong there), but it
Yugal Kishore Gupta wrote:
That's true. You need a public facing IP to do the scan.
Well, that's a pity then. I could try to somehow connect an lwIP device
to my cable line at home, though... How often do they allow you to do
the scan, anyway?
I can see that after scan I have at least 6
You are allowed to disable/enable the nagle algorithm where you like,
but if you want to do so before sending the first segment, any place of
these is equally good:
- at initialization time (as you did)
- in the accept callback (for passive connections)
- in the recv-callback before sending
Felipe de Andrade Neves L. wrote:
May I ask something, how came the Nagle's algorithm has caused the
problem, as it is suppose to group small data until receive the next
ack, but the JPG has lots of pending data to be sent and the algorithm
shouldn't retain it.
That's a good, question.
Have you also tried to increase MEM_SIZE? HTTP connection structures are
allocated on the heap (unless using a separate pool), and when failing
to allocate such a structure, an already accepted connection is aborted
with a RST (directly after the 3way handshake).
That doesn't describe all of
Miller, Mark wrote:
Has anyone gotten CyaSSL running with lwIP in RAW mode? I'm running on
a bare-metal Arm 9.
Specifically, I'm having trouble getting lwIP to send the Server Hello
message after CyaSSL builds it.
Although I'd be interested in SSL support for the raw API httpd, I'm not
Kieran Mansley wrote:
Apologies for the late reply, and thanks for sending in this fix.
Another example of why bug reports should be sent to the bugtracker, not
to this list (or lwip-devel)!
Can you clarify what goes wrong in the existing code. Is it that we are
delivering it to one PCB when
Kieran Mansley wrote:
On 22 Jul 2011, at 17:54, Simon Goldschmidt wrote:
non-blocking send is the way to go.
Or the compromise of a blocking send with a timeout, and then if/when the
timeout occurs you can check if you need to close it, or try the send again.
Although I'm afraid that won't
Kieran Mansley wrote:
On 22 Jul 2011, at 20:28, goldsi...@gmx.de wrote:
we don't support send-timeouts (yet?) :-(
Ahh, apologies. We should!
Yes, I also though we would, just checked the code to find out we don't.
Shouldn't be too hard to implement, though. I'll add a bug entry.
Simon
rocco brandi wrote:
EDIT: I've tried to set LWIP_HTTPD_SSI=1 in a version of my web server
where there's no SSI handler and I have the same problem: try to send
the page up to the first tag, but the packet is lost
That's strange, I think that worked for me, the last time I tried. I'll
see if
rocco brandi wrote:
EDIT: I've tried to set LWIP_HTTPD_SSI=1 in a version of my web server
where there's no SSI handler and I have the same problem: try to send
the page up to the first tag, but the packet is lost
Just tried that again, and it works perfectly: instead of the (replaced)
tag,
rocco brandi wrote:
if I set:
const tCGI myCGI[]={{string, extract}};
http_set_cgi_handlers(myCGI,1);
the compiler warn:
error: syntax error before numeric constant
warning: type defaults to 'int' in declaration of 'http_set_cgi_handlers'
error: conflicting types for 'http_set_cgi_handlers'
timmy brolin wrote:
In almost all lwIP *.c files, there are a couple of standard #includes
at the top, just after the lwip #includes.
Such as #include string.h and #include stdlib.h.
These feel misplaced.
Well, I don't think they feel misplaced: including them in sys.h or
arch.h would include
Bill Auerbach wrote:
It's one thing to makes changes for warnings in
popular standard C compilers (e.g. GCC) but I thought handling special
platforms or sub/non-standard compilers was not a goal of lwIP.
Well, that's my point of view, too. It's a matter of how many
compilers/setups have
so I changed EVERY length variables in u32_t or long int and now
everything works fine!
I think I remember having changed that sometime, as I have already
sent files bigger than 64k. However, I'll have a look at that again.
Simon
I just checked that and the current CVS HEAD version in the
rocco brandi wrote:
thanks, Simon!
I've tried two ways:
1) still using lwip 1.3.2 with the latest http server (changing
ip_addr_t in ip_addr);
2) using lwip 1.4 with the latest http server and no change
in both case nothing works neither with example page of lwip! as you
can see in the
rocco brandi wrotte:
I've found the problem!!!
I was using an older version of httpd that doesn't have the parser of
the HTTP requests!
now I was trying to compile the latest version of the http server raw
but the compiler find an error in the declaration of the function
rocco brandi wrote:
according to wireshark, here is what happens:
-handshake (ok)
- GET/ HTTP 1.1 (try to get the index page)
-continuation or non-HTTP traffic (what does it mean?)
That last line means that the HTTP response is not contained in the
first packet but spanned accross multiple
ambarisha b wrote:
I am working on a OS independent port for lwip. I have a couple of
issues with this.
Which version of lwIP are you using? I'm assuming 1.4.0 for the rest of
this mail.
The function declarations for semaphores and mailboxes are different
in sys_arch.txt and from lwip/sys.h.
wurzel wrote:
A followup to this discussion; after further debugging I did find
the cause of my flaky behavior and it was because the call to
tcp_write above needs to have TCP_WRITE_FLAG_COPY set.
I was optimistically hoping that since I called tcp_write and
tcp_output() from my receive
Martin Velek wrote:
There will be a memory leak if I
set the semaphore to the NULL in the *_invalide() function. Or what is
worse, the sys_sem_free() will fail with a NULL semaphore.
sys_sem_invalidate() will never be called before sys_sem_free().
Therefore, there is no memory leak.
Simon
Kieran Mansley wrote:
On Tue, 2011-06-07 at 12:47 +, ha...@gawnet.ch wrote:
Hi
I am just curious, if we have regression test problems with bug #24212
(I already reported some years ago).
In my latest application release I had to reintroduce the workaround
to reorder unacked tcp segments.
FreeRTOS Info wrote:
I'm not sure how most of lwIP development is done currently, but this
setup (with or without FreeRTOS) would make an easy and convenient
development and test bed (maybe it is done on Windows or Linux already?).
There's a windows port which I'm using for development. It has a
MaX wrote:
I saw there are some examples in the apps directory, but none of those
is complete as the main function and the
makefile are missing.
That's the nature of lwIP: it is not intended to be an end user
product but only a library. There *are* some ready-to-use examples in
contrib/ports,
ake.forsl...@nibe.se wrote:
Out of curiosity, can sockets usually (in other implementations) be
shared between threads?
I don't think there's a standard documenting this somewhere, but I think
at least linux and windows do support this.
Simon
___
Kieran Mansley wrote:
On Tue, 2011-05-24 at 15:14 +0200, ake.forsl...@nibe.se wrote:
1. Can I use threads? One to receive and one to transmit data and
then
check if the data arrives correctly?
You can, but I would do it all in one thread, and use poll() to
determine when each socket needs
Luca Ottaviano wrote:
I have only one remark: I guess that since you're developing a stack for
embedded systems you have a working port done on your reference
platform, don't you? Is it possible to include an 'official' working
port with the source code releases? That's because contributed ports
Elad Yosef wrote:
Is it under 1.4.0?
Can't remember when it has been added, but 1.4.0 should support it, yes.
I looked at the code and saw don't use note
Where did you see that? I had a quick look at the code but don't see
anything. Especially in opt.h, the comment just says Enable
Elad Yosef wrote:
But I get the following errors:
eladidy@eladidy-PC:~/Desktop$ ./make_epk.sh
test: 8: /home/eladidy/Downloads/contrib-1.4.0/contrib-1.4.0/ports/old/ecos:
unexpected operator
No idea.
test: 14: /home/eladidy/Downloads/lwip-1.4.0: unexpected operator
cp: cannot stat
Elad Yosef wrote:
In opt.h file It marked not to use SO_REUSEADDR.
Why and Is there any fix for it?
Because you are using an old version of lwIP. Please upgrade.
Simon
___
lwip-users mailing list
lwip-users@nongnu.org
Enrico Murador - Research Development - CET wrote:
It seems to me that, once one defines LWIP_PLATFORM_ASSERT macro as
fatal, as it should be,
also when LWIP_NOASSERT is defined LWIP_ERROR remains fatal.
You don't need to define LWIP_PLATFORM_ASSERT to fatal when
LWIP_NOASSERT is defined:
Yoav Nissim wrote:
Narke, not that you should need me to, but I join Simon in highly
recommending you use the latest stable version and not 1.3.2.
Well, strictly spoken: 1.3.2 *is* the latest stable version. However,
1.4.0RC2 is stable enough to be used: there are no (known) open bugs
which
Enrico Murador - Research Development - CET wrote
Dear Kieran,
Is there a way to send attachments to this mailing list?
Did just attaching the pcap file to a mail not work?
Simon
___
lwip-users mailing list
lwip-users@nongnu.org
Kieran Mansley wrote:
On Fri, 2011-04-22 at 10:52 +0200, Ruben van der Kraan wrote
After a boot of the software everything works ok. I can Ping, acces
the webserver pages, open the telnet server.
But at a point the websever and ping stop working. In wireshark i see
my PC sending request to the
Fixed, thanks for reporting!
Simon
bekanosky wrote:
Hello All.
I try to compile unixsim from contrib.
And i get error message as mentioned in the subject of my email.
By deleting '-Werror' from Makefile, the compilation goes fine.
The code in question is:
if (++port
Kieran Mansley wrote:
You'll have to look forward a little longer - 1.4.0 will be released as soon as
I have the time to do it,
Speaking of it, is there anything I can help for the release?
I'm really looking forward to adding functional IPv6 support - although
I won't be getting IPv6
Wilson, Dave (Stellaris S/W) wrote:
I took a look at the trace you posted. Aside from all the IP header checksum
errors in the requests sent from the browser (which appear to be ignored),
Such ignored bad checksums most often come from wireshark monitoring a
(windows-) network card which has
sanjib das wrote:
Hi All,
Hi onebrother,
I am very new to lwip. I have a very basic doubt on porting lwip with
without OS.
I googled a lot...but dint get as such any link where things are
explained in detail.
In the lwIP case, OS has nothing to do with Linux or Windows or other
Emil Ljungdahl wrote:
The reason for being concerned about this is that I want to make sure you
cannot mess up your current connection by adding the second netif in a
configuration interface with faulty parameters.
Well, I guess the point is you *can* mess up connections when you
misconfigure a
Thanks for reporting, I've filed a bug report:
https://savannah.nongnu.org/bugs/index.php?32926
Although the bug is rather minor, you can surround the
'TCP_RMV(tcp_bound_pcbs, pcb)' lines by 'if(pcb-local_port != 0)' if
you want to go on handling it like you did to prevent the assert from
Noam weissman:
I have a problem that I have seen lots or users straggling with, but
without any real solution.
I am trying to send data in a loop. I have triad closing NAGLE as follows:
// this should shut down the NAGLE algorithm
pcb-flags |= TF_NODELAY | TF_ACK_NOW;
Please don't use
Elad Yosef wrote:
Using eCos
On Wed, Mar 23, 2011 at 2:41 PM, Tim Lambrix t...@fleetwoodgroup.com
mailto:t...@fleetwoodgroup.com wrote:
If you are using a TI Stellaris micro, their boot loader example
uses lwIP with a TFTP transfer protocol.
The tftp code is included in the
Roger Cover wrote:
I am confused about a couple of things here. Why does the stack send 4
duplicate ARP requests in 2 microseconds?
That's just the way lwIP ARP works: if it does not find a stable entry,
it sends a request. In order to keep it simple, there is no check for
the last request
Mullanix, Todd wrote:
For my port to SYS/BIOS, I have NO_SYS=0 and I'm making sure the netif-input is
being called from a thread and not in the interrupt. So I think I'm adhering to the
rules of the game in my case. Note: I'll make the change to use netif-input.
Yeah, the NO_SYS=0 case looks,
farid mahini wrote:
Question: Since the SYN message has both source and destination
addresses (IP and MAC), why does MyServer request it? Wouldn't it get
added to ARP table as the SYN message travels up the stack to TCP layer.
You can configure lwIP to behave like that, but it's not a good
Yoav Nissim wrote:
Our PPP code seems to be working fine for some time now after the
modifications discussed below:
Good to know it's working for you and thanks for sharing the results.
I will submit a bug in savannah soon, and check original ppp code as well.
That would be great!
Simon
Bernard Mentink wrote:
Yes, I am using DMA. Can you please elaborate on how to invalidate the
cache lines, I havn't had much to do with dma to date ..
Basically, you just have to make sure that data written by the processor
(lwIP or your driver in this case) is actually written out to RAM
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
David Hammerton wrote:
closing a socket, whilest thread 1 is still using it for send/recv,
which causes a problem - as yes, that would be a problem in any socket
environment.
I think some socket environments support this. The result would be that
the send/recv call returns with an error
Yoav Nissim wrote:
I've opened a ticket for this issue on savannah, and have a few
problematic points left.
Great!
1. Could you give some feedback as to how we should process each of the
PCB queues? (e.g retiring a PCB but leaving it to be cleaned up later
vs. calling the upper layer with an
Chen wrote:
lwipopts.h already includes debug.h, and there is no def for
DBG_ON, unless you meant DBG_ON is the same as LWIP_DBG_ON, etc:
The debug macros have been renamed to include the LWIP_ prefix back in
1.3.0, so the lwipopts.h you are using has been designed for 1.2.0, and
that's a
Chen wrote:
Kieran, thanks for the reply
I can't find TCP_SND_WND in lwipopts.h (see attachment)
I think that was a typo and Kieran meant TCP_SND_BUF (the send queue
limit in bytes). You might have to change TCP_SND_QUEUELEN (the send
queue limit in pbufs), too.
Nagle's algorithm
Chen,
lwIP targets embedded systems. The lwIP-internal heap (which can be
replaced to use any other heap or the C-library's malloc/free functions)
uses MEM_SIZE to define a region of memory that is reserved for the heap
when creating the embedded system's memory image. Making this
Am I assuming correct that you are using the raw api with your own
threading-mechanisms instead of using the netcon- or socekt API? If so,
you don't have to wait for your poll callback to be called: you can
always try to send more data from the sent- or recv- callback. And if
you need to to do
Rick Solotke wrote:
I just wanted to pop in and say that I have observed and debugged the
same problem, specifically for the UDP and TCP PCB lists. It would be
great if the code could be changed to explicitly initialize these to
NULL.
You could have had that problem with any other third-party
Peter Murphy wrote:
I'm developing a FTP server to run under lwip and freeRTOS. I can send
directory info and files over the FTP data port but when I go to
receive a file I get a 20 second delay. WireShark shows the first
packet is sent milli-seconds after the '150 Opening connection'
Bill Auerbach wrote:
I wait to call dhcp_start until I see that I have a link established.
... and as a reminder to those who don't know:
- netif_set_link_callback() is used to set a callback per netif to get
informed when the lwIP-internal link state changes.
-
Timmy Brolin wrote:
It seems to be known that the performance of lwip when used in a OS
environment is less than optimum.
Well, that depends on the API used: the raw API is quite fast even if
you are using an OS... :-)
Some tests done in this task: http://savannah.nongnu.org/task/?6935
showed
Timmy Brolin wrote:
Ok, thanks for the input.
That is why I posted on the mailing list. To get an impression of the
potential risks and problems involved.
We have a UDP-loop application using the netconn interface (it responds
to any UDP frame by sending another UDP frame).
The risk for
PHAM ANH THIEN wrote:
so you mean:
netif_set_default(netif_add(netif, ipaddr, netmask, gw,
NULL,pcapif_init, tcpip_input));
dhcp_set_struct(netif, netif_dhcp);
dhcp_start(netif);
is enough?
You can even leave away dhcp_set_struct(): it's only a helper to prevent
dhcp_start() calling
UDP and TCP are two totally separate protocols built on top of IP, so
there's (from the protocol point of view) no way they can influence each
other. What you're seeing looks like a misconfiguration or a bug in your
port or application. Normally, what you described should work with lwIP.
Hi Thien,
PHAM ANH THIEN wrote:
I could not find a well sample dhcp source code on lwip-1.4.0.rc1 and
contribute folder, could you please to point me where it is?
The main problem with your code isn't finding an example but
understanding lwIP threading and how not to break it. Please read the
701 - 800 of 1087 matches
Mail list logo
