[lwip-users] new SSI/SHTML parser testers needed
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 this engine supports standard 'echo var' and 'exec cmd' tags (but resorts to exec unknown tags, so old non-standard tagging should work), and might (not yet decided) change the way cmd functions get their parameters and provide status (based on user preferences). Just comment on this thread. Regards PS: I'm using lwIP1.4.1, so you might need to upgrade too. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] Receiving of data slows down / lwIP 1.4.0
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 don't find the answer, post whatever calls for your attention + capture files + oscilograms and I will try to help. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Receiving of data slows down / lwIP 1.4.0
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 don't find the answer, post whatever calls for your attention + capture files + oscilograms and I will try to help. -- ___ 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
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
Re: [lwip-users] TCP Retransmission when receiving consecutive packets
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 and the driver can't find enough memory to
store the packet.
If I would have to hunt this witch, I would start by setting a
breakpoint on the Ethernet driver low_level_input() routine, somewhere
around here:
static struct pbuf *
low_level_input(struct netif *netif)
{
[...]
/* We allocate a pbuf chain of pbufs from the pool. */
p = pbuf_alloc(PBUF_RAW, len, PBUF_POOL);
if (p != NULL) {
[...]
read data into(q->payload, q->len);
}
acknowledge that packet has been read();
[...]
} else {
drop packet(); <-
It actually depends on how the one who actually wrote the driver wanted
to make it difficult for you.
Let me know how it goes.
Cheers
--
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP Retransmission when receiving consecutive packets
> 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 since I didn't write the code, but that is what I understand by "single-threaded" and what I did on my driver) As you are using an RTOS, it surely dispatches a task to get the frame(s) later. The frames should happily rest inside the eth chip (or equivalent) until them, providing there is enough memory for them. The chip I use has 13K devoted to that. > It seems to imply that calling ethernetif_poll in an IDLE thread will > only process on packet even if multiple interrupts have been raised : Many eth chips issue only one interrupt for the first frame, the driver then checks for how many outstanding frames there are. check here --> ethernetif_input (netif); it should have some form of a do while loop > Could that have anything to do with my problem ? IMHO, yes, quite probably, if that function does not perform a loop to get all the outstanding frames. Sorry but you'll have to learn your chip to check how it issues interrupts and buffers frames, and then check the driver. One quick try: send ping floods and see if you get the same behaviour. Pings are answered at the very first part of the IP processing, so if pings are OK, the issue is not probably inside the driver (do check inter-ping time with wireshark) Regards ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP Retransmission when receiving consecutive packets
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 drivers for the DM9000 to write my driver, and I've seen they read all the packets out of the chip every time; then I setup a simple test to see if interrupts would trigger on every frame or only on empty buffer, and guess what... empty buffer only (there is no int ack here) Looks like we've got a different situation here, the chip seems to be issuing an interrupt after the first one is ACKed, as you Jens described for your case. Julien, can you confirm this from the chip docs ? Pitty one has to fix the drivers for a manufacturer, maybe someone in ST can lend a hand ? -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] proper pbuf usage for TCP -> real-time in raw API NO_SYS=1
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 check my assumptions are true); The application might already have an outstanding pbuf, so the receiving function pbuf_cat()s the new pbuf. When the application is finished handling prior data, it will tell the receiver the amount of data freed, so it can tcp_recved() that amount of data (in the long run, the TCP window will somehow adjust the throughput). Then, at some point, the amount of data used will cross a pbuf boundary, so it should be freed. Furthermore, as I (think I) understand, pbufs could be chained, and the two pbufs I mention are in fact chains of pbufs (a full Ethernet frame coming into a PBUF_POOL ?) 1) I wonder if there is a proper "standard" way of handling this situation, an example application, or whatever. 2) I thought of using pbuf_header(), but I noticed it only adjusts ->tot_len for the first pbuf in the chain; so I guess I'll have to manually move pbuf by pbuf, comparing to their ->len, freeing them one by one, and then adjusting with pbuf_header() for the last in chain ? 2.a) If so, then, could we add this function to pbuf.c ? Clue: (1) Please, don't point me straight through to the POST code in httpserver_raw, cause I see it does (2) to remove the header, but I don't see it doing any pbuf_free later on for the rest of the content (except probably for the last one, didn't check too hard) Best regards. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] proper pbuf usage for TCP -> real-time in raw API NO_SYS=1
...
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 don't have enough memory to buffer incoming data, we must. So,
delaying tcp_recvd() will have this effect, be ready to have some
"external" (to the lwIP stack) way to revive and call tcp_recvd()
because the lwIP won't call your receiving function again unless there
is new data.
lwIP is zero-copy, so, if your link level driver allocates pbufs as
PBUF_POOL (as in the ethernetif example and my DM9000 driver), then your
receiving functions will get pbuf chains of PBUF_POOL_BUFSIZE (plus some
possible alignment overhead), unless received data is (of course) smaller...
So, once you are done with some part of the data you received (and
called tcp_recvd()), either if you manually concatenated two pbufs or
not, if the amount of data you have just processed is >= chunk size, you
are ready to free pbuf chunks one by one by moving through the chain.
To get rid of one pbuf in the chain, you have to reference the next one
by calling pbuf_ref(q=p->next), and then pbuf_free(p). Then, p is freed
and q is your new pbuf holding the rest of the data. (This is true if
"you" are the only one using those pbufs, that is, no other task is also
referencing them).
To hide any remaining data at the beginning of the pbuf (for example
after the former process or when you have just processed < chunk size),
you can call pbuf_header().
Assuming you have a valid p chain, holding more data than you just
processed (because you have just done that from that chain), the former
text explanation resumes to something like this:
while(p->len <= processed_data) {
struct pbuf *q;
processed_data -= p->len;
q = p->next;
pbuf_ref(q);
pbuf_free(p);
p = q;
}
pbuf_header(p, -(s16_t)processed_data);
Add any safety checks that make you feel safer, and you are done.
In a NO_SYS=1 environment, there is a shortcut by manually manipulating
the pbuf fields instead of referencing, but you know that may break
future compatibility and violates some good practices, don't you ? ;^)
You must return ERR_OK to the lwIP functions once you have freed the
whole pbuf yourself.
--
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] raw api tcp_write()ing small chunks fills snd_queue
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 = 536 TCP_SND_BUF = 2*TCP_MSS TCP_SND_QUEUELEN = (4*TCP_SND_BUF + TCP_MSS -1)/TCP_MSS TCP_OVERSIZE = TCP_MSS MEMP_NUM_PBUF = 30 MEMP_NUM_TCP_SEG = 16 PBUF_POOL_SIZE = 32 PBUF_POOL_BUFSIZE = TCP_MSS+overhead (default) My operation: Get a request tcp_write() with apiflags=0; 5 times, with ~20-byte messages len = tcp_sndbuf(pcb); len = LWIP_MIN(len, 2*tcp_mss(pcb)); tcp_write(,len,0) 900-bytes fails, 450 fails, 225 succeeds debug log is: "tcp_write: queue too long 9 (8)", that is, line 581 of tcp_output.c (in 1.4.1 release), Phase 3: Create new segments. As I understand, those small nocopy tcp_writes generate a queue of type PBUF_REF, which added to something (? there is no prior traffic in this pcb, only a just recently closed connection for a prior request) leads to a queue that is too big for this segment. Instead of just increasing TCP_SND_QUEUELEN, or avoiding those small writes (which I can't right now), I'd like to understand what is going on and don't have the same problem later. I've tried inserting a tcp_output() call between the small writes and the big one, with no difference. I guess this is because tcp can't get rid of the chain until the remote end acknowledges this segment and I'm still holding the CPU. I've set TCP_WRITE_FLAG_COPY for the small writes and it works OK (and this is what I would do if there is no other option to try) I'd like to hear suggestions, explanations, criticism, pointers to documentation I overlooked, whatever. Everything is welcomed. Regards -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] raw api tcp_write()ing small chunks fills snd_queue
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
Re: [lwip-users] need help building netio server
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 re-wrote the tx part on that one, so we all can have something (far from ideal) but probably good enough to catch some flaws when developing link-layer drivers. And yes, I've added it to that patch, found here: http://savannah.nongnu.org/patch/?7026 -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Transport terminal Using Tcp - ask for help~
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 your application is well written. 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 ? Check the code in the contrib area, smtp.c and httpserver_raw/httpd.c are good examples on how to use the TCP functions. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Transport terminal Using Tcp - ask for help~
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 -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Transport terminal Using Tcp - ask for help~
Simon said: > I still don't know what the OP's problem is, though. Same here, although on one of the "I didn't change the subject" mails I found his response: > Thank you for your answer. > I have found my fault. > in tcp callback , i had not call tcp_recved(tcp, p->tot_len); Well, I didn't nail it (my 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 ? -- --------- 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] TCP Checksum = 0xFFFF
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
Re: [lwip-users] broken DHCP/ARP interaction
Hi, Quick&dirty 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- 0.0.0.0 In scenarios 1 and 3, everything works "as expected" In scenario 2, I see a "gratuitous ARP", but the address is accepted anyway. Here is my capture: No. Time SourceDestination Protocol Length Info 1 0.0192.168.1.42 255.255.255.255 DHCP 350DHCP Discover - Transaction ID 0xabcd0001 2 0.001705000192.168.1.1 192.168.1.42 DHCP 342DHCP Offer- Transaction ID 0xabcd0001 3 0.002564000192.168.1.42 255.255.255.255 DHCP 350DHCP Request - Transaction ID 0xabcd0002 4 0.04042192.168.1.1 192.168.1.42 DHCP 342DHCP ACK - Transaction ID 0xabcd0002 5 0.0408410003com_03:04:05 Broadcast ARP 60 Gratuitous ARP for 192.168.1.42 (Request) Frame 5: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0 Ethernet II, Src: 3com_03:04:05 (00:01:02:03:04:05), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Address Resolution Protocol (request/gratuitous ARP) Hardware type: Ethernet (1) Protocol type: IP (0x0800) Hardware size: 6 Protocol size: 4 Opcode: request (1) [Is gratuitous: True] Sender MAC address: 3com_03:04:05 (00:01:02:03:04:05) Sender IP address: 192.168.1.42 (192.168.1.42) Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00) Target IP address: 192.168.1.42 (192.168.1.42) 6 0.499763com_03:04:05 Broadcast ARP 60 Gratuitous ARP for 192.168.1.42 (Request) I suggest you check your options and step the code to see where this rejection takes place -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] broken DHCP/ARP interaction
I suggested the Q&D 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, I'm just trying to help so I won't have these problems myself in the future, and I'm willing to peek in the sources to give my opinion or propose a patch. Unfortunately I can't duplicate your scenario so I can't dive deeper. As far as I can follow the analysis, you are right, and the DHCP code seems to rush to assign an IP when it should wait after the ARP validation. Try to find that with a breakpoint and tell us what you see. Try also following the maling list thread and keep us posted, someone else might have submitted a patch or a (more elegant) workaround -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwip recv callback questions
Hi, following is MY opinion (and experience) 1: Since the callback function is called by the stack as I instructed, I wouldn´t answer with ERR_ARG, since arg is just as I instructed the stack to call me... so, if you still do it because you don't trust the stack, then don't rely on it to stop calling you the wrong way... goto 3; 2: Once you tcp_recvd() those bytes and answer ERR_OK, you are the owner of the pbuf, you can free it when you want. Remember that that memory won't be available to hold new packets until you release it. 3: Vendors do what they think will sell more. I wouldn't use 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 (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] lwip recv callback questions
> 1. Can you point me to a description of how to use the different error codes, then? Just follow the goto 3 >> 1: [...] goto 3; >> 3: [...] check the available examples in the contrib tree: SMTP for a >> client, netio/httpserver_raw for a server AFAIK callback functions return ERR_OK when they do 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 opinion (and experience) > > 1: Since the callback function is called by the stack as I instructed, I > wouldn´t answer with ERR_ARG, since arg is just as I instructed the > stack to call me... so, if you still do it because you don't trust the > stack, then don't rely on it to stop calling you the wrong way... goto 3; > 2: Once you tcp_recvd() those bytes and answer ERR_OK, you are the owner > of the pbuf, you can free it when you want. Remember that that memory > won't be available to hold new packets until you release it. > 3: Vendors do what they think will sell more. I wouldn't use 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 (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] lwip and fragmented http messages
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 standard SSI and CGI with POST, give it a try if (1): http://scaprile.ldir.com.ar/cms/el-ingeniero/open-source-projects-im-working-on/lwhttpd/ For (2), please post a wireshark capture file and I'll try to help. When I tested my code, I went the other path, testing to smaller MSS sizes. Didn't occur to me that somebody might have plenty of memory, that is never my case... Regards ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] DHCP request fails after 5th try (memory leack?)
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 udp_new() caller ? I'm not familiar with the DHCP code but it is not too hard to follow. Regards ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] unix port: simrouter SIOCADDRT: No such device
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: make ARCH=cygwin ARCH=linux There is also a line #To compile for openbsd: make ARCH=openbsd in the makefile for 'minimal'. I don't recall right now, but if you follow the docs (yes, that all caps README file) you'll get through it. This is related to the particular network interface to use in every particular system, because some systems have /something/tun, others /otherthing/tap, and so on. The demo program is trying to patch into your system's networking stuff so lwIP can see it as a link-level device, and it can't do it if you don't tell it which system you have (otherwise the demo programmer would have to spend more time diving inside every possible system than doing the demo itself) Regards ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Routing and link up/down vs. netif up/down
> 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 case you should run your app on a full fledged Linux system. You'll see, when the dinosaurs ruled the earth and I was studying networking, Cisco's did not allow two interfaces within the same subnet. The definition of "routing" requires different "networks". Since then, some strategies were developed, like for example having a bridge before the router and so the router sees a virtual interface which is virtually connected to the virtual bridge, which has two more interfaces, belonging of course to the same subnet because it is a bridge. As both interfaces are on the same device, a switch is a simpler concept. Things may have changed, but since IPv4 and Ethernet are still the same, I don't think Linux might actually do anything radically different from this, although it does it internally and you don't see it, and it does it good. The lw in lwIP stands for light-weight, so if you require a heavy-weight you'll have to lift it yourself. I would start by writing a netif driver for a non existent simple pseudo-device that will connect lwIP to "the switch", and then write the switch code to do what its name suggests among the external, aka "real" interfaces, keeping one and only one active (otherwise you'll have a bridge... and you'll have to avoid repeating yourself. If I were you, I would instruct the user not to do what is not intended to do with the device. But I'm not. Regards ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] unix port: simrouter SIOCADDRT: No such device
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 something here and there. My system is a CentOS 5 which has been iteratively upgraded from a RH7.1, so I can't tell you if there is a package needed to have a tuntap interface working. My bet is it should work out-of-the-box, so fire a ddd and follow the clues. Did you run simhost ? Try that one first, simrouter plays with other interface. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] tcp_write fails: package generation doesn't work properly
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 check its returned value to confirm data has been sent. Have you run any other (supposed to work) example on your client before trying this your own code ? Assuming the port is working and you are calling lwip functions from only one thread, have a look at the examples in the contrib area, smtp.c is a master piece of an example for a client. Also, the wiki is not bad at all. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] Ethernet link state: needed ?
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 attached to the network, and not mobile devices like a laptop. My question to the lwIP users: does anyone have the need to know the link state ? Can you share why ? Thank you, regards ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] change PHY and strange behaviour
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 in your text, and in the hypotetical case that that is what is going on, you might see something like that. 2) In case frames are being lost, we need to find where. 2.1) I don't know if you have the proper (expensive) tools to see the signal at the wire and check the pcb design and magnetics are working OK. Do you ? 2.2) Same for the interface between the micro and the PHY. Those are differential pcb traces and require some hardware knowledge. 3) In case frames are not being lost and every echo reply is for the latest echo request and yes, there is that strange "wraparound" delay: we'll try to find out the source. A logic analyzer will be helpful. Do you have one ? Regards ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] DHCP request fails after 5th try (memory leack?)
Good to know! ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] Re. Re: Ethernet link state: needed ?
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 from one network to other, and doing that on an embedded system without power cycling is really rare. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Re. Re: Ethernet link state: needed ?
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
Re: [lwip-users] Encoding problem for received packet?
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 between and don't realize. There si no encoding nor the concept of that, either on lwip or on TCP/IP today. You send bytes, you get bytes, so try to use a debugger and watch memory first. (Words may have endianness issues, but lets leave it on bytes for now since this is ASCII text). If Wireshark shows the packet is correct (at the byte level), then you should get your TCP payload out of the tcp_recv receiving function, inside a pbuf p, at p->payload. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Missing ACKs in Websocket echo server
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 download the examples in the contrib tree and study them. There you will see how a tcp_recv() callback has to work. tcp_recved() tells the stack you have taken care of the data, so it can manage ACKs, but to work, the stack needs to be called when an Ethernet frame (for example) arrives. You provide no info on what you are doing and how you call the stack, whether you are using bare metal or an RTOS, and I could guess you use the raw API because you mentioned tcp_recved() and tcp_recv(). Have you confirmed your tcp_recv() function is called on incoming frames and there is no delay there ? ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Problem after lwIP update (1.3.0 -> 1.4.1)
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 ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] [LwIP-1.4.1 + ChibiOS-2.6 + STM32F407] memp_malloc: out of memory in pool PBUF_POOL
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 the port ? Has it been thoroughly tested ? (I just don't know of it, but I'm no expert whatsoever) - A google search for STM32F407 yields it has a huge amount of RAM, so it is not likely that the compiler let you compile for more RAM than you actually have. However, the stack/heap you configured (or your OS did for you) is probably not enough for whatever you are doing that you don't say. Check that. If your problem persists, you'll probably have to dive into your OS memory management and see it is not fighting lwIP's own. I have no expertise here (I prefer to fight bare metal instead of OSs) and won't be able to help. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] any ideas ??
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 https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Little endian
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 be used a lot. That should be a part of your arch port. Have a look at (or just use) my ARM Cortex-M generic (CMSIS) port: http://scaprile.ldir.com.ar/cms/category/os/lwip-port and also have a look at my ethernet code to see how it uses that macro: http://scaprile.ldir.com.ar/cms/el-ingeniero/open-source-projects-im-working-on/ Regards ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Retransmission of a already acknowlegded package.
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, which is... - your link-level driver, which is... - lwIP, which you shouldn't have this problem, unless you don't call it properly. You are not calling the stack from within interrupt code, aren't you ? It is not safe unless you know exactly what you are doing ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LWIP malloc/free issue
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 lwipopts.h and settings internal to the application you are trying to run. Afaik those settings you mention are correct as I have them both set to 0 as the comment states; but some applications might have their own settings for their own memory allocation. Regards ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Retransmission of a already acknowlegded package.
You are right, Christian, I should have had a better look before (educated) guessing. frame 1513's content is ACKed by frame 1514, which is seen by lwIP because it is indicated by frame 1515's content. frame 1516 retransmits 1513's content, or at least that is as far as I can see. How come you are using FreeRTOS ? You said you were using NO_SYS ! If you use an OS, you have to use NO_SYS=0 and have an OS compliant port. Is the TI port compatible with FreeRTOS ? You should use a FreeRTOS port of lwIP. Is it possible that THAT is your problem ? The stack is single-threaded, and while some functions have provisions for safe reentrancy, the rule is to call lwIP from a single thread, that means: all functions calling the stack, including the Ethernet rx, must run on the same non-reentrant task. This is as far as I can help, I don't use OS and don't know the more complex APIs that you can use to help in multi-threading. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] DHCP Unit tests fail
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 CentOS 5.9 with check 0.9.13. Prior tests where with check 0.9.3, however, I see lots of errors against that release, so the one used by the developers on the stable branch might lie between them. In the meantime, try checking that dhcp stuff in the stable branch code (get the zip) Regards ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] DHCP Unit tests fail
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
Re: [lwip-users] RAWSOCKETS_IN_LWIP
Hi,
I think you have things a bit confusing here. Let me try to clarify:
* There si no data link layer in TCP/IP. TCP/IP can virtually use any
data link layer and so lwIP. The most common data link layer used for
TCP/IP is Ethernet.
** In linux, the OS owns the stack and the Ethernet chip, and you have
to ask permission to access the Ethernet layer and inject "raw frames"
* lwIP is not an operating system nor a kernel, it is a TCP/IP stack.
** Therefore, if you need to use Ethernet, you will use Ethernet, not
lwIP. You don't need to ask the OS permission to write to the Ethernet
chip, it is an embedded system and you own the Ethernet chip, you write
the driver and you write to the chip at will. This has nothing to do
with lwIP, except:
*** In case you need to use both your own stack for your own protocol
(which you refer to as "Application Layer" but in this scenario is a
layer-3 protocol) AND lwIP for TCP/IP; then YOU will modify the _netif_
code in YOUR driver and capture the proper Ethernet protocol-type and/or
IEEE802.3/SNAP, for example, in src/netif/ethernetif.c:
switch (htons(ethhdr->type)) {
/* IP or ARP packet? */
case ETHTYPE_IP:
case ETHTYPE_ARP:
#if PPPOE_SUPPORT
/* PPPoE packet? */
case ETHTYPE_PPPOEDISC:
case ETHTYPE_PPPOE:
#endif /* PPPOE_SUPPORT */
/* full packet send to tcpip_thread to process */
if (netif->input(p, netif)!=ERR_OK)
{ LWIP_DEBUGF(NETIF_DEBUG, ("ethernetif_input: IP input error\n"));
pbuf_free(p);
p = NULL;
}
break;
you will add something like:
case ETHTYPE_myOWNLAYER3PROTOCOL:
/* full packet send to mylayer3_thread to process */
if (netif->mylayer3protocolinput(p, netif)!=ERR_OK)
{ LWIP_DEBUGF(NETIF_DEBUG, ("mylayer3protocol_input: PROTOCOLNAME input
error\n"));
pbuf_free(p);
p = NULL;
}
break;
This is just an example, you will have your ethernetif.c equivalent in
your port for your particular hardware, adapted for your particular chip.
Regards
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] init network interfaces
* 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 teach you how to initialize interfaces. Beyond that, you should ask for help in your environment, whether it is Gnu/Linux or BSD or whatever UN*X flavor you are using. ** You can't bind to an IP address in your machine because lwIP is not an application or a library for your machine running on top of its TCP/IP stack; it is an independent TCP/IP stack written for machines that don't have other TCP/IP stack and so need it. lwIP needs to see a link-layer interface. The way you are using it is by providing a virtual interface via a bridge/router. That is a helper to try and debug other applications. This has been told many times to some other questions of yours. Do you understand this ? *** To reach your lwIP-based application you have to connect to the IP address YOU provide when you setup the stack. Your tun/tap inet addr is the gateway address YOU provide so the UN*X internal router can reach your lwIP stack, and they are configured in the file you are using for the port, either contrib/ports/unix/proj/minimal/main.c or whatever YOU are using. Your lwIP-based application will have that IP address as a source address, your networking environment must route that network, in other words, if your destination is in other machine, it must know how to "go back" to your lwIP stack * Before debugging @application layer, you should check connectivity. Start by trying a simple ping ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] RAW Api to receive large image data
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 pbuf chains: pbuf_copy_partial(p, towhere, p->tot_len, 0); To ACK all the data: tcp_recved(tpcp, p->tot_len); Regards ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] RAW Api to receive large image data
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 whole pbufs is not a problem, I just pointed out that a single pbuf per Ethernet frame is not a constant, and might change with memory conditions, you must check p->tot_len and free tot_len to avoid losing data and stucking the memory pool, respectively. There is no lwIP magic for large data vs. small transfers, it is just data transfer and it will keep going as long as you call tcp_recved() to send ACKs and pbuf_free() to free memory. Have you looked at a network capture ? Can you post one ? What port are you running ? NO_SYS ? Are you definitely calling the api from a single thread ? (foreground only, no ints, if NO_SYS=1) Do you call TCP timer functions frequently enough ? ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] problem with multiple UDP sockets
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 problems. If you don't, ask someone who can help you with networking. The red packets in your capture snapshot are RSTs, I am no TCP expert but that looks like an improper session termination. There are no other errors I can see, except that the supposed http server is not actually sending anything. Please post the capture FILE, not a snapshot, and if possible, isolate the traffic in question. Also, ask the people resposible for this port regarding help on this demo. If you have specific lwIP issues I'll be happy to see your capture files and try to help. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] RAW Api to receive large image data
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 https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Retransmission of a already acknowlegded package
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 trouble.
You should get a known good FreeRTOS port of lwIP first.
If you have to port it yourself, then by all means try a known working
lwIP app first !
> [...] LWIP ASSERT "pbuf_free: p->ref > 0" message. I don't understand
> what this means and how I can find the reason.
Well, if you read the documentation and explore the source code, you
will learn what pbufs are and how they have a reference count to track
the number of referers.
If you do a search on pbuf.c in lwIP code, you'll see that string
appearing only once, inside function pbuf_free(struct pbuf *p), at line
650 in the official 1.4.1 release, and it is in the following context:
/* de-allocate all consecutive pbufs from the head of the chain that
* obtain a zero reference count after decrementing*/
while (p != NULL) {
u16_t ref;
SYS_ARCH_DECL_PROTECT(old_level);
/* Since decrementing ref cannot be guaranteed to be a single
machine operation
* we must protect it. We put the new ref into a local variable to
prevent
* further protection. */
SYS_ARCH_PROTECT(old_level);
/* all pbufs in a chain are referenced at least once */
LWIP_ASSERT("pbuf_free: p->ref > 0", p->ref > 0);
ref = --(p->ref);
SYS_ARCH_UNPROTECT(old_level);
You'll see that this is decrementing the number of references to a pbuf
when called, and when that is 0, the pbuf will be freed.
The assertion inside the SYS_ARCH_PROTECT/SYS_ARCH_UNPROTECT is checking
that p->ref is indeed >0, so you don't try to free a pbuf that was
already freed, and it checks this while trying to avoid other tasks to
screw things up.
So, even though I have no experience on NO_SYS=0 and I might be
overlooking something, I can tell you that:
- either your port is not good and it is messing things up,
- you are not calling the stack from a single thread as requested,
- or your application is broken and is trying to free an already freed pbuf.
You can try to log p->ref before and after the lock to check if things
are being screwed up, and you can track the pbuf_free caller to check if
someone is passing a freed pbuf.
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] UDP Raw receive / pbuf_free?
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 without deallocating the pbuf and that will do put you in trouble. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] IEEE-1588 with lwip?
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. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Closing TCP connections
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
Re: [lwip-users] tcp echo example
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 what you are describing in that code, and there is only one tcp_write() call in echo.c: [scaprile@Hal ~]$ grep -n tcp_write programming/lwip/contrib/apps/tcpecho_raw/echo.c 311: wr_err = tcp_write(tpcb, ptr->payload, ptr->len, 1); BTW, if you want to really test the net throughput (or at least come closer) get the netio patch: https://savannah.nongnu.org/patch/?7026 Regards -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] tcp echo example
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 pcb. Once your buf is filled, you can only send again once data has been sent out, acknowledged by the receiver, and so that buffer freed, and that is signalled to you via the tcp_sent() callback. The whole point of calling echo_send() from inside the callback function is that in this case the total amount of data actually sent might not equal the amount of data received (in the whole pbuf). The first call to tcp_write() sends only the first pbuf in the pbuf chain, and once this is acked, the tcp_sent() callback will try to send the remaining pbufs in the chain. A pbuf may be a chain of pbufs, linked by p->next Either you have some memory problems or I've been lucky enough to get whole data inside a single pbuf and didn't trigger the possible bug. I recall sending small packets, what are you sending ? Again, I suggest you use netio for big chunks of data. I don't have the time to build a short tcp_mss version of my linux port and try it, maybe on monday. I suggest you (besides going for netio) try with small messages, I'm sure those work OK. If they do, then check the pbuf chains, if they don't... check your port. Regards -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] tcp echo example
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 from a single thread, no interrupts here (if it works, fine, but if it doesn't, then don't complain), and call the system timers frequently enough. Since long ago there is sys_check_timeouts() that will take care of everything, you can call it from your main loop. Make sure you are doing that. I will see if I can run the linux port later with several message sizes and check again, I've run it on a taiwanese Cortex-M3 last month and had fun watching it work as expected. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Closing TCP connections
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 will be called is the one you provided as a
parameter when you set the environment for that pcb. How come you don't
know what you setup ?
tcp_err(mypcb, myerr);
If you will reuse one tcp_err() function for many connections, you will
use the arg parameter, as shown in every example application:
tcp_arg(mypcb, myapplicationstructurepointer);
A closure action is something like this:
static void myclose(struct tcp_pcb* pcb)
{
state = myCLOSING;
if(tcp_close(pcb) == ERR_OK){
tcp_recv(pcb, NULL);
state = myCLOSED;
}
}
You need to have a state (or equivalent) and try to do close later if
the call to tcp_close() fails for low memory or whatever. If the other
host sends RST, you are going to close anyway.
To try later, you can use tcp_poll():
tcp_poll(mypcb, mypoll, POLL_TIME);
static err_t mypoll(void *arg, struct tcp_pcb* pcb)
{
if(state == myCLOSING){
// Retry closing the connection
myclose(pcb);
} else {
// Retry sending data we couldn't send before
mysend(pcb);
}
return ERR_OK;
}
--
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] tcp echo example
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 provide specific details of what you are doing. If you didn't
write the port, and your schema is not somehow like the following, I
suggest you ask for help to the guy(s) that wrote the port.
E.g.:
main()
{
lwip_init();
setipaddress
netif_add(&netif0,...);
netif_set_default(&netif0);
netif_set_up(&netif0);
echo_init();
while(1){
ethernetif_input(&netif0);
sys_check_timeouts();
}
}
ISR: fight the chip and set heyIhaveaframehere=1;
ethernetif_input(&netif0)
{
if(heyIhaveaframehere){
alloc
netif->input();
}
}
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LWIP RAW tcp_close, tcp_connect
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 https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Embedded Web server unable to display image atclientsid
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 on the contrib tree; check tcpecho and smtp (besides the aforementioned http server, also) And you have a wiki with proper documentation: http://lwip.wikia.com/wiki/Raw/TCP If something in the wiki is not clear, I'll change it. And, finally, two _personal_ pieces of advice: - if you plan on developing something TCP/IP, do yourself a favor and learn TCP/IP first. Particularly if you will actually use TCP and not UDP. - if you plan on developing on lwIP, get the contrib tree, study the examples, break them, read the wiki, write small examples, make them work, and then jump into rocket science (as a web server). ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LWIP RAW tcp_close, tcp_connect
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 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. > -- ------------- 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] TCP IP Port accept Issue- Reg
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 only one thread ? - Have you successfully run the examples in the contrib tree? Not any vendor examples, the ones in lwIP's contrib tree. - Have you checked your application against those examples ? Can you tell what is different, anything you are doing that is not exactly like in the examples ? Once you have fullfilled those points, please send a detailed lwIP log and a wireshark capture and I will try to look at them and see if I can help. Chances are you won't need to send anything. In such a case you need to send files, it would be nice to have a chance to know not only what you are doing, but what you are actually trying to do. Please add a detailed description of your application in correct networking terms. For example: "after three times the TCP won't accept my connection and the client application will close" is too vague, who is "the TCP" ? what is "the client application" ? who is "the client"? If you send a connection request, then YOU are the client, the other side is the server, then who is sending what ? Where is lwIP? Is it the client, is it the server, is it both ? Are you writting a client or a server, or both? Have you actually tested your server with a simple telnet ? Is it a well known application ? Please take into account that we on the other side of the mailing list have no clue whatsoever of what you know or don't know, have or don't have. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP IP Port accept Issue- Reg
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
Re: [lwip-users] Split DNS for multihomed setup
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 https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Split DNS for multihomed setup
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 application in which you need some specific destination associated to a specific source address/interface. As far as I can see, either you write a routing module that has static routes based on your constraints, or you'll have to modify every single application you ever need to use in this context. Backing off... ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Split DNS for multihomed setup
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 anything other than two separate TCP/IP stacks, as Simon suggested; and perhaps even two application spaces too... Any other ideas, just as food for thought, outthere ? ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] packets dropped ,no space: which PCB?
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 where you'd usually free pbufs and pcbs and check that everyone is freeing what is supposed to free. grep -R "packet dropped, no space" * does not return any hits, so I also suggest you take note of the actual error, search for it in the sources, and then, with a clue of what to follow, someone here will try to help you find where it can be lurking. BTW, you wrote "other tasks", pay attention to lwIP rules for multiple threads (same as Highlander: "there can be only one") and please describe what are you doing with what (raw?, netconn?, ?) ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] mem alignment issue when updating to Rev 1.4.1
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 be an alignment dependency issue in lwIP. Simon? For your specific problem, if you could somehow force the const struct sockaddr *name (that you are allocating and passing to lwip_bind() and lwip_connect()) to be aligned to 32-bits, that should solve your problems. How it is allocated is beyong my knowledge. Regards, and donate your payment to the lwIP foundation ;^) ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] DHCP callback was removed - Correct way to obtain new address?
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 LWIP_NETIF_STATUS_CALLBACK is defined. Now, I've been calling netif_set_up() before dhcp_start() cause I though the ifc needed to be somehow "up" before UDP/IP would be sent through it... looks like I was wrong and that was not necessary, or worse, not correct. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] DHCP callback was removed - Correct way to obtain new address?
Hi Paul, Please take a look at http://savannah.nongnu.org/bugs/?43105 to have an idea why I won't consider looking at a vendor's implemntation to understand how to correctly use lwIP (or any other Open Source, btw) ;^) ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP IP Port accept Issue- Reg
B> Can you share your email id with me? It is helpful for sending the project files. S>I'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 capture files to the list if ncecessary. If you really need to hire me, I only take bitcoins for payment ;^) ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwIP hangs after some data transferred
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 for their priorities and single thread and the Rx handler missing every other packet ? Sort of a FAQ ? Then we only need a volunteer to paste the FAQ link as a response... ;^) Regards ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwIP hangs after some data transferred
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. Not your case, since you are using the sockets API. The ST rx handler bug is the winner this August: The interrupt routine takes the first frame off the controller and forgets to ask if there are any others waiting, so fast consecutive frames cause lost frames. IIRC, there is also a task running every second that somehow gets frames out of the chip (?), so some people notice this issue by observing a 500ms average ping delay, constantly changing (but I might be confusing it with other bug I read on the list). I'm glad you found it in the list and fixed it. Fortunately I don't use vendor code so I can't tell you if there are any other serious bugs, I prefer to deal with my own bugs (which keeps me very busy indeed ;^)). Sorry for hijacking your thread, should I start a new one or do you prefer to elaborate on the FAQ here ? You are the OP Best regards ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] DHCP callback was removed - Correct way to obtain new address?
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, netif_status_callback_fn status_callback); your 'status_callback' function will be called when the interface comes up after the DHCP state machine reached the DHCP_BOUND state and netif_set_up() has been called by the dhcp code. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] RIP and OSPF support
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 routing hooks, my (probably educated) guess is that the amount of resources you'll need to run the Dijkstra algorithm in OSPF (which depends on the size of the visible network) will probably justify the usage of something closer to a full-blown OS. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] clear buffers just like reset
I don't think there is such a thing, is it ? In any TCP/IP stack ? (besides the fact that you souldn't have to do it) ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwip reports bad FCS on some packages
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 configuration. btw, fwiw, your capture text is missing 8743. Third: before posting again, please make sure you are not having lost frames because of the same RTOS problem everybody has with ST and other vendors bugs. Please search the list. Fourth: by all means, please, indeed, please post an attached capture file. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] How to check send state?
> 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 ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Failed to send TCP data
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 ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP retransmission flooding at end of stream
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 https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Context of poll and recv?
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;
p = pbuf_alloc();
get frame;
netif->input(p, ifc);
} while(more frames);
}
main()
{
while(1){
eth_input(&myeth);
}
}
void rxint()
{
ack;
set flag;
}
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP retransmission flooding at end of stream
>>/ 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 ? - Your DHCP on UDP port 5, turn it off, just in case, you don't seem to be using it - Frame 2094: Yes, 2058's ACK has been seen, but 2057's not. Then, Seq#s jump at sometimes more than 1460, so some frames were lost, some not. - Frame 2162(3,5) ARP request is not seen by lwIP, frame loss You are definitely having an event that triggers frame losses. Where is it, I can tell. You said this is a custom board, I had once something like this where my driver went out of sync with the eth chip by incorrectly reading available bytes. Please run known to work code first, this looks to me like an eth driver problem - You say you are using tcp_poll() to enqueue data. Don't do that if you aim for performance, that is just to avoid state machines on connection closures and some other good stuff, not for streaming data. You should start sending your data from your tcp_recv() parsing the request and then keep steady sending from your tcp_sent() > According to lwip_stats there is no memory leak and no packet drop Well, lwIP can only count *packet* drops, not *frame* loss. And memory leak is tricky, is it possible you are freeing a wrong pointer or in the wrong place ? Try sending and freeing at the same place, that is tcp_sent(), let tcp_poll() aside for now. Check the web server or smtp client sending functions. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP retransmission flooding at end of stream
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 is more important for your main task. The fastest way to transmit is by filling the TCP buffer from tcp_sent(), just after freeing the acked pbuf. This way you can keep the buffer full and respond quickly to window changes (if any). However, you'll keep your hardware dedicated to this task, and if it is not your highest priority, it might not be your main interest. If you otherwise just fill the current buffer and let tcp_poll() wake you up and keep sending, you'll probably won't saturate your link, but use less processing power. The send loops in servers mostly work on tcp_sent(), this is OK when serving "regular" amounts of data. For CGI handlers that might serve long logs, I like to put a pause once in a while in case the rest of the tasks need to breath, but I don't use RTOS but bare metal. In any case, I think it is clearer if you handle data sending on the tcp_sent() callback and keep the polling for closure or resume after pause (if any). ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] poll-function not called
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 application. If that doesn't help, then you should ask in the TI forum as mobin.seven said. Anyway, keep us posted so the next victim can find it in the list, and/or the FAQ keeps growing. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] poll-function not called
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 same scope you are calling all other lwIP routines... or ask TI where to, if possible... or use a vendor-agnostic port, like mine: http://scaprile.ldir.com.ar/cms/category/os/lwip-port/ ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] pbuf leak for HTTP POST
> 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 opinion, it is quite far from CGI standards so basically CGI POST code is difficult to write and non-portable Sorry if I touched someone's feelings. My code sucks too ;^) ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwip minimal example, echo server
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 ARCH=linux Once you have the correct tun or tap device, it will show up in your ifconfig and you will be able to ping the lwIP stack as a new machine on a new network, which is what you should do first when debugging networking problems. In main.c: /* startup defaults (may be overridden by one or more opts) */ IP4_ADDR(&gw, 192,168,0,1); IP4_ADDR(&ipaddr, 192,168,0,2); IP4_ADDR(&netmask, 255,255,255,0); So, 192.168.0.1 will be the address of the gateway in your machine to "the lwIP network", via a tun or tap interface. In Linux seems to be tap tap0 Link encap:Ethernet HWaddr 86:99:D8:CE:27:DC inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::8499:d8ff:fece:27dc/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 b) TX bytes:468 (468.0 b) The specifics to get the tap working are beyond my knowledge, I remember I just followed a tutorial. The interface will be up once the example is running, and will dissappear after that. Anyway, you should be able to ping that interface to check if the tap is working. And, 192.168.0.2 will be your "lwIP machine" address, you should be able to ping it [root@Hal minimal]# ping 192.168.0.2 PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data. 64 bytes from 192.168.0.2: icmp_seq=1 ttl=255 time=8.76 ms 64 bytes from 192.168.0.2: icmp_seq=2 ttl=255 time=9.66 ms --- 192.168.0.2 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 8.766/9.214/9.663/0.458 ms and you should be able to telnet to it in port 7, cause no one knows if your SimpleEchoClient really works, although you probably will. [root@Hal minimal]# telnet 192.168.0.2 7 Trying 192.168.0.2... Connected to 192.168.0.2. Escape character is '^]'. hola hola You probably noticed I run this as root... there are some permissions associated to the tap interface, and I'm lazy enough to change them. Anyway, you should see something like this: tapif: tapif_init: open: Permission denied if that is the case. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Cannot connect to Windows 7 ethernet interface directly or through a hub
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 * an Ethernet driver problem, triggered by the difference in the arrival speed of frames * a broken TCP application You should: * check your hardware with proper instrumentation, or have a known to work hardware. * check your Ethernet driver, or have a known to work driver * check your port, or have a known to work port. * use a known to work TCP example, as the echo server Once you have checked that (not necessarily in that order), if you still get "lots of retransmissions and dropped packets", please post a capture file and give details on who is who and I will try to help. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Sending large data problem.
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 you can send more data, but only if you free the memory you've allocated for the prior buffer. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwip stall
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 putting this along with an explanation in the wiki ? (No guarantee STers will read it anyway) ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwip minimal example, echo server
Even though my name is on that bug report (I reopened it), I completely forgot about that. I don't even remember how I got there, though I do remember doing step by step debugging and finding those flags. Somehow the wireshark capture led me there but I don't remember the symptoms. Simon reported 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 ARCH=linux > #To compile for cygwin: make ARCH=cygwin > #To compile for openbsd: make ARCH=openbsd > ARCH=linux > Once you have the correct tun or tap device, it will show up in your > ifconfig and you will be able to ping the lwIP stack as a new machine on > a new network, which is what you should do first when debugging > networking problems. > > In main.c: > /* startup defaults (may be overridden by one or more opts) */ > IP4_ADDR(&gw, 192,168,0,1); > IP4_ADDR(&ipaddr, 192,168,0,2); > IP4_ADDR(&netmask, 255,255,255,0); > > So, 192.168.0.1 will be the address of the gateway in your machine to > "the lwIP network", via a tun or tap interface. In Linux seems to be tap > > tap0 Link encap:Ethernet HWaddr 86:99:D8:CE:27:DC > inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0 > inet6 addr: fe80::8499:d8ff:fece:27dc/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:500 > RX bytes:0 (0.0 b) TX bytes:468 (468.0 b) > > The specifics to get the tap working are beyond my knowledge, I remember > I just followed a tutorial. The interface will be up once the example is > running, and will dissappear after that. > Anyway, you should be able to ping that interface to check if the tap is > working. > > And, 192.168.0.2 will be your "lwIP machine" address, you should be > able to ping it > > [root@Hal minimal]# ping 192.168.0.2 > PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data. > 64 bytes from 192.168.0.2: icmp_seq=1 ttl=255 time=8.76 ms > 64 bytes from 192.168.0.2: icmp_seq=2 ttl=255 time=9.66 ms > > --- 192.168.0.2 ping statistics --- > 2 packets transmitted, 2 received, 0% packet loss, time 999ms > rtt min/avg/max/mdev = 8.766/9.214/9.663/0.458 ms > > and you should be able to telnet to it in port 7, cause no one knows if > your > > SimpleEchoClient really works, although you probably will. > > > [root@Hal minimal]# telnet 192.168.0.2 7 > Trying 192.168.0.2... > Connected to 192.168.0.2. > Escape character is '^]'. > hola > hola > > You probably noticed I run this as root... there are some permissions > associated to the tap interface, and I'm lazy enough to change them. > Anyway, you should see something like this: > tapif: tapif_init: open: Permission denied > if that is the case. > > -- - 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] Memory allocation fail after some time in lwip stack for lpc1833 controller
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. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] pbuf_alloc failed after sometime at driver side.
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) pending, the receiving task allocates a buffer for it and transfers data. Then, this buffer is checked for upper-layer protocol and handled to the stack or discarded. Code for this is in the netif tree and is modified by the one providing the driver and the port. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] pbuf_alloc failed after sometime at driver side.
> 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 non-IP frames. Code for this is in the netif tree and is modified by the one providing the driver and the port. It usually follows src/netif/ethernetif.c and usually uses etharp.c, but the only one who actually knows that is you, the user (and others running the same driver...), so if you are using vendor code, you should check with your vendor, they do like to do things at will. > And now upper laye stack have resposibilty to free this packat after > it no longer in use. No jbhoi, the upper layer is ultimately layer-5to7 and ergo your responsibility, unless we are talking about pings/arp..., or you are using a known to work application, which I don't know because you don't say. > [...] will pass it io next phase like ip_input and from that it call > tcp_input or udp_input or other and it will free that packet. Nope, it will just ultimately call the application callback function and it (YOU) will free the pbuf. TCP will only free the pbuf when INSTRUCTED TO DO SO, by returning a specific value in your callback function. UDP will not free it. You guys should by all means try a known to work application to rule out any problem in your driver and/or port. I first thought of the driver because the problem description looked like non-IP frames pbufs were not being freed. Now, since you actually don't know you have to free pbufs, I'm beginning to think that you actually have a non-working application. Anyway, there are many network conditions that may cause different pbuf allocation and that might fail in different ways. Please read the docs. Take a time to read the wiki http://lwip.wikia.com/wiki/Raw/native_API Check that you are following the multithreading requirements (just one thread and only one will talk to lwIP (pbuf functions are supposed to be a bit more permissive but I don't run RTOSes so I can't tell you how to do anything other than keep everything on the same context). http://lwip.wikia.com/wiki/Raw/TCP http://lwip.wikia.com/wiki/Raw/UDP Then take a time to check the tcpecho_raw application for TCP or the sntp application for UDP; in the contrib tree Follow those guidelines in your application. Regarding specifics for pbuf freeing; from the wiki: UDP: "The callback function is responsible for deallocating the pbuf" TCP: "If there are no errors and the callback function returns ERR_OK, then it is responsible for freeing the pbuf. Otherwise, it must not free the pbuf so that lwIP core code can store it" Let's make a deal: If something is wrong in the wiki, I will fix it. If something is wrong in your code, you will fix it. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwip processing of posts
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: http://scaprile.ldir.com.ar/cms/el-ingeniero/open-source-projects-im-working-on/lwhttpd/ Could you provide specific details on how your work relates to the lwIP and contrib trees ? ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Closing tcp-Connection
> 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 http://lwip.wikia.com/wiki/Raw/TCP I will also assume that you checked the code in the contrib tree. So no, it should work. But, if you didn't go to any of these steps, please do. The only thing that comes to my mind is that you are not calling the tcp_tmr() function, make sure you have a call to sys_check_timeouts() in your main loop. If any of my assumptions is wrong, please come back with the missing data. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Closing tcp-Connection
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;
if(tcp_close(pcb) == ERR_OK){
tcp_recv(pcb, NULL);
state = myCLOSED;
}
tcp_close() may fail due to a number of reasons, mostly involving low
memory situations (and I'm too lazy to dig more into the source), so if
it fails you'll have to retry later, maybe in the poll callback:
if(state == myCLOSING){
// Retry closing the connection
myclose(pcb);
}
Are you checking tcp_close()'s return value ? That should give a hint.
If somehow it fails and you don't retry later, it won't close.
(Should've started there... didn't I ?)
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Closing tcp-Connection
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 machines, I've seen from 4 minutes to 4 seconds. I don't know if there is any workaround to this, you surely will be able to shorten this time if you can't wait, and maybe Simon or any other might lead to a compile option to provide a workaround if there is one; the default is to wait or design for an extra "socket". ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Closing tcp-Connection
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, and put in a closing state. * * The pcb is then automatically freed in tcp_slowtmr(). It is therefore** ** * unsafe to reference it (unless an error is returned).* ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ARP lookups and UDP servers
I fail to see the problem here. You want to avoid ARP delays. An ARP cache will only help with locals, as client MACs are only used for local LAN communication. When traversing to other networks, the router/gateway MAC is needed. A way to keep it fixed in the table without being purged should suffice if I understand what your problem seems to be. You probably will have more luck asking for this on the developers' list. Can't comment on IPv6. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] tcp_tmr and timers.c
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 myfunction(something *myarg); sys_timeout(SEND_TIME, (sys_timeout_handler) myfunction, myarg); // callback gets called back on timeout; sys_untimeout((sys_timeout_handler) myfunction, myarg); // timer removed ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
