[lwip-users] info required on lwip for win2000

[wilson gomes]

  Dear All,

I am  a newbie to lwIP.I am  compiling Florian Schulze lwIP(light weight 
Internet Protocol) stack on MS Visual C++  for a RealTek RTL8139(A)-based PCI 
Fast Ethernet Adapter.When I Execute a test application built over the lwIP  
stack , the output which I get says "UlbytesReceived =0".Hence the application 
does not proceed from there.I am using WinPcap 2.2.Could any user who has 
executed lwIP on Windows 2000 help me out on this?I would appreciate a "Readme  
" on how to execute lwIP on Windows 2000.

Thanks and Best Regards,
Wilson Gomes
  


On Mon, 14 Jun 2004 address@hidden wrote :
>Send lwip-users mailing list submissions to
>       address@hidden
>
>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
>       address@hidden
>
>You can reach the person managing the list at
>       address@hidden
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of lwip-users digest..."
>
>
>Today's Topics:
>
>    1. Re: Multiple IP addresses (Leon Woestenberg)
>    2. Re: Socket API thread safe? (Leon Woestenberg)
>    3. Is the pbuf_alloc usage correctly? (=?gb2312?q?bingsen=20xie?=)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Mon, 14 Jun 2004 10:18:45 +0200
> From: Leon Woestenberg <address@hidden>
>Subject: Re: [lwip-users] Multiple IP addresses
>To: Mailing list for lwIP users <address@hidden>
>Message-ID: <address@hidden>
>Content-Type: text/plain
>
>Hello Paul,
>
>On Fri, 2004-06-11 at 15:19, Paul wrote
> > Thanks for the answers. I have implemented option 2 and it looks like a
> > winner.
> >
>You are welcome. Nice to hear it worked out.
>
>I do not consider option 2 neat enough for lwIP though :-)
>
>Regards,
>
>Leon.
>
>
>
>
>
>------------------------------
>
>Message: 2
>Date: Mon, 14 Jun 2004 10:18:42 +0200
> From: Leon Woestenberg <address@hidden>
>Subject: Re: [lwip-users] Socket API thread safe?
>To: Peter Graf <address@hidden>, address@hidden
>Message-ID: <address@hidden>
>Content-Type: text/plain
>
>Hello Peter,
>
>On Fri, 2004-06-11 at 12:55, Peter Graf wrote:
> > >>Leon Woestenberg wrote:
> > >>>This is a recurring topic (and rightly so).
> > >>>lwIP socket API is *not* multi-threaded safe in the *generic* sense,
> > >>>i.e. for a full-pre-emptive environment (this is as far as I know).
> > >>So how do you know (given a proper implementation of sysarch and
> > >>lightweight prot. of course)? Can you provide an example?
> > >I do not know for certain, but lets take an example where I think it
> > >goes wrong:
> > >
> > >1 - network interface hardware receives packet, raises interrupt
> > >2 - the lwIP netif device driver's foobar_input() funtion is called
> > >     from a task that is made runnable, triggered by the interrupt.
> > >3 - the packet happens to update the ARP table
> > >4 - During 3, a higher priority task becomes runnable (and thus running)
> > >and sends out a packet on its own private UDP socket.
> > >
> > >We have a concurrent reader and writer in the ARP module and have
> > >incorrect behaviour.
> >
> > Thanks. I think you are right. Now it becomes clearer that I never saw an
> > effect like this, because in my case:
> >
>Yes, I assumed you are in a fully pre-emptive environment but like I
>said in one of my first sentences (see above):
>
> >>>lwIP socket API is *not* multi-threaded safe in the *generic* sense,
>
>i.e. there are some critical sections in the code that can clash, and
>mostly so when concurrent in/out traffic walks through the stack. This
>can currently only simply be protected against using a big lock approach
>where you regard the lwIP stack as one big resource.
>
> > a. The task that is triggered by the interrupt has highest possible priority
> > b. I have little movement in the ARP table. There are few local hosts, most
> > traffic goes to the gateway.
> > c. I use TCP rather than UDP
> >
> > Can we say that the essential thread-safety problems are restricted to ARP?
> >
>This needs investigation. We need to walk through all possible traces of
>where a pbuf travels and see wherever we modify a shared resource. Yes,
>ARP comes to mind for sure, but I suspect there are nitty tiny spots
>elsewhere. This is exactly why I have repeated that lwIP is not
>considered fully multi-threaded safe.
>
> > To me it looks like (almost) the only case where the sequential API is
> > circumvented.
> >
>True. Someone might be willing to fix this, but the hard thing is that
>you do not want to have recursive locking of mutexes.
>
> > experience anyway - I can not prove correctness. I have, however, used lwIP
> > quite a lot, and at found it stable enought to be _useful_ in a
> > full-pre-emptive environment.
> >
>Depending on how your set of tasks pre-empt each other, you might be on
>the safe side (maybe even fully thread safe in your case). Also, no
>proof there.
>
>Thanks for your input!
>
>Leon.
>
>
>
>
>
>------------------------------
>
>Message: 3
>Date: Mon, 14 Jun 2004 22:17:32 +0800 (CST)
> From: =?gb2312?q?bingsen=20xie?= <address@hidden>
>Subject: [lwip-users] Is the pbuf_alloc usage correctly?
>To: address@hidden
>Message-ID: <address@hidden>
>Content-Type: text/plain; charset="gb2312"
>
>
>hello,every one!
>
>I have use the lwip-0.7.1 with UCOS.I write an application with the UDP RAW 
>API.
>
>The program is list following. But my program cann't run stablly.
>It seems that the pbuf_alloc cann't correcttly return.
>Do you have the relative experience?Can you tell me?
>
>//*******************************************************
>//get a pbuf struct pointer matching with the size of data to be sent.
>//and fill the pbuf with data
>//************************
>int prepare_pbuf(struct pbuf* psendata)
>{
>  struct pbuf* q;
>  int nRet;
>  char* ptr;
>  char* data;
>
>  long i;
>  static char   data_buffer[UDP_SEND_PACKAGE_SIZE];
>  nRet=0;
>
>//Read my target send data
>  nRet=ReadFromCache(data_buffer,UDP_SEND_PACKAGE_SIZE);
>
>  if(nRet<=0) return -1;
>
>#ifdef __DEBUG
>  printf("the nRet is %d",nRet);
>#endif __DEBUG
>
>  psendata=pbuf_alloc(PBUF_ROM,nRet,PBUF_POOL);
>  if(psendata==NULL) return -1;
>  data=data_buffer;
>  for(q = psendata; q != NULL; q = q->next)
>  {
>   ptr=q->payload;
>   for(i = 0; i <q->len;i++)
>   {
>    *ptr++=*data++;
>   }
>  }
>  return 0;
>}
>
>//*******************************
>//release the pbuf pointer
>//*******************************
>void release_pbuf(struct pbuf* pdata)
>{
>  pbuf_free(pdata);
>}
>//******************************
>//send a lot of data to remote
>//********************************
>void voice_udp_sendout()
>{
>  struct udp_pcb * upcb_client;
>  err_t err_code;
>  char* ptr;
>  struct pbuf* psendata=NULL;
>  IP4_ADDR(&g_udp_remote_ip,192,168,1,100);
>  g_udp_remote_port=7;
>
>  upcb_client=udp_new();
>  if(upcb_client==NULL)
>  {
>   printf("client cann't create upcb\n");
>   return ;
>  }
>
>  printf("good\n");
>  g_udp_client_stop=0;
>
>
>  if(udp_connect(upcb_client,&g_udp_remote_ip,g_udp_remote_port)!=ERR_OK)
>  {
>   printf("cann't connect to remote server\n");
>   return ;
>  }
>
>  while(1)
>  {
>   //sys_sem_wait(g_sem_getvoice);
>   OSTimeDlyHMSM(0,0,0,5);
>
>   printf("3\n");
>   if(prepare_pbuf(psendata)!=0)
>   {
>
>
>// after some times successfully it will alway run into here!
>//I think it is because I use pbuf_alloc error.But I don't know whu my
>//usage about pbuf_alloc is error
>
>
>    //printf("Cann't Get Data for Sending!\n");
>    continue;
>   }
>   printf("4\n");
>
>
>   err_code=udp_send(upcb_client,psendata);
>   if(err_code==ERR_MEM)
>     printf("Mem Error\n");
>   else if(err_code==ERR_USE)
>    printf("Error used\n");
>   else printf("Send OK");
>
>   release_pbuf(psendata);
>   if(g_udp_client_stop==1)
>   {
>    udp_remove(upcb_client);
>    OSTaskDel(OS_PRIO_SELF);
>   }
>  }
>
>}
>
>int voice_udp_client_init()
>{
>  sys_thread_new(voice_udp_sendout, NULL,2);
>  return 0;
>}
>
>
>
>---------------------------------
>Do You Yahoo!?
>ÏÓÓÊÏä̫С£¿ÑÅ»¢µçÓÊ×ÔÖúÀ©ÈÝ£¡
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: 
>http://lists.gnu.org/pipermail/lwip-users/attachments/20040614/5fe63118/attachment.html
>
>------------------------------
>
>_______________________________________________
>lwip-users mailing list
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/lwip-users
>
>End of lwip-users Digest, Vol 10, Issue 16
>******************************************