Re: Contents of lwip-users Digest, Vol 42, Issue 7

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: Contents of lwip-users Digest, Vol 42, Issue 7

geckook Xu
I use api of socket.c .
When I create the 4th connect, the other connects will receive a lot
of I/O inturrupts(all the sockets are receiving data.), but can not
receive any data,so in my program,I will decide these connects are
idle and should be shutdown.

On 2/8/07, [hidden email] <[hidden email]> wrote:

> Send lwip-users mailing list submissions to
>        [hidden email]
>
> 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
>        [hidden email]
>
> You can reach the person managing the list at
>        [hidden email]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of lwip-users digest..."
>
>
> Today's Topics:
>
>   1. Re: curious large packets and transmit stuck (Andre Puschmann)
>   2. problem with netconn_accept (shobhit saxena)
>   3. I can only create 3 tcp/ip connects ? why? (geckook Xu)
>   4. Re: problem with netconn_accept (Kieran Mansley)
>   5. Re: I can only create 3 tcp/ip connects ? why? (Kieran Mansley)
>   6. client-server arch. using lwip (TEJ)
>   7. Just to inform : Internet Explorer 7.0 and LwIP   Savannah web
>      site problem (Fr?d?ric BERNON)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 07 Feb 2007 20:45:31 +0100
> From: Andre Puschmann <[hidden email]>
> Subject: [lwip-users] Re: curious large packets and transmit stuck
> To: [hidden email]
> Message-ID: <eqda90$g5u$[hidden email]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> hey thomas,
> we are using a freescale mpc5200 and its integrated fec.
> the os is a osek/vdx compliant one.
> the driver uses the bestcomm dma engine that is integrated in the mpc5200.
> i don't think that there is a problem at the basic functionality of the
> driver but indeed there is a point which i can't understand.
> if i count the times the fec_send()-method was called and the number of
> fec-tx-interrupts they differ from time to time, i mean i got less
> tx-interrupts, what properly shouldn't be the case.
> if i really loose some tx-interrupts maybe i loose rx-interrupts as well?!
> but how could that be?
>
>
> Regards,
>
> Andre
>
>
>
> Taranowski, Thomas (SWCOE) wrote:
> > I didn't see any details on what driver/hardware/os you're using, so I'm
> > making an educated guess...
> >
> > The problem you describe could potentially be a problem within the
> > driver.  I could see a scenario where the driver fails to send/transmit
> > any data because, say, there are no transmit buffers available.  In this
> > case the driver would fail to send, but be unable to notify that data
> > was sent, depending on the implementation of the low level driver/stack
> > interface.  In this case, the stack could be caught in some undefined
> > state.  The receipt of the ping triggers a transmit, and an interrupt,
> > and perhaps some other events, depending on the implementation, that
> > could cause operation to resume, but you'd probably see that some
> > packets were lost.
> >
> > I'd make sure that the driver send call never returns an error
> > condition.  As a simple test, try increasing the size of the transmit
> > queue, or whatever you use, for the driver.
> >
> > You could also increase the size of the PBUF_POOL_BUFSIZE option, so
> > that the depth of the buffer chain sent to the driver is shorter.  This
> > could result in fewer transmit buffers being used, depending on your
> > implementation of course.
> >
> > -Thomas
> >
> > -----Original Message-----
> > From: lwip-users-bounces+thomas.taranowski@6ãù¶ÏN!75|k%6l†uœ(c)j
> > [mailto:lwip-users-bounces+thomas.taranowski@6ãù¶ÏN!75|k%6l†uœ(c)j]
> > On Behalf Of Andre Puschmann
> > Sent: Sunday, February 04, 2007 12:06 PM
> > To: [hidden email]
> > Subject: [lwip-users] Re: curious large packets and transmit stuck
> >
> > hey guys,
> > another thing that maybe brings a bit more light is the following. once
> > the stack is as slow i can burst the things up for another ~300 packets
> > with a single ping.
> > after that burst transmission is slow again. but i can do this "trick"
> > again and again.
> > i already checked the timer function but they are called frequently.
> > what can a single ping packet activate in the stack (or its helper
> > functions)??
> > any hints??
> >
> >
> > best regards,
> >
> > andre
> >
> >
> > Andre Puschmann wrote:
> >> hi kieran,
> >> here are my lwip opts.h and one trace using the netconn-api and
> > another
> >> one using the raw api ..
> >> if you have a look at the first trace (netconn) you can see that the
> >> packets slowly dropping out/in .. it seems that lwip "forgets" acks
> > the
> >> other end send. you can't see the large packets directly, i mean there
> >> is one large and another small one, but before the stuck all packets
> >> were 1000bytes long. so it seems that it has something to do with
> > that.
> >> if i use the raw api there are no "large" packets .. since as long as
> >> lwip has something to send it sends packet with max size (1456byte).
> > but
> >> nevertheless, after a while the whole system shows the same behavior.
> >>
> >> do you think it has something to do with my timer/semaphore/mbox
> >> implementation?
> >>
> >>
> >> many thanks
> >>
> >> andre
> >>
> >>
> >>
> >> 1: http://www.puschmann.net/public/dropping_packets_rawapi.cap
> >> 2: http://www.puschmann.net/public/large_and_small_packet.cap
> >> 3: http://www.puschmann.net/public/opt.h
> >>
> >>
> >> Kieran Mansley wrote:
> >>> On Tue, 2007-01-30 at 21:56 +0100, Andre Puschmann wrote:
> >>>> i am aware of this fact. the curious thing IMO is the correlation
> >>>> between the occurrences of this "larger packets" and the stuck of
> > the
> >>>> whole stack.
> >>> Sounds like you may either have a locking problem (the usual cause of
> >>> deadlock) or possibly a resource allocation issue.  Is lwIP sending
> > or
> >>> receiving the large packet?  Could you get a packet trace using
> >>> something like ethereal?  Your lwipopts.h configuration might throw
> > some
> >>> light on the problem too.
> >>>
> >>> Kieran
> >
> >
> >
> > _______________________________________________
> > lwip-users mailing list
> > [hidden email]
> > http://lists.nongnu.org/mailman/listinfo/lwip-users
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 8 Feb 2007 06:19:56 -0500
> From: "shobhit saxena" <[hidden email]>
> Subject: [lwip-users] problem with netconn_accept
> To: [hidden email]
> Message-ID:
>        <[hidden email]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> hello everyone,
>                    i am using arm e7t board with ecos cofig tool & my
> target is to establish LWIP-TCP/IP over PPP & have communication
> between a server and ARM kit(client).I am using the lwip_init()
> function to establish PPP connection.I am using the following code for
> establishing TCP/IP .
> my problem is that the program is running fine till the line
> "newconn=netconn_accept(conn);"
> but its not accepting connection.Is there something wrong with my code?
> Is there any function to check the ip address that is being used?
>
>
> static void simple_prog(CYG_ADDRESS data)
> {
> cyg_io_handle_t handle1;
> cyg_io_lookup( "/dev/ser0", &handle1);
> lwip_init();
>    printf("\nConnected PPP\n");
> struct netconn *conn, *newconn;
> err_t err;
> struct ip_addr *addr;
> unsigned short port;
> conn = netconn_new(NETCONN_TCP);
>    cyg_thread_delay(50);
>
> int bind_result = netconn_bind(conn, NULL, 2506);
> //int bind_result = netconn_bind(conn,"192.168.0.4",2506);
>    cyg_thread_delay(50);
>    printf("\nBind to port 2506: [%d]", bind_result);
> int listen_result = netconn_listen(conn);
>    cyg_thread_delay(50);
>    printf("\nListening: [%d]\nPress any key to begin accepting.",
> listen_result);
>    getchar();
>    cyg_thread_delay(100);
> int netconn_peer_result;
> netconn_peer_result = netconn_peer(conn,NULL, NULL);
>
>    printf("\nEntering while loop");
> while(1) {
>        printf("\nInside while loop");
>
>    // --FROM HERE THE PROBLEM STARTS--//
>
>        newconn=netconn_accept(conn);
>        cyg_thread_delay(50);
>        printf("\nAccept: [%d]", newconn);
>        if(newconn != NULL)
>        {
>                  struct netbuf *buf;
>                  void *data;
>                  u16_t len;
>                        while((buf = netconn_recv(newconn)) != NULL)
>            {
>            do {
>                  netbuf_data(buf, &data, &len);
>                  err = netconn_write(newconn, data, len, NETCONN_COPY);
>                    if(err != ERR_OK) {    }
>               } while(netbuf_next(buf) >= 0);
>            netbuf_delete(buf);
>                  }
>                    netconn_delete(newconn);
>                }
>     }
> }
>
>
>
> void cyg_user_start(void)
> {
>    cyg_thread_create(4, simple_prog, (cyg_addrword_t) 0, "serial",
>                      (void *)stack[0], STACKSIZE, &thread[0], &thread_obj[0]);
>    cyg_thread_resume(thread[0]);
>    cyg_scheduler_start();
> }
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 8 Feb 2007 19:55:29 +0800
> From: "geckook Xu" <[hidden email]>
> Subject: [lwip-users] I can only create 3 tcp/ip connects ? why?
> To: [hidden email]
> Message-ID:
>        <[hidden email]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> When I create the 4th connect, All the others connects will be quit,
> and the new connect are not avaliable.
>
> Are there some other setup?
>
> There are my lwipopts.h file.
> -------------- next part --------------
> /*
>  * Copyright (c) 2001, 2002 Swedish Institute of Computer Science.
>  * All rights reserved.
>  *
>  * Redistribution and use in source and binary forms, with or without modification,
>  * are permitted provided that the following conditions are met:
>  *
>  * 1. Redistributions of source code must retain the above copyright notice,
>  *    this list of conditions and the following disclaimer.
>  * 2. Redistributions in binary form must reproduce the above copyright notice,
>  *    this list of conditions and the following disclaimer in the documentation
>  *    and/or other materials provided with the distribution.
>  * 3. The name of the author may not be used to endorse or promote products
>  *    derived from this software without specific prior written permission.
>  *
>  * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED
>  * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
>  * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
>  * SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
>  * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
>  * OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
>  * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
>  * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
>  * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
>  * OF SUCH DAMAGE.
>  *
>  * This file is part of the lwIP TCP/IP stack.
>  *
>  * Author: Adam Dunkels <address@hidden>
>  *
>  */
>
> #ifndef __LWIPOPTS_H__
> #define __LWIPOPTS_H__
>
> #if 1
> #define LWIP_DEBUG
> #define DBG_MIN_LEVEL   0
> #define DBG_TYPES_ON    (DBG_ON | DBG_TRACE | DBG_STATE | DBG_FRESH | DBG_HALT)
> #if 0
> #define TCP_DEBUG       DBG_OFF
> #define TCP_QLEN_DEBUG  DBG_OFF
> #define TCP_OUTPUT_DEBUG        DBG_ON
> #define TCP_RTO_DEBUG   DBG_ON
> #define TCP_FR_DEBUG    DBG_ON
> #define TCP_CWND_DEBUG                  DBG_ON
> #define TCP_WND_DEBUG                   DBG_ON
> #endif
> #define TCP_RST_DEBUG                   DBG_ON
> #if 1
> #define LINK_STATS  1
> #define IP_STATS    1
> #define IPFRAG_STATS    1
> #define ICMP_STATS  1
> #define UDP_STATS   1
> #define TCP_STATS   1
> #define MEM_STATS   1
> #define MEMP_STATS  1
> #define PBUF_STATS  1
> #define SYS_STATS   1
> #define RAW_STATS   1
> #define LWIP_STATS_DISPLAY  1
> #endif
> #define MEM_DEBUG       DBG_ON
> #define MEMP_DEBUG      DBG_ON
> #if 0
> #define TCP_INPUT_DEBUG DBG_ON
> #define RAW_DEBUG       DBG_OFF
> #define PBUF_DEBUG      DBG_OFF
> #endif
> #endif
>
> //efine SO_REUSE        1
> #define NO_SYS                  0
> #define LWIP_CALLBACK_API       1
> #define LWIP_DHCP               0
> #define SYS_LIGHTWEIGHT_PROT            1
>
> /* #define TCP_TMR_INTERVAL     250 */
> #define TCP_TMR_INTERVAL        250
>
> /* ---------- Memory options ---------- */
> /* MEM_ALIGNMENT: should be set to the alignment of the CPU for which
>   lwIP is compiled. 4 byte alignment -> define MEM_ALIGNMENT to 4, 2
>   byte alignment -> define MEM_ALIGNMENT to 2. */
> /* tried 4 byte alignment, but that seems to cause problems with pbuf
>  * routines */
> #define MEM_ALIGNMENT           4
>
> /* MEM_SIZE: the size of the heap memory. If the application will send
> a lot of data that needs to be copied, this should be set high. */
> #define MEM_SIZE                1024*90
>
> /* The following four are used only with the sequential API and can be
>   set to 0 if the application only will use the raw API. */
> /* MEMP_NUM_NETBUF: the number of struct netbufs. */
> #define MEMP_NUM_NETBUF         2
> /* MEMP_NUM_NETCONN: the number of struct netconns. */
> #define MEMP_NUM_NETCONN        4*2
> #define MEMP_NUM_TCP_PCB                5*10
> #define OS_MAX_QS                20*2    /* Max. number of queue control blocks in your application      */
> /* MEMP_NUM_APIMSG: the number of struct api_msg, used for
>   communication between the TCP/IP stack and the sequential
>   programs. */
> #define MEMP_NUM_API_MSG        16
> /* MEMP_NUM_TCPIPMSG: the number of struct tcpip_msg, which is used
>   for sequential API communication and incoming packets. Used in
>   src/api/tcpip.c. */
> #define MEMP_NUM_TCPIP_MSG      16*10
>
> #define MEMP_NUM_SYS_TIMEOUT            4+1
>
> #define PBUF_POOL_SIZE          16*16
> #define PBUF_POOL_BUFSIZE       128
> #define PBUF_LINK_HLEN          14
>
> #define TCP_MSS                 1460
>
> /* TCP_SND_BUF should be less than or equal to MEMP_NUM_TCP_SEG *
>  * TCP_MSS otherwise the system will not be able to allocate enough
>  * tcp_segs to transmit all the data and will return ERR_MEM when
>  * attempting to transmit large amounts of data.  You want to guarantee
>  * that there are more tcp_segs than there is memory.  Each segment
>  * is equal to TCP_MSS.
>  */
> #define MEMP_NUM_TCP_SEG        255
>
> #define TCP_WND                 2048
> #define TCP_SND_BUF             (MEMP_NUM_TCP_SEG-1) * TCP_MSS
>
> #endif /* __LWIPOPTS_H__ */
>
> ------------------------------
>
> Message: 4
> Date: Thu, 8 Feb 2007 12:42:21 +0000
> From: Kieran Mansley <[hidden email]>
> Subject: Re: [lwip-users] problem with netconn_accept
> To: Mailing list for lwIP users <[hidden email]>
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=us-ascii
>
> On Thu, Feb 08, 2007 at 06:19:56AM -0500, shobhit saxena wrote:
> > hello everyone,
> >                    i am using arm e7t board with ecos cofig tool & my
> > target is to establish LWIP-TCP/IP over PPP & have communication
> > between a server and ARM kit(client).I am using the lwip_init()
> > function to establish PPP connection.I am using the following code for
> > establishing TCP/IP .
> > my problem is that the program is running fine till the line
> > "newconn=netconn_accept(conn);"
> > but its not accepting connection.Is there something wrong with my code?
>
> I haven't looked in detail but it sounds like the packets aren't
> getting through to lwIP.  I'm afraid I don't know enough about the
> board you're using to suggest how to debug it though.
>
> Good luck,
>
> Kieran
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 8 Feb 2007 12:44:54 +0000
> From: Kieran Mansley <[hidden email]>
> Subject: Re: [lwip-users] I can only create 3 tcp/ip connects ? why?
> To: Mailing list for lwIP users <[hidden email]>
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=us-ascii
>
> On Thu, Feb 08, 2007 at 07:55:29PM +0800, geckook Xu wrote:
> > When I create the 4th connect, All the others connects will be quit,
> > and the new connect are not avaliable.
>
> Which API to lwIP are you using?
>
> Kieran
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 8 Feb 2007 13:12:27 +0000 (GMT)
> From: TEJ <[hidden email]>
> Subject: [lwip-users] client-server arch. using lwip
> To: Mailing list for lwIP users <[hidden email]>
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> hi
> can i use the complete lwip for a client server acrh. even if my system is having full fledged TCP/IP code and network driver.
> if yes then how to proceed with this design
> just give me some example...
> help needed very desparately
>
> Thank you in advance
>
>
> ---------------------------------
>  Here's a new way to find what you're looking for - Yahoo! Answers
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.gnu.org/pipermail/lwip-users/attachments/20070208/34b381c5/attachment.html
>
> ------------------------------
>
> Message: 7
> Date: Thu, 8 Feb 2007 15:41:57 +0100
> From: Fr?d?ric BERNON <[hidden email]>
> Subject: [lwip-users] Just to inform : Internet Explorer 7.0 and LwIP
>        Savannah web site problem
> To: "Mailing list for lwIP users" <[hidden email]>
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Skipped content of type multipart/related-------------- next part --------------
> A non-text attachment was scrubbed...
> Name: =?iso-8859-1?Q?Fr=E9d=E9ric_BERNON=2Evcf?=
> Type: text/x-vcard
> Size: 589 bytes
> Desc: =?iso-8859-1?Q?Fr=E9d=E9ric_BERNON=2Evcf?=
> Url : http://lists.gnu.org/pipermail/lwip-users/attachments/20070208/df64b3ae/iso-8859-1QFrE9dE9ric_BERNON2Evcf.vcf
>
> ------------------------------
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>
> End of lwip-users Digest, Vol 42, Issue 7
> *****************************************
>


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users