Update of task #1551 (project lwip):
Percent Complete: Any = 0%
___
Follow-up Comment #2:
Can someone comment on this? Does it make sense to make ARP independent of
ethernet?
Personally,
Why not close the listening pcb in your accept function? And then set
it up again after closing the other connection (tcp_err gets called
if you don't close it yourself).
Hi,
Except set MEMP_NUM_TCP_PCB=1 in your lwipopts.h, I don't think
there is a way to do that with tcp_listen. Even
The simple answer is the lwIP core is not protected from concurrent
access, which means you must take care yourself that the stack is not
accessed from different contexts (as you explained) at the same time.
Unfortunately, this means what you are trying to do will not work
with the current
Am 25.10.2007 um 17:21 schrieb Siva Velusamy:
The solution of this problem, once found was simply to add
SYS_ARCH_PROTECT protection mechanism as an alternative to
sys_sem_xxx function already present. The generic form is :
#if SYS_LIGHTWEIGHT_PROT
SYS_ARCH_PROTECT(level)
#else
Am 31.10.2007 um 21:23 schrieb Ivan Delamer:
...
Now, I have two questions/concerns:
1) do I have to manually free/delete the netbuf? I read the source
code for netconn_recv and I see a buf = memp_malloc(MEMP_NETBUF)
but no free in the examples.
Yes, look at sockets.c, lwip_recv()
Am 09.11.2007 um 16:18 schrieb Jonathan Larmour:
Paul Andrews wrote:
What happens is lwip will connect to a server, exchange some data
then
the server will send a FIN ACK. However, when lwip ACKs this, the seq
number is not incremented. After this, it's a whole lot of FIN ACKs
going back
Hi,
don't really need to simulate this, it's really a silly bug (and
rather simple to solve, I think).
I'll work on it. Thanks for finding it, Thomas!
Simon
Am 10.11.2007 um 09:36 schrieb Frédéric BERNON:
Simon,
I think you can be interrested, so, if you want to simulate the
problem
I really don't know the VSDP++ port of lwIP or which version of lwIP
they are using, but it sounds like a threading issue: your
application thread talks to the lwIP core using mailboxes. If one of
that mailboxes is full (which it never should), your application
thread might be waiting
The check framework supports forking every test case, which means that
while(1) loops and segfaults wont stop running all tests. Forking can
also be turned off for debugging. With forking turned off it may even
be possible to run tests on target for some OSes.
Does it really work on cygwin if
I’m seeing an odd problem with lwip (1.2) in which the system uses DHCP
and
gets an IP, and then it will respond to ARP queries from my laptop running
netcat, but it fails to respond to other ARP queries. The only difference
that I can see in Wireshark ( other than the source IP of course )
I have posted this message two days before but it was not yet accepted for
more than a day,so only i am sending again
kindly make my subscription valid so that my posts will be accepted by
other members
Well, it seems like you didn't only send again once :-) Your mails have been
sent
hi
any one know how to port lwip 1.1.0 in visual c/c++ 6.0. that is lwip
for windows in vc++ platform,kindly suggest how to implement the lwip and
sending packets
There is a port of lwIP 1.3.0 for MS visual studio 6.0 in the contrib folder in
CVS. You can download it via anonymous CVS
_will_ crash if there is a single
unaligned access.
Regards,
Timmy Brolin
Simon Goldschmidt wrote:
#define FIELD1(A) (*((short int*)A[0]))
#define FIELD2(A) (*((long*)A[2]))
x=FIELD1(data); /* using field1 */
I don't know how this should help: say A starts at 0x03, then accessing
This issue is win32-port-related: the win32 port in contrib uses the same API
as wireshark to receive and send ethernet packets. It can see all traffic seen
by the windows-internal ethernet adapter, even traffic that is originated by
the PC it runs in. However, to distinguish each lwIP process
Datum: Thu, 10 Jul 2008 09:52:14 +0100
Von: Kieran Mansley [EMAIL PROTECTED]
An: Mailing list for lwIP users lwip-users@nongnu.org
Betreff: Re: [lwip-users] How to build a simple TCP [...]
On Thu, 2008-07-10 at 10:41 +0200, Simon Goldschmidt wrote:
If your PC's MAC address is 01:02:03:04:05:06
I've had a look at the code, and that combination is not supported. You
should see an error like this one when you try and compile it:
../../../../../lwip/src/core/init.c:156:4: #error MEM_USE_POOLS
requires custom pools (MEMP_USE_CUSTOM_POOLS) to be enabled in your
lwipopts.h
I always
From your post it is not clear whether you understood the principle of using
threads with lwIP: the core is not protected against concurrent access,
therefore the RAW api may only be used from one thread at a time, which is the
tcpip_thread (started in tcpip_init) if you use the other APIs.
To me this seems like you send every single pbuf as one ethernet frame. LwIP
can combine multiple pbufs to one ethernet frame, which is done for many tcp
packets: the first pbuf contains all the headers, the second pbuf contains the
'user data' (in your case the HTML page). Your driver should
I don't have any means to read the debug values. When if i enable display
functions, i won't have any means to read it.
Am i sounding confused? All i wish to say is that i don't have means like
JTAG, etc. to read back any thing from my kit.
That's a pity because all you can do then is make
From what he said, it does support structure packing, but still
includes
padding for alignment at the end.
I believe that is not a bug, on the contrary it looks like a bug-fixing.
Let me explain: I use OpenWatcom and the new versions have the padding,
the very old don't. I believe it
The first call to sys_create_thread, will call sys_init if you didn't call
it before!
I works in this way:
- create a first lwip task using sys_create_thread (so, sys_arch_timeout
will be initialized)
- this task will initialize the stack (so, will start tcpip_thread) and
will
start
In the udp_send() of lwip 1.3, when there is not enought space to add an
UDP header, we allocated the pbuf with:
p = pbuf_alloc(PBUF_IP, UDP_HLEN, PBUF_RAM)
This is wrong. A pbuf given to udp_send must be allocated with PBUF_TRANSPORT!
This should look like:
p =
WOW, that's really great! I wouldn't have dreamed of my small comment about the
backup leading to our own wiki-server ;-) Thanks a lot for this!
Unfortunately, I can't help with syncing the stuff over :-(
Simon
http://lwip.baringforge.com/wiki
It's there, but don't have a convenient method
The way I fixed this was to change the helper structure to this...
struct ip_reass_helper {
PACK_STRUCT_FIELD(u16_t start);
PACK_STRUCT_FIELD(struct pbuf *next_pbuf);
PACK_STRUCT_FIELD(u16_t end);
};
If that works for you its OK. But to be more portable, some more defines are
I have looked through all of the files many times. But I think you are
missing the point that I am working on an embedded MCU LPC2468 with
FreeRTOS. There is no Windows, Unix, uLinix, or anything else that
contains
implementation of sys/time.h for me. I have to come up with an
I understand that there are reasons for not supporting non-blocked io, but
are there any plans or work in progress regarding this? Or doesn't the
current infrastructure lend it self to this easily?
This always bugs me, too. Not that I need it right now, but I think this is
still a major
I find the lwIP did not manually init global parameters. In most of the
And it does this on purpose.
system, the global paramter has default zero. But my embeded system only
init the static paramters, and won't init the gloable parameters.
That's a bug in your compiler. We've had this
can i exec a process instead of a thread? and how will syncronization
work b/w processes, if they aren't threads.
Yes, you could execute a process instead of a thread. However you would
then, as you realise, have to re-write the other parts of sys_arch.c to
use inter-process
I don't think the core would have to free anything in the case of the
threaded code. If you are a one machine system, don't actually copy
the data in the mbox_post: Ignore the size.
The sender side stays of course the same, no modifications needed.
If you are a multiprocess machine, you
[..] So, in
this situation, I need to manually check from one machine to another what
is the actual adapter it is using and update the PACKET_LIB_ADAPTER_NR. Do
I really need to do this? Or maybe lwIP supports automatic detection of
which adapter to use? Please advise.
Since I wrote that
Well I used sizeof(string) instead of strlen, but the problem was - I
got only 4 bytes on receiver side. However, whenever I used some
integer :
tcp_write(pcb, test, 1024*1024, 0);
I got the ack that 1024 bytes sent.But could not received by receiver end.
That worked? Very strange, since
tcphdr-wnd = htons(pcb-rcv_ann_wnd) + 1;
I'm not sure, but shouldn't that be
tcphdr-wnd = htons(pcb-rcv_ann_wnd + 1);
or else you would add one to the converted ushort?
Simon
--
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen:
I'm using lwip with FreeRTOS. How can I write a server that accept
connections, but dont disconnect them after transfering data. In other words I
must to have a multiple opened connections waiting for incoming data. Is that
true, that I must to create task for particular connection?
With
Hi,
I am trying to port the lwIP to run on a LPC2468 without OS using
Crossworks. I am a bit lost on how to pass on an incoming packet from
EMAC to ip_input. Has anyone some sample code for the EMAC driver
functions?
Take a look at what the example win32 port (in contrib module) does when
then : Does anyone had already implement a socket API on top of the raw
API (and not the sequential API) ?
Not as far as I know. A version of the socket API without using the netconn API
is planned (though not scheduled), but that would still require an OS (the only
benefit being one API
So all calls to etharp_arp_input are their own critical sections.
Will this avoid the problem of calling into the etharp module from
outside the tcpip_thread context? Other comments welcome.
Definitively not, as ARP is also used for outgoing packets. You should try to
fix the problems you
I just tested my LWIP implementation with pings of several sizes. When I
increase size so much that ping needs 2 packets my application crashes.
Does LWIP 1.3 support pings which need more than one packet?
Yep, it does, via IP fragmentation. To use this without errors, the
configuration
There's a task on savannah on this (#7896 ):
https://savannah.nongnu.org/task/?7896
Basically, the scheme will work on _POOL and _RAM pbufs, but not on _ROM/_REF
pbufs, which is why usage of these types would have to be adjusted (including a
copy-on-delayed-usage flag or something like that).
Things like this are normally better put into a bug report on savannah to
prevent them getting lost between all the other mails on this list.
Sending a segment before it is added to the unacked list may result
a racing problem when it's ack is received before it got added to the
list.
How
Same old story...
Hello
If you in SYS_ARCH_PROTECT save the interrupt flags before you disable the
interrupt and in SYS_ARCH_UNPROTECT restore the interrupt flags,
You can use the functions in ISR
I guess you mean 'pbuf_free' by 'the functions'? If so, I have to dissapoint
you: if you use
tcp_output() actually is the place where the nagle algorithm is implemented!
And no, there is no global option to disable the nagle algorithm.
Simon
Bill,
Thanks for the prompt response. That would make sense to me. Where/how
would I include this in the code? Do you know if there is a way
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 always helpful).
Since you
About performance measurement: I'd be happy to include such applications in the
contrib module - they do have to fulfill our needs though (an active
maintainer, mainly) - and they should have counterparts on some platforms (i.e.
unix/mac/windows) to be able to use them broadly.
Simon
One
I know it sounds repellent, but get a good book on sockets programming and read
about the function 'select()'.
Simon
Hi,
I am using lwIP in context with FreeRTOS and try to write a NTP client. I
have a task which is called fix every 1000 ms. In the task loop I either
send out a UDP
I don't get it: Do you mean your lwIP device has to have 2 IP addresses, or do
you want the device to have 192.168.0.x and accept packets from 192.168.1.x??
Simon
Hi,
I need to sent receive data between 2 different network address. One is
192.168.0.x and another is 192.168.1.x
In
dropping the incoming packet
from
192.168.1.x because they got different network number.
Regards
On Thu, Apr 30, 2009 at 12:01 PM, Simon Goldschmidt
goldsi...@gmx.dewrote:
I don't get it: Do you mean your lwIP device has to have 2 IP addresses,
or
do you want the device to have 192.168.0
While trying to compare the ports (provided in contrib) for unix and
win32, i found that the following files were not present in unix port:
lwippools.h
This file is only needed if mem_malloc uses the memp pools, which is not the
case for the unix port. The win32 port can be set to that
Since lwIP 1.3.0, there is an SNTP client available in the contrib module.
However that one works with sockets only, so you don't get the precise time of
when the response packet was received. To get that, you'd have to parse every
received packet in your ISR (basically, check ethernet, and IP
lwip1.3 I downloaded the contrib files back a couple weeks ago from CVS.
But the ping.c file date was March 23, 2008. I just checked the files
again, and the site still has files from 2008.
That's because it was released with lwIP 1.3.0! If you want never versions you
can a) download them
ps. I think the Netconn API should have a function like select to handle
many connections without need to create separate tasks.
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().
The wiki page is indeed very confusing. I recently added some lines to
rawapi.txt, but that new version is only available through CVS, yet.
The baseline is that what you are doing is not really supported: sockets AND
netconns are not allowed to be shared between multiple threads. This is a
Sounds pretty much like the same like a TCP-to-serial converter I wrote on
lwIP. I did it with the raw API though:
- I have a tcp_recv-callback that waits until a complete packet is received
- then that packet is parsed and sent to the right serial thread (together with
the PCB, for responses)
I didn't want to tell you how to write the serial part, however, the connection
to lwIP stays the same: assemble a packet for serial either in netconn-recv or
raw-API recv-callback and put it on a queue to the correct serial task.
The problem you then have is you need to know the correct pcb
Finally I wrote the server with RAW API and tcpip_callback function. It's
working ok, but there is a one strange thing. Sending reply to the client
takes about 250 - 1000 ms (taken from Wireshark). Sending reply directly
(without tcpip_callback) takes less time (max 2 - 5 ms). Have you got
Hi,
I'm using lwIP and the socket IF. The lwIP 1.3.0 source file ethernetif.c
contains a function low_level_init which initializes some of the netif
flags; but it does not initialize the flag NETIF_FLAG_UP. I can't find
anywhere else in the code where this flag is set. Should this flag
Jeff,
That makes sense to me, I was just a little puzzled by why Lwip doesn't
set NETIF_FLAG_UP with the rest of the flags in low_level_init and why there
is no comment or anything else I can find that indicates that it even needs
to be set. Hence my original question.
You're mixing
I certainly can *not* tell you what the Xinlinx code does, you will have to ask
Xilinx about that, not us! However, maybe there are users reading this list who
can help you, but I wouldn't count on that...
In general, the timer functions for ARP and IP reassembly are there to free
memory by
BTW which checksum algorithm did base your
assembly code on? Does anyone know which of the checksum algorithms is the
fastest?
Unfortunately, that depends largely on your platform. The best thing to do is
to try all of them: call them in a loop on a data buffer that is bigger than
your
If i add pxNetCon-err = ERR_OK; after the do while everything works. It
seems that ERR_TIMEOUT is treated as a fatal error and lwip wont send
anything trough the connection if a timeout occurs.
Which version of lwIP are you using? I just had a look at err.h in CVS and
there, ERR_TIMEOUT is
please attache me in your mailing list
I don't know if you can read this, but as you managed to write a mail to this
list which has been published, it seems like you already managed to subscribe
to this list... ;-)
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt
hi:
this is my code,modified form stand-alone lwip example web server. I am
trying to send messages through UDP. But all it is sending are ARP's.
That's perfectly OK: before the stack can actually send the UDP packet, it has
to know the target MAC address. Since it doesn't know it, yet, ARP
The default values are MEMP_NUM_TCP_PCB = 5 and MEMP_NUM_TCP_PCB_LISTEN
= 8. I wonder why there should be more listening connections
than active connections. Shouldn't the numbers be equal?
They are independent, see below.
I can remember having troubles with low MEMP_NUM_TCP_PCB
At the moment there is only port 80 active. So what about scans to other
ports? Are they left half open or immediately disposed of? I think it
is the later, because after a portscan MEM TCP_PCB max is only 1!
Packets for other ports are rejected right away (you should see a RST being
sent
I use DMA to transfer packets from CS8900 to a RAM buffer. There can be
a problem if the buffer is filled faster than processed by LWIP. I tried
to avoid this by dropping packets that have been already received from
the CS8900. This was disastrous. Nothing worked anymore.
That's strange,
To prepare for the imminent release of lwIP 1.3.1 we have prepared a
release candidate. This is your chance to test that lwIP 1.3.1 works and
get any fixes you need included in the final release. Please test and
report any failures or problems. The code is available via CVS using the
tag
Why do nearly all people on this list seem to use the raw API instead of
netconn or sockets?
Performance-gain? Flexibility?
Maybe the ones using netconn or socket API don't have any problems? :-)
But really, I haven't used the netconn API so far, but the socket API solves
many lwIP-related
If you say PBUF pool is only for incoming packet, then lwip SNMP driver is
in Fault.
I know, there's some 'room for improvement' in the snmp code... In any case
it's a bad example and the pbuf pool really should only be used for incoming
packets right now.
The reason is that *if* outgoing
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 won't help you, either, since that flag is
not added to the netbuf but only stored in the PCB: it might get
- Forward IP packets between interfaces.
lwIP's PPP runs as a netif, of which multiple are supported. Forwarding between
networks (netifs with different network addresses) should be no problem.
- Possibly bound services only to specific interface TCP/UDP
TCP/UDP can bind to 0.0.0.0 to
Baptiste Chaboud-crousaz wrote:
Can you explain me what is the purpose of this function?
The poll function is used for timeout handling. For example, the http
server closes connections that are idle for too long (poll is called
twice without data sent or received in between).
lwIP is very limited in routing. Currently, it can only send one packet on one
interface. I guess the current 'routing' mechanism will return the default
netif as target of a packet with broadcast address.
Simon
Original-Nachricht
Datum: Mon, 10 Aug 2009 12:55:33 +0530
If that's the case, then I think your fix of copying the address out of
the received pbuf is the right thing to do. The only alternative would
be for lwIP to do this operation all the time, when usually it would not
be necessary.
Well, I do think that would be the right thing to do all the
This would probably not be necessary since I only want to use UDP, DHCP,
IGMP and DNS with the socket API in my application. I guess I could set
LWIP_TCP to 0(?)
You could do that, but it's a hint for us to increase the default to 7.
In netdb.c I get some warnings for implicit declarations
Maybe we can collaborate - I did a crude git er done GET and POST
handler
practically hard coded for a demo. I want GET and POST to be able to
reference (easily if possible) C variables - updating on a POST and
returning on a GET.
I thought of something like that, also. The problem is
manually if upgrading is not
an option.
Simon
Hi,
I am using
http://download.savannah.gnu.org/releases-noredirect/lwip/lwip-1.3.1.zip
md5
af8c4bf938e3ca48af3d54e29d57ab54 *ip.c
1a1ec514a862fb1d931f4eb4c236cb21 *pbuf.c
Martin
2009/9/1 Simon Goldschmidt goldsi...@gmx.de:
Which
Also, I see a *huge* difference in performance with packing by 2 versus
1
which we do in many if not all ports.
I find it interesting that this makes a difference.
Why? I think that's pretty good to explain: All the network protocols we use
packing for would require 2-byte-packing only,
Why was this added?
I think I remember this being added to dump packets that are not for us in an
earlier stage as it would be done without this test. The downside of course is
that you don't receive these packets... Seems like the test isn't good enough,
then.
Simon
--
GRATIS für alle
Could you please file a bug report on savannah to make sure this doesn't get
forgotten? I'm currently not in a position to check in code, so it might be
take while...
Simon
All,
Can this particular code section be removed? (this in context of this
thread)
Or at least make it
You should specificaly pay attention to the timers: they are executed within
the semaphore/mbox functions (sys_sem_*/sys_mbox_*) and fetch a list of
timeouts from an arch-dependent function. This list must be per-thread - if
not, timers will be executed in a wrong thread, which may lead to the
On Mon, Sep 7, 2009 at 6:49 PM, Kieran Mansleykie...@recoil.org wrote:
On Mon, 2009-09-07 at 18:05 +0530, Mandeep Sandhu wrote:
Hi All,
I have a question on the function ip_addr_isbroadcast():
Why do we check for destination address even before we've determined
if the network
Please enter bug reports into the bug-tracker on the savannah server to prevent
them getting lost.
Simon
Hi ho,
I gave mem.c my 8KB USB ram for its heap. This sram stands alone in
memory space.
mem.c:mem_init() failed, because it creates a struct mem at the first
address after the
BTW: There is this LWIP_TCPIP_CORE_LOCKING define in opt.h which obviously
should not be used and therefore I did not change the default here... but
to me it sounds as if this could be exactly the thing I'd need here?
It isn't, really. TCPIP_CORE_LOCKING is just an idea for faster throughput
a short question about sys_arch_sem_wait(). When someone is waiting for
it, and it gets an eror/deleted.
Is that a serious condition that shouldn't hapen or should it just return
the usual SYS_ARCH_TIMEOUT?
I don't know what you mean by the semaphore getting an error, but it certainly
So, does implementing this create a way to peek for a message?
No, if there's a message, it is returned, not left in the queue. This is only
for implementing nonblocking recv.
What should I return as the 'timespent' value?
Zero. This might lead to some jitter in the timers if used from
I hadn't considered getting rid of them altogether, but you make a good
case for it. Interestingly, CVS says you added the ERR_IS_FATAL macro
so if you don't understand what they're for, I'm guessing that no one
does!
That was after a discussion with Frédéric, who did not agree that no
I am using lwIP 1.3.0 and it works great, but I've always wondered where
there's an approx. three second delay after the ARP response before lwIP
sends the SYN. In other words:
1. I initiate a TCP connection
2. lwIP sends an ARP request almost immediately
3. The host responds (relatively)
I need confirmation about the lwIP memory use.
The lwIP uses two areas of memory:
- one dedicated to the buffers pbuf and defined by :
PBUF_POOL_SIZE x PBUF_POOL_BUFSIZE
- and one area for the structures (tcp_pcb, udp_pcb) and other
variables which are dynamically allocated, and this area
WND = 512
MSS = 512
Having WND == MSS is generally not a good idea regarding throughput because
that raises problems both with the nagle and delayed ack algorithm. You should
at least make sure the nagle algorithm is turned off when having WND == MSS,
although you can then still have
Is it worth adding a check like other checks that are in lwip_init?
Up to 1.3.0, it seems to have been working with WND == MSS. And although this
is not a good idea regarding performance, there are applications where it makes
sense, e.g. if your system is too slow to receive two segments in a
Hi
It works by setting MSS = 2*WND (the threshold is higher), but it still
decrease the window size and that is wrong, I have also compare it with a
windows machine
Setting the threshold = 0, will not turn off the behavior
Thanks for clarifying this.
Comparing your two wireshark logs, I
I'm a bit confused in regards to using the raw API in a multi-threaded
enviromnent. The current documentation indicates that you can not call the
raw API functions from a context outside of the main lwIP process. Is this
true?
Yes, this is correct and has been since for all the lwIP
That's all true, but David's and Jan's recent problem was that the window was
changed although tcp_recved() was called right away. This is not an
RFC-violating problem but a problem in lwIP (when and how it calculates the
window changes).
However, adding a bug entry for your comments below
Kieran Mansley wrote:
On Wed, 2009-10-21 at 17:04 +0200, goldsi...@gmx.de wrote:
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 only
greater than TCP_MSS?) to prevent problems:
I think a compile
In other words, could memory still be required for data copy that is not
checked by the tcp sndbuf queue space.
Yes. That's because tcp_sndbuf() tests against a counter variable that can be
configured to any size in lwipopts.h. However, the memory needed to enqueue a
segment can be
Steffen wrote:
Thx for your fast answeres ! I don't use an operating system, so i don't
have threads. The target is a PowerPc MPC5567. I call the
SendDiagnoseMessage() function, when results from another Bussystem
are available.
My ETH Controller is in Interrupt mode ! When calling the
Under special circumstances I need to transfer about 500kB of data from
lwip to a browser. To do this I borrow some memory from another task.
After the data is transfered I need to clear the borrowed memory and
return it to the other task.
I tried using tcp_sent() to trigger this.
gu...@quantec.de wrote:
[..]
I'm not sure if the http_sent of version 1.3.0 is correct. It tries to
close the connection before all data is ACKed.
Closing the connection before all data is ACKed should be OK: closing is only
enqueueing a FIN segment, which will get ACKed, too. The trick is
Did you read Kieran's response to your mail yesterday?
I also doubt the changes are correct and find it quite strange that it makes
things better, not worse.
Simon
Hervé GARAT : Audemat ga...@worldcastsystems.com wrote:
Hi All,
I use the last CVS Head LWIP on LPC2468 with FreeRTOS. My
Just sending a post a second time is normally not a way to attract much
attention...
Hervé GARAT : Audemat wrote:
Kieran said:
No, that's wrong. p-len refers to the length of each individual pbuf.
We've added another pbuf to the chain, but not changed the length of
each pbuf. Because
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 (as it is ported
from sources that don't know pbufs) needs the input packets in contigouous
memory and copies from
1 - 100 of 940 matches
Mail list logo
