Re: [lwip-users] tcp_tmr and timers.c
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 sys_check_timeouts(), and I have used a timeout for a UDP application as I sent. As this seems to work for any similar scenario, what is actually your problem ? ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Need to Know more about tcp and it's concepts
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 what a connection oriented protocol is, and get an idea of what a machine to serve that protocol should do, try to think how to make it work in an event driven framework with a small overhead. That is the lwIP raw api. You can read an intro to how to use these functions in the wiki. However, the text assumes you know TCP (it is qiute difficult to do rocket science without knowing about rockets or science, the same applies to networking with microcontrollers). http://lwip.wikia.com/wiki/LwIP_Wiki ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Has anyone been using the Keil lwIP software packs?
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. This way you can reaaly move in and out of any architecture without any vendor restrictions. Peek my page: http://scaprile.ldir.com.ar/cms/el-ingeniero/open-source-projects-im-working-on/ ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Assertion "pbuf_free: p->ref > 0" failed at line 651 in ../src/lwip/core/pbuf.c
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 it out by myself, but if I can't, I would write a brief
and concise description of what I'm doing, what I can't solve, and what
I don't understand. That description would include a description of the
system in which I'm doing that, stating that I followed the previous
steps and the system works, and what type of lwIP API I'm using.
With the data you provide, I can only direct you to line 651 of pbuf.c
and see why something you are passing to that function is incorrect.
OK, I feel like wasting some time today, here I go:
$ vi src/core/pbuf.c
651
/pbuf_free(struct pbuf *p)/
{
[...]
/* all pbufs in a chain are referenced at least once */
*651-->LWIP_ASSERT("pbuf_free: p->ref > 0", p->ref > 0);*
//* decrease reference count (number of pointers to pbuf) *///
//ref = --(p->ref);/
that means you are trying to free an already freed pbuf.
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] hayes commands popping up in ppp stream
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 serial Some GSM modems provide a packetization interface to clearly separate muxed channels on the same serial interface. If yours does not, you'll have to work harder. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] hayes commands popping up in ppp stream
BTW, "\r\nUNDER-VOLTAGE WARNING\r\n" is a clear indication that your power supply is not well designed and/or your module is not well decoupled. It needs >2A current to transmit for a very short time, you need a 100uF low impedance in parallel with 2uF MLCC close to the module; or better, what the hardware manual recommends. And make sure your power supply can provide that current for that amount of time, which you'll find in the manual. Sorry about that, but I used to work with the tech support for Simcom in Argentina... On 14/11/2014 10:06 a.m., Sergio R. Caprile wrote: > 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 serial > > Some GSM modems provide a packetization interface to clearly separate > muxed channels on the same serial interface. If yours does not, you'll > have to work harder. > > -- - Sergio R. Caprile, Human Being, Bs.As., Argentina Electronics Engineer, Musician (guitarist), TaoFx http://www.scaprile.ldir.com.ar/ - ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] hayes commands popping up in ppp stream
Chrysn, yes, Simcom tech department sucks... they've had some internal issues on the move from SIM340 to SIM900. They are chinese and english docs are poor and mostly non-existent. We've had a tech contact long ago but hopefully I haven't contacted them for years. Regarding the hw, you are too close to the limit, I've never run them bellow 3.6V. You need a heck of a stable power supply to drop only 0.1V with a >2A pull. It might work OK in the lab/city (close to the cell) and fail on a moving truck. Should you need anything else, you can pm me so we don't bother lwIP users. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] How to explicitly set IP6 header version = 6 in outgoing packets
$ grep -R BeginPacketSend lwip/* $ What are you talking about, Willis ? Are we talking lwIP here ? ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Query regarding internals of lwip-contrib: Unix port
Trying searching for those words in the list, I've been discussing about that one or two months ago If you can ping your lwIP from your shell, then the rest is routing/natting/firewalling. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] fnConnected not invoked
Have you read the wiki ? http://lwip.wikia.com/wiki/Raw/TCP Have you tried the working examples in the contrib tree ? Vendors have the marketing idea of showing they are bigger and stronger, more macho than the other vendors. Try simple working examples from the contrib tree. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Interfacing LwIP for a radio communication
Something is not clear to me here... "PPPoS" might be confused with PPP over SONET/SDH You guys are talking about plain old PPP, RFC-1661, Point-to-Point Protocol, which (by definition) works over any point-to-point link, as long as it is full-duplex and can carry bytes (octets). I guess "point-to-point" and "peer-to-peer" can be considered equivalent in this aspect. So... Please forgive my ignorance, I don't know what a SwMi is (even less a centralized one) ;^) PPP runs on telephone modems and serial ports, although, as Sylvain cleverly points out, SLIP will have way less overhead, both in bandwidth and code size. Perhaps confusion comes from the way cell modems capture PPP by "dialing" a fake number ? Or because of authentication with PAP/CHAP ? As long as the two end points can see each other, you can establish a PPP link or a SLIP link. You don't need to "dial" or "login" to have PPP working. Authentication is not mandatory, you can bypass it. Regards -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Interfacing LwIP for a radio communication
OK, I think I'm starting to get a hint on what you do have and what you are trying to do. You seem to have a packet radio system, and you seem to need to route IP over that packet radio system. I will assume that you already studied and know your packet radio system and you are sure it does not have its own way of handling IP frames with AX25 or other similar stuff. In such a case, you need to build your router, either out or inside lwIP. I guess you already decided to build it on a netif, and I guess the SLIP code will allow you to build a static routing table to accomplish some sort of mapping from IP address to radio address. You might get some clues and directions if you ask the guys at AMPRNet or study AX25, KISS, 6PACK. Good luck. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Where to get the LwIP version information
$ grep -R VERSION programming/lwip/lwip programming/lwip/lwip/src/include/lwip/init.h:#define LWIP_VERSION_MAJOR 1U programming/lwip/lwip/src/include/lwip/init.h:#define LWIP_VERSION_MINOR 4U programming/lwip/lwip/src/include/lwip/init.h:#define LWIP_VERSION_REVISION 1U programming/lwip/lwip/src/include/lwip/init.h:#define LWIP_VERSION_RC 255U programming/lwip/lwip/src/include/lwip/init.h:/** LWIP_VERSION_RC is set to LWIP_RC_RELEASE for official releases */ programming/lwip/lwip/src/include/lwip/init.h:/** LWIP_VERSION_RC is set to LWIP_RC_DEVELOPMENT for CVS versions */ -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwIP TCP STACK
I will try my best to understand. You seem to have some Ethernet hardware related to the Arduino. That hardware seems to have some library called EMAC doing something. That something at least answers a ping, so there is at least some sort of a fraction of a TCP/IP stack on it. You've found lwIP and you think that might help you to achieve something. Well, if that something means porting lwIP to the Arduino to work with that hardware and that library as a driver for the Ethernet interface, then check the wiki and the comments other people porting the stack have made. You know this is C, do you ? If not... then... -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] DNS host not resolving using lwip_gethostbyname function using ppp over serial
I will give you the best advise I can give you. Two of them, and for
free. Well actually three:
1 - Don't expect some random one to help you, if you don't provide a
clue on what you are doing. Do you know what you are doing ?
2 and 3 - At bottom
Here's what I can extract from your writing
You seem to be working with some hardware connected to some GPRS modem.
You are running PPP over GPRS to connect to whoknowswhere, where there
is some 103.8.45.5 who seems to be a DNS server.
You seem to be using the netconn API, which I don't know and so I'm not
able to help you, but if you provide that info on your msgs, maybe one
who knows it gets attracted by the subject line.
You seem to do some calls to the API, expecting to get some results.
Maybe if you actually explain what you are doing, maybe someone will
actually tell you what you are doing wrong.
You seem to have seen the (supposedly) DNS server response is not coming
back. Did you actually see the question going out ? Have you checked it
is OK and consistent ?
But even before getting there, have you ever checked your routing and
your port works OK ? Have you ever tried a known to work example ? Have
you pinged google or yahoo ?
2 - First: check your port works, try known to work examples, try simple
stuff, make sure it works. E.g.: PPP over a modem to a known to work ISP
phone number. Yes, use other hardware if you have to, or use Ethernet,
you MUST be sure your port works. Second: check your connection to the
world works, repeat the former tests over your connection. You MUST be
sure your connection works. Third: read the wiki. Know how to use your
system and your functions. Fourth: if you have a problem, read the wiki
again and learn how to properly report an issue or ask for help.
E.g.:
Subject: lwip_gethostbyname (netconn) returns ERR_VAL
Hello, I'm using netconn on a blablabla port of lwIP 1.4.1 (release),
the port has been tested and it works OK. Connection is OK, I can ping
the DNS and it is known to work (I'm using it from other machines). When
I call lwip_gethostbyname() I get ERR_VAL (-6), the DNS client has been
properly initialized, here is my code:
function()/* I don't know netconn, so I can't write a proper code
example */
{
call to init dns()
call to lwip_gethostbyname (parameters)
here I can see the error
nothing else
}
Attached you can find the capture I did with wireshark. I'm not
proficient to understand the DNS dialog, so please help me on this one too.
wiresharkattachment
Best regards
3 - Never follow old ugly women and advise (old engllish (american ?)
saying)
--
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] DNS host not resolving using lwip_gethostbyname function using ppp over serial
On the log, you have this dns_check_entry: "www.google.com": timeout lwip_gethostbyname(www.google.com) failed, err=-6 Since I seem to have nothing more interesting to do today, I googled this for you. I've found an answer from Simon from 2011, some guy had this very same problem. Yes, you have a timeout, either the DNS server response is not arriving (in time) or your question is getting lost, or your system is trashed and you are not asking properly/missing data/trashing data. I already explained to you what a developer should do to solve your case. If I were you, I would follow one of them at least. Find a way to dump your IP traffic so you can at least reduce some of the uncertainties. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwip and microblaze
Your problem is not with lwIP or the microblaze. To "Connect to a web api" you need to know what the web api does and do what it expects you to do. The only thing that this shares with a web server is that maybe both will use TCP port 80 and maybe both will talk HTML at some point. You will choose an lwIP API, you will open a TCP connection on destination port 80 (assuming it uses the standard port for http) to the host hosting the web api of your interest, and you will parse its responses and send whatever you want/need to send. There are examples on using TCP in the contrib tree -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwip gpio
There is no gpio in lwIP "gpio" means General Purpose Input Output and is a common name for the I/O ports in some processors. It is a processor thing. lwIP does not talk to gpios, lwIP is a TCP/IP stack, you write applications that do what you want them to do, and if that is moving I/O pins (or "talk to gpios") then you will write the code that does that. You need a web server and have to write the equivalent to a CGI script or use SSI. The HTML on the hosted page may read an internal variable (SSI) or call a function (CGI) which does the trick. Besides that, you are better off asking for guidance on your processor forums. And please, don't crosspost and don't send user questions to developer's lists. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP keeps re-transmitting but no ACK packet after SYN, SYN+ACK
Can you at least explain what you are doing with what and post a capture file ? -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP keeps re-transmitting but no ACK packet after SYN, SYN+ACK
There are 298 frames in your capture file. Somewhere in the middle of it I see a 10.9.208.127 sending a TCP SYN to port 80 to 10.9.208.210 Judging by the amount of crap it is sending, and the fact that it is opening the connection, I assume 10.9.208.127 is your PC Then, 10.9.208.210 must be your "box", which is running git head code on a X processor with a X port, configured for X (SYS or NO_SYS) which is OK and tested good because ? And, your webserver is X from X, using API X which is also OK and tested good because ? The TCP three-way handshake for opening is SYN SYN + ACK ACK I can see the first two frames, but there is no clue of the third one. Since it has to be sent by the opener in response to the SYN+ACK, which I can see, then the opener is either not seeing this frame or not liking itm or broken. Enabling checksum validation in wireshark, I see the (supposed to be) lwIP box sends correct checksums, but the PC does not. (?) This is probably due to checksum offloading and you taking the capture on the same machine. Can you do a plain "telnet mybox 80" from a known-to-be-good machine on a not so loaded (read "just the two boxes and all the extra crap removed") network and ellaborate on all the Xs ? -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP keeps re-transmitting but no ACK packet after SYN, SYN+ACK
By "port" I meant who did the work of porting the stack to your processor. Sorry, I don't fully agree with your definitions of "known to be good" or "known to work". To me those are "supposed to be OK". Your web server is not lwIP code, how are you certain it works OK ? You can't have two unkown variables and believe both of them are true. In order to test the port for good, you need a known to work application, and viceversa. Some things might have happened on what you have there: - The web server might have defects that weren't seen on 1.4.1 and are evident in git head. - The official release 1.4.1 might have been manipulated by the one doing the port to make it work, so when you apply a git head it won't work. As Simon pointed out (I missed that, only TCP checksum validation activated on my Wireshark...), you are sending IP datagrams with bad checksums. That is the reason why your browser does not see the SYN+ACK and keeps sending SYNs. What he describes is what I called "defects that weren't seen on 1.4.1 and are evident in git head" a couple lines above... If we assume that the driver (the port) and the stack (the port) are OK, you have to try to reduce the web server to the minimum required to serve a static page, know what API is it using, and if you post the minimum code someone will probably check it (I offer my help with the raw API, don't know the others. Be specific in the subject on what API you are using. If we assume the web server is OK (why ?), then something is broken in your port, that is, the lwIP code is modified and or the ethernet code is buggy. Pickup one of the known to work applications, and see if it works, and if it doesn't, find why. You are using NO_SYS=0, hope you know what your are doing with tasks and calling lwIP from just one of them. I can't help further on this, I'm a NO_SYS=1 guy. Good luck PS: how come you are developing networking applications and don't know how to do a plain telnet to a port ? you open a command shell or whatever M$ calls it and write "telnet" followed by the port number, or install PuTTY. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Zynq Z7010 network exception problem,
I assume the product you describe is some sort of soft core. If it was an ARM, I would put a breakpoint at the exception vector, and trace the registers back to the offending instruction. I suppose you can do something similar, that's what exceptions are for. I remember Simon telling you to look for help on your product forums, that is not an lwIP bug, that is a port/driver problem and you should ask there. Good luck -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP keeps re-transmitting but no ACK packet after SYN, SYN+ACK
or install PuTTY. > Right. That's what I do. With that knownledge however, I think you'd have > to explain what to do with telnet in this case... haha, right, developing web server applications and not knowng HTTP either... oh, these kids nowadays... good point Simon, sometimes I forget I'm an old man... Once you connect to the box to port 80, however you do it, you paste (the web server might not wait for you to type) the following GET / HTTP/1.0 Anyway, we just wanted to connect here and it served our purposes. Mohsin: your telnet capture: frames 75 and 173: you are not trying to connect to port 80 but to the telnet port (last time I used M$ stuff, the port number was entered plain text without brackets, as in any other shell in the Un*x world), that explains the RSTs. Anyway, your PC is ignoring the RST+ACK and I bet that is because of the IP checksum error. Your previous stuff capture (1.4.1) shows IP checksums are correct, so as far as I'm concerned, that is the problem. OK, summing up: Web server uses socket API, so it can't be the problem (Simon's statement) driver + vendor port seem to work OK with (vendor ?) 1.4.1 (you don't say where your 1.4.1 came from). IP checksums are OK driver + vendor port don't work with git head. IP checksums are bad My best guesses 1) Are you calculating IP checksums in software and in your hardware (driver)? Please check 2) I remember there were some changes on the checksum functions, perhaps something in your port collides with those changes or exposes a defect in them. 3) Your port can be trashing memory that was not in use by 1.4.1. My suggestions: 1) Check for this #define CHECKSUM_GEN_IP 1 and also check how your driver initializes the chip for checksums. Setting the above macro to the opposite value might be faster to check... 2 and 3) Check for these anywhere in your port and please post what you find * #define LWIP_CHKSUM * * Or you can select from the implementations below by defining * LWIP_CHKSUM_ALGORITHM to 1, 2 or 3. I don't know anything but the raw API, so in my case I would use the echo application from the contrib tree.. You need to see what the IP checksum function calculates, compare with what is written in the pcb, and what goes out. One of those three should be wrong. I would put a breakpoint at the echo and work my way down, but there is probably a closer place to start. Good hunting. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP keeps re-transmitting but no ACK packet after SYN, SYN+ACK
> For ethernet packets, I'm claculating checksum in hardware but for TCP and > IP, its is in software only. >>* My suggestions:* >>* 1) Check for this* >>* #define CHECKSUM_GEN_IP 1* >I checked above Macro in my opt.h and it is set to 1. Then you have just found your problem. If you are calculating IP checksums in hardware, you must not calculate them in lwIP. Set *#define CHECKSUM_GEN_IP 0* ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Patch to update from 1.4.0 to 1.4.x?
> Is it possible TI's lwIP bases on some release candidate or BETA-version? Even though I do like TI, they, like any other vendor, will play with any code to make their demo work. I've seen infinite loops in Cortex-M3 libraries (Holtek), interrupt routines preempting and calling non-reentrant functions in lwIP (Fujitsu), hardcoded memory references to RAM in lwIP contrib (TI), long loops called again and again parsing texts from the beginning again and again... as long as the demo works and the deadline is met, you guess. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Connect my computer (client) to my board (server/Lwip) using the hostname
> Here’s my problem: Your problem is that you are confusing windoze sort of name resolution based on netbios or whatever they do today, with DNS (Domain Name Resolution). The translation from a name to an address, name resolution, requires a properly configured DNS server. The requester asks the server with a name and gets an address in return. Netbios way: the client broadcasts the name, disturbing everyone in the network (UDP broadcast), until hopefully the owner gets the question and responds with its address. Yes, there is WINS and there are better options. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] Patch to update from 1.4.0 to 1.4.x?
> I don't agree, some vendors, like Atmel, have a perfectly clean lwIP port > announced as being production ready, and it really is. Kudos to Atmel then ! The only problem with them down here is that their products are hard to get. I used to have a strong sympathy for TI and I think I still have it. I'll start taking a closer look to Atmel. Thanks! ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp over serial works with gsm modem sim900d but not working with sim5216j using same controller harware
Looking at your frames, the SIM900 outputs a PPP frame with HDLC address and control bytes, while the SIM5216 does not. I'm by no means a PPP expert, but just looking for PPP in wikipedia shows this: /The Address and Control fields always have the value hex FF (for "all stations") and hex 03 (for "unnumbered information"), *and can be omitted whenever PPP LCP Address-and-Control-Field-Compression (ACFC) is negotiated*./ You should actually check if that is the case before calling SimCom tech support. Besides that, those two HDLC-like framed PPP frames containing an IPCP message are equivalent, you are being assigned an IP address and provided primary + secondary DNS addresses -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Local "ping"
Ola Norberto, > - VM´s network configured as "NAT Network" Sorry, I don't know what that is, assuming your virtual machines + network are properly configured, it doesn't matter wether they are virtual or real, they are machines in one or many networks and can be pinged if routed and not firewalled. If I understand correctly, you are running lwIP under Ubuntu GNU/Linux. I don't know what your particular netif does (sorry, that is your job), the "standard" provided in the contrib tree: mintapif, uses a TUN/TAP interface. Bear in mind that different interfaces (except in some particular cases) must belong to different IP networks, otherwise you must bridge them. The TUN/TAP interface has its own IP subnet and the host machine routes to it because it looks like a physical interface. In order for the other machines to reach that, they have to be configured to properly route that subnet. > I configure the netif with IP=10.0.2.62, MASK=255.255.255.0, GW=10.0.2.61 > > The eth-7 (VM#1) interface has this configuration: > eth7 Link encap:Ethernet HWaddr 08:00:27:48:61:0c > inet addr:10.0.2.6 Bcast:10.0.2.255 Mask:255.255.255.0 For what I think I understand, you have two Ethernet interfaces within the same IP subnet in the same machine. That won't work unless you bridge them or change one of them. You should see an interface for lwIP in your ifconfig with the GW address you configured for lwIP. If you expect Linux to route, then addresses must belong to different subnets, otherwise, put the interfaces into a bridge so Linux can bridge them. The ARP request is a broadcast, the Echo Request (ping) is unicast. check for something like this in your netif.c netif->flags |= NETIF_FLAG_BROADCAST | NETIF_FLAG_ETHARP; -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP keeps re-transmitting but no ACK packet after SYN, SYN+ACK
If IP checksums come out as 0x when you set them in lwIP for hardware calculation, that means your system seems to be correctly configured for that, lwIP sends 0x and the link-layer driver is doing nothing (or at least it is not setting any bits...). OK, so your IP checksums are calculated in software and they are going out wrong. Then [quoting myself]: >> You need to see what the IP checksum function calculates, compare with what is >> written in the pcb, and what goes out. One of those three should be wrong. I guess the easiest test is to check for the output of the checksumming function and compare that to the IP checksum in the wire. Put a breakpoint there, or a printf, or whatever. See src/core/inet_chksum.c, start with checking this: /#ifndef LWIP_CHKSUM// //# define LWIP_CHKSUM lwip_standard_chksum// //# ifndef LWIP_CHKSUM_ALGORITHM// //# define LWIP_CHKSUM_ALGORITHM 2// //# endif// /and then >> Good hunting. BTW, you could also just try changing the algorithm and see what happens. Also check for a definition of /LWIP_CHKSUM_ALGORITHM/ in your port/. /I see many changes to this file from 1.4.1 to git head, maybe you have just found something... maybe not. Sorry but you are the one with the problem and you have to hunt it down, as no one else seems to see what you are seeing in your system./ / -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwip ARP reply delay at first time
Dmitriy, you seem to have a non-working port and/or a non-working driver. FCS errors are not intentionally generated, so you can't correct them unless you know why they are there. So... I'll assume you mean those errored frames belong to the lwIP board. FCS should be correctly generated by a correctly initialized Ethernet chip; check your driver, check your cable. The delay between frames can be because of an RTOS task polling the chip instead of an interrupt driven rx framework. Check your port. The initial delay... if you connect two machines together without a hub/switch, one of them needs to reverse its function (unless you use a crossover cable), that might be both Ethernet chips trying to satisfy the other. A correctly configured chip shouldn't take long, but... check your driver, try with a switch or a crossover cable if you can't get a switch. In any case, you should step through your code to find some answers. Regards -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] RFC1867 HTTP file upload - rawAPI
The web server in contrib (for RAW API) has minimal support for POST and CGI-like functions. You can build an upload with that. For a fork of this supporting minimal multipart/form-data in POST try mine: http://scaprile.ldir.com.ar/cms/el-ingeniero/open-source-projects-im-working-on/lwhttpd/ It is work in progress, and I'll be glad having beta testers other than myself. RAW API only. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwip release
If you check the developers list, you'll see they are busy trying to get 1.5 out The current git head has many bug fixes, no new experimental stuff afaik, except for advanced development in IPv6 and PPP. You can get specific patches from Savannah to fit your needs https://savannah.nongnu.org/patch/?group=lwip or you can run git head. Unless Simon or any of the other main developers says otherwise, I bet you are safe. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Missing ACKs using LWIP 1.3.2
I bet you won't find specific lwIP patches on this because it doesn't seem to be an lwIP bug. Polling the ethernet controller every 10ms is a very bad idea, unless you are absolutely sure there won't be more frames arriving in that time frame than what can fit in its buffer. You should interrupt and buffer/signal and/or poll the controller as frequently as you can. Another common mistake is polling the controller for last frame only, two or more consecutive frames arriving between polls cause only the first one to be retrieved. My bet is that you are constantly losing frames you don't care about, and once a day you lose an important one. You can try fixing the code to be more responsive, or you can try another port. Anyway, I suggest you check it for proper behavior by running netio or something similar. Porting lwIP is not as cumbersome as it might seem, I did. You can try this ARM Coortex-M3 vendor-agnostic port here: http://scaprile.ldir.com.ar/cms/category/os/lwip-port/ you can probably keep your link-layer driver. Let us know. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Lwip with two ethernet ports
I beg your pardon, I don't understand what you are doing and what you are trying to do. I don't think you can netif_set_default() two interfaces, can you ? Two defaults ? And btw, lwIP won't route, or at least it was not designed to do it and has a minimum support for it. Last time I checked there were a couple of hooks you could grab to do it yourself. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Lwip with two ethernet ports
To answer a ping to eth0 coming from eth1, lwIP has to actually route the response. Is it capable of doing that or will it send it to the gateway (which does not exist) ? Have run Wireshark on your PC and checked if your lwIP device is actually sending something ? Have you followed the packet flow inside your lwIP device ? For the future: You won't be able to ping Device_2 from your PC unless: - Device_2 is configured to have Device_1 as its gateway to 192.168.190.0/24; otherwise it will send it to .254, which is... - Device_1 routes -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] problem after a packet loss event
My 2 cents: frame 644 gets lost ... frame 651 says "send 624651" frame 652 repeats, why ? possible software problem here, short timeout ? frame 653 is the retransmission frame 654 ACKs it for good frame 655 says "send 624651" which in this context means "resume sending after frame 650". Your device buffered content in 645+647+648+650 = 4 x TCP_MSS There is a 125ms delay between 654 and 655. Looks like something went out of sync inside your device. What are you exactly doing with that much data you are receiving ? Is it possible that you store it somewhere and that somewhere takes more than expected and a timer times out and then is improperly reset and immediately times out again and the system goes nuts ? Why did 644 get lost ? This is between your PC -> your device. Hardware ? Driver ? Looks like a driver not attend in due time problem. My best guess on the window is that lwIP reduces its size based on the ACK delay between frames 650 and 655, which is the time it took for your app to tell the stack to resume sending. I can't guess why the PC doesn't fill that window, that depends on the app in your PC afaik, but I can tell you that 2352 is not a multiple of TCP_MSS, so only 1 fits in there. Nagle ? Good report, btw -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] problem after a packet loss event
Well, John, I wouldn't blame de lwIP stack without having an actual proof. So far, all packet loss reports have been cause of a bad driver polling the controller for only the first frame (missing the second one in two consecutive frames) or a bad main loop polling the driver at a time longer than the one need to keep the amount of frames being received. I didn't raise this subject before because Fabrizio's capture shows the first frame being lost, is it possible that there are other (maybe broadcast) frames in the wire not being captured/shown by the capture filter ? I would check the stats and put some frame received counter in the netif before blaming the stack, I got myself tired of doing netio transfers in both directions and never got a frame loss problem. Have you guys properly validated your port and your driver with known to work apps ? -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Single connection with "httpd" web server
Hi, a system I used to work with, happened to solve this issue in a very elegant way. You need a tag, a hidden variable in your form, whose value will be received by the browser when loading the form (SSI) and will be incremented by the system at every form submission (CGI). If the received tag does not match the one in the system, then there's been a collision where one configurating user is trying to submit changes based on old data, and another configurating user has already submitted changes in between. The login/logout suggested by Simon can be easily done with a couple CGIs and a timer, and you can also use user authentication. My fork of this web server supports all this (raw API only). http://scaprile.ldir.com.ar/cms/el-ingeniero/open-source-projects-im-working-on/lwhttpd/ Regards -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LWIP LPCWare Example: Questions on Transmit PBUF Usage
Justin, I will assume you are using the raw API: you should check the wiki for the documentation on the proper way to do things lwIP: http://lwip.wikia.com/wiki/Raw/TCP ; the contrib tree for examples on the proper way to do things lwIP: (check echo); and LPCwhatever for what where you thinking when you did that and didn't document it properly. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LWIP TCP server for STM32f107 microcontroller
for lwIP, there is a wiki http://lwip.wikia.com/wiki/Raw/TCP and a contrib tree plenty of (good) examples. for TCP/IP there are books (and universities). Google is your friend, along with Dr. Tanenbaunm, Comer, Stallings. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] DHCP problem with lwip 1.4.1
Please post a wireshark capture. It is hard (if not impossible) to divinate the dialog between them both in order to judge which one is not following the RFC. You must get a hub to plug both wireshark PC and lwIP device or run lwIP in the same box. BTW, your device is... and the port is good because... -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Strategy Question for DHCP
You should see your ping, and the ARP before that... do you ? Did you configure for gratuituous ARP ? Did you see it ? -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LWIP LPCWare Example: Questions on Transmit PBUF Usage
I understand the wiki part on TCP does not talk about PBUFs, that is correct. The rest of my post, after what you quoted, stated that you should check the contrib tree. Those example applications instruct on proper PBUF usage. I'm glad you've found your problem. Regards ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LWIP HTTP Issue sending multiple packets
If you are using an Atmel http server, you should check at the Atmel forums. In case that server is coincident with the one in the contrib tree, and also with the RAW API, and you are not using an OS (which you don't say, btw), I can try to help. I don't understand what you are trying to do, you say you open the connection but you don't in an http server, the client does. Can you please explain how you handle the whole process, if possible in proper http terms, and where does your code differ from the tested and working http server in the contrib tree ? Example: The browser calls for this html page wich does blablabla and then a CGI function gets called which does blablabla and so blablabla. In a system with RAW API and no OS (NO_SYS=1), the user usually reads the eth controller from the main loop, and for every frame the stack gets called, which in turn leads to your application function getting called. Many functions are not reentrant, so you can't call them from within an interrupt handler, you will call tcp_send functions when your app function is called. You will also get called to your tcp_acked function, which will release buffers in order for more data to be sent. If you don't release buffers, then you won't be able to send more data, unless you provide more buffering space, which you do in lwipopts.h I suggest you study and understand the examples in the contrib tree before you dive into writing a full asynchronous application. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LWIP HTTP Issue sending multiple packets
I seem to understand what you are trying to do. Support for CGI is maybe less than minimal in the contrib tree web server; I don't know what Atmel did on this, if any. But, anyway, it all comes down to the basic TCP functions you'll find in the wiki http://lwip.wikia.com/wiki/Raw/TCP You are not sending raw Ethernet frames, you are sending TCP segments, your limit is the TCP MSS buffering space. Check the http_send() function again and you'll see. I bet your problem is that you are not taking ACKs into account. In short and not too strictly true: You may send upto the window size, then you can't send anything else until you get an ACK from the remote side. The stack will inform you when an ACK is received. You then will call the stack to keep sending. The problem from within an http server is... In short: you get the HTTP connection, you enter your app function via the parser (recognizes the GET/POST, the URL belongs to your function, and it is called somehow). Then you will call http_write() or however you decide to wrap the final call to tcp_send(). THEN, you can't send more than what TCP provides in this stage. THEN, you have to wait for an ACK coming, it will go through to http_sent(), which will call http_send(), and this function has to have a way to know that your function has to be called... I don't know if Atmel provided a way for you to do this; you need to study an actual CGI sending data to understand that. From your example, I bet there isn't. If you have lots of RAM, you might buffer all your data in a "file" and serve that file. http_send() is basically written to serve files. Once you understand how http_send() works, you might change it to serve your purposes, but, are you willing to do this ? If you want a webserver with some CGI support and some examples of actually sending data on a CGI function, try my fork: http://scaprile.ldir.com.ar/cms/el-ingeniero/open-source-projects-im-working-on/lwhttpd/ In this server your CGI function is basically a function that just stores data in a buffer and returns. How you handle the asynchronicity between the mic sampling frequency and the http transfer rate is all up to you. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] memory leak ?
You are using lwIP through RAW API Do you have NO_SYS=1 or any OS ? 1.4.1 /HEAD I guess The port is good because it have been validated with a known to work application, not just the one you wrote ? You are seeing an indication that looks like a memory problem. How exactly are you freeing your received PBUFs in your application ? ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] memory leak ?
Tx: yes Rx: if you free them properly then they shouldn't be scarce. Have you tested this ? I'm not familiar with lwIP under RTOS except that you must adhere to the general rule of not calling the stack from different threads. You should check your port with a known good application first. Try echo, for example, or netio; both are available in the contrib tree (and there is nice patch for netio sent by youknowho) ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] DHCP usage
I'm no DHCP expert, but, is there any reason why you have to see something in wireshark when turning DHCP off ? You have been leased an address for a period of time, whether you use it or not is your problem (though I may be wrong). Your pseudo-code looks right to me. If you want to see something maybe you should turn on gratuitous ARP. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ERROR:Assertion failed: "tcp_slowtmr: active pcb->state != CLOSED" at line 662 in tcp.c
I don't know if 1.3.2 has the following comment before the function:
/**
* Called every 500 ms and implements the retransmission timer and the
timer that
* removes PCBs that have been in TIME-WAIT for enough time. It also
increments
* various timers such as the inactivity timer in each PCB.
*
* Automatically called from tcp_tmr().
*/
void
tcp_slowtmr(void)
But I bet it sure has some code looking sort of like this one:
tcp_slowtmr_start:
/* Steps through all of the active PCBs. */
prev = NULL;
pcb = tcp_active_pcbs;
if (pcb == NULL) {
LWIP_DEBUGF(TCP_DEBUG, ("tcp_slowtmr: no active pcbs\n"));
}
while (pcb != NULL) {
LWIP_DEBUGF(TCP_DEBUG, ("tcp_slowtmr: processing active pcb\n"));
LWIP_ASSERT("tcp_slowtmr: active pcb->state != CLOSED\n", pcb->state
!= CLOSED);
As far as I understand, you seem to have an active pcb that stays CLOSED
for too long.
Perhaps you forgot to free it ?
Anything else to give us a clue ?
What are you actually doing with what and how do you end up there ?
--
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] tcp_output.c fault?
Vendor strikes again... You should post this to TI's forums. Your processor looks like an ARM processor, check the hard fault related registers and determine why you are having that hard fault. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] DHCP reboot after link up event
Well, I'm no DHCP expert either Looking at the source and checking RFC-2131, REBOOTING state only needs to verify an existing lease. That can be done by issuing a DHCPREQUEST message with the known ip address. Coherency suggests that given the address is correct, then the client already has all necessary parameters correct, obtained from last request. I would say the problem lies on that subject. Somehow that is not working. Please post a network capture showing first DHCPREQUEST on startup and then the link-down/link-up issue. Please post a log with DHCP debugging (:#define DHCP_DEBUG LWIP_DBG_ON) -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] DHCP reboot after link up event
I see what you mean.
1660c1660,1662
< else if ((dhcp->state == DHCP_REBOOTING) || (dhcp->state ==
DHCP_REBINDING) || (dhcp->state == DHCP_RENEWING)) {
---
> else if ((dhcp->state == DHCP_STATE_REBOOTING) || (dhcp->state ==
DHCP_STATE_REBINDING) ||
> (dhcp->state == DHCP_STATE_RENEWING)) {
> dhcp_handle_ack(netif);
Based on the differences, I bet you could get away with removing that
call to dhcp_handle_ack().
This is due to a bug fix (see below), I suggest you leave a comment on
bug #38203 so you can discuss this with Simon.
http://savannah.nongnu.org/bugs/?38203
git blame:
d6620f0f (sg2015-03-20 20:29:04 +0100 1662)
dhcp_handle_ac
git log:
commit d6620f0f3af60ba1be8c5df795c29dcddcd2698e
Author: sg
Date: Fri Mar 20 20:29:04 2015 +0100
fixed bug #38203 (DHCP options are not recorded in all DHCP ack
messages)
--
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Networking device discovery protocols
I think what you describe (and need) is a simple NetBIOS name server (NBNS for short). It listens on a UDP port 137 for UDP broadcast queries for its name, and responds to matches. You could also configure the DHCP server to assign a DNS provided IP address, so people would find your device based on a proper name resolution. Although that requires you to be friends with the IT guy. Using NBNS will work only in windoze environments, and I personally don't know if that port is still operational in newer systems. Anyway, the name server itself is pretty simple, I wrote a quick hack for it several years ago; it is for another system but I can help you move it to lwIP RAW API. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] How to send data at a defined time?
Martin H., First of all, what are you using ? Do you have an RTOS or are you running on bare metal with NO_SYS=1 ? Second, are you using the RAW API or what ? Then, how exact needs this "defined time" to be ? You can call a send function whenever you want, lwIP (at least the RAW API) is event driven, so you can send UDP by just calling the send function when needed. TCP is a bit more complicated because it is... well, it is TCP. Basically, you can send as much data at once as your buffers allow. What is "lwIP context" for you ? Are you programming in C or what ? Since there is no udp_sent() callback, I have to guess you are using TCP... then, once the connection is established and flow is steady, the amount of time until the sent callback is called is what it takes for the receiving host to send you an ACK, cause that is how TCP works. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Retransmit too quick?
Yes, looks like that to me. Perhaps you have a broken timer implementation and it is expiring ahead of time ? Looks like a "glitch" in a real-time system. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Dead loop inside tcp_output
Perhaps if you share what you are doing ? Is it the RAW API or ... ? Is it NO_SYS=1 or an RTOS port ? And your port is OK because ... ? Have you run a known good application and it works flawlessly ? Are you following the thread-related guidelines ? Your application is ... and you call ... and then you get stuck in the loop. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Retransmit too quick?
If you are using the raw api and no RTOS, then your port should (must)
be calling the lwIP timers function and you don't have to do anything
with timers
(that is what I meant by "a broken timer implementation").
Your main should be something like
while(1){
sys_check_timeouts();
...
}
and you have to make sure it loops often (as it should).
You call the raw api functions only from the main loop, no calls on
interrupts. Do you ?
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Sending with thread safety
If you are running with NO_SYS=1, you don't have an OS and all you have is a main loop or equivalent. From within than main loop you will always call lwIP, no calls from interrupts. This is easy, right ? If you have an asynchronous event, well, you will signal with a flag and take care of it in the main loop; this is no different than what is normal for rx. Sort of: Asynchronous Tx necessity -> set txflag controller -> there is Rx -> set rxflag main loop -> sys_check_timeouts(); rxflag -> netif_input -> tcp_input() -> your application (either tcp_receive() or tcp_sent()) txflag -> tcp_sndbuf() -> tcp_write() -> netif_output -> no room -> tcp_poll() will take care later This is so either for server or client frameworks, and you can see it in the examples, or read it in the wiki: http://lwip.wikia.com/wiki/Raw/native_API If you are running with NO_SYS=0, you have an OS that handles threading. You will always call lwIP functions from within the same thread, or you will use netconn or socket, and/or you will ask someone else, not me. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Retransmit too quick?
Again, you should check how you are handling timers in your port. sys_check_timeouts() needs a consistent time base, it expects you provide a sys_now() function which returns time in milliseconds. You should call sys_check_timeouts() from your main loop as frequently as possible so it does its jobs, it will take care of time by using sys_now(). Sorry, I can't check/follow your code, you should send the first block when you need it and following blocks will be sent via the tcp_sent() callback, check the examples. And, you should not be freeing pbufs the way you are doing in echo_recv(), please check the examples and the wiki http://lwip.wikia.com/wiki/Raw/TCP ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Sending with thread safety
I'm not sure about the timers, but as far as I know ALL lwIP functions must be called from within the same thread (context), you can't call something from interrupt context and then call something from the main loop. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Retransmit too quick?
>So I don't understand why calling sys_check_timeouts without any > delay yields a poorer performance than calling it or tcp_tmr at 250ms > pace. Neither do I. Either your port is broken or your code is not properly written and this condition masks that out. >I think tcp_sent callback is only an option, not a requirement, in > lwip. You are free to think whatever you want. However, that doesn't necessarily need to be correct. Do you actually know TCP ? If you understand TCP, you'll understand why tcp_sent() is not an option, unless you know exactly what you are doing. Now, in my opinion, that is the reason why you are observing that strange timer dependent performance change. >So I think it is OK to use the following flow: > >use tcp_sndbuf to check available buffer >use tcp_write to write data to queue >finally use tcp_output to send out data asap. > >Is my understanding correct? No, afaik it is not. TCP can't send more data than the receiver allows for, so if you don't pay attention to the receiver's ACKs, you will end up with a full buffer, won't be able to send anything, and will be wasting precious time calling functions that can't do anything, hogging your CPU. Then, automagically, you will adjust your timers and suddenly it somehow approaches the receiver's ACK speed and you see an increase in performance. Comer is your friend, Stallings too, be a good boy and read them. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Retransmit too quick?
The RAW API is event driven code. The ACK is handled as an ACK by lwIP. This means the window is updated, the sent pbufs are freed, and you can send data again. You can't send more data until you receive an ACK for your window size. You can't queue more data until lwIP frees pbus (when you receive an ACK). There is no point in calling the send function when you don't have room to queue/send more data, this causes CPU hog. There is no point in calling the send function at specific intervals (assuming you need to send a big bunch of data); if the ACK gets received in between the interval, you'll have dead times where nothing is sent. The write time to call the send function is when the sent callback is fired. You are free to choose and write your app the way you want; but, if it does not work and you ask for help... Good luck. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] new SSI/SHTML parser testers needed
Yes it is. (been on vacations) ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwip-users Digest, Vol 143, Issue 10
tcp_sent() is called when a frame arrives, your port notices it and dispatches to lwIP, and it reckons it is a TCP ACK. All your timing woes depend mainly on your port, as me and many others don't see that in ours and we all run the same lwIP. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Problem with SSI, does not read SSI file content, reads/writes only header.
Your lwIP version ? Your API ? Your port works OK because... Do you happen to use an RTOS or not ? The webserver you are using is ? The one in contrib tree ? If your responses happen to be 1.4.1 or HEAD RAW I tested with echo and the other apps in contrib tree or something equally convincing No, I do have NO_SYS=1 Yes Then, make sure you have actually read all the comments in the source which reference 'SSI', properly setup the #defines required by SSI in your lwipopts.h, named your file with a .shtml extension (or .shtm or .ssi) so the server knows it has to parse it, and you have written and initialized your SSI handler as described in the .h If you fancy using a somehow more "standard behaviour" server, with a simpler and faster SSI engine, and usage examples, check my fork: http://scaprile.ldir.com.ar/cms/category/os/lwhttpd/ -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] What should I do when tcp_err callback
I will assume you are using the RAW API, you are using no RTOS, and you have set NO_SYS=1 A call to tcp_err callback y as indication of a problem in a connection. It has been aborted (reset by the other end) or never setup (timeout on connection attempt). When called, you must free your own resources and not disturb lwIP, since it already did what it had to do. See the accompanying examples in the contrib tree for more information and proper usage, you'll save a lot of time; yours and ours. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Opinions on using lwIP for making application GPRS-chipset-agnostic
What I would do, if I were in your shoes, is to write my app for lwIP, and then either use PPP for those TCP/IP capable GPRS modules and a layer-2 interface (netif) for the other ones. This way, your app is always the same and you only change code for what is below layer-3. You'll have to write your own netif, though. lwIP is a TCP/IP stack which communicates to "the outside world" via interfaces called "netif". Basically you can run it on top of everything where you can write a netif for. The git HEAD contains working PPP code, stable 1.4.1 is OK for everything else but PPP and IPv6, although the maintainers recommend using git HEAD now because 1.5.0 is just around the corner. Your app will be written for lwIP using one of several APIs available. The 'RAW' API, a poem for bare metal lovers; 'netconn' API, more suitable for RTOS accolites; and 'socket' API for the full-OS minds. Pick your own, and please, read the wiki http://lwip.wikia.com/ -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] memory management
There is a comment in mem.c: /** If you want to relocate the heap to external memory, simply define * LWIP_RAM_HEAP_POINTER as a void-pointer to that location. * If so, make sure the memory at that location is big enough (see below on * how that space is calculated). */ #ifndef LWIP_RAM_HEAP_POINTER /** the heap. we need one struct mem at the end and some room for alignment */ u8_t ram_heap[MEM_SIZE_ALIGNED + (2*SIZEOF_STRUCT_MEM) + MEM_ALIGNMENT]; #define LWIP_RAM_HEAP_POINTER ram_heap #endif /* LWIP_RAM_HEAP_POINTER */ ehmm... it is just an array of bytes... how would you instruct your compiler to put YOUR array of bytes in whatever it is "external memory" for your particular application ? Then do it that way. For example, if you are running on an ARM Cortex-M3 with an external memory space going from 0x600 to 0x700 and you happen to have put your RAM chip decoded from 0x6400 upwards and you happen to want to have your heap there, then you will read your compiler manual and figure out how to tell it to use 0x6400 as a void-pointer, and then you will write the macro LWIP_RAM_HEAP_POINTER accordingly: #define LWIP_RAM_HEAP_POINTER ((void *) 0x6400) works (at least) on Keil and IAR and seems to be CMSIS compliant. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Question regarding how to access a linux lwip application from outside
How would you access any application on any machine other than the one connected to the Internet inside your home/workplace ? Exactly. A tap interface is no different from another Ethernet interface, so your Linux box will route/firewall/NAT and that is a whole adventure which is not related to lwIP whatsoever. Forget about NAT if you run IPv6. Assuming your box is already configured, just add the tap interface. Otherwise, there are a lot of tutorials you'll have to follow. The main point here, if you run IPv4, is that you'll have to configure port forwarding so your application is seen from outside at a particular port. You'll use private addresses for the lwIP stack. Another problem is that the lwIP interface goes on and off with the process, so don't expect to see it on ifconfig while lwIP is not running; unless you configure it to stay permanent, which I don't know how to do it. My best bet is you add your firewall rules after lwIP is running. In most real applications, you won't have lwIP running on your linux box connected to the Internet but on an internal machine, so this is the most generic recipe. This is in no way complete and/or advisable, you better read the how-tos and do your own math. This is how I forward a port to my son's computer with iptables: # forward UDP 5000 (Voobly) to Fer iptables -t nat -A PREROUTING -i $EXTIF -p udp --destination-port 5000 -j DNAT --to-destination 192.168.69.70 EXTIF= the interface connected to the Internet. So UDP 5000 traffic to my Internet public IP is forwarded to the same port on an internal machine. Replace 192.168.69.70 with your lwIP box address. You'll have two addresses: one for the "router" and one for the "machine". Use the "machine" address, the "router" is like an internal address for an internal Ethernet card. Read /contrib/ports/unix/proj/unixsim/README When you setup your netif, the tap interface will be started and assigned the address you set for your gw. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Opinions on using lwIP for making application GPRS-chipset-agnostic
> > and a > > layer-2 interface (netif) for the other ones. > > This way, your app is always the same and you only change code for what > > is below layer-3. You'll have to write your own netif, though. > > lwIP is a TCP/IP stack which communicates to "the outside world" via > > interfaces called "netif". Basically you can run it on top of everything > > where you can write a netif for. > I don't understand why Sergio is proposing that, lwIP embeds a full > featured PPP stack and all GPRS modems I know are able to do PPP. Yes, same here, all modules I know are TCP/IP capable and PPP capable. The OP mentioned some modules/chipsets which are not TCP/IP capable and I assumed they weren't PPP capable also. As long as the chipset/module supports PPP, you rule and dinner's ready. Otherwise, long way to walk on the netif road. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] memory management
> It's much safer to integrate this with linker script (for example > with attributes on gcc). Casting number to pointer does not > guarantee that other variable will no be placed in the same area (by > linker or other Dev using such tricks). Happy debugging when it > happens :) Yes. However, in this particular example, since by definition of external memory there is no on-chip memory at that location, the linker will not assign any variable to that memory space. As for other Devs... well, let's say all developers know the external memory map... Had that "double allocation" happening once when toying with fixed addresses in internal memory though, don't remember what I was doing and why I did that... Nice pointing that out anyway! AFAIK there is no CMSIS way of assigning segments, is it ? (but that is completely off-topic) -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Call tcp_close() out of tcp_recv()-context?
It depends on what you mean by "context". If you don't have any kind of OS running, you have one thread and interrupt handlers, you can safely call lwIP RAW API functions from your main thread. It is not safe to also call from interrupts. If your application depends on interrupts, just set a flag or equivalent and let the main thread react to that. If you have an OS, you have to keep everything on one thread or use another API. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Call tcp_close() out of tcp_recv()-context?
There is no "possibly" here, if you call lwIP RAW API functions from within an interrupt, you can't also call them from the main thread or other nested interrupts. All calls to lwIP RAW API functions must happen from within the same context, they can't interrupt themselves. Check the examples in the contrib tree. Read the wiki http://lwip.wikia.com/wiki/Raw/native_API You can call tcp_close from your my_recv. Make sure your "my_send" (if any)is not interruptable by your my_recv -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] How to get rid of TCP Retransmission and PSH flags
> I don't know where to start. You could start by correctly describing what you are trying to accomplish, with what, what API are you using, and what lies under. lwIP version API OS ? port: has it been validated ? (works OK with known good apps) netif driver: same here Application Regarding "newbie": Do you actually have some TCP/IP knowledge and need help with lwIP or you are a complete newbie ? You should have some networking knowledge to develop networking apps. Do you ? Regarding your capture files: who is who ? TCP retransmissions can be caused by lost frames or timer issues (among other stuff). Check your port. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] porting
lwIP runs under Un*x, that includes GNU/Linux and so Raspbian, hence the Raspberry PI. You already have a full featured TCP/IP stack there, why do you want to run lwIP ? -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] UDP and TCPIP at the same time
If you mean "UDP and TCP" at the same time, that depends only on your available memory. If you compile TCP in and UDP in, and you have enough code memory for it to run and data memory for them to use, then yes. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Patch to update from 1.4.0 to 1.4.x?
There is no reference to 'GMAC' in the whole lwip tree. That seems to be Atmel stuff and you should ask them -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Patch to update from 1.4.0 to 1.4.x?
Well, I'm by no means even close to an expert, but afaik that certainly depends on how you configure lwip. PBUF_RAM is a single consecutive chunk of RAM for a pbuf, taken from the heap. PBUF_POOL is a pbuf which is itself a chain of pbufs, which are chunks of RAM taken from the pool. Allocation of a PBUF_RAM uses mem_malloc() Allocation of a PBUF_POOL uses memp_malloc() Depending on your configuration, memp_malloc() can be #define'd as mem_malloc() (when MEMP_MEM_MALLOC is defined and != 0 ) So... you'd better check their lwipopts.h afaik, for a "common" use, the pool and the heap are separate pieces of RAM and the phrase you highlighted is controversial, but since it involves macros not belonging to lwip... -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] IP connection going down spontaneous
Sandra, lwip is stable, you should check your product. As you probably know, there is no such thing as an IP connection, so if you are specific on what you are doing and what is the problem you are having, there is a chance to find a solution or at least the culprit. If you want to take traffic captures and post links to them, I'll be happy to take a look. If you want to log lwip messages and describe what your usage is (NO_SYS, OS, API), sure someone will be happy to look at it and suggest. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] IP connection going down spontaneous
Hi Sandra, You seem to have an issue that gets noticed with a traffic pattern. Try to find a way to log stats somewhere because I can't imagine a way to figure this out without logging or real-time debugging. Try ARP flooding locally, maybe you are lucky. You might have an improper driver leaking memory, or one of your apps not behaving correctly, but I can't see further as I don't know the socket API and how it works with multithreading. Try to start a new thread with a more specific subject line if no one else jumps into this one. Regards -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LWIP and Websockets
Leonardo, you have some board using some port from some manufacturer which uses what API interface ? And runs with or without an RTOS (NO_SYS) ? And that webserver is ? As I see from your code, it looks like it is the RAW API with callbacks, however, you are interacting with the webserver code, not with lwIP directly. You should ask the ones who wrote the webserver code for guidance. It looks similar to the lwip httpserver_raw code in the contrib tree. As far as I can see, in that server, we don't play around with tcp_sent(), it is setup at connection establishment. Then, you are messing around with 'hs', the server http_state structure, which has many more fields than the ones you are setting up, so it is quite likely you are delivering the server an inconsistent structure and it fails to do its job. If you expect the caller to send more data after you received something, you have to call tcp_recved() before freeing the pbuf. Then I guess the next data to you won't honor your 'requestType' detection, so you should establish a state machine there. And you are patching this in what function ? A web server is a delicate piece of code and you are not expected to be modifying around without knowing exactly what to do. I have a working beta of a (somehow more polished) fork of the contrib tree web server here: http://scaprile.ldir.com.ar/cms/el-ingeniero/open-source-projects-im-working-on/lwhttpd/ If your application works with NOSYS=1 and the RAW API, whether you decide to use mine or the "official" one, I can try to help you. If you want to use the one that came with your manufacturer board, you have to ask them for help. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LWIP and Websockets
> - If I need to wait for a handshake in the HTTP form, it would be fine > if I start with a HTTP server. As I understand it, HTTP server is mostly > a TCP server with some retries and the particular communication scheme > (Get, post, etc.). No it is not >> A web server is a delicate piece of code [...]. An HTTP server is a statefull machine, and the fact that you are not working with sockets but with callback functions makes it even more complicated and cumbersome to follow. > I will take a look at your code to try to figure this out. It can be > something with the HS for sure. It's weird that I am doing the same that > they do and it doesn't work... Evidently you are not, otherwise it would work... ;^) > For me, if I get XX from http_recv it > should be easy to send YY back as a response. HTTP should be the next > step, right? You don't have a single point of entry, your application is distributed among many functions, you may not get the whole request at once, you might not be able to send the whole response at once, etc. You need to modify the http_parse_request function to understand the websocket request. Then you have to serve your response instead of the server's standard response with is send_headers + send_file. If you don't return the proper value, your data won't be sent. If you hog tcp buffers, your data will stop being sent and nothing else will work. Then, you have to patch other functions so next coming dara is sent to your websocket server and not rejected as unknown data. Essentially, HTTP was not conceived as a bidirectional protocol and so is the server, so you might find this is not easy to do. Your first step now should be to determine if the web server your vendor provided is the one in the lwIP contrib tree or it was modified by them. I don't see references to decodeHttpMessage() (and it doesn't follow the lwIP group code standard guidelines for naming convention) $ grep -R decodeHttpMessage * $ so my bet is that that webserver does not belong to lwIP but your vendor. Then, you have to choose whether: you'll use that webserver, in which case you should ask your vendor for help you'll use the contrib tree webserver, in which case you'd ask this list for help you'll use my fork of the contrib tree webserver, in which case you would ask me for help. If you are not in a hurry, I can try to add support for this to my server, but I'm quite busy right now. Regards -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LWIP and Websockets
> What do you mean with proper value? I mean the value you return when you exit in a function, the whole web server code knows what the callee has done and needs to be done by means of the returned value. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Tcp Window Update generation forcefully
It is hard to suggest a solution when there is no description of the problem. If you are thinking on making changes to your code, you should upgrade to the latest code, there's been lots of upgrades and bug fixes and I don't think you'll find someone willing to help on 1.3.1 You mention Modbus/TCP and "serial to Ethernet" Are you connecting two Modbus devices via a serial connection transported over TCP or are you connecting a (serial) Modbus device to a Modbus/TCP device ? Did you implement Modbus/TCP in any one of them or you pack Modbus messages into TCP segments ? Are you spoofing messages or do you just bridge them ? Do you use ASCII or RTU ? How do you determine the end of the message ? What API are you using ? Raw/Socket/Netconn ? Do you have an RTOS running ? (NO_SYS=???) What is the problem you have ???!? I know Modbus and it can be picky about delays, but certainly I don't see how it won't work with a faster connection, since messages can't arrive faster than they are sent; do you need to throttle the server ? Who is the server ? Who is the client ? You say you want to generate window updates for client requests, but afaik in Modbus the one who requests is the server... please give a thorough description of your problem. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Bug on lwIP TCP section (or HTTP client from contrib)?
There are two HTTP servers on the contrib tree. Which one are you using ? RAW API or ? The webserver worked more than OK the last time I checked. If you modified it and it doesn't work, common sense dictates you rollback and examine if this issue you notice can be observed on fresh code. If you can observe this issue on fresh code, from GIT HEAD or from 1.4.1, and you are using RAW API with NO-SYS=1, on a tested and known to work OK port, with a tested and known to work OK linklayer driver, I'll be happy to help. There is a fork of the RAW API server with added authentication (and other stuff) on my site: http://scaprile.ldir.com.ar/cms/el-ingeniero/open-source-projects-im-working-on/lwhttpd/ Feel free to use it if it satisfies your needs. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Bug on lwIP TCP section (or HTTP client from contrib)?
yes, you are right. I don't remember seeing the RSTs last time I checked, I switched to my own fork long ago, and as I don't have the time to look at it in detail, I am not able to test for a "maybe" a bug. Since Simon signals this one as a possible bug, I'll try to see how I can help, as it probably affects my code also. Please describe your API and NO_SYS when you open your bug (you didn't tell, yet). ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] http client
Perhaps his is not the place to look for that info, and I don't know if you are looking for the POST method details in the HTTP spec or you want working examples for doing that with lwIP. In the first case, you should google for HTTP POST ;^) In the second case, would you be so kind to describe which API you are using and what is the problem you are facing? -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Bug on lwIP TCP section (or HTTP client from contrib)?
I forked because I wanted to have some stuff and it was really complicated to coexist with the current state of CGI and POST. Thanks for your compliments, I'd be more than glad to help in merging and even maintaining. I still have some stuff to add and fix in authenticated multipart POST, I've been quite away from this this year. Your description is quite good, as soon as I have some time I'll try to see what is going on. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] http client
OK, RAW API and NO_SYS=1 then. I guess this will be easier with socket or netconn, but since you require small code and no OS, RAW API is great. As the other guys remarked, an http client is quite complicated. However, just sending a hardcoded POST is not (quite) complicated. You need a simple TCP client, you can build one with the info in the wiki: http://lwip.wikia.com/wiki/Raw/TCP Then, as you probably know, you have to choose the way you will pass your data to the server, either form or multipart. The easiest way, if you won't make changes on the server side, is to use a GET and just pass the parameters on the URL. If you must use POST, then it gets more involved. The other point is if you need authentication, which makes things a bit more involved too. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwIP UDP Receive Issues - RAW API
Your recv function looks fine, but since it is not called, it is quite likely the problem is not there. Please post your setup, check for return values, and by all means check your driver and port. Please single step a received frame and see if it is delivered to the stack and then to your function. "Ethernet interrupts" are OK as long as you do not call lwIP on interrupt context and main context. Choose only one. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Questions about how to get a robust lwIP TCP Raw API server application.
Sorry bom, please don't consider this as thread hijacking, I think you'll find this useful too. I do work on baremetal, and always thought a move like DP's is OK, I don't see any problem with that. OS task switches would be seen by lwIP as peripheral interrupts. As long as all lwIP calling code is in the same thread, I don't see any issues. Yes, perhaps using the OS would take advantage of it, but not using it enables porting code from bare metal to OS a no hassle. Otherwise, one would have to keep two copies of his applications. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Duplicate ACK issue lwIP 1.4.0
Yes, same impression here, as Enrico said, your dup ACKs are yuour .65 machine asking for the lost frame to be retransmitted. Your layer-2 driver seems to be broken. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Compilations errors with MEM_USE_POOLS
/** * MEM_USE_POOLS==1: Use an alternative to malloc() by allocating from a set * of memory pools of various sizes. When mem_malloc is called, an element of * the smallest pool that can provide the length needed is returned. * To use this, MEMP_USE_CUSTOM_POOLS also has to be enabled. */ Did you ? /** * MEMP_USE_CUSTOM_POOLS==1: whether to include a user file lwippools.h * that defines additional pools beyond the "standard" ones required * by lwIP. If you set this to 1, you must have lwippools.h in your * inlude path somewhere. */ and this ? What are you running ? 1.4.1 ? git HEAD ? -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Missed Ethernet Frame
My best bet is that lwIP is not missing an ethernet frame, but you are. Your frame enters your chip, goes to your driver and is then sent to lwIP, which runs in your system (your port of it), then the TCP data (I guess you are using TCP because you talk about ACKs) is sent to your application, and your application must tell the stack the data is done so lwIP can ACK. Let's put this last one aside as it is a bit more involved. Have you checked between your driver and lwIP ? Have you checked between your driver and your chip ? Is your port a good one ? Do you know it works OK ? BTW, are you running with or without an OS (NO_SYS=?) Are you honoring the thread-safety recommendations ? That includes not calling lwIP from main loop and interrupt handler at the same time. This list has seen lots of reports from people running vendor provided demos with broken drivers that miss (at least) the second frame on a burst because they don't poll the chip for more data after an interrupt, and so on. Try to be more specific, 1.4.1 runs more than OK, and git HEAD has lots of bugfixes, you should upgrade anyway, but to me this problem is not lwIP's. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Bug on lwIP TCP section (or HTTP client from contrib)?
Enrico, can you provide a trigger ? My wireshark screen is all green... I mean, please provide an HTML that I can include in my code that you know forces this behaviour. I remember getting RSTs when POSTing to authorization required pages, the browser sends the whole pack and the server stops immediately. This is my fault and I will address it some day, but what you describe is exactly the opposite, the client sends FIN+ACK. I'm I correct ? I've tested with Firefox 41.0.2 and now 42.0 on Windoze, and my test bed is my lwHTTPd over the minimal unix port. My LWIP_HTTPD_SUPPORT_EXTSTATUS is #defined to 0 My server sends the 401 header and status in one TCP segment in one Ethernet frame. Please provide your config too; I don't quite get the issue (my fault, not yours), but I seem to understand from what you describe that the 401 header is on one frame and the HTML status on the next one ? My code is optimized not to do that unless memory is scarce. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LWIP_ERROR when LWIP_SDK_DEBUG is not defined
$ grep -R LWIP_SDK_DEBUG * $ There is no such SDK for lwIP as lwIP is not a commercial product, LWIP_SDK_DEBUG has been introduced by your vendor, and you should address your vendor, whoever it is. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Bug on lwIP TCP section (or HTTP client from contrib)?
OK, I see. I'll try to trash my server so it sends headers first and then status, on two frames (I've spent a long time polishing it so it does not... unless there is absolutely no room). BTW, what is your MSS and so ? can you attach your lwipopts.h please ? I might have some spare time tomorrow. I only have Chrome on a tablet, will try with that -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Bug on lwIP TCP section (or HTTP client from contrib)?
As a matter of fact, if I'm not wrong, it is the server who must close the connection and not the client, so this is Chrome's bug. However, you mentioned a "off by 1" in the window so I'll try to see that and what the culprit. Ciao -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Missed Ethernet Frame
Hi Colin, I'm sorry I can't help, I'm not familiar with the socket API. Try opening a new thread with your specific issue, and specify you are using the socket API. Please include file and line number where you see the packet is dropped. As far as I can see, TCP drops because the upper layer can't handle, maybe you are not getting data fast enough out of the socket API, but again, I'm not familiar with it. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
