Dany Thiffeault wrote:
oh and Simon, another question. I haven't seen anything about this in your
wiki, but are PBUF_POOL_SIZE and PBUF_POOL_BUFSIZE important too?
Oh, then it seems like I forgot those two: PBUF_POOL_SIZE is the number of
PBUF_POOL pbufs, each with a size of PBUF_POOL_BUFSIZE
tes_wzm wrote:
I use lwip+ppp to send data to my tcp server.
When sth occured, I want to close tcp thread. How can I do it? If I kill
this thread through OS, it will leak some memory which use to create
mailbox
and sem. Is't some routes to release this memory?
Shutting down lwIP is not
lwIP + PPP is used.
lwIP has TCPIP thread and PPP thread.
which task needs higher priority?
I'd say PPP needs higher priority as it puts together RX-packets that are
passed to the TCPIP thread (TX-packets are sent from the TCPIP thread
directly). If you give the TCPIP thread a higher
You probably already do this, but if you do not put a connection:close in
the response header and then close the tcp connection, the browser will
consider it an error and retry the call two or three times, even if it
displays your page.
Other things to look out for for these 'dead simple'
Joe Dupre wrote:
I've had this warning since v1.3.1. How can I make it go away?
[..]
opts = (u32_t *)(seg-tcphdr + 1); WARNING: cast increases required
alignment of target type
[..]
This is with arm-elf-gcc (yagarto build 20091018).
If I understand it correctly, the warning is
JM wrote:
[..]
pcb_web = tcp_new();
tcp_bind(pcb_web, IP_ADDR_ANY, 80);
pcb_web = tcp_listen(pcb_web);
tcp_accept(pcb_web, http_accept);
tcp_recv(pcb_web, http_recv);
[..]
Everytime I send data to lwIP, I see a similar output, but http_recv still
doesn't get called. What could I be doing
Sägesser Walter wrote:
I'm trying to get used to lwIP and thus I'm looking for documentation.
What I found so far:
1. A document 'Design and implementation of the lwIP TCP/IP stack' by Adam
Dunkels, which does not seem to be quite up-to-date, however (written
nine years ago). Should this
Kieran Mansley wrote:
2. How unacked-seqno is created? and why sometime this value less
than 0 as
above log?
That looks wrong, it should always be positive as seqno is unsigned.
That's probably just a wrong printf-modifier (%d?) that interprets the seqno as
signed value. I guess in the
Lou Cypher wrote:
The case above isn't always true, in fact it yields false when
pcb-dupacks == 0xFF.
May be that was the intended behavior? Then could have been shorter (and
more
intuitive) checking for
if( pcb-dupacks != 0xFF )
The original check intends to be still valid if the type
Tamas Somogyi wrote:
I'm also interested in the right solution. Currently in my code I modified
etharp_ip_input() and etharp_output() so that it tries to search the
hwaddr by ipaddr in an external lookup table...
Static ARP entries are currently not supported by lwIP. This would be a new
Yigal Hochberg wrote:
The solution is in ethernetif.c code.
I don't find any file called ethernetif.c in the contrib win32 port!
[..]
The contrib/win32 pcap related code cannot be compiled with the latest
pcap.
It does work for me, although my version of pcap is nearly 6 weeks old now...
Yigal Hochberg wrote:
I am trying to make the latest cvs lwip work on w32 platform using
msvc60.
/contrib/ports/win32 already includes a netif driver using packet.lib, it seems
you are using a different netif driver? Unless there's a specific need to do
so, I'd suggest to use the existing
Joe Dupre wrote:
I've created a netconn with a callback, but it appears nothing in the
tcpip_thread does anything to check the interface for them. The tcpip_thread
only waits for a TCPIP_MSG_INPKT message. I see that I can use
tcpip_input() to pass an incomming pbuf to the tcpip_thread.
Joe Dupre wrote:
I have a simple application that sends out a UDP packet every few seconds.
When using the raw API, I created a raw pbuf in ram, filled the payload,
and then had udp_send() send that same pbuf over and over from my lwip
task.
This is only valid when you don't have a
Fabian Koch wrote:
do you have any great ideas/hacks/workarounds to make netconn_connect()
non-blocking?
My idea would be to use CVS HEAD, as I have implemented non-blocking connect
last week. But be warned that there have been *many* changes since 1.3.2 and
just updating the sources won't
Kieran Mansley wrote:
Something that's been in the back of my mind recently is that we should
work on a guide to updating ports from 1.3.2 to 1.4.0 at the same time
as we make the changes to the source. Trying to write this guide just
before 1.4.0 is released will be much harder. So far, as
Sirjee Rooplall wrote:
seen in website:
http://lwip.wikia.com/wiki/Lwipopts.h#Memory_management_.28RAM_usage.29
However I cannot see where these difnes will be used in LWIP port 1.3.0.
There have been a lot of changes since 1.3.0, one of them is moving heap and
memp-pools to user-defined
Sirjee Rooplall wrote
I am using PPP, and at the moment I am trying to track a bug that causes
my
system to crash, and when I stop me debugger it points to the
PPPthreadHandle. The failure seems to occur in the function pppInProc()
everytime.
The change log, does not show any changes
Sirjee Rooplall wrote:
Hi,
The pppMain thread is created as a sys_thread_new in sys_arch.c, from the
ATMEL UC3A port of LWIP.
So I am not sure how the thread will end bby itself.
Normally, a thread function loops endlessly. If such a function returns, the
thread should be terminated
Chen wrote:
Where can I find the bug fix log between my lwIP and the latest rev?
In the file CHANGELOG in the top directory of the ZIP file or CVS checkout.
The current version can be found here:
http://cvs.savannah.gnu.org/viewvc/lwip/CHANGELOG?root=lwipview=markup
However, there have
Kieran Mansley wrote:
It would be very useful to know what change was responsible for this. I
don't recall any modifications since 1.3.2 that would obviously have
this effect.
There have been some (2 I think?) bugs in this area, but I only remember this
one:
Marco Jakobs wrote:
LWIP_ASSERT(tcp_slowtmr: TIME-WAIT pcb-state == TIME-WAIT, pcb-state ==
TIME_WAIT);
That means that one of the PCBs on the TIME-WAIT list is not in state
TIME-WAIT, which is not correct. This could either be a bug in lwIP (state
changed without removing the PCB from this
Sorry for not including the original mail, gmx webmail somehow does not include
your original mail. Maybe you can send a text-only mail next time (i.e. no
html)?
Marco Jakobs wrote:
The problem is not always in the tcp.c, after some more testing i've seen
that i also get i.e. this assert:
Marco Jakobs wrote:
So this means that there *was* a change according the PPP in 1.3.2?
Only some minor ones, but there have been big changes to PPP after 1.3.2 (only
availabl in current CVS HEAD).
You *might* want to try PPP from lates CVS HEAD, but that also involves
some changes to your
Stefano Marini wrote:
I have the following problem with lwip 1.3.2
the etharp_output function report ERR_BUF, when try to answer to an icmp
echo.
what I can see to understand the problem?
Does that happen when icmp.c response the ping or when do it yourself? If
icmp.c did it, either
Bernhard \'Gustl\' Bauer wrote:
Hi,
my pbufs are large enough to contain a complete packet, so pbuf chains
should not occur. While hunting an error I discovered a pbuf with these
settings:
pbuf-next!=NULL
pbuf-len = 568
pbuf-tot_len = 4948
My TCP_MSS is 1460. So 4948 = 3 *
Kieran Mansley wrote:
On Sun, 2010-01-17 at 16:14 -0800, kanprin wrote:
in mem.c line 414:MEM_STATS_DEC_USED(used, (size - newsize));
the decrease shoud be done for the first two cases,but not for the third
one.
so MEM_STATS_DEC_USED(used, (size - newsize)); shoud be pleased at line
You're using an old version, added an extra sleep and violate api layering. Any
reasons for that? ;-)
Sirjee Rooplall wrote:
Hi, I am using lwip 1.2.0 under freeRTOS, I am also using PPP + external
modem to establish a PPP connection to a server over GPRS.
Using such an old version is not
Sirjee Rooplall wrote:
Hi Simon,
I am new to LWIP, so I copied that code from an example I have seen.
Well, then be so kind and tell the author of that example that it is really a
very bad one!
I removed the sleep and I have removed the access to the internal pcb, and
only rely on the
Ethernet is normally limited to 1500 bytes of payload (starting at the IP
header). To send bigger frames, your netif driver has to support this. I think
the defines below should then be enough, although TCP limits the size of sent
frames to the MSS received by the remote side (included as
p == NULL is perfectly normal and tells your application that the remote side
has sent a FIN. However, this should not lead to memory- or pbuf leaks... I'll
see if I can reproduce that.
Simon
Bernhard \'Gustl\' Bauer wrote:
goldsi...@gmx.de schrieb:
tcp_abort currently shouldn't be used
Mathias Zenger wrote:
I would like to write an ethernet boot loader for my embedded system. A
small TFTP client shall be part of the bootloader. The client shall be
based
on the raw API (code size is critical). Can somebody explain me which bare
parts from lwIP (or perhaps uIP) I shall use
Bernhard \'Gustl\' Bauer wrote:
I just checked the status of my LWIP 1.3.0 and it says:
MEM_HEAP
avail: 8192
used: 59408
max: 63492
err: 0
How can more heap memory be used than is available?
Since those values are in the range of MAX_U16, I guess the calculation is
wrong somewhere
2. Keep Rx and Tx threads locked and waiting on a select running in
another thread (in essence adding the locking mechanism that lwIP does
not support)
The idea is good, but it's not what lwIP doesn't support, since you don't get
full duplex but mutual exclusion for read write. Full duplex
Yoav Nissim wrote:
Simon,
Is the half duplex limitation only a socket implementation issue? other
than the missing locks, what else is missing? using the netconn API
seems to result in the same problem.
Well, the problem really lies in the netconn API (and the sockets API is
implemented by
Jonathan Ross wrote:
[..]
Did I do something wrong?
Unfortunately, I can't help you much there, as I don't really use IGMP...
However, your code does seem correct. Do other packets have trailing zeros?
What does wireshark say to those zeros?
[..]
Also, xemac_add calls netif_add, and
Ehrm, sending this once is enough ;-)
From this lwIP init,
/*!
* \brief start lwIP layer.
*/
static void prvlwIPInit( void )
{
sys_sem_t sem;
sem = sys_sem_new(0); // Create a new semaphore.
tcpip_init(tcpip_init_done, sem);
sys_sem_wait(sem);// Block until the lwIP
Marco Jakobs wrote:
But i have to also get rid of the RAW stuff, because i want to do some
changes concerning NAT support ...
And NAT support can't be used with the raw API? I'd be surprised about that...
Although I haven't used NAT for lwIP yet.
And relating to this, my question to you
pragnesh patel wrote:
There is only one connection. As I understand, the crash inside
tcp_enqueue() may be because of two threads (one from incoming request through
tcp_in.c) and other outgoing request) and needs protection. But as newcomer to
lwip world, I don't know where to protect.
Take
In summary, this still doesn't affect my earlier comments - the PPP code
will work fine with pbuf size less than MTU.
The only code that may have problems with pbuf size less than MTU are
applications or Ethernet drivers which aren't prepared to deal with chains
of pbufs.
I didn't want to
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
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
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
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.
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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).
- 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
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
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
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
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
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,
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
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
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
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
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
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
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
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().
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
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
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
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
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
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
801 - 900 of 940 matches
Mail list logo
