He didn't stutter... don't call lwip from
anything but main loop code. Side-effects
are hard to diagnose when you don't follow
directions.
__
Steve
.
On 2/18/2016 1:00 PM, Gustavo Pinho Oliveira wrote:
I have checked my code and I do call lwip from interrupt callbacks.
But my problem is with the receiver and that one isn't using lwip
within interrupts.
The system was working like this before and we had no problems.
I control both sides of the system (A and B).
I have to thank you for the hub idea.
I configured my switch with port mirroring and it's much easier to
debug now.
I attached a pcap.
The flow is changed but it should work nonetheless.
My problem of not getting tcp_recv callback still exists.
On 17 February 2016 at 16:36, Sergio R. Caprile <scapr...@gmail.com
<mailto:scapr...@gmail.com>> wrote:
your system is single threaded if you don't call lwIP functions from
within interrupt code. You can't. Please make sure you don't do that.
The applications you mention do not belong to the contrib tree, so I
don't really know if they do work OK. It is just my user opinion,
I only
trust contrib tree apps and (sometimes) my own.
In fact, lighttpd is not (afaik) a RAW API application...
You say you are just trying to implement Digest Auth but you mention a
communication flow problem. If you expect some help, I would like to
actually see that communication flow. Maybe you are fiddling the wrong
way with your application, I added HTTP AUTH to my own web server,
which
is a fork of the contrib tree official web server for RAW API.
You are welcomed to see if it fits your needs here:
http://scaprile.ldir.com.ar/cms/el-ingeniero/open-source-projects-im-working-on/lwhttpd/
Besides that,
"B connects to A": what is the application running in A, who wrote
that,
why do you think it works OK ? OK, it connects, but...
"B tries to make the 2nd connection to A": so, your application is
listening and should have bind to a port and receive.
Before B receives a callback to tcp_connect(), A must receive a
callback
to tcp_accept(), and the callback must do its internal magic and
return
ERR_OK to lwIP.
You should be able to see why tcp_connect() is not called in B by
following the frame flow in A and/or B, putting a breakpoint at
ethernet_input() [assuming you did see the SYN and/or SYN ACK in the
wire, what you could do by attaching a PC running wireshark to a hub
(not a swith, a hub) where you connect the three Ethernets], which
should be called via netif->input inside your driver, if correctly
initialized by your call to netif_add():
netif_add(&netif, &ipaddr, &netmask, &gw, NULL, yourdriver_init,
ethernet_input)
Please attach a capture file so we can see the comm flow and the
requests and responses.
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org <mailto:lwip-users@nongnu.org>
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users