Subject: RE : Problem with lwip_select under Nucleus - msg#00165

Previous Message by Date: click to view message preview

Problem with lwip_select under Nucleus

Hello again. I had a look at the points you mentioned to me: First of all, I have checked that MSG_DONTWAIT in the flags to the recv operation, and O_NONBLOCK to the socket options are both set to zero. In fact, both flag fields are completely zero. So that the socket should be blocking, am I right? >Take a look at the lwip_recvfrom() function.  Can you check the following when you call it by adding some extra debugging: > - that sock->lastdata is NULL. OK, it is null > - that buf returned by netconn_recv() is NULL. It is null too. >If that is the case, take a look at netconn_recv().  This can return NULL for all sorts of reasons.  Add debugging (e.g. a printf) to each one and >see which case is failing. Next, I specify the failing case, which shows the reason for which the function returns NULL. struct netbuf * netconn_recv(struct netconn *conn) { ...       if (conn == NULL) {     return NULL;   }     if (conn->recvmbox == SYS_MBOX_NULL) {     conn->err = ERR_CONN;     return NULL;   }   if (conn->err != ERR_OK) {     return NULL;   }   if (conn->type == NETCONN_TCP) {     if (conn->pcb.tcp->state == LISTEN) {       conn->err = ERR_CONN;       return NULL;     }     buf = memp_malloc(MEMP_NETBUF);     if (buf == NULL) {       conn->err = ERR_MEM;       return NULL;     }         sys_mbox_fetch(conn->recvmbox, (void **)&p);     if (p != NULL)     {         len = p->tot_len;         conn->recv_avail -= len;     }     else                                                                        <<<<<<<<<<<<<<<<<<<<<<<<< IT GETS INTO THIS ELSE         len = 0;             printf("\n Entra en el ELSE, Chkp1\n");         /* Register event with callback */       if (conn->callback)         (*conn->callback)(conn, NETCONN_EVT_RCVMINUS, len);             printf("\n Entra en el Callback, Chkp2\n");     /* If we are closed, we indicate that we no longer wish to receive        data by setting conn->recvmbox to SYS_MBOX_NULL. */     if (p == NULL) {                                                        <<<<<<<<<<<<<<<<<<<<<<<<< IT GOES INTO THIS IF (p==NULL)       memp_free(MEMP_NETBUF, buf);       sys_mbox_free(conn->recvmbox);       conn->recvmbox = SYS_MBOX_NULL;       return NULL;                                                        <<<<<<<<<<<<<<<<<<<<<<<<< RETURNS NULL     } .... .... ....   return buf; } The problem seems to be that it is receiving that null p. I would thank any advice. Thank you very much for your help and for using your time for this purpose. Best regards, Borja. _______________________________________________ lwip-users mailing list lwip-users-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx http://lists.nongnu.org/mailman/listinfo/lwip-users

Next Message by Date: click to view message preview

Re: Problem with lwip_select under Nucleus

On Mon, 2007-05-28 at 17:06 +0200, brivero-sx6kfo2fYiI@xxxxxxxxxxxxxxxx wrote: > The problem seems to be that it is receiving that null p. I would > thank any advice. OK. That leaves two possibilities: - someone has posted a NULL message to the mbox (which is used I think to signify that a connection has been closed) or there's a problem in the mbox code that means it's returning NULL when in fact there is nothing there. I think some of the mbox code is defined by the port. I'd suggest this is a good place to look. Kieran

Previous Message by Thread: click to view message preview

RE : Problem with lwip_select under Nucleus

Same question than the last time: which release? Even if a "connect" should do an implicit "bind", can you test to call it (bind) before connect? ==================================== Frédéric BERNON HYMATOM SA Chef de projet informatique Microsoft Certified Professional Tél. : +33 (0)4-67-87-61-10 Fax. : +33 (0)4-67-70-85-44 Email : frederic.bernon-BCy3RaB/VaZGWvitb5QawA@xxxxxxxxxxxxxxxx Web Site : http://www.hymatom.fr ==================================== P Avant d'imprimer, penser à l'environnement -----Message d'origine----- De : lwip-users-bounces+frederic.bernon=hymatom.fr-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx [mailto:lwip-users-bounces+frederic.bernon=hymatom.fr-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx] De la part de Kieran Mansley Envoyé : vendredi 25 mai 2007 10:15 À : Mailing list for lwIP users Objet : Re: [lwip-users] Problem with lwip_select under Nucleus On Fri, 2007-05-25 at 09:54 +0200, brivero-sx6kfo2fYiI@xxxxxxxxxxxxxxxx wrote: > At this point, I supposed that for default, sockets in LWIP were non- > blocking (is this true???), No. By default socket operations are blocking. I assume you haven't specified MSG_DONTWAIT in the flags to the recv operation, or O_NONBLOCK to the socket options. These would both result in non-blocking sockets. > I cannot find an explanation to what happens, but actually, select > does not wait when it is called after a connect. I would be very > pleased if somebody could give me some advice. It sounds like there's a problem with your port that is causing the blocking operations in the sockets API to not block. For some reason lwIP is behaving as if there is data to read on that socket, when in fact there is none. Ignore select() for now as I think if we can solve the simpler recv-not- blocking issue, that will be a good start. Take a look at the lwip_recvfrom() function. Can you check the following when you call it by adding some extra debugging: - that sock->lastdata is NULL. - that buf returned by netconn_recv() is NULL. If that is the case, take a look at netconn_recv(). This can return NULL for all sorts of reasons. Add debugging (e.g. a printf) to each one and see which case is failing. With that information we should be able to work out what's wrong. Kieran _______________________________________________ lwip-users mailing list lwip-users-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx http://lists.nongnu.org/mailman/listinfo/lwip-users Frédéric BERNON.vcf Description: =?iso-8859-1?Q?Fr=E9d=E9ric_BERNON=2Evcf?= _______________________________________________ lwip-users mailing list lwip-users-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx http://lists.nongnu.org/mailman/listinfo/lwip-users

Next Message by Thread: click to view message preview

netif related quetions

I am getting more and more questions as I keep trying to understand the lwip code. And I am using lwip 1.2.0. I believe this is the latest version , am I right?. Hoping that I am right : For now I have few netif related questions. I understand that ethernetif.c is to be tailored according to the user dependent implementation of how he glues his low level driver to lwip, on that I have these questions, 1. Why is netif->state initialized two times, once in netif_add (netif.c) and again in ethernetif_init() (ethernetif.c)?. The second initialization is going to overide the first one anyway right ?. The question is the netif_add() calls ethernet_init(), so why do we have to assign netif->state two times both thes two functions ?. Cant it be initialized always only one time & at only one place ?. Whats the purpsoe behind doing it that way. 2. Why isnt some function of format "err_t xxxxxxx(pbuf *, netif * )" declared or implemented in ethernetif.c, shouldnt this be passed as last argument when you call netif_add ( ) ?. In ethernetif.c, in ethernetif_input(...) function, netif->input(p,netif) is called. What exactly should be called as input function ?. How should I pass the pbuf obtained from low_level_input() to network layer ? Thanks in for sparing time to answer my questions Bilahari -----Original Message----- From: lwip-users-bounces+bilahaak=nortel.com-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx [mailto:lwip-users-bounces+bilahaak=nortel.com-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx] On Behalf Of lwip-users-request-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx Sent: Friday, May 25, 2007 4:45 AM To: lwip-users-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx Subject: lwip-users Digest, Vol 45, Issue 33 Send lwip-users mailing list submissions to lwip-users-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx To subscribe or unsubscribe via the World Wide Web, visit http://lists.nongnu.org/mailman/listinfo/lwip-users or, via email, send a message with subject or body 'help' to lwip-users-request-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx You can reach the person managing the list at lwip-users-owner-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx When replying, please edit your Subject line so it is more specific than "Re: Contents of lwip-users digest..." Today's Topics: 1. RE: Xilinx lwIP raw-api beginner question (Pisano, Edward A) 2. Problem with lwip_select under Nucleus (brivero-sx6kfo2fYiI@xxxxxxxxxxxxxxxx) 3. Re: Problem with lwip_select under Nucleus (Kieran Mansley) 4. Basic Design Question (Spies, Dominik) 5. RE: Basic Design Question (FreeRTOS.org Info) 6. RE: Basic Design Question (Spies, Dominik) ---------------------------------------------------------------------- Message: 1 Date: Thu, 24 May 2007 16:32:39 -0000 From: "Pisano, Edward A" <edward.pisano-VXdhtT5mjnY@xxxxxxxxxxxxxxxx> Subject: RE: [lwip-users] Xilinx lwIP raw-api beginner question To: "Mailing list for lwIP users" <lwip-users-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx> Message-ID: <13F3EDB639E68B4DB0CD2C14BF284A5B0191F3B2-5Ohrr2JZSRoSZAcGdq5asR6epYMZPwEe5NbjCUgZEJk@xxxxxxxxxxxxxxxx> Content-Type: text/plain; charset="us-ascii" Hi Erik, The problem you describe sounds very similar to the problem I had when I first attempted to run the raw_api XiLinx example. The solution was that the sample code assumed a polling design, whereas my MicroBlaze architecture had the EMAC configured for interrupts. As such, I needed to also register the XEmac_IntrHandlerFifo function to be called when the ethernet controller notified EMAC that a message was incoming. I put this call right before the call that registers the "mytimer_int_handler" like you have in your code. /* *Register XEmacHandler with interrupt controller *This is the FIFO-based interrupt handler */ XIntc_RegisterHandler(XPAR_OPB_INTC_0_BASEADDR, XPAR_OPB_INTC_0_OPB_ETHERNET_0_IP2INTC_IRPT_INTR, (XInterruptHandler)XEmac_IntrHandlerFifo, xemacif_ptr->instance_ptr); Of course, you'll need to change the constants to the names used in your architecture. Also, running lwip-debug for STDOUT messages has unpredictable effects on lwIP performance. It has to do with how the UART is a synchronous device. When strings are sent to it, processing is held up until the string output is complete. This can results in lwIP not being able to service things as quickly as it should. I use STDOUT very sparingly when network traffic is underway. Xemacif_input is still a polling function. The Ethernet controller to the EMAC core may be interrupt driven. But the EMAC to lwIP interface, via xemacif_input, is polled. That's what your mytimer_int_handler helps to make happen. Regards, Ed (a.k.a.-Paisan) -----Original Message----- From: lwip-users-bounces+edward.pisano=hp.com-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx [mailto:lwip-users-bounces+edward.pisano=hp.com-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx] On Behalf Of Erik Jagre Sent: Wednesday, May 23, 2007 11:57 PM To: lwip-users-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx Subject: [lwip-users] Xilinx lwIP raw-api beginner question Hi, I am a lwIP beginner and have some questions about getting a raw-api application up and running on a Xilinx Spartan-3E 1600E MicroBlaze Development Kit. I have tried to run the xilinx reference design xapp663 (echo server) but without success. It seems like my design never takes care of incoming traffic. When I try to connect to my echo-server with telnet ARP requests are sent to the development board. But my design never replies. I have tried to use the lwip-debug feature, but my program gets stuck during the call to netif_add (this does not happen without the lwip-debug feature activated). A print-out is made that confirms that the IP address has been set but after that the program stops and the program counter is set to 0x00. This makes me belive that my call to netif_add is not done in the right way. How is netif_add used correctly? What preparations need to be done before calling it? I am also curious about how xemacif_input(default_netif) works. Is this the call that takes care of all incoming traffic? Or is another call needed to take care of ARP requests? My code is included in the zip-file. Grateful for any suggestions or ideas. Regards Erik ------------------------------ Message: 2 Date: Fri, 25 May 2007 09:54:20 +0200 From: brivero-sx6kfo2fYiI@xxxxxxxxxxxxxxxx Subject: [lwip-users] Problem with lwip_select under Nucleus To: lwip-users-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx Message-ID: <OFA2C4E514.837DD719-ONC12572E6.00230A92-C12572E6.002B8BB0-sx6kfo2fYiI@xxxxxxxxxxxxxxxx> Content-Type: text/plain; charset="iso-8859-1" First of all I would like to thank you very much for your help. Next, I would like to explain the scenario in which the problem takes place. I have found a standard Unix-sockets code in a book and I have implemented it for Win32 with no problem. Since the objective is to create a wrapper socket API in order to work with a few OSs (Win32, LWIP&Nucleus,...), I tried to do the same for LWIP. The structure of the application is as follows: Server Client ====== ====== socket bind listen socket connect <server> accept send recv socket_delete This daytime application works in Win32 (both server and client in Win32) with no problem. But in LWIP(server in Win32 and client in LWIP), before the server sends the packet, the client ends the program closing the connection. This way, the client finds nothing to receive, and the server has no connection for when he is going to execute the send statement, causing a send error. At this point, I supposed that for default, sockets in LWIP were non-blocking (is this true???), and in consequence, the lwip_recv() worked as non blocking. That would be the reason for which it would not wait for the server to send, and the client execution would finish before the server send statement. Introducing a one second sleep statement just before lwip_recv() all worked ok. That´s why I tried to implement a blocking recv() by calling select just before recv(). But In spite of the 5 seconds timeval structure used as input to this select, it did not wait. I used this select looking at the readset in which the socket used to receive was set. At first I was afraid that there was some kind of problem with the semaphores, dealing with the port to Nucleus or something like that. But I have had a close look at some other select calls, and as long as there is not a connect before, they work perfectly waiting the timeval value etc. I have gone into the select by debugging, and the execution changes in sys_sem_wait_timeout(in sys.c). This function returs a 1 when it does not wait, and a 0 if it does wait. Inside this function, the problem is in the sys_timeout function, as it does let the sswt_cb.timeflag with a 0 value when it does not wait, while it changes its value to 1 when it waits. I cannot find an explanation to what happens, but actually, select does not wait when it is called after a connect. I would be very pleased if somebody could give me some advice. Regards, Borja. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.gnu.org/pipermail/lwip-users/attachments/20070525/3a2d98e8/attachment.html ------------------------------ Message: 3 Date: Fri, 25 May 2007 09:14:55 +0100 From: Kieran Mansley <kieran-1e/NZYDlv+odnm+yROfE0A@xxxxxxxxxxxxxxxx> Subject: Re: [lwip-users] Problem with lwip_select under Nucleus To: Mailing list for lwIP users <lwip-users-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx> Message-ID: <1180080895.4119.10.camel-hRIl1UN7MAKcHFV8EhV95y+nzDADDju6hCv4THm1bDM@xxxxxxxxxxxxxxxx> Content-Type: text/plain On Fri, 2007-05-25 at 09:54 +0200, brivero-sx6kfo2fYiI@xxxxxxxxxxxxxxxx wrote: > At this point, I supposed that for default, sockets in LWIP were non- > blocking (is this true???), No. By default socket operations are blocking. I assume you haven't specified MSG_DONTWAIT in the flags to the recv operation, or O_NONBLOCK to the socket options. These would both result in non-blocking sockets. > I cannot find an explanation to what happens, but actually, select > does not wait when it is called after a connect. I would be very > pleased if somebody could give me some advice. It sounds like there's a problem with your port that is causing the blocking operations in the sockets API to not block. For some reason lwIP is behaving as if there is data to read on that socket, when in fact there is none. Ignore select() for now as I think if we can solve the simpler recv-not- blocking issue, that will be a good start. Take a look at the lwip_recvfrom() function. Can you check the following when you call it by adding some extra debugging: - that sock->lastdata is NULL. - that buf returned by netconn_recv() is NULL. If that is the case, take a look at netconn_recv(). This can return NULL for all sorts of reasons. Add debugging (e.g. a printf) to each one and see which case is failing. With that information we should be able to work out what's wrong. Kieran ------------------------------ Message: 4 Date: Fri, 25 May 2007 10:41:40 +0200 From: "Spies, Dominik" <dominik.spies-kv7WeFo6aLtBDgjK7y7TUQ@xxxxxxxxxxxxxxxx> Subject: [lwip-users] Basic Design Question To: "Mailing list for lwIP users" <lwip-users-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx> Message-ID: <7B804B9F8A4D0D4D9113317D2A7DB0AD03F92074-8RRRemGfdJJ9ph0i+PXKDlOnKfhBOm/VrE5yTffgRl4@xxxxxxxxxxxxxxxx> Content-Type: text/plain; charset="us-ascii" Hi! I have some basic questions about the software design with the lwIP stack. Currently I'm using a port of FreeRTOS with lwIP. This port uses lwIP with NO_SYS true and calling it in one single task in a infinite loop. Every cycle ethernetif_handlepackets is called, and after that depending on some timing things the tmr functions. So, I do not think this is a good solution. My first idea is: Two Tasks, on handling the incoming packets, blocked via queue. An ISR handles incoming packets and write it to the queue. The second tasks executes all tmr functions. Because a preemptive scheduler is used, the lwip stack stuff has to be protected via mutexes. Two tasks for recieving/tmr processing is overhead. So how could I do that in one task? I can either wait for a specified time (tmr stuff) OR for an event (incoming packet) but not both (This is by design of FreeRTOS I think). Suggestions? Or is it in my case generally better to use the socket api, especially regarding to RAM consumption? I did'nt spent any time on considering to use it because rawapi.txt says it uses much more ram, and I do not have unlimited amount (40kb total) of ram. I do not know how much more ram the socket api needs, but maybe it is not much more or even less than with my "two tasks and queue... " solution. I hope this is not to basic for this list, but I'm no expert in realtime kernels or embedded systems design, so I hope some of you experts can spend some time helping a beginner ;) Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.gnu.org/pipermail/lwip-users/attachments/20070525/eed1fa16/attachment.html ------------------------------ Message: 5 Date: Fri, 25 May 2007 10:27:21 +0100 From: "FreeRTOS.org Info" <nospam-vE0BiPcBQ1hg9hUCZPvPmw@xxxxxxxxxxxxxxxx> Subject: RE: [lwip-users] Basic Design Question To: "'Mailing list for lwIP users'" <lwip-users-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx> Message-ID: <006001c79eae$e57a8ae0$c8da19ac-9l8sU3mM2BYN3CSpybL5APFuni90GbTbWmv/VHan8Is@xxxxxxxxxxxxxxxx> Content-Type: text/plain; charset="us-ascii" > I have some basic questions about the software design with > the lwIP stack. > Currently I'm using a port of FreeRTOS with lwIP. This port > uses lwIP with NO_SYS true and calling it in one single task > in a infinite loop. I would be interested others comments on this too - but also be aware that there are some nice lwIP demos for FreeRTOS.org already that do not use NO_SYS. You can use these as a reference. The most recent in the AVR32 demo. There is also an ARM7 demo. These are available in the download. Regards, Richard. + http://www.FreeRTOS.org A free real time kernel for 8, 16 and 32bit systems. + http://www.SafeRTOS.com An IEC 61508 certified real time kernel for safety related systems. ------------------------------ Message: 6 Date: Fri, 25 May 2007 13:44:32 +0200 From: "Spies, Dominik" <dominik.spies-kv7WeFo6aLtBDgjK7y7TUQ@xxxxxxxxxxxxxxxx> Subject: RE: [lwip-users] Basic Design Question To: "Mailing list for lwIP users" <lwip-users-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx> Message-ID: <7B804B9F8A4D0D4D9113317D2A7DB0AD03F92075-8RRRemGfdJJ9ph0i+PXKDlOnKfhBOm/VrE5yTffgRl4@xxxxxxxxxxxxxxxx> Content-Type: text/plain; charset="us-ascii" Richard, This didn't answer my questions, but thanks for your hint on that, the AVR32 example is nice. One question regarding the socket api: Where is the timeout, icmp and other stuff processed? Dominik -----Original Message----- From: lwip-users-bounces+dominik.spies=siemens.com-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx [mailto:lwip-users-bounces+dominik.spies=siemens.com-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx] On Behalf Of FreeRTOS.org Info Sent: Freitag, 25. Mai 2007 11:27 To: 'Mailing list for lwIP users' Subject: RE: [lwip-users] Basic Design Question > I have some basic questions about the software design with > the lwIP stack. > Currently I'm using a port of FreeRTOS with lwIP. This port > uses lwIP with NO_SYS true and calling it in one single task > in a infinite loop. I would be interested others comments on this too - but also be aware that there are some nice lwIP demos for FreeRTOS.org already that do not use NO_SYS. You can use these as a reference. The most recent in the AVR32 demo. There is also an ARM7 demo. These are available in the download. Regards, Richard. + http://www.FreeRTOS.org A free real time kernel for 8, 16 and 32bit systems. + http://www.SafeRTOS.com An IEC 61508 certified real time kernel for safety related systems. _______________________________________________ lwip-users mailing list lwip-users-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx http://lists.nongnu.org/mailman/listinfo/lwip-users ------------------------------ _______________________________________________ lwip-users mailing list lwip-users-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx http://lists.nongnu.org/mailman/listinfo/lwip-users End of lwip-users Digest, Vol 45, Issue 33 ******************************************