I sent my response before you answered to Simon, so I couldn't know your
problem was in the output path without violating causality. I think some
states penalize that... ;^)
When the stack needs to send a frame, it will call netif->output. That
pointer is usually setup at the init function
> Oh, right. You see, I don't really follow the wiki... Wikia has way
too much advertising.
AdBlock Plus rules!
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
> psNetif->linkoutput = tivaif_transmit;
> If i check the tivaif_transmit function, "tivaif_transmit(struct
> netif *psNetif, struct pbuf *p)" it maps the pbuf to the MAC
> controller for transmission. It is this buffer that needs to be
> modified for LLDP frame.
Not exactly. You need to
I saw this
> fail ,including tcp client which is an independent thread )
and then
> *Testing Conditions*
> Lwip 1.4.1 , web server is based on example of ‘httpserver_raw’,
> that means the web server is inside the tcpip_thread rather than an
> independent thread.
All lwIP RAW API functions
It shouldn't
Check your code against the docs or the wiki
http://lwip.wikia.com/wiki/Raw/UDP
My code is something like:
mypcb = udp_new() != NULL
DEST_IP();
// for SPECIFIC other end IP address
udp_connect(mypcb, , DEST_PORT) == ERR_OK
// otherwise, to connect to anyone
DEST_IP();
Sorry about that, it is a private wrapper using IP4_ADDR to set
destination to my lab peecee. oops, my mistake.
I don't see any errors, do you check return codes (just in case...) ?
Try using IP_ADDR_ANY, we can see why later if it works.
--
Sergio R. Caprile, Human Being
Hi,
I contributed the transport abstraction for the Packet libraries for
MQTT and MQTT-SN in Paho for embedded.
I've been working on the transport for MQTT-SN to use the lwIP RAW API,
which seemed to be working, but I didn't submit them to Paho.
I can post it if you or anyone else are willing
Confusion might arise from the examples in contrib, neither tcpecho_raw
nor smtp do call tcp_output(). Not everyone seems to look at httpd...
nor read the wiki, nor the docs...
___
lwip-users mailing list
lwip-users@nongnu.org
I don't have a clue on the sysbios port nor the time to google it.
Looks like you have a routing problem, a connection problem, a who knows
problem.
arm9emac_rx_callback is clearly not an lwIP callback, you´d better ask
your vendor if you are unsure about that.
If you need further help (and no
Have you actually looked at the ports, particularly the ones for the
architecture you are trying to compile in ?
Please look at the contrib tree, in the win32 directory for ideas on
what to do on windoze, I guess that by "visual studio 2010" you mean you
are trying to compile lwIP under
In short, the latest git head will give you many bug fixes, a working
PPP, IPv6, beter SNMP, and maybe some yet-to-be-found new bugs.
The UPGRADING file is yet to be updated, and I didn't upgrade myself to
comment on that. As I've been following the posts in the devel list, I
expect differences
Hi Sandra,
I wrote a driver following the ethernetif skeleton and a NO_SYS=1 port
for Cortex-M3.
Can you please compare that with what you have and mark the conceptual
differences where you are in doubt ? I'm too busy/lazy to look at the
entire port, and those functions you mention do not
> 2.we did post the capture files “wireshark.pcapng” ,which is just
> above the snapshots.
Not in this list, maybe in nabble, but many of us don't use nabble.
I would try the server alone, you might have some task leaking.
___
lwip-users mailing list
... and by looking at your capture file I discover you might not be just
"using the web server"...
You are serving XML files.
I tend to think that means those are not static files, I may infer that
you are generating those pages dinamically. So:
- Are you serving static XML pages ? I don't
It shouldn't, but your piece of code is too extense.
Try to reduce it to something simple and not related to other modules,
like sending "The quick brown fox jumps over the lazy dog" or something
like that.
Check you don't inadvertently call tcp_close() somewhere. The connection
is closing
Hi there,
here I am with this chinese module having linkable libraries for the
link layer driver (no source) and an (I think) netconn-like layer over
RAW API (yes source), developed for lwIP 1.4.0RC2. Introducing ESP8266.
Let's say I want to move to 1.4.1 or even 2.0.0
For 2.0.0, I think that
Thank you very much guys, probably next weeks I'll give 1.4.0 -> 1.4.1 a
try, spare time permitting.
Will keep you posted.
Next attempt will probably be 1.4.1 -> 2.0.0, at least a compile test to
list the ABI issues to be resolved for case evaluation.
It's going to be IPv4-only for now.
Next
> 1. We got the web server original code from STM32 provided example
> "LwIP_HTTP_Server_Raw" , but also mixed with 1.4.1 contrib, which are
> quite the same.
Then go to ST, "mixed" and "quite the same" is not the thoroughly tested
server in the contrib tree. It is your code, your
Please search the list,
read the wiki,
http://lwip.wikia.com/wiki/Raw/TCP
and or go to this recent msg
http://lists.nongnu.org/archive/html/lwip-users/2016-08/msg00063.html
there you'll see a working way to interact with TCP.
You can also check the code in the web server and the
I don't follow your logic, and don't have the time to sort it out. Sorry.
You have a server.
A server receives a request on the rx path, on an rx frame. I wouldn't
process that on a poll callback, which is called at fixed intervals.
Then the server tries to send something back, and it may have
I've just read the brand new shiny 2.0.0 docs, and tcp_accepted() has
been put to sleep, six feet under, pushing up the daisies.
Mi example TCP server code does this:
static err_t myconnected(void *arg, struct tcp_pcb* pcb, err_t err)
{
if(err == ERR_OK){
Great!
The text in
http://www.nongnu.org/lwip/2_0_0/raw_api.html
still references tcp_accepted(), which has been removed
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Hi,
there is no POST capable browser in 1.4.1; whose code are you using ?
You can try my web server if you please (lookup lwHTTPd in this list or
google it/me), however, I don't think your are chasing the bug in the
proper way.
Your browser should not crash... the server should not care about the
Well, that looks like the usual vendor "features" for that particular
vendor. I don't have a full duplex mode nor a loopback of sent packages
in my controller chip and I'm happy using lwIP with my driver.
I think lwIP doesn't even think the driver would dare to send back a
sent package; but I
1.4.0 -> 1.4.1 required the addition of the ip_info structure, which had
been deprecated. I could do that on user files, the module manufacturer
used that structure for internal stuff. Everything compiled
straightforward once I copied the sys_now() from their version of sys.h...
My journey
I would #define fixed fields in the lldp.h equivalent and #ifndef
#define the user modifiable values in a lldpopts.h file. However, I'm
just as a user as you are; Simon is THE man here ;^)
___
lwip-users mailing list
lwip-users@nongnu.org
Can you please write down all involved IP addresses and MACs and attach
a wireshark capture file ? And the lwIP version, and where did you get
it from.
___
lwip-users mailing list
lwip-users@nongnu.org
I bet your driver is missing frames by letting them sleeping inside the
chip as many do, but you have a lot of unknown variables.
Is there any other traffic in your network ?
Is the TCP app running while you ping your hardware ?
Did you try the same with a known good application like the
http://lwip.wikia.com/wiki/Writing_a_device_driver
You have to peek in your driver when it calls netif->input
(function pointer passed on netif add)
Wether you call ethernet_input or ip_input depends on your driver: the
flags it sets, it removes link layer info or not. Common behavior for
You either start the netif yourself with a valid address, or let dhcp do
that for you.
if(usedhcp){
dhcp_start();
} else {
netif_set_up();
}
However, I guess you shouldn't get assertions. Anyway, try it and let us
know.
Please give details about your port and where did
Oops...
http://www.nongnu.org/lwip/2_0_0/upgrading.html
* Changed netif "up" flag handling to be an administrative flag (as
opposed to the previous meaning of "ip4-address-valid", a netif will now
not be used for transmission if not up) -> even a DHCP netif has to be
set "up" before starting
TCP/IP stack in ESP8266 is a heavily modified development branch between
1.4.0 and 1.4.1 stable versions.
The non-OS usage of this little beast requires releasing cpu quite
frequently for wifi duties, so they require using os_ versions of the
standard C library functions. Don't know how
OK...
you are using some vendor port for some device.
You have to check on your vendor's forums for the intricacies of
debugging your particular device. I could help with some ARMs and there
surely are some other guys knowing other processors here, but this is
not the right place for that.
This is getting off-topic for the list, if you need further info please
feel free to write a personal message.
The company I work for resells Espressif chips/modules, they are focused
on ESP32 right now, I don't think they will work on the 8266, but you
never can tell.
I found what I think
Nope, the difference will be preserved by type promotion, unless the
wrap around occurs more than once between calls or the counter counted
more than half length counts (which also includes the former...).
Are you calling frequently enough sys_check_timeouts() ?
You should (read 'must').
Thanks for the update, vendors are really thriving these days.
And to answer your question (sorry I'm late, but I was not checking the
list these days), assertions usually mean something has gone out of
bounds. In this case, it is informing you that a function was trying to
free an already
What your vendor offers belongs to your vendor, you should ask them for
support.
lwIP has several APIs, most of us can only help at the API level;
although if you are lucky you'll find a fellow advocate who can guide
you through your vendor nightmare. I still think your vendor's forums
are a
The crashes are your responsibility. Or your vendor's...
If you clearly indicate which API are you using and how you use the
stack, someone here might guide you.
The dup acks are indicating your lwIP is not seeing some expected
frames. This is usually a driver fault. Most common culprit is that
I assume you already checked as Dirk's suggestion. If in doubt, please
post your lwip initialization code. From your description I assume your
netif sort of works, so:
Did you happen to try pinging ? First local, then routed.
Did you correctly set the networks ?
It might have worked by chance
1.4.0 -> 1.4.1 required the addition of the ip_info structure, which had
That's not an lwIP structure: I've never heard of that name.
Oh, the vendor had put that into ip_addr.h
Heavily modified... even more than I thought.
___
lwip-users mailing
> My question. Is it the lwip Netconn FreeRTOs demo poorly made?
> Is it the netconn API that has problem?
Ehmmm... I don't think anyone of us helping here, or the developers,
would think we are devoting our time to something not working as
expected... that is for lwIP code.
As for the vendor
Hi Noam,
the OP seems to be using lwIP's web server.
From what I've seen, the connection gets closed, and tens of
connections later the web server starts resending TCP stuff like data
and ACKs. It looks like trashed TCP memory or a queue somewhere.
I would start by checking that the ethernet driver works, the port
works, take a known to work application and make sure that everything
works.
If errors arise here, it is quite possible that either the driver is
buggy or the port is buggy. All calls to low-level functions must be in
the same
I vote for sharing.
Perhaps you could write a patch or give an example and us interested
users can also help ?
What about the API ? I guess there is the need for a new function that
returns the number of available responses and provides a means to
retrieve them either one by one or all at
You should not free the pcb in the error callback, it does not get a pcb
as a parameter (unless you provide it). It is intended for you to free
your resources (if any).
Some people advocate for the check your goesintos mantra.
I personally prefer smaller and tighter code.
There is a nice
You have to correctly set your checksum options according to your
hardware checksum capabilities.
Setting all 1 or all 0 is not correct per se.
Ethernet hardware is also capable of generating IP checksums, TCP
checksums, UDP checksums, all of them, some of them, none of them.
Check your
Your picture of the threads running suggests you are using some form of
an OS... have you tested the port with a known good application so you
know for sure that everything is running fine ?
If so, in what part of memp_overflow_check_element_overflow() you see
the loop and how is it occurring
> I am developing an embedded web server using lwip.
[...]
> When the server is live and running, when multiple number of PCs’
> give web requests, server fails to respond.
> Is their any solutions for fix this problem?
yes, fix your web server... ;^)
Are we understanding each other ? I mean,
Netconn has more overhead than the RAW API. In scenarios where the eth
pipe is faster than the micro, this extra overhead means extra latency
and so less thruput.
However, 2 seconds rtt is, how can I say it, a bit way too much ?
Having "problems" with more than 128 bytes per message is another
> I wrote the bridging part and for testing purposes I didn't implement
> buffer to TCP to serial. So Some while receiving data some data piles
> up in somewhere in tcp thread (I think).
No, don't "think", debug, do know exactly where you have your problem,
because it is not lwIP, it is you,
Data size can't be 2MB/s, by data size I mean the size of the data
chunks you are handling in each frame, you expect to handle an amount of
data in a period of time, and that data is handled in pieces, if pieces
are too short you need to handle many pieces, if pieces are too long,
you need
The amount of memory used depends on your application. There is no
reason to queue UDP datagrams unless you don't get them as they come.
API ?
NO_SYS ?
port ? layer-2 driver ?
data size ?
stats ?
frames per second ?
memory usage ?
app details ?
If you are expecting high-performance, you should
I see what you mean.
I also see that the 1.2.0 version sent content-length=0 and the 1.4.1
version sends content-length=115
IIRC, this is not unusual, lwIP might be indicating that there is still
data to be sent. Is it possible that you left some data in the buffer ?
Thank you very much indeed
Perhaps if you explain which API you use, and how you use it, and attach
a wireshark capture file, who knows, maybe.
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
> When it comes to layer-2 driver, it is a driver provided by Xilinx,
> so I guess that problem couldn't be there.
Ha ha, nice joke! Do you have more like this one ? ;^)
Sorry, I can't help further. You should read the wiki and take some
training on embedded systems debugging.
Hi Noam,
I was about to say you could sniff how windows 7+ does it; but I don't
think they would do it in an elegant, not even standard, way... ;^)
I don't know if I get the whole picture, but I bet your problem is an
"application ping". Do you actually need to know link is present or
My suggestions:
don't send pictures, post capture files
explain who is the server and who is the client
define "packet is lost", it is not normal to lose "packets"; what is
your problem: frames getting lost or the retransmission time ? I bet the
first one.
explain the scenario in which you are
It is not that it wasn't clear before, it is that I did not
understand... ;^)
I do now.
If there is a better way, I don't see it.
I think your solution is preferable over toying with DHCP or ping
flooding a router.
___
lwip-users mailing list
* @return ERR_OK if data was sent, any other err_t on error
*/
err_t
netconn_sendto(struct netconn *conn, struct netbuf *buf, ip_addr_t
*addr, u16_t port)
Instead of tuning UDP, I think you should first try checking return
codes to see if datagrams are being sent or what.
Maybe (just maybe)
> Great work. Need to find the time to move from 1.41 to 2.0 J
Same here.
Congrats to all the team, you guys rule!
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
> package loss is < 1%.
anything above absolute zero is no good, indicating a problem in your
system.
I would accept that some frames might get corrupted in the wire... of
course...
> I thought someone had experienced same issues.
lwIP problems, when properly reported, are found and fixed.
If you run a un*x flavor, you can have a fresh 1.4.1 tree and your
modified tree, and run a simple 'diff -pu -r fresh mod >lldp.patch'
standing at the parent for both trees.
A readme will be nice in case the developers decide not to include it as
built-in and there is 'user installation' needed
There are docs you should (must) read.
They are in the distribution itself.
There is a wiki you should read.
http://lwip.wikia.com/wiki/LwIP_Wiki
If I understand what I think you are asking:
lwIP is a TCP/IP stack, layer-2 frames are responsability of the
hardware and a user piece of code, the
It depends on what you actually do when you "use" the sockets.
If you trust your port and driver, then debug your app and do a traffic
capture. Is it possible your app is starving the lwIP task as Noam
suggests ? Where do your messages get lost ? Are they in the wire ? Do
they enter the lwIP
I'm intrigued by your use of the word "other" when referring to
interrupts...
If you are properly using lwIP RAW API, then you should NOT be using
interrupts. Maybe your driver, but it won't call any lwIP low-level
function. Will it ? That would be bad...
> NOTE 1: It is not ideal but I don't
Too much code, I won't look at it.
From the wiki:
http://lwip.wikia.com/wiki/Raw/TCP
"The function may return ERR_MEM if no memory was available for closing
the connection. If so, the application should wait and try again either
by using the acknowledgment callback or the polling
You should probably get some ideas if you run a sniffer, as I would
probably too if I see your capture file.
As a first guess, I bet you are losing frames in your driver. You should
first run an application you know it works (like the ones in "apps" or
in the "contrib" tree) before diving into
I suggest you check here and on the developers list, there's been a
thread on using those libraries some time ago
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Maybe it is just me, but I can't access your link.
Can you post the wireshark capture ?
Also, can you please describe exactly what you are doing and in which
environment ? lwIP 1.4.1 has 3 different APIs, you might or not have an
RTOS, you might be not paying attention to single-threading rules
Your "HTTP example for the SAM4E xplained pro board" has a layer-2
driver for the Ethernet controller, a port for the environment (be it
bare metal or OS: NO_SYS=?), the lwIP stack (version ?), the httpd
server (RAW API or netconn, is it lwIP's ?), the example itself (which
should be a safe
It is not a matter of "compatibility" but doing things right or wrong,
you either do things the right way or you violate the rules of your
working environment.
If you are suspicious on printf(), then don't use it, your port should
have the correct output function and you should be able to ask
I missed your other post,
You shouldn't have threading issues with netconn, however, these can be
at a lower level, check how frames are dispatched, all calls to
low-level functions must be on the same thread (unless you clearly know
what you are doing)
Furthermore, now you say you are
I see your out-of-order friend in frame #11 looks very much like frame
#8 revisited. I would say that is a DMA driver glitch (are you using DMA
?), however, the IP ID field is different, so it looks more like a
resend, due to frame #9 being internally lost; however, this does not
look
> Sergio, can you just explain what you mean by third sentence, how can
> I check all those things (port, driver) and what is known-to-work app?
lwIP is not and end-user full contained product, it starts at layer-3
(IP) and runs on some hardware, it has been ported to that hardware.
Your
Depending on where you are, and what you use, you might find the
outdated doc directory inside the main release file and the contrib tree
examples in the contrib release file, enough. That covers 1.4.1
The git repository has its doc files updated, plus some Doxygen
embellishment:
OK...
your signals "seem reasonable"... that is layer-1, lwIP starts at layer-3.
Do you know if your messages actually go out of your hardware ?
Have you tried sniffing with wireshark ?
Above your hardware there is:
Your driver, the layer-2 code, in lwIP terms: "the netif". This has been
written
Keep in mind the 'lw' in 'lwIP' stands for 'lightweight'.
I guess you are thinking in terms of the socket API, but lwIP can run
without an OS; it is more suited to a small embedded system than a
computer. In this context, you use the RAW API, which is event driven.
I guess you can benefit from
> (Oh, and I guess this would be what Sergio would say, too, only I try
> to say it less "rude" ;-) Nevertheless, the advice stays the same)
You got me... ;^)
___
lwip-users mailing list
lwip-users@nongnu.org
Someone designed that hardware, wrote a driver to configure that
Ethernet chip, and some SPI stuff to send that config to that chip.
Then, someone wrote a driver and probably someone else a port so lwIP
could talk to that chip and work on that hardware.
You should ask them. If you see the frame
I can tell you two things:
You can't really take a low-level driver for version x and dump it into
version y without hassle. It should work, but you also should read the
docs because there can always be, and there have been, changes.
There is some slight difference with the way 2.0.0 handles
You make capture files smaller by capturing at the right time and
enabling only the hosts/ports you need to see.
You understand TCP by reading Stallings, Comer, Tanenbaum... ;^) The
amount of data sent by a TCP stack is what it thinks best for the
current scenario, given its configuration. It
Your sequence number is jumping backwards.
Most common causes are either one of your apps is trashing memory of you
have a bad DMA driver.
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
There is a nice FTP client library (RAW API) here:
https://github.com/gezedo/lwftp
Laurent, the author, can probably be found lurking around here.
I contributed the data handler code, which also managed to find its way
into the SMTP client, so you'll find a similar API to apps in the
contrib
杨辉, 你好
this has been (sort of) asked some months ago, maybe the answr is still
the same one:
http://lists.nongnu.org/archive/html/lwip-users/2016-05/msg00125.html
___
lwip-users mailing list
lwip-users@nongnu.org
I guess lwIP could get a hint and recover (quite) faster if it got RST
for response instead of silence. Try without the firewall in between.
Nevertherless, can you please post a capture file so we can get the
whole picture ? I think you have a memory hog problem and you need to
detect/recover
You seem to have many thinks mixed up, and a lot of documents to read.
Your application will depend on three software players:
- the TCP/IP stack: lwIP
- Here, on this list, after you read all the documentation and have
something to ask which is a bit more specific than "how do I get my work
Imagine your image data is 3MB. Would you expect lwIP to buffer that on
a 32KB microcontroller ? No, would you ?
Right, that is, light-weight IP.
The server will send bytes as it wants.
TCP will send bytes as it wants.
They will be put in IP and sent via Ethernet
Each frame gets IP extracted,
As long as you have the memory and CPU resources, you can have an RTOS
and as many threads as you can, with all the apps you need. lwIP main
core and RAW API apps will run on a thread, other apps with their
netconn/socket APIs on their respective threads.
The point is... do you actually
A pbuf can be a single one or a chain of them, and your app gets what
the rx driver got, so most likely you can't tell in advance and have to
be prepared to just deal with it.
If you can spare the memory, you can copy to a buffer and be happy. But
if you can't spare it, there are pbuf_
It is not a matter of possible/impossible, but how much are you willing
to thrive to do it.
Unless you do it yourself from the RFCs, you'll work with already made
parts, which most probably have been written for a socket(-like) API,
most probably on a non event-driven way.
You'll find some
All you need is in the other apps, and the RFCs (for the telnet protocol...)
Once you get a pbuf, you basically get the data by reading each pbuf in
the chain, though there is a function to do that.
The easy way:
pbuf_copy_partial(p, buffer, p->tot_len, 0);
The hard, instructional
I can think of:
- your driver
- your FreeRTOS priorities/loop (aka your port)
- your application not freeing PBUFs properly
- not enough PBUFs
TCP buffers data when you call tcp_write() and sends when you call
tcp_output(). If you follow the code with a debugger you can get up to
the point
> I recall having seen an asian SDIO module, but I can't remember the part
> number.
Found it:
WF111 from BlueGiga, now Silicon Labs.
Atmel has a module series too, but I personally don't like Microship.
Murata is also building a number of modules, some based on the Cypress
(formerly Broadcomm)
Without a _small_ and clear example (I won't browse your entire code)
and a proper capture file I can't help you further. Perhaps someone else
jumps in.
___
lwip-users mailing list
lwip-users@nongnu.org
Not "probably" ;^) Effectively tcp_sent() is called when an ACK arrives.
That is what the docs say and how TCP works.
No need to do it timely, though.
Perhaps the idea is something like this:
Oh, I need to send something now.
Is there any room ?
Yes -> Fill as much buffer as I can
I've been searching for something like that for some time.
Most wifi modules have their own TCP/IP stack because they already have
horsepower and intelligence to support WPA.
We embedded developers would want to have our applications written once
for lwIP and peruse them either on Ethernet or
Have you read the docs ? the wiki ?
you can pump into the buffer as much as it fits into the buffer.
TCP can send as much as its window allows, and will certainly need ACKs
to keep sending thereafter.
http://lwip.wikia.com/wiki/Raw/TCP
--
Sergio R. Caprile, Human Being, Bs.As., Argentina
You could check how the httpd app does.
What I usually do is have a state variable shared among all the
callbacks, so the application can know what is the state of the connection.
___
lwip-users mailing list
lwip-users@nongnu.org
According to major communications texts authors, due to parallel paths
and some esoteric magic, some data might be in transit when you close a
TCP connection. IIRC it is mandatory that it remains that way after closure.
There is a thread on this list where Simon answered (sort of) your question
You need to read about two things. Perhaps three.
One is TCP, and connection oriented protocols. Before sending you need
to establish a connection, you can't send to iwishsomeoneisthere like
UDP, which is a connection-less protocol. TCP is just like a phone call
before voice mail was invented.
301 - 400 of 533 matches
Mail list logo
