Hi everyone,
I rewrote the SHTML parser inside the httpdserver_raw project, and I
wonder if there is anyone interested in testing it in real-life situations.
All you would need to do is replace your contrib/apps/httpserver_raw
files and probably some slight mods to your tag handling routines, as
Get and install wireshark
Capture the traffic
Look for any unusual TCP stuff (retransmissions, etc)
Look for dead times
Move a pin on your routines entry point
Watch those pins toggling on an oscilloscope.
Compare what you see in the scope with the wireshark capture
If you
Get and install wireshark
Capture the traffic
Look for any unusual TCP stuff (retransmissions, etc)
Look for dead times
Move a pin on your routines entry point
Watch those pins toggling on an oscilloscope.
Compare what you see in the scope with the wireshark capture
If you
For anyone interested, the modified package lies here:
http://scaprile.ldir.com.ar/cms/category/os/lwhttpd/
Regards
--
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Hi Julien.
Yes, there is a TCP retransmission from your host.
I bet that is because when the two packets come in such a close
proximity your Ethernet driver is losing the second one. This, in fact,
can be because there is a problem with the driver itself, or you have a
really low-memory condition
I am a bit surprised that the ethernet interrupt just raises a flag :
Don't be surprised, lwIP is single threaded, meaning you shouldn't call
an lwIP memory allocation routine from inside an interrupt, since it
might have interrupted another lwIP memory allocation routine... (I
might be wrong
Yes Jens, looks like you are absolutely right, missed that, there is no
frame loss here, the receiving process must be getting only the first
frame in the chip cue.
Julien is using some ST microcontroller, I guess it has a built-in eth
controller, probably with DMA.
I've studied the Linux
Hi,
let's have this scenario:
Data received from TCP is going to some real-time usage, let's say we
are writing to an SD card or something like that. The point is that when
data comes from TCP, the application might not be ready to use it for
some (hundreds of) milliseconds.
LWIP_ASSERT( please
...
so, if you get here by searching the list for an answer to this very
same question, before browsing the source files, as I did, here is what
I've found.
There is also an example of pbuf handling in tcpecho_raw
We all know telling the other end to shut up is not the fastest way, but
if we
Hi, I need help here.
I have this raw api application which tcp_write()s 5 small (~20 bytes)
messages and then checks tcp_sndbuf() to send the biggest possible
chunk, but it ends up having to send a smaller chunk because an internal
queue gets full.
My settings are (almost) standard:
TCP_MSS =
Thank you Simon, your words now populate the wiki
--
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
If you arrive here looking for something on the netio server, yes, the
one in contrib (at least upto 1.4.1) is incomplete.
There's one guy who submitted patch #7026 with a full server; however,
that server reacts with one write to each ACK it gets, and so its output
throughput is very low.
I
I would like to try to help you, but honestly I don't understand
what are you doing
what is not working
I guess that by answer the ACK you mean your application is supposed
to send something in response to something and you think it should do it
when the ACK comes. Well, that would be true if
Marty,
some sniffers (like Wireshark) on some OSs (like windoze) do not capture
the preamble nor the CRC, and are intelligent enough to remove the padding.
54 is OK for 14 bytes Ethernet + 20 IP header + 20 TCP header, no
options, no length
Regards
--
crystal ball seems to be not fully
functional...).
On 07/05/2014 10:38 a.m., Sergio R. Caprile wrote:
When lwIP receives the TCP ACK, among other things, it will call the
function YOU provided to be called by setting up a callback via
tcp_sent(). Did you
Quick check: try changing the checksum algorithm with LWIP_CHKSUM_ALGORITHM
This might point to a possible bug in the algo
--
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Hi,
Quickdirty workaround: disable ARP checking by defining
DHCP_DOES_ARP_CHECK to 0
Analysis:
I'm no expert in DHCP nor ARP, but I don't see anything similar to what
you are experiencing.
I've setup three scenarios:
1- different IP (static) prior to DHCP
2- same IP (static) prior to DHCP
3-
I suggested the QD workaround as a way to check if that was really the
problem.
I guess your problem is that you are seeing your own messages, something
that may not be the case in standard Ethernets (you mentioned Wi-Fi,
didn't you?)
I suggest to follow the code execution and help the developers,
their
examples as a learning tool for lwIP. Instead, check the available
examples in the contrib tree: SMTP for a client, netio/httpserver_raw
for a server
Regards
--
-
Sergio R. Caprile, Human Being, Bs.As., Argentina
Electronics Engineer, Musician
take the data and ERR_ABRT
when there is an error and they expect the stack to dispose of the data. Check
(for example) http_recv() in httpd.c. If there is any other possible situation,
it doesn't come to my mind right now.
On 30/05/2014 02:47 p.m., Sergio R. Caprile wrote:
Hi, following is MY
Hi David,
I didn't get if your problem is with (1) THE httpserver or with (2) YOUR
APP, that handles http requests and it is (loosely ?) based on the
httpserver.
I also modified the httpserver code and found some stuff I wasn't
entirely convinced, so I rewrote many parts of it. My server handles
George,
where did you get your stack ported ? How is it being called ? Since it
is running under an RTOS, have you checked there is only one thread
calling it ?
Is there any other application using pbufs ?
If everything is fine, can you put a breakpoint after the udp_remove()
and track the
Hi,
In my system (uname -a - Linux 2.6.18-348.1.1.el5.centos.plus #1 SMP
Tue Jan 22 19:16:31 EST 2013 i686 athlon i386 GNU/Linux), I see a tun0
interface.
Yours is ?
There is a line in the makefile which you have to set to your system:
#To compile for linux: make ARCH=linux
#To compile for cygwin:
Well yes and no. I don't decide how the customer will use the two interfaces.
But if he does attach them to the same subnet and wants to have cable
redundancy, it should behave in a way that works at least similar to what a
full fledged IP stack like the linux one would.
Well, in that
Well, I'm no Linux expert and I'm not familiar with kernel 3.x, but I
would go looking that way.
My apologies, it is not tun0 but tap0, and it shows up in ifconfig only
when you run the program (when it is open), and in some systems you have
to be root for this to succeed, unless you change
Well, I don't see how you call those functions on your client, but you
know you have to wait to be connected before you send data, do you ? The
callback in tcp_connect() will be called when that happens.
Also, you are supposed to check for the available room before calling
tcp_write(), and/or
Hi folks,
I wrote a driver for the DM9000 Ethernet chip, and nowadays it is
missing the link state part. I feel reluctant to add it because I don't
really see a need for the stack/application to know the link state,
since all the devices I can imagine I'll be developing will be
permanently
Hi, this is the kind of problem I love to figure out and not have it
myself... ;^)
1) I would put a wireshark or equivalent to really see what is going on,
those text reports can be lots of non-related stuff. I guess packets
have an id number and so lost packets are detected, but I don't see that
Good to know!
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Hi Sylvain, thanks for your input.
I don't see why that is a problem, as long as you don't change networks
you can keep your address for as long as your server assigned it and
there is no need to change it, even if your cable goes in and out
several times.
That would only be necessary when moving
Bill, Alain, thanks for your inputs.
The front-panel LED is a good one.
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Mike:
What you say is a bit confusing, I suggest you see bytes and check bytes
instead of who knows what.
I mean, \365 looks like octal, so maybe you are taking something from
somewhere and displaying in someotherwhere by doing someotherthing in
between, and maybe you are scrambling something in
I suggest that you use breakpoints and actually debug your code.
Many of us here are willing to help on networking issues and even catch
lwIP bugs, but it is sort of near to impossible to guess what the
problem in your code is just by looking at a wireshark capture file.
I also suggest you
I'd like to help on this but currently don't have the time to analyze
the capture file.
Check you are calling the netif receive function on frame arrival with
no polling delays, and if you are still thriving let me know and I'll
try to check the capture file and see if I see anything wierd
Hi,
I will guess:
- Since you describe something ending with 'OS', you are using an (RT)OS
port, probably with NO_SYS = 0.
-- If you have multiple tasks, check you call lwIP only from one task
(unless you know exactly what you do and why you are doing it). This
includes the netif input.
-- Who did
Hi,
check my fork of the server, I already added authentication
http://scaprile.ldir.com.ar/cms/el-ingeniero/open-source-projects-im-working-on/lwhttpd/
Regards
___
lwip-users mailing list
lwip-users@nongnu.org
Hi Fabian,
for clarity's sake:
lwIP uses internally its own representation, and there are macros to
convert from network format to host format. I guess all systems are more
or less like that.
You are supposed to have a fast macro, preferably with machine code
instructions, because it is going to
Hi,
there are many reasons why that can happen.
You should tell which application you are running, so we can have less
stuff to guess at.
My best (probably educated) guess is that frame 1513 got lost somewhere.
Somewhere here can be:
- your transmitter, which is...
- your network
- your hardware,
Hi,
I don't understand what your problem exactly is, but I happen to have a
running Keil port for ARM Cortex-M (CMSIS, Keil/IAR/GNU in fact). Take
a look at it and maybe you find your problem (or use this port)
http://scaprile.ldir.com.ar/cms/category/os/lwip-port/
Beyond that, check your
Hi Fabian,
Try posting this to the developers list, I see the same on my system
with the latest version of check. However, I remember running the suite
on the stable 1.4.1 when I hadn't patched it, with an older version of
check, which I can't now with the latest one (and my patches...)
I'm using
Got it to run now.
The checks in the stable branch do not test DHCP, so I guess that in the
git head is brand new or fresh.
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
* You are confusing lwIP with a Linux/Un*x environment.
** tap/tun is what a port for that environment does, lwIP is just a
TCP/IP stack, not even a library, the library you are using is a compile
of a port for that environment.
*** You have working examples you are supposed to follow, those will
Hi nkumar,
on reception, you won't ALWAYS receive a single pbuf, but probably a
chained pbuf.
This means, you have to ALWAYS look for p-tot_len, not just p-len, to
actually get ALL the data you were sent.
To extract ALL data in a pbuf chain, use pbuf_copy_partial(), it is
easier than travelling
The way pbufs are arranged depends on the fragmentation of the memory
pool at the time of allocation.
When an Ethernet frame is received, your netif code calls the lwIP alloc
function to get memory to store the frame's content. DMA implementations
might be different.
The fact that you are getiing
Mario:
Would you please
- not hijack other people's questions
- open a new thread and post YOUR problem in the subject
You are mixing netmasks and using public IP addresses, I hope you know
what you are doing cause unless your network is correctlyl configured
you will have non lwIP related
Yes, nkumar, your latest post came after I had sent my response to your
former, I just look at the page when I have some time to relax, not
getting emails from this list.
___
lwip-users mailing list
lwip-users@nongnu.org
Well, Christian, I don't have any expertise on the NO_SYS=0 world, but I
can tell you that you normally don't implemented the port function.
You don't port lwIP to an OS unless you know exactly what you are doing,
you normally get a port for your OS and ask your OS port maintainers
when you have
Hi Friedrico,
I see you call udp_connect lots of times (once every new incoming
packet), without actually calling udp_disconnect(). I don't know if this
causes trouble, or the function will just return an error condition.
BUT, in such a case that this function is returning != ERR_OK, you will
exit
Hi,
I might have some use for this, if you guys host the project in some
CVS/SVN/Git repository I offer to help with development/testing.
Please make sure TI (or whomever) sources licensing allows this.
I'm quite busy, so don't depend on me if you need to rush.
--
Counter-proposal:
Read the wiki, and if it is not clear enough, I will change it
http://lwip.wikia.com/wiki/Raw/TCP
Regards
--
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Hi,
when you say echo example, do you mean the echo example in the contrib
tree or some vendor distributed (and probably modified) file ?
'cause i've run the echo example from the 1.4.1 contrib tree some weeks
ago and I don't recall seeing anything strange.
And btw, I don't see anything close to
Not really.
tcp_write() allocates an internal pbuf itself, but you can only send 3
times in a row if yu have enough memory, and as TCP works, there is no
concept of packet and no need to call 3 times in a row. You have a
sndbuf and you can send as much as you can fit inside that sndbuf for
that
What can I tell you...
I've seen the code running fine, if it doesn't run fine on your
scenario, then either your scenario is faulty or mine didn't trigger the
bug.
You are not supposed to have ticks and/or timing here, the stack works
when a frame is received, you have to always call the stack
Hi,
if you do need to detect a particular situation on tcp_err(), then you
can use the arg parameter. You are not getting the pcb because, afaik,
it no longer exists; it has been removed and freed before calling the
callback function; see tcp.c line 393 for example
The tcp_err() callback that
I've run the example on my linux port, with TCP_MSS set to 536 bytes,
connecting via telnet and sending messages from 4 to ~800 bytes.
It works as expected.
Unless there is something not exercised by the tests I've run, your
problem lies on your port or your usage. If you need further help,
please
Read the wiki, and if it is not clear enough, I will change it
http://lwip.wikia.com/wiki/Raw/TCP
So far, the last user that asked (almost) exactly the same as you did
not complain, so it should be OK.
___
lwip-users mailing list
lwip-users@nongnu.org
You have a working http server in the contrib tree.
You also have my http server, which expands a bit over the official one:
http://scaprile.ldir.com.ar/cms/category/os/lwhttpd/
If that is not enough and you really need to do your own, you have
working examples on how to develop TCP applications
OK, so you seem to need help with TCP, not with lwIP (yet).
I'd like to see a wireshark capture; not a screenshot, the capture file.
And please enable logging on lwIP and capture that too.
You can post capture files to the list.
Regards
On 08/08/2014 02:46 p.m., Sergio R. Caprile wrote:
Read
You guys seem to be both making the same mistake, however, I can't tell
which it is without knowing what you are actually doing (assuming I'm
capable enough to tell, of course).
- Is your port a good one, known for not trashing memory and respecting
the mandatory laws of calling lwIP from one and
I recall reading about a similar problem with an RTOS port.
Search in this list.
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Either I'm having a dèja vu or Simon answered part of this this very
same week.
Look for it in the other threads. Clue:Sending to a non-local network
without default netif se
___
lwip-users mailing list
lwip-users@nongnu.org
Oh yes! And you were the OP of that thread! I do need vacations...
My mistake, I don't see a difference. Sorry, don't want to inject noise
in your thread, I just don't see how DNS is different from other
applications. This to me is the same source routing issue and you will
face it for every
Being out on vacations, I missed part of this thread.
I'm tempted to cite Simon's famous words: think on how would you do it
with Linux (or something like that)
Well, I can't.
Just to learn some more on networking, which I enjoy, I tried to figure
it out, but I can't build something like this with
I assume you are trying to mean that you actually know some pcb
somewhere is not freeing pbufs and you need to find out which one it
is... I don't think flushing or restarting the stack is a solution.
If I'm in the right path, then I'd suggest you enable statistics and
print them on the functions
Well, I'm not trying to get paid for helping here ;^)
I noticed
mem_ptr_t)name) % 4) == 0))
in both macros, so sockets.c is actually expecting the 'name' pointer to
be aligned to 32-bit boundaries.
I don't see why and I'm not familiar with lwIP's socket interface, but
this to me seems to
When I did it, I basically polled for
netif.dhcp-state == DHCP_BOUND
and read
ipaddr = netif.ip_addr;
netmask = netif.netmask;
gw = netif.gw;
but now I realize the dhcp code calls netif_set_up() when it reaches
that state, which also calls NETIF_STATUS_CALLBACK if
B Can you share your email id with me? It is helpful for sending the
project files.
SI'd be surprised if Sergio wanted to receive your project files
Simon: as 100.1% of the times, you are right ;^)
Bellphin: please search in the list and try to solve the problem
yourself. You can post your
Hi guys, I've been online for a couple months on the list and I'm
already tired of reading about this; I imagine how you guys are... ;^)
Anyway, joke aside, since people don't search the list they will
probably won't read the wiki either, is there anything we can do to
induce RTOS users to check
Hi Grzegorz,
let's make this a kickstarter for the FAQ ;^)
single thread applies mostly to raw API users and/or vendor code; they
use an RTOS and the raw API and forget to call the lwIP stack from a
single thread. I've seen some vendor code which also calls the stack
from within interrupt code.
According to the wiki, the correct way to initialize a DHCP interface is
to call dhcp_start() and not netif_set_up(). So, summarizing:
you can poll for netif.dhcp-state == DHCP_BOUND
you can define LWIP_NETIF_STATUS_CALLBACK, and call
void netif_set_status_callback(struct netif *netif,
There is a thread on a guy needing something like source routing last
month, in which Simon discussed some hooks to provide routing.
As far as I can see, you are better off using embedded Linux. Even
though nothing forbids you from runnig RIP or OSPF on top of lwIP and
build a routing table and
First:
lwIP does not report bad FCS, it can't, it does not check FCS in frames.
So...
Second:
Wireshark reports FCS incorrect but the server answers anyway, so
obviously it is not seen by the server as incorrect. Please check your
networking hardware and connections, then your Wireshark
There's nothing wrong with what's described at
http://lwip.wikia.com/wiki/Raw/TCP.
What's wrong is that your lwIP calls into lwIP from interrupt context and you
call it from your main loop. This is not allowed, that's all.
Thank you Simon
Wiki 1
users 0
Your code is too long for me to try to figure out which API you are
using and follow your approach.
In case you are using the raw API, please check the wiki, and then your
code, and if something is not clear then come back to us. I'll try to help
http://lwip.wikia.com/wiki/Raw/TCP
Is this the (in)famous ST-lost-frames bug again ?
Translation: is your port running on an RTOS with an Rx task fired from
Eth interrupt and taking only the first frame out of the chip ?
___
lwip-users mailing list
lwip-users@nongnu.org
Hi Karl,
I'm not trying to teach you how to do things, but I need to ask you if
there is any reason why you can't rise a flag in your eth rx interrupt
and run all lwIP code from the main loop ? (zero latency ?)
Mine (sort of):
void eth_input(ifc)
{
do {
if(!flag)
break;
/ The FW Library bug in the Ethernet IRQ, eating fast packets is fixed./
So no, this does not seem to be the standard STM issue...
Oh, I see, missed that part. Should we believe the vendor ? (terrified face)
Anyway, here are my 2 cents:
- Frame 16: bad FCS on ARP response from MCU to PC, why ?
For any Dragon Ball Z fans out there, this STM bug looks like Majin Buu
to me...
Anyway, glad you managed to solve your issue Michael, next user with an
STM bug will be charged ;^) I wonder if the SICS can take donations...
As per the tcp_poll() vs tcp_sent() in your scenario, it depends on what
You could try the way we vendor-agnostic use the stack:
Once you set NO_SYS_NO_TIMERS = 0, add a call to sys_check_timeouts() in
your main loop. This is the 1.4 way of checking all the timers,
including DHCP. This should take care of TCP and so calling your poll
function callback for your
Yes Simon, it was Karl.
Maybe that is the reason why TI disabled the timers... I would have
expected that from a teenager, not from TI... anyway, Karl said he was
buffering at interrupts and calling lwIP at main loop (or so I understood).
So... Karl: you must call sys_check_timeouts() from the
Can you check the current git version of the httpd? I discovered this problem
some weeks ago and hopefully, it's fixed in git. I'd be glad to hear someone
test it, as the POST code does not seem to be too widely used, or is it?
The POST code is one of the main reasons I forked off...
In my
OK, here I go...
The UN*X examples use a tun/tap device, and there is a specific
configuration parameter for different flavors of it. Check the Makefile
for this, did you ?
#To compile for linux: make ARCH=linux
#To compile for cygwin: make ARCH=cygwin
#To compile for openbsd: make ARCH=openbsd
I don't have the slightest idea on Windoze, but I happen to know that
networking is networking, frames are frames, and hardware is hardware.
You are likely to have:
* a hardware problem, triggered by the difference in
full-duplex/half-duplex and/or 10/100 due to different wiring and PC
hardware
*
You should read the wiki and check the examples in the contrib tree.
TCP can only buffer a certain amount of data, and will not accept
anything more. It will send it, and can't send anything else until that
data is ACKed. Once that data is ACKed, you will receive a callback in
tcp_sent() and then
Thank you Jens
I'm discussing this with my shrink, the STM bug haunts me in my
dreams... ;^)
Maybe Simon can modify the list signup banner to read:
if you are using an ST micro with the STCube software, apply this patch
and try before you sign up and post
Never mind, just joking, fancy
it's been patched in git HEAD anyway.
On 03/10/2014 10:27 a.m., Sergio R. Caprile wrote:
OK, here I go...
The UN*X examples use a tun/tap device, and there is a specific
configuration parameter for different flavors of it. Check the Makefile
for this, did you ?
#To compile for linux: make
I'll take the risk of saying the obvious:
Some task in your example is allocating memory and not freeing it.
Check a running example and see how memory is freed, cause you are
testing with ...?
Always test with known good examples. Try the echo server.
Please don't repost the same issue with a different name...
Check your driver code, from what the other user said, looks like non-IP
packets are being discarded without freeing their buffer.
Check with the one who wrote the driver and/or the port.
When the Ethernet controller signals frame(s)
Isn't the stack responsible for freeing PBUFs?
No Grzegorz, the stack isn't more responsible than you are.
The Ethernet driver usually allocates the pbufs when signalled by the
Ethernet controller. This code does not belong to lwIP but to the driver
developer. It is responsible for freeing
I'd like to help, but I have absolutely no clue how this relates to lwIP.
I worked on the httpserver_raw and forked it (among other stuff) to
handle POSTs (CGIs actually) in a more transparent and standard fashion.
If that might help you, grab this:
Any hint what I could do to close the connection?
I will assume that you are using the raw API, and that you have already
checked that the port is working good by running known to work TCP
examples on the contrib tree.
I will assume that you did read the wiki and are following its guidance
OK, another thing I assumed is that you were using NO_SYS=1, and forgot
to tell.
I know nothing on RTOS ports, so I will assume you are calling the right
function and respecting the single-thread restrictions, as your other
apps work.
My tcp closure is:
state = myCLOSING;
Now I understand.
You are reusing a socket.
After a TCP socket is closed, data can still be going around and the
default behaviour is to wait for a while before reusing that socket.
The raw API does not use sockets, but the behaviour is the same. The
waiting time varies from full hosts to embedded
In other words, do another call to tcp_new() when you want to reconnect
from tcp_close() in tcp.c:
* Connection pcbs are freed if not yet connected and may not be referenced
* any more. If a connection is established (at least SYN received or in
* a closing state), the connection is closed,
All I can tell you, and I don't know if it suffices, is that you call
sys_check_timeouts();
in your main loop and all timing is done.
Check your lwipopts.h for the number of timers if using dhcp, dns, etc.
Should you need to use a timer for your own purposes:
static void
All my TCP examples and applications work, and I'm calling
sys_check_timeouts(); so, if tcp_tmr is really not called, then
something with the same functionality is being called.
I do use NO_SYS=1 and have provided a working sys_now() function.
DHCP and DNS timeouts are also handled through
You should start by learning communications and networking, there are
several books outthere, I'm fond of Mr. Tanenbaum, get a copy of
Computer Networks.
For TCP/IP itself, read Douglas Comer or Stallings.
However, what you mention in your mail are lwIP functions.
Apples and oranges
Once you know
No,
I have my own port and been compiling it with Keil on a Cortex-M3.
I have some patches on top of 1.4.1 and didn't like the way Keil packs
lwIP. My advice is to use lwIP with an open and portable port, with an
open and portable driver. You can use the one I wrote, modify it, write
your own.
If I was you, I would:
- make sure the port I'm using works, by first running known good examples.
- study those examples to learn how to work with lwip.
- read the wiki, it is great for bed reading.
- trace assertions to my code, execute step by step and see what I'm
doing wrong.
- try to figure
My view:
Since PPP expects a serial transparent interface, and you are not
providing that, I would write a tap which provides that to PPP and
taps all other data out.
GSM modem real serial -- my module - PPP virtual serial
--- tracking virtual
1 - 100 of 533 matches
Mail list logo
