Thanh NGUYEN wrote:
I see there is an implementation of autoip in lwip. I would like to know
if there is any implementation or port of mDNS for lwip ? Does lwip
support multicast ?
I don't know whether anyone implemented mDNS for lwIP, but I haven't
heard of it on this mailing list, yet.
But
You did not say which platform you are running on nor which version of
lwIP you are using. Please download the contrib module and take a look
at the example applications in the windows or unix port to get an idea
of how to start with lwIP.
Simon
sandy tewari wrote:
I am new to LWIP and im t
At least from reading your post (not reading the source code), it seems
you're right. Could you file a bug at
http://savannah.nongnu.org/bugs/?group=lwip ?
Thanks,
Simon
Charles Landau wrote:
In lwIP version 1.3.0, in core/tcp_out.c, starting at line 336 the code
appends the pbuf chain queue
sandy tewari wrote:
Thanks for your help guys. So i am trying to implement it.
Things that i need to do:
1. change sys_arch.c to work on processes not threads: i am going to
exec a process now, rather than p_thread_create
2. secondly, i want to make them share common data: is that only going
t
Rishi Khan wrote:
Does it really need to know the 'type' of message, or does it just
need the size of the message.
Hmm, good idea, might be worth a try! But that would also mean that data
taken out of an mbox must be explicitly freed (since it is duplicated by
sending it through the mbox). T
I guess you won't get too many really neutral answers on this list, but
I'll reply anyway... Only my opinions of course!
Altera first used lwIP since they needed an inexpensive (or free) TCPIP
stack for their users (many TCPIP stacks are quite expensive...). They
don't seem to have worked too
ny help is of course welcome!
Simon
-Mike
On Mon, Dec 15, 2008 at 2:29 PM, goldsi...@gmx.de
<mailto:goldsi...@gmx.de> mailto:goldsi...@gmx.de>>
wrote:
I guess you won't get too many really neutral answers on this
list, but I'll reply anyway... Only my opini
Sergio Sider wrote:
I am using lwip "ported" by LuminaryMicro, and CodeSourcery (GCC)
#define SYS_LIGHTWEIGHT_PROT1 // default is 0
#define NO_SYS 1 // default is 0
On interesting fact: A custom UDP message I send on the beggining was
not
Sergio Sider wrote:
I am using lwip "ported" by LuminaryMicro, and CodeSourcery (GCC)
#define SYS_LIGHTWEIGHT_PROT1 // default is 0
#define NO_SYS 1 // default is 0
On interesting fact: A custom UDP message I send on the beggining was
not
I'm afraid I can't help you right now: it's been a while since I worked
with lwIP arp and/or VLAN, but I can tell you it has worked for me
somehow :-)
I've added a task on savannah for this. I'll see what I can do to dig
out my changes for that.
Simon
Anubhav Saksena wrote:
For this do I
Kieran Mansley wrote:
In other
words, is there a difference in this:
netconn_write(..., 4096, ...);
or
netconn_write(..., 1460, ...);
netconn_write(..., 1460, ...);
netconn_write(..., 284, ...);
The correct answer is "maybe".
I'd say netconn_write(4096) is faster since it implies les
Hi michael,
First you need a port to use lwIP o your platform. There are existing
ports for unix and win32 in the conrtib module.
As to your application: I guess you would need to write a virtual
ethernet driver. An example skeleton of this can be found in
src/netif/ethernetif.c and use this
The parameters you want to tweak mainly influend throughput of streaming
data, i.e. the stack on your side is fast enough to fill the tcp window.
If so, increasing the three parameters you stated below increases
throughput!
But there can be other reasons for low throughput, mainly:
- packet lo
Forgot one:
DownyTif wrote:
Is TCP_WND only for receiving data? If I only receive small frames in my
lwip, do I have to still make it big?
TCP_WND is the receive window announced to the other side with a SYN,
but it is also used as a maximum limitation on a transmit window
received from t
The memp err simply says all TCP PCBs are in use. The expected behaviour
would be that every SYN leads to allocating a PCB and a SYN+ACK is sent
back. However, with a SYN flood attack, the originator does not respond
to that SYN+ACK (as it normally would, with an ACK). Instead, the PCBs
are lef
Chen wrote:
[..], they all dealt with socket/netif directly, which I am not
familiar with, not a single sample project calls tcp_* raw APIs, so I
am having trouble to extract the pieces to make a TCP echo server.
There is an example (very simple) HTTP server for the raw API in the
contrib mod
David Shmelzer wrote:
I converted all my code to netconn api and it works, but is a bit
slower.
If I wanted to convert it all to the raw API how do I send to the raw
API from a separate task?
Can I safely call tcp_write from a separate task?
Absolutely not!
I noticed there's work being d
Chen wrote:
Could you show me how to get to the download section to get the sample
mentioned by Simon?
http://savannah.nongnu.org/projects/lwip/ -> 'Downloads' in the upper
navigation row. After unpacking contrib, the HTTP server is in
apps/httpserver_raw/
Simon
__
Both the netconn and the socket API can only be used with an RTOS! I
beleive this is sufficiently described in the various text files in the
lwIP release as well as in the wiki!
Simon
Francois Bouchard wrote:
Hi all,
Is the */httpserver-netconn/* demo meant to run in a *RTOS* environment?
Francois Bouchard wrote:
Ok yes, I should have looked before posting, but thanks. Anyway I got the
webserver working now, and this is my starting point to make a basic echo
web server. From what I see the server netconn closes between requests in
order to accept new ones. But what if my client
dogeye wrote:
Thank you, Kiran, for the explanation. Yes, i got the idea, so it's
basically a implementation choice, like windows xp doesn't update ARP
table if the request is not for it. In this way, we can avoid the
trouble that the ARP table will filled up quickly in a large network,
and we n
Chen wrote:
I didn't realize lwIP's default is only one TCP socket, I will try
your suggestion
That's not the lwIP default but the value you have in your configuration
file (lwipopts.h), which is *not* part of the lwIP distribution. Your
file probably comes from Atmel, so it's worth going throu
Francois Bouchard wrote:
Ok, I think that the cast is the good thing to do (I got exemple that
does that).
But that does'nt fix my problem. The client application sends 10
unsigned short, then the server is supposed to send back the 10 u16_t
var, but it retransmits half of the data. The le
Of course if the incoming netbuf/pbuf says it only holds 10 bytes there
is no point in changing its length: it doesn't have more. I suggest
tracing what's on the wire using wireshark/ethereal and comparing that
with what you receive. Breakpoints in the ethernet driver also help a lot.
Simon
Francois Bouchard wrote:
The other thing that makes me slightly nervous is the use of
NETCONN_NOCOPY. How/when are you freeing inbuf?
I'm doing a netbuf_delete after each receive. Grosso modo:
inbuf = netconn_recv(conn);
if (no errors)
net
Thanks for reporting this, especially for the detailed report from the
snmp-net list! When discovering a bug which such a good report at what's
wrong, it is always best to create a new entry in the bugtracker at
http://savannah.nongnu.org/bugs/?group=lwip to prevent the bug getting
lost. I'll d
Edward Harris wrote:
Can anyone advise on SYS_LIGHTWEIGHT_PROT, please?
SYS_LIGHTWEIGHT_PROT should be set to 1 if you are using pbufs or
memp-pools from different execution contexts (e.g. more than one thread
or interrupt context). The name is somewhat misleading as 0 does not
lead to 'hea
Bernhard 'Gustl' Bauer wrote:
I attached a wireshark file at my 1st posting. SYN is ok. GET is not
ACK, but there are 2 RSTs! I'm not sure where the GET fails.
The RSTs only happen when the connection is forcibly closed by the
application. This can be due to lack of (configured) memory, check
Chen wrote:
1) I tried checking tcp_sndbuf, but I doubt it is the answer, for the
thruput rate is way too low, and I can send much more error-free
without it
Watch out to not mix the APIs here: tcp_sndbuf belongs to the raw API,
not to the socket API (which lwip_send belongs to).
Simon
Kieran Mansley wrote:
You can probably get away with leaving TCP_WND alone
if you're acting purely as a sender of packets,
In fact, I think you won't, as TCP_WND is not only the announced receive
window size but serves as a limit for transmit window, too.
Regarding memory size, the PBUF_POOL s
Chen schrieb:
I believe it is 1.3 since the soure codes have many reference for
1.3.6.1.2.1.xx (which definition should I search to be absolutely sure?)
1.3.6.1.2.1.xx??? Where's that from? Unfortunately, there is still no
version in the sources. It's a new "feature" just added in CVS HEAD.
Wh
Kieran Mansley wrote:
Kieran Mansley wrote:
You can probably get away with leaving TCP_WND alone
if you're acting purely as a sender of packets,
In fact, I think you won't, as TCP_WND is not only the announced receive
window size but serves as a limit for transmit window, too.
I know this is not the answer you'd expect, but I have to warn you that
there is currently no active developer using the PPP part of lwIP, so
you might have to rely on answers of other users on this list. As
always, new developers caring about PPP are welcome to take part and
improve it!
Simo
I'm grateful to hear that! Still, the offer is valid ;-)
Letschi wrote:
I found it! It isn't a lwip-Bug! With every reconnect I called pppInit and
this function calls mem_malloc!
___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.no
Are there any other devices on the network? I'd expect your hardware is
too slow to keep up with full wire speed receiving and that's what you
get with a hub when there are many devices talking over the net (as with
a hub you get *every* packet, not only broadcast packets like you do
with a swi
Jeff Barber schrieb:
1. The function ethernet_input should be called to introduce new
packets into the lwip stack.
(Or, more specifically, it appears that my framework should specify
ethernet_input in the netif_add call as the input function; then the
driver should call netif->input.)
Corr
Ken Smith schrieb:
Also, in looking at my ethernet driver the way it interfaces with
lwIP, I noticed some meaningful differences between my implementation
and the reference implementation in CVS HEAD.
The infinite loop is not a problem for the stack (I'd expect the thread
waits on a semaphore
Chen wrote:
once entering lwip_accept, it blocks until a connection is made. How
can i allow more than 1 tcp connection on differnt portS?
That is a general question about sockets programming, not limited to
lwIP. Thus this list may not be the best place to ask. In general, you
can pass a lis
Ken Smith wrote:
... it works. For relatively large changes like this, where concurrency
issues might arise if something is overlooked, perhaps more explicit
upgrade instructions are in order. Or have I missed a key piece of
documentation?
No you haven't, but unfortunately, documentation is rar
arun kumar wrote:
Hi Can any body .. answer me for this query that i have posted..
I have treied increasing the IP_REASS_MAX_PBUFS and the PBUF_POOL_SIZE
but it didnt work out. It is always going to Assert statement in
pbuf_header in pbuf.c at line
Since pbuf_header is called multiple times w
Hans-Erik Floryd wrote:
Is it correct for netbuf_chain to free the tail netbuf? If that one line
is removed the code above works fine.
If it is correct behaviour, any ideas how to best use the netconn API to
send the message? I have read what documentation I could find on the
wiki but there d
Questions like this one are often asked here. In fact, TCP is not really
helpful here. There are a few parameters to tweak to make TCP detect
connection errors earlier, but most of them have some side-effects so
that you really have to know what you are doing.
What you are doing is already the
Bill Auerbach wrote:
Incrementing the reference count is the way to move the freeing of the pbuf
from the stack to the Ethernet driver. It's been done by several
implementers successfully.
I can tell you that won't work if
- sending data over UDP using the sockets API and
- having a fast device
John Kennedy wrote:
Since pbuf_free decrements the pbuf reference count and only frees the pbuf
when the reference count goes to zero I assumed that by incrementing the
reference count in the Ethernet driver it would prevent the stack from freeing
or reusing the pbuf, and that the Ethernet dri
@Younger: There is no function like 'main_thread' in the lwip source!
What you have to do is
a) provide a timeouts structure per thread, sys_arch_timeouts() must
return a unique structure for the currently running thread
b) provide the correct wait-time return values for sys_arch_sem_wait()
and
yangjinwei82 wrote:
Dear Simon,
I find function "main_thread" from
contrib1.3.0(contrib/ports/unix/proj/unixsim/simhost.c),
That would be the unix port. Stll, there is no main_thread function in
the main lwip source. Starting a new port from the unix or win32 port is
a good way, of course, but
John Kennedy wrote:
Hi,
I'm porting lwip to run on Xilinx Spartan 3 with Microblaze using the
xps_ethernetlite MAC.
How do I obtain a MAC address or a block of MAC addresses? What does it cost?
How long does it take?
Wikipedia gives this link for requesting an IAB (4096 addresses):
http
If I remember correctly, there are many places in the stack where your
simple semaphore can be used (tcpip_thread, netconn semaphores, etc.)
but there are also other usages where multiple waiting threads have to
be supported (i.e. locking the heap in mem_malloc). So I guess you are
right that t
ners on an mbox does not make sense to me in the situation of this
stack, as results are not predictable.
Simon
I think it would be pretty straight forward to add support for
semaphore/mailbox deallocation to our OS, so that is not a very big issue.
Regards,
Timmy Brolin
goldsi...@gmx.de
Oscar Cutanda wrote:
How are you managing it? Some type of tasks? Interrupts?
The lwip raw API is event based. You create listening connections that
include a callback for when a new client connection attempt is received.
In that accept callback, you in turn set callbacks to the newly created
Right now, there is no support in lwIP to automatically call the timers.
You have to do that yourself by monitoring a timer in your hardware.
However, calling tcp_tmr() is enough, it will call tcp_fasttmr() every
time it is called and tcp_slowtmr() every second time it is called.
Simon
Alain M. wrote:
That is normal PING behaviour, you may even get it on Linux
ocasionaly... (pinging a Win machine :)
The explanation is simple: Before sending the ping to the destination
machine, the system has to resolve ARP and this may take some time. Only
after that the ping will be sent.
Hi,
I committed the first 2 (since they are obvious), don't know how about
the last, since I canot compile the source (no unix at hand), and I'm
not really the unix port maintainer...
Thanks,
Simon
w...@koebler.com wrote:
Hello,
Those patches cleanup and simplify the example from
contrib
Wow, that was fast! I told you I couldn't compile it :-) I've remove
that brace, hope it works now.
Thanks again,
Simon
w...@koebler.com wrote:
On Sat, Apr 18, 2009 at 01:22:15PM +0200, goldsi...@gmx.de wrote:
I committed the first 2 (since they are obvious), don't know
When encountering errors, bugs or just strange behaviour in lwIP, it's
always best to *first* look at the open issues (bugs, tasks, patches)
before posting here.
The bug you encountered has already been entered into the list of open
bugs: http://savannah.nongnu.org/bugs/?25632
I have to disa
Rick Culver wrote:
> At any rate it appears that httpd module can only serve up one chunk
of the file about every 200msec.
200msec rings a bell: this is the delay windows waits before sending a
(delayed) ACK: normally, it prevents sending an ACK for every packet to
keep the total packet coun
Bill Auerbach wrote:
I see - tcp_output isn't a "send now" - I thought it meant that (if not, why
do a tcp_write *and* a tcp_output?). So with tcp_output, Nagle delays are
not circumvented. The contrib example doesn't do tcp_output - so is it
optional? Why?
I guess this is not really a good
HM2 wrote:
It's in the current download of the RAW text, and also on the wikia
web site.
If that's old, that's still what's there.
I still cannot find it in the downloadable files (contrib-1.3.0.zip and
lwip-1.3.0.zip) nor in CVS (lwip, contrib and lwiphtml) - I'd be happy
if you could point
Simon Goldschmidt wrote:
Hi,
first you should go to savannah.nongnu.org/projects/lwip and subscribe for the
lwip-users and lwip-devel mailing lists. Then you should file a bug report
including detailed data what went wrong (a debug-log, lwipopts.h file and, if
applicable, a packet trace is al
Emmanuel Baguia Jr. wrote:
Hello,
Sorry, I did not exactly get your point. What I really wanted to have
is to create a gethostname() functionality. What I thought is to
enable and activate a hostname for the ethernet interface.
I was able to check the things you mentioned below but somehow g
Data gets parted in 2 ways:
- the remote host may split the data in multiple network packets
- lwIP may split a received packet into multiple pbufs
There is however nothing unsorted. I.e. the pbufs you receive hold the
data in exactly the same order as the remote host sent it. If you don't
get
HM2 wrote:
I'm a little confused as to what the actual input function needs to be for
RAW in 1.3.
The possible choices seem to be:
- ip_input()
Input function for packets starting with IP header
- ethernetif_input()
Private input helper function for the example ethernetif (you couldn't
John Kennedy wrote:
In the Xilinx lwip 1.3.0 port the low_level_output function basically
copies the entire pbuf to the Ethernetlite MAC using the pbuf len (or
total length if the pbuf is chained). This seems inefficient, since
the actual packet length could be much smaller than the pbuf len
When allocating a pbuf, the end of it is defined by the length passed to
pbuf_alloc, while the start is defined by the layer: pbuf_alloc
allocates a pbuf (or a chain) of length + layer offset. E.g. if you call
pbuf_alloc(PBUF_IP, 10, PBUF_RAM), a pbuf with a total length of 10 + 20
+ 16 = 46 by
John Kennedy wrote:
So my quandary is this, I have a breakpoint set in low_level_output. When I
send a ping I hit the breakpoint and the pbuf lwip is trying to send is an ARP
response packet, the pbuf has len == tot_len = 1518 although the ARP response
packet is actually only 60 bytes?
Just
I think that etharp_request is the wrong function to cahnge: it is
mainly used for sending real requests (and I think ethzero is correct
here). Instead, we should update the code which wants to send a
gratuitous ARP (netif.c only) to use an own function. The current
implementation is only happe
John Kennedy wrote:
Yes, I'm sending a ping from my PC to my embedded system running lwip. With no
breakpoints set wireshark shows an ARP request going out and the ARP response
returning from lwip. Then the PC sends an ICMP (ping request) to the embedded
system. So the ARP response packet g
The pbuf leak might still be in there, but the checksum generation has
already been corrected in CVS (I assume you are using 1.3.0, you don't
tell that).
Simon
HM2 wrote:
I ran into a number of issues using the PING app from the contrib section.
I am using RAW mode. The PING app just did re
ncoage wrote:
I don't know about that, but you can write your own: the socket-select is
implemented by passing a netconn-callback to
netconn_new_with_proto_and_callback().
Simon
Just to be sure - the callback function is from TCP thread (created by lwIP),
not from thread where netconn
HM2 wrote:
This is probably nit picky, but I think the Target Hardware Address should
be set to the FF... broadcast value, rather than Zero. This is in Etharp.c
in the function etharp_request(). ðzero is used where I think it should
be ðbroadcast. In the other examples and doc I always see FF
John Kennedy wrote:
(albeit sometimes a bit terse)
Sorry, that's because I write the mails during work (and lwIP is not on
my project list, currently) :-)
The problem with other ports is that you can never tell if they are
correct. The *nix and windows ports are maintained by the lwIP team
Pavel Daniel Lopez Castillo wrote:
I download lwIP 1.3.0
I can not see the makefile to build a binary on the download
That's because there is none. lwIP is like a framwork: it's not an
application that you compile but only the source code. You have to
integrate the source files into your pro
PELISSIER Christophe wrote:
One point is not clear for me, is Lwip able to manage multicast
address? can we bind, send and receive on multicast address using BSD
like interface?
If I remember correctly, when things like IGMP are turned off, lwIP
should not make a difference between unicast an
Pavel Daniel Lopez Castillo wrote:
After that I download contrib module
how I can Can run any application
I'm working on debian, I also like to know in windows
eg: contrib\apps\httpserver_raw
I can't tell you on linux, but on windows, open
contrib/ports/win32/msvc6/test.dsw o
Bill Auerbach wrote:
I can't tell you on linux, but on windows, open
contrib/ports/win32/msvc6/test.dsw or ../msvc8/lwIP_Test.sln and run it
(after adding the missing config file lwipcfg_msvc.h from _example).
That brings you a running lwIP system where you can enable the
httpserver_raw app.
Niels Hendriks wrote:
... To test the receiving of data via TCP I've programmed the code at
the end of this e-mail. For some reason, when I'm using a interrupt to
call tcp_tmr() every 250 ms, the proc. stops at (what appears to be) a
random time and reboots.
When I disable the interrupt/timer 1
Pavel,
Please don't get me wrong, but posting the same message again and again
will generally lead to the exact opposite of what you want: people will
get annoyed and not even read your posts any more.
This is a project and (a mailing list) of people working on an open
source project in thei
Unfortunately, I also don't have that much experience with the snmp
code, and I did not use traps so far (only snmpwalk). But what I can say
about your code is that it is likely to fail because you are using the
snmp functions from an application thread.
At least snmp_send_trap will call the U
I don't really think this is a bug, either. But there should be a
comment and maybe example code in one of the ports so that one can find
the right way to use it.
Simon
Alexandre Malo wrote:
I cant get the leak again. Im now at 6 trap sent with out any
memory leak.
I think that the val
From reading the code, the cause of the delay is that you don't call
tcp_output() after calling tcp_write(). tcp_write() only enqueues
without sending. The data is then sent later by a TCP timer (which is
the reason for the relatively exact delay of 200 ms). (BTW: Variant 2 is
the correct way,
If your deadline is quite short, I'd stay with the latest release: since
CVS HEAD is work in progress, you never know in which state the source
is at the time you download it...
Unfortunately, I cannot tell you how long you'd have to wait for the
next release: Kieran took some time off and I'm
Kieran Mansley wrote:
A) How the PPP implementation works / is implemented
B) What has to be done to port the PPP implementation so that it can
be used without a OS.
Those are very open-ended questions, and so are unlikely to get a useful
reply. Can you be more specific about what you nee
What you are seeing is that the PCBs are remaining in a wait-state for
some time. This is to prevent packets from the old (closed) connection
being possibly accept on a new connection. The port stays known to the
stack and it can send RST packets when new packets for that port are
received. How
Bill Auerbach wrote:
Shouldn’t the following work?
p = pbuf_alloc(PBUF_TRANSPORT, 1, PBUF_POOL);
udp_sendto(pcb, p, ipAddr, port);
Wireshare shows a mal-formed packet. The following does work.
p = pbuf_alloc(PBUF_TRANSPORT, 2, PBUF_POOL);
udp_sendto(pcb, p, ipAddr, port);
Bill
Bill, I t
Kieran Mansley wrote:
On Wed, 2009-06-24 at 14:16 +0100, David Ward wrote:
I'm using the RAW API.
This is the receive callback, I'm using.
The problem is quite simple in that case: your receive callback is only
handling a single pbuf. The pbuf passed can in fact be the head of a
ch
When "no data is being sent", does the code even reach netconn_write
(wherever it is, it isn't in the code below), or could it be that it is
stuck in the second call to netconn_recv (which is blocking, so does not
return until there is more data!). If netconn_write was called, did you
check its
Jesper Vestergaard schrieb:
Where do i set the buffer space?
There is no single "buffer space", there are many different options
influencing the memory used by TCP. Take a look at opt.h and the
explanations there, that should help you finding the right option to tweak.
When enabling deb
In that case, it has been fixed in CVS after 1.3.0. You can either
upgrade to CVS head or just change the error defines...
Simon
Jesper Vestergaard wrote:
Simon Goldschmidt wrote:
If i add pxNetCon->err = ERR_OK; after the do while everything works. It
seems that ERR_TIMEOUT is treated as
The main work seems already done: there are ports for uC/OS-II available
on the web. Using these to run on PowerPC should not be too hard and
should mainly require defines or typedefs in cc.h to be changed.
Simon
Kevin wrote:
Hi,
I plan to port LwIP 1.3.0 to uC/OS-II with PowerPC. But I am
Kevin wrote:
Hi, Simon:
You mentioned "there are ports for uC/OS-II available on the web", are
they ports for lwip130? May I have a link to this port?
I found one for lwip110 and since lwip130 changed a lot from lwip110,
I am not sure how hard to move from 110 to 130 port on uc/os-ii. Do I
4/lwip/ip.h:136: warning:
'packed' attribute ignored for field of type 'struct ip_addr'
Could you please give me a help on why this warning and how I can get
rid of it?
I am using powerpc-eabi-gcc and powerpc405.
Thank you!
Regards,
Kevin
On Sun, Jun 28, 2009 at 3
Kevin wrote:
Hi, Nicolas:
In your port, how do you register lwip interrupt into uC/OS-II? Are
there functions like "register_interrupt_handler()" or
"enable_interrupt()" so that OS may aware of interrupt from LwIP?
I didn't find this info in the package you posted. Are these interrupt
handl
Bernhard 'Gustl' Bauer wrote:
Simon Goldschmidt schrieb:
In the past, stalls like this have often been driver bugs: a portscan
is like a stress situation to your driver, maybe it leaves interrupts
disabled or something like that, so the device cannot receive any
packets?
I enabled the
Bill Auerbach wrote:
Maybe this is legacy now. If tcp_write cannot send data, it will be called
by the stack when data can be sent.
Or empirically, I don't use tcp_poll (it gave me problems) and I don't have
memory to send 500k at once. tcp_sent is simply called until I am able to
send all of m
Lou Cypher wrote:
The poll handler didn't spawn exactly in my intentions: for some reason it was
already there.
Then going on with tests, I started /loosing/ some packets coming from a web
client: those packets are _never_ routed to recv handler, from that point of
view they're lost, while the po
Lou Cypher wrote:
A source code is worth a thousand words... My recv looks like this:
---
err_t http_recv( void *arg, struct tcp_pcb *pcb, struct pbuf *p, err_t err )
{
...
if ( err == ERR_OK && p != NULL )
{
PRINTDEB
the_gadfly wrote:
[...]
int count=0;
void Delay(unsigned long ulVal)
{
while ( --ulVal != 0 );
Any good compiler will optimize this away to nothing, I guess. If you
really want to delay like that, you'd have to use a volatile variable.
}
void
httpd_init(void)
From where (which threa
So if I understood you correctly, when udp_echo_recv() sends a packet by
calling udp_send(), it works, but the udp_send() in the main function
does not work?
The explanation for that could be simple (and nearly described by
yourself): In order to really send the packet, the MAC address needs t
Kieran Mansley wrote:
On Wed, 2009-07-08 at 13:07 +0200, Simon Goldschmidt wrote:
To upgrade the version yourself, just download 1.3.0 from
http://savannah.nongnu.org/projects/lwip (-> go to download section)
and replace the old 0.7.1 version with the new version. After
recompiling your NIOS
the_gadfly wrote:
Simon:
Yes,your comment is reasonable ! Here is the stats print after udp_send:
My stand-alone lwip 's version seems too old 0.7.1 ,download from Altera
NIos forum:
http://forum.niosforum.com/forum/index.php?showtopic=949 (I haven't found
any newly than it )
Why did you d
1 - 100 of 1212 matches
Mail list logo
