Thanks for reporting, I missed part of the code for using custom memp
pools. It should work now.
Simon
yueyue papa wrote:
Hi All,
I update the latest CVS code. The windows project reported
httpd.c#
http_state_alloc()
{
return (struct
David Empson schrieb:
Simon Goldschmidt goldsi...@gmx.de wrote:
Marco Jakobs m...@piciorgros.com wrote:
I'm just wondering how the PPP of LWIP is handling the pbuf's, maybe
someone can drop a line about this ...
I don't know that by heart but I think I remember the PPP code
JM wrote:
I'm sort of nitpicking here, seeing as how I had to increase MEM_SIZE
not much beyond what I originally had it set to, but in my application
RAM is very valuable. It would be nice to dynamically allocate RAM
for DHCP, then release it since it's only required momentarily (I'm
pragnesh patel wrote:
I am a new user of LWIP and have few questions,
1) I am using web demo example for EVK1100 from ATMEL, which uses
sequential API for web connection. This runs as one thread on freeRTOS
2) I have another task running on separate system thread for TELNET
server, where I
Francois Bouchard wrote:
I'm running lwIP in stand alone mode and I'm wondering if I
should mask interrupts routines during buffer allocation? memp_malloc()
Yes, you should. That's what's SYS_LIGHTWEIGHT_PROT is meant to be for.
Simon
___
Mike Kleshov wrote:
2009/11/27 goldsi...@gmx.de goldsi...@gmx.de:
Yes, you should. That's what's SYS_LIGHTWEIGHT_PROT is meant to be for.
Simon
Surely it depends on the application. I'm using lwip raw API with no
OS. I'm not using any concurrent access protection whatsoever. My
Jan Wester wrote:
Hi all
I’m trying to optimize my TCP/IP communication
Is it anyone how have the checksum, htons and htonl routines in
assembler for ARM
I do have a checksum routine in (gcc) assembler. It's quite optimized,
but I haven't used it for some years and don't remember if it
Martin Velek wrote:
Which ARM architecture exactly?
Ah, yeah, I forgot to mention that my version was for ARM7, farily old...
Simon
___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users
Kevin wrote:
Hi, all:
I find a pbuf flag in lwip1.1.0: which is as this:
#define PBUF_FLAG_LINK_BROADCAST 0x80U
I assume it flags a broadcast message in the pbuf. Right?
At least that's what the comment said it would...
While in lwip1.3.0, I cannot find this flag. My question is:
How
Bernhard,
I'm currently (though very infrequently) in the process of working on
httpd, so I'm not really sure on which version you are based.
However, there are two correct ways when to free application buffers:
- when data is copied with tcp_write(), application data can be freed
when
Zahir Lalani schrieb:
while (1){
ptel_pcb = tcp_listen(ptel_pcb);
tcp_accept(ptel_pcb, echo_accept);
}
Is this correct? I would normally expect to issue the listen on a port
only one
No, the correct way is to call tcp_listen() before the
Bernhard 'Gustl' wrote:
tcp_write is used in my copy too.
Of course it is. The question is whether you pass TCP_WRITE_FLAG_COPY or
zero as 4th argument to tcp_write(). If you pass TCP_WRITE_FLAG_COPY,
data is copied from the pointer you pass to internal buffers which are
freed when ACKed.
JM wrote:
How is the error callback specified? I have not been able to find this.
Use tcp_err() from tcp.h.
Also, I looked in the rawapi.txt file and found this, which further
confuses me:
The tcp_connect() function returns immediately; it does not wait for
the connection to be
What's the time plan on 1.3.2 final? There haven't been any serious bug
reports since then, I think. On the other hand, I'm not sure how well it
has really been tested as we didn't have a news item or a ZIP to download...
Simon
Kieran Mansley wrote:
I've just made a release of
Kieran Mansley wrote:
On Wed, 2009-11-11 at 17:45 +0100, goldsi...@gmx.de wrote:
What's the time plan on 1.3.2 final? There haven't been any serious bug
reports since then, I think.
Agreed, hopefully I'll get some time this week to sort things out.
Great!
On the other hand, I'm
Bill Auerbach wrote:
It's a bit wasteful, but could he pre-allocate what tcp_write would do when
copy is enabled, if it passes, free the memory and then call tcp_write. If
the pre-allocate fails, it would have in tcp_write also.
So why bother with trying? tcp_write failing will tell you the
I suppose you mean cancel the netconn accepting as netconn_accept() is
the blocking call, not netconn_listen()?
This has been covered numerous times on this list: The netconn and
socket API is *not* designed to let one connection (or socket) be used
simultaneously from more than one thread.
Bertrand Van Kempen wrote:
Thanks a lot Simon.
Yes, it is exactly that.
I'm new with lwIP and I'am sorry to ask for solved issue.
Could you tell me how to have access to old post?
Archives are accessible via
http://lists.nongnu.org/archive/html/lwip-users/ and
You didn't say from where you call the SendDiagnoseMessage() function
(i.e. which thread). Most often, things like checksum corruption (or
corruption of linked lists etc.) result from multiple threads being
active in the lwIP code at the same time. You should make sure that this
is not the
Bob Brusa wrote:
Hi
I have written a tiny lwip-based server-ap that sends and receives tcp
packages.
When receiving data - how can I find out if this are normal or urgent
data? (or OOB=out of band data, as MS calls them).
Similarely: How can I send a tcp-package with the urg-flag set?
What exactly do you mean with NAT for lwIP? There has been code for
that around and there is a task for this on savannah (task #7506: NAT
support for lwIP). However, I assume both aren't used widely and I do
not know of any example code for it.
For it to work with DHCP, I guess NAT will have
Kieran Mansley wrote:
On Tue, 2009-10-27 at 19:34 +0100, Stephane Lesage wrote:
Hi,
I needed to call netif_set_addr in my OS environnement.
So I added netifapi_netif_set_addr to the netif API.
It can be useful to other users, can someone merge it ?
Could you add this to the lwIP
Lou Cypher wrote:
As well: the example httpd.c in contrib is similarly vulnerable, should be
annotated, just not to forget...
Yeah, that's one of the reasons it is marked as example application for
the lwIP raw api, not as httpd to be used in production environments!
However, I'm still
Jeff Barber wrote:
Now 256 happens to correlate to the size of the Tx and Rx ring buffers
in my driver so that was the obvious place to look. I notice that
sometimes my driver's linkoutput function is being called when its Tx
queue is full. I'm thinking that's the proximate cause of the
Kieran Mansley wrote:
If there's not already a description like the above on the wiki, could
you add one? That reply was an excellent summary.
Done :-) Although I had some problems using that wiki... It's not
exactly intuitive to work with...
___
Jan Wester wrote:
Hi Simon
The latency is not coming from my application. I use exactly the same
application for both versions
Jan, would you mind sending another wireshark trace with WND==2*MSS? I'd
love to see how that looks like (regarding ACK latency and and window
management).
Simon
Kieran Mansley wrote:
Yep, this is the case: the silly window avoidance means we update the
advertised window only when it increases by at least one MSS.
But is that really what we want (an bug free)? If so, we would really
need a compile-time check that TCP_WND is at least 2*TCP_MSS (or
RC stands for Release Candidate, which is a pre-version of a stable
release. However, you got the file names wrong, the files (in correct
timestamp order) are:
lwip-1.3.1.rc1.zip
lwip-1.3.1.rc2.zip
lwip-1.3.1.rc3.zip
lwip-1.3.1.zip
You should always download the latest version, which currently
David Shmelzer wrote:
I'm still confused as to why the the window size is decreasing in the
first place in 1.3.1 and not in 1.3.0. Isn't that causing the silly
window syndrome? The lwIP server is processing the packets immediately
via the callback API so the window should not be decreasing.
David Shmelzer wrote:
Thanks Hans.
I was indeed calling tcp_recvd.
Problem was my TCP_WND == TCP_MSS.
I doubled TCP_WND and it now works.
David, did it totally stop working or was it just slow (high latencies)?
The reason I ask is it could be slow with WND==MSS, but it shouldn't
stop
bobbyb wrote:
It sends 32 packets each with 1500bytes total including all headers. changing
it to PBUF_RAM had no effect :(
Oh, you mean 32 packets? I thought you were talking of 32 bytes per
packet! That's indeed odd. Are you freeing the packets correctly? 32
could be a limitation in
Continuing this on lwip-devel...
Jan Wester wrote:
Hi
I change my WND to 1024 (2*MSS) and now it works
Thanks Simon and Kieran for your help
Kieran, I studied Jans wireshark logs and indeed it looks a little
strange that the window doesn't open unless it reaches 0, although lwIP
was
You should provide a little more information about your application (not
everyone knows the provided iperf application, I guess - at least noe
me!):
- What API are you using (sockets, netconn, raw)?
- If using raw API, which type of pbuf are you using? (For outgoing
data, you should use a
bobbyb wrote:
Iperf is a common application used for testing network bandwidth
(http://en.wikipedia.org/wiki/Iperf for more details). xapp1026 provides a
utxperf which allows you to setup an iperf server which basically just spams
packets as fast as it can to determine maximum bandwidth. This
Fabian Koch wrote:
I'd be glad if you could give me any ideas on how to achieve this
behaviour in another way (and not setting recv_timeo and polling accept!)
In such situations, I guess you'd normally use select to not let the
accept task block in accept. You can then either have select use a
Your conservative approach is the right thing to do since basically,
what you are trying to do is not supported! Calling netconn_close()
while the connection waits in netconn_accept() means you are using one
netconn from two different threads, which is not supported.
Simon
Fabian Koch
I haven't used your compiler, but from what you say, I think you can
leave away the PACK_STRUCT_FIELD() define, since lwIP only uses
completely packed structs, not normal structs with packed members.
Simon
Yann Suisini wrote:
Hello,
I'm trying to compile lwip using Keil ARM compiler but it
Kieran Mansley wrote:
ERR_IF is deemed to be a fatal error: one from which the connection
cannot recover. Clearly in your case this is wrong: unplugging and
replugging the cable is not a permanent state so not a fatal error.
What we probably need to do is split ERR_IF into two: one to describe
Oscar F wrote:
One thing reading the wiki lwip, do you recommend me use the model of
memory MEM_LIBC_MALLOC and forget MEM_SIZE?
As Kieran already said, it is generally a good idea to first get your
application running with the standard options and once that works begin
tweaking it to suit
Bill Auerbach wrote:
I thought I'd ask something that just occurred to me: Can lwIP's
implementation of malloc result in fragmentation of lwIP's heap?
If it can, than a system requiring 24/7 operation would be better off using
lwIP pools since they cannot fragment.
That's why I added the
Yann Suisini wrote:
I want to use the netconn_api for my app , but I have a question :
I need to optimize the bandwith due to high latency connection
(intercontinental) , so I'll send big packets
(about 5KB by 5KB) .
That doesn't result in big packets: the data will be splitted into
multiple
Yes, it does.
Simon
___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users
JM wrote:
What is the proper way to close a connection and free all resources,
namely pbufs, associated with it? In my application, I have to use
tcp_abort to end the connection. (I do indeed have to send a RST;
Winamp does the same thing with streaming audio and I'm emulating that).
I can
Chuck Kuecker wrote:
I've got TCP_WND and TCP_MSS set to 1200. This seems to give the best
communications. Setting TCP_WND 2048 and TCP_MSS to 1500 worked for
TCP_MSS 1460 in conjuction with ethernet is *not* a good idea as it
will result in IP fragmentation! The MTU on ethernet is 1500,
Baptiste Chaboud-crousaz wrote:
I solved my issue by bringing some modifications to my HTTP server: by
now my HTTP server is able to store the received TCP chunks until the
request is complete. Once completed, the request is served.
That's a TODO for the httpd included in lwIP contrib...
JM wrote:
There isn't much out there that describes these settings in good
detail. However, TCP_MSS is simply the maximum amount of data that
lwIP will Rx/Tx per packet. This is data payload only, not including
headers, etc. I believe anything over 1460 is not possible since this
is the
Chuck Kuecker wrote:
No, the LWIP timers are called from the main timer tick, and there are
no other threads. This is how LWIP is set up for the Luminary driver
library I am using, and it has always worked before.
As several users here seem to use the luminary package, can anyone
direct me
Chuck Kuecker wrote:
For what it’s worth, I’ve got TCP_WND and TCP_MSS set to 1200. Other
settings seem to cause resends in the body or at the end of the file
transfer.
Setting TCP_WND and TCP_MSS to the same value is not a good idea if you
want to achieve high throughput as you
Chuck Kuecker wrote:
I’ve tried changing the frequency of LWIP interrupt handler calls,
both greatly slowing and speeding them up, with no apparent change in
behavior.
What exactly do you mean with interrupt handler calls? The timers?
They should *not* be called from an interrupt level:
Chuck Kuecker wrote:
No, the LWIP timers are called from the main timer tick, and there are
no other threads. This is how LWIP is set up for the Luminary driver
library I am using, and it has always worked before.
So lwIP is running in the main thread and the timers are called from
intterupt
Chuck Kuecker wrote
There has to be something different about how I handle TCP reception
in this part of my code as compared to the other section, where I do
TCP reception flawlessly, always. I’ve just got to find it.
You could post your code here if you want. If it's something obvious,
Fabian Koch wrote:
1) Is the mbox implementation supposed to accept NULL as a message?
Yes, it is!
2) Is the change only for correcting the statistics?
Which change? The change in the order of calls? That was to prevent
calling the callback if the mbox didn't accept the message, and it was a
Bill Auerbach wrote:
Why not:
typedef u32_t ip_addr;
What is the point of a single member struct? It forces more typing as well.
[..], but from a
C standpoint, a single member struct makes no sense to me either.
That's what I thought, too: that way, we could also get rid of struct
ip_addr2!
Bill Auerbach schrieb:
I'm being pushy because for me this packing
was one of 3 performance killers.
3? What are the other 2? (Except for the TCP macros I recently checked in)
Simon
___
lwip-users mailing list
lwip-users@nongnu.org
Fixed. Thanks for the report. Aside from me monitoring the list today,
it could well be that such bug reports get lost between all the other
mails on this list, which is why bug reports like this one belong in the
bug tracker at savannah: http://savannah.nongnu.org/bugs/?group=lwip -
log in
Nice idea. A bug or patch entry at savannah makes sure this doesn't get
forgotten. Thanks.
Simon
Chris Strahm wrote:
Perhaps I have missed a function that may already exist, if not I guess this
would be a request for a new feature/function.
When displaying an IP address as a string this
Christian Walter wrote:
- We would need some defragmentation code to handle fragmented UDP and
TCP pakets correctly. This is the most difficult one but is not need by
my customer right now. Still I would like to have the opportunity to add
this later. Are there some design issues I should take
If you have a savannah account, I think you can send a direct mail to
the user that added the patch (bockham)...
Simon
Christian Walter wrote:
Hello,
We are looking for the current version of the lwIP/NAT code in lwIP.
It seems that the modified patch has been deleted accidently on the
I'd like to see that changed, too. Does anyone have anything against
leaving away the LWIP_DEBUGF for MEMP_TCP_PCB, making it a normal,
non-severe message? Since memp_malloc(MEMP_TCP_PCB) is only used (3
times) from tcp_alloc(), I think it's good enough to solve it this way.
The code would be
It all comes down to your code not being the same as the contrib code
(and I guess this cofused me, as you talked about both, and Baptiste
posted his code here about the same time...).
What confused me all the time is that *any* callback gets called *after*
the call to close_conn(), as this
Kieran Mansley wrote:
One thing I noticed was the way it calls tcp_sent() to specify the
callback every time it does a write is harmless but not a good example -
it should only need to be called once to set the callback up.
It does? As I see it, tcp_sent() is only called once - after
Simon Goldschmidt wrote:
In netdb.c I get some warnings for implicit declarations of strlen(),
memcpy() and memset(). This probably could indicate a missing string.h
include.
That could well be as I think the example ports include string.h in their
port-defined cc.h file. Just try to add
lwIP should not have any problems with a timeout of zero. However,
converting timeout valus inside the function sys_arch_mbox_fetch() (like
you did) is not supported and will confuse the stack. This is because of
the way the stack handles timers: it keeps the time until the next timer
expires
Chris Strahm wrote:
As you can see it clears the tcp_sent cb. Yes I agree with you it seems
outright impossible that lwip can still be calling the cb after this has
been cleared, but that's exactly what it does.
Yeah, that's strange. I will have to look into that when I find the time.
Now
I must say I agree to what Jakobs says. I thought the functions
sendto()/recvfrom() were meant exactly for situations like this.
Simon
Jakob Stoklund Olesen wrote:
Kieran Mansley kie...@recoil.org writes:
On Thu, 2009-08-06 at 15:36 -0700, Brian Lam wrote:
I looked into udp.c and
Chris Strahm wrote:
The second is when it receives a packet and it's either not a
GET request, or it's a NULL pbuf. You're almost certainly seeing a NULL
pbuf passed to the receive callback which means that the other end has
closed the connection.
I have not seen a single http_rcve()
Ben Hastings wrote:
On a side note, what happens if the pbuf is freed before the end of the
callback? Does that also free the memory that the address pointer
points to?
That's a good point. Since p-ref is (almost always) == 1 at the point
where the pbuf is passed to the receive callback,
Chris Strahm wrote:
Maybe recursion?
Where is close_conn being called from here?
It comes from my send_data() routine.
Once all of the data to send has been written to tcp_write(),
then close_conn gets called, and send_data() returns.
I scratched my head for a while trying to
Brian Lam wrote:
Oh, I see now. udp_sendto() isn't on the raw API wiki so I didn't know it
existed. Thanks for all your help.
Looks like the wiki is really used, a great thing we have it! :-)
Really, I was thinking of the function lwip_sendto(), which gets defined
to 'sendto()' and is a
Brian Lam wrote:
Oh, I see now. udp_sendto() isn't on the raw API wiki
Updated. Thanks for the info.
so I didn't know it existed.
Looking at the headers is always a good idea, since the wiki is a) not
always up do date and b) (unfortunately) not always complete. Besides,
there's also the
Unfortunately, I think there is currently no way to change this
behaviour when using the socket API. The reason is this:
1) the ACK packet gets sent from the tcpip_thread, when the received
data is put into the mbox.
2) Then there's a thread change to your application thread. After
reading the
From your description, it seems like memory beloging to a packet is
being changed after being delivered to your netif-linkoutput function.
Does your MAC support DMA? If so, make sure the pbufs are freed after
receiving a transmit interrupt for the packet. (pbuf_free(p) then must
*not* be
Did you try the file netdb.h/.c (LWIP_COMPAT_SOCKETS must be set to 1)?
Simon
Mathias Zenger wrote:
Hi,
I am a bit confused! Is DNS supported for the sockets API or not? (Version
1.3.0 stable). First of all I couldn't find the LWIP_DNS definition in
lwipopts.h and secondly I couldn't find
Baptiste Chaboud-crousaz wrote:
Sometimes, the face trouble with my callback http_connect - called by
the macro TCP_EVENT_SENT - because arg is null.
I don't understand that one:
a) there is no function 'http_connect' in the code you posted
b) TCP_EVENT_SENT calls the function set by
JM schrieb:
Now I'm more confused. I found a post by bill, which appears to be
regarding v1.3 who said:
What is your TCP_SND_QUEUELEN? If you tie up all of your pbufs to
send queued packets, you won't have any pbufs left to support
receiving packets.
Is there any truth to this statement
Fabian Koch wrote:
lwip-users-bounces+fabian.koch=de.abb@nongnu.org wrote on
04.08.2009 14:54:29:
No, you're not wrong. Of course the function is not usable from the
netconn thread. However, my proposal is not much different to yours:
having a flag UDP_FLAGS_IS_BROADCAST in the PCB
Fabian Koch wrote:
Big Fat Warning! This is not how it works! You are cleary violating
threading rules here!!! Don't ever access the pcb from a different
thread than the tcpip_thread or you will get random results!
This poses some more questions...
Until now I used:
conn-pcb.tcp-state
Fabian Koch wrote:
No patches necessary there. What else are you missing to use lwIP as is?
Well for example my first mail regarding this. Getting dest-addr up to
the netbuf level. I think SOF_BROADCAST is nice and elegant but I'd
have to mangle a lot with the rest of our system to get that
In 1.3.1, we added the function ip_current_header(), which should give
you everything you need (unless I understood you wrong).
Simon
Fabian Koch wrote:
Hey all,
I still have the Problem that I can't determine a Broadcast on higher
levels (netconn/netbuf), which I need.
I saw the
JM schrieb:
I'm trying to understand all these options in opt.h/lwipopt.h so I can
assign them intelligently instead of guessing and wondering why
communication fails. So, this is what I think is correct; please
correct me if I'm wrong:
In the case of all PBUFs being the same size as
Since version 1.3.0, the memp pool array is calculated dynamically by
some C-preprocessor magic, therefore it's really not easy to match array
entry and memp type. However, using the stats-display function, the code
does this for you.
Regarding the dropped packets: have a look at the other
Setting PBUF_POOL_SIZE *much* lower than 16 is also not a good idea as
this limits the number of RX-packets being processed simultaneously. If
you are low on memory, it's a better idea to decrease the size of each
pbuf in the pool so that, for a big packet, multiple pbufs are used,
while
the_gadfly wrote:
ps: kieran ,simon ,i think i have to use the old version lwip 0.7.1 .because
it's diffcult to me to port 1.3.0to nios .I think it will be ok with
0.7.0 ,couse udp_echo runs ok in my board .
That's sad because now, we cannot help you: chances are very *very* high
you
I also double-checked our httpd_raw in contrib, and it does kill a
TIME_WAIT pcb. However, we might want to get rid of the warning in
memp_malloc somehow because you aren't the first user confused about
this message.
Out of interest, do other httpds work now or our httpd in contrib, or do
Roger Cover wrote:
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.
That's what I thought of. The problem (and why it won't make it into
1.3.1) is that the current message is a generic message
I don't really get which function you are talking about, but if the
input mbox is full (thus a received pbuf cannot be passed from the
driver to lwIP), of course it has to be freed by someone. Normally, the
function passing the pbuf to the mbox would return an error that would
allow the driver
JM wrote:
I had planned on using tcp_poll() to do the periodic buffer checking,
but it's a little slow (500ms). Is it Ok if I instead do this in the
ethernet/periodic interrupt before lwIP runs?
If you mean the big loop before checking the ethernet driver and
feeding packets to the
As I said in my previous post, the netbios code in the contrib module
creates a udp pcb that hooks to the netbios port (don't know right now
which one). Now if a netbios name resolution request is received (these
requests are sent as broadcast) that matches the configured name, it
responds
Changing these defines is generally not a good idea, unless you have
detailed knowledge of what they do in the tcp stack. You might risk
unstable connections on networks which are not 100% safe against packet
loss, and you also might risk interoperability with other network
stacks/devices.
.
Usualy a second atempt (which will use a different return port) will work.
Thanks,
Alain
goldsi...@gmx.de escreveu:
Changing these defines is generally not a good idea, unless you have
detailed knowledge of what they do in the tcp stack. You might risk
unstable connections on networks which
Alexandre Malo wrote:
Hi,
I am looking to stop/start lwip and the physical layer. What Im
trying to do it to be able to change the ip address on runtime without
restarting the uc.
For that, you don't have to stop the physical layer! You will only have
to bring the lwIP netif down,
Oscar F wrote:
Hello everybody, i'm using lwip 1.3.0 port to AVR for using in the
board EVK1100.
Iḿ seeing a example code of tftp, and i don't understand this part,
exactly the part to call the function lwip_select.
Can anybody help me?
and where is the documentation for all API and struct,
at 9:05 PM, goldsi...@gmx.de
mailto:goldsi...@gmx.de goldsi...@gmx.de mailto:goldsi...@gmx.de
wrote:
Oscar F wrote:
Hello everybody, i'm using lwip 1.3.0 port to AVR for using in
the board EVK1100.
Iḿ seeing a example code of tftp, and i don't understand
gregoryhouse wrote:
Hi,
According to a fact that you are attempting to release new version of lwip, I
have some notices.
In my compilation I don't include LWIP_NETIF_API module. Compiler says:
lwip/tcpip.h 'struct netif' declared inside parameter list
because the content of the
Bernhard 'Gustl' Bauer wrote:
Hi,
how does LWIP treat these pings?
Incoming or outgoing? For incoming, IP_REASSEMBLY must be set to 1. For
outgoing, IP_FRAG must be set to 1. If so, the pings should be handled
correctly. If not, some error counter in LWIP_STATS should be increased.
From reading the posts in this thread, this bug comes pretty close
(TCP hangs on MSS pcb-snd_wnd):
http://savannah.nongnu.org/bugs/?25882
Although that was slightly different as the server never announced
enough data, it's kind of related since the stack-internal source of the
problem is
Mandeep Sandhu wrote:
But IP fwding between 2 interfaces is possible w/o any modifications
to the stack...right?
Yes, IP forwarding should without any problems.
For intercepting DNS request, I plan to do the following:
* Implement a very limited DHCP server (one which offers addr
to
gregoryhouse wrote:
Hi,
When using RAW API we can't execute a blocking code in callback functions. But
what does it mean exactly? Can I, for example, execute code that writes data to
external eeprom and then waits 10ms (this will block tcpip_thread for that
time)?
Not blocking the
Timmy Brolin wrote:
The good parts:
2. The scatter-gather DMA is nice if utilized.
Most processors with integrated 100Mbit MAC supports scatter-gather.
Not really a noteworthy feature unless it supports some more advanced
features
Well, I do think simple scatter/gather is a worthy
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
901 - 1000 of 1087 matches
Mail list logo
