[lwip-users] Re: lwip-users Digest, Vol 66, Issue 4

[devesh]

Hello Bernhard,

Well I used sizeof(string) instead of strlen, but the problem was - I
got only 4 bytes on receiver side. However, whenever I used some
integer :
 tcp_write(pcb, test, 1024*1024, 0);

I got the ack that 1024 bytes sent.But could not received by receiver end.

I am using XILINX and dont know how to set TCP_SND_BUF?? :(

Ya,my interface(network) is working correctly. And, the bytes are
being lost in such a way:
1. when I sent 24 I got 16.
2. when I sent 16 I got 8

Where are these 8 bytes going? (and these are not zeros)

Thanks,
Devesh.

> Hi Devesh,
>
> the limitations of lwip are definetly not 24Bytes for a data segement.
>
>  From your code snippet I can not tell what is going wrong.
> The only strange thing is that you calculate the size of your data via
> strlen. This will not work if your data contains bytes with value of 0.
> But from my point of view longer strings should be transmitted as well.
>
> Are you sure that your interface to the ethernet ( I assume this is the
> transport medium you use) works correct?
> There could be data loss as well. Are packets with larger payload
> transmitted?
> If they are not transmitted: Is the data even received by the interface
> driver or not?
>
> How did you set up lwip? To what value is your TCP_SND_BUF set?
>
> Maybe that helps you tracing your problems a bit more...
>
> Regards,
> Bernhard
>
>
> devesh schrieb:
>> Hi all,
>>
>> Thanks for previous responses!!
>>
>> I have been facing a problem as I told earlier. I want to send an 2-D
>> array of 128X128 (say:char img[128][128]) from one Spartan board to
>> another. I am able to send 32bytes with the following code. But at
>> receiving end, I got 24bytes(8 bytes are being lost) only. When i
>> exceed from 32,I get nothing.
>> So I concluded that the max bytes can be transferred are 24. But how
>> can I send 128X128? Through loop?
>> Well, I am using RAW api of LWIP and edk on WinXP
>>
>> //FROM SENDER
>> static err_t client_connected(void *arg, struct tcp_pcb *pcb, err_t err)
>> {
>>    int i;
>>    char test[32];
>>    //char *string = "Hello!";
>>    char LWIP_UNUSED_ARG(arg);
>>
>>    for(i=0;i<32;i++)
>>    {
>>       test[i]='1';
>>    }
>>    test[i-9]='A';
>>    test[32]='\0';
>>    xil_printf("The Payload is %s \n\r",test);
>>    if (err != ERR_OK)
>>
>> printf("\nclient_connected(): err argument not set to ERR_OK, but is
>> value is %d\n", err);
>>
>>    else
>>    {
>>        tcp_sent(pcb, client_sent);
>>        tcp_write(pcb, test, strlen(test), 0);
>>    }
>>
>>    return err;
>> }
>>
>> //FROM RECEIVING SIDE
>> err_t recv_callback(void *arg, struct tcp_pcb *tpcb,
>>                                struct pbuf *p, err_t err)
>> {
>>
>>       /* do not read the packet if we are not in ESTABLISHED state */
>> #if 0
>>       if (tpcb->state >= 5 && tpcb->state <= 8) {
>>               tcp_close(tpcb);
>>               if (p)
>>                       pbuf_free(p);
>>               //xil_printf("Connection (%d) closed\n\r", (int)(arg));
>>               return;
>>       } else if (tpcb->state > 8)
>>               return;
>> #else
>>       if (!p) {
>>               tcp_close(tpcb);
>>               tcp_recv(tpcb, NULL);
>>               return ERR_OK;
>>       }
>> #endif
>>
>>       /* indicate that the packet has been received */
>>       tcp_recved(tpcb, p->len);
>>       int n=32;
>>       /* echo back the payload */
>>       /* in this case, we assume that the payload is < TCP_SND_BUF */
>>       if (tcp_sndbuf(tpcb) > p->len) {
>>               char testing[100];
>>               strncpy(testing, p->payload,p->len);
>>               testing[p->len]='\0';
>>               xil_printf("The actual Payload is %s\n\r",p->payload);
>>               xil_printf("The Payload is %s \n\r",testing);
>>               xil_printf("The Payload on %d is %c \n\r",n-9,testing[n-9]);
>>               xil_printf("The Reference is %d\n\r",p->ref);
>>               xil_printf("The Length of packet is %d\n\r",p->len);
>>               xil_printf("Remote Port Number :: %d\n\r",tpcb->remote_port);
>>               xil_printf("Local Port Number :: %d\n\r",tpcb->local_port);
>>               err = tcp_write(tpcb, p->payload, p->len, 1);
>>       } else
>>               print("no space in tcp_sndbuf\n\r");
>>
>>       /* free the received pbuf */
>>       pbuf_free(p);
>>
>>       return ERR_OK;
>> }
>>
>> Now what I get:
>> on sender
>> Input string -
>> The Payload is : 1111111111111111111111A11111111
>>
>> on receiver:
>> output -
>> The actual Payload is : 1111111111111111111111A
>> The Payload is : 111111111111111111111A
>> The Payload on 23 is A
>>
>> I want to know what are the limitation of LWIP? And can size of
>> TCP_SND_BUF be changed?
>>
>> Please help me out!!!
>> Regards,
>> Devesh
>>
>>
>> _______________________________________________
>> lwip-users mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>>
>>
>
>
> --
> Dipl-Ing Bernhard Wiegel
>
> Universität Ulm - Ulm University
> Institut für Organisation und Management von Informationssystemen (OMI) - 
> Institute for Information Resource Management
>
> Albert-Einstein-Allee 43
> 89081 Ulm, Germany
> Tel: +49 731 - 50 28788
> Fax: +49 731 - 50 28789
> E-Mail: address@hidden
>
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 4 Feb 2009 02:10:23 -0800 (PST)
> From: "Emmanuel Baguia Jr." <address@hidden>
> Subject: Re: [lwip-users] lwip stack network adapter
> To: address@hidden
> Cc: Mailing list for lwIP users <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Simon,
>
> Thank you very much for the informative reponse. I dont know until now about 
> the stability of the win32 port of lwIP. Since I am using it now and found to 
> be useful and working according to my design, I will continue with it. 
> Anyways, I will take a look on some of your approaches on how to deal with 
> the lwip stack network adapter. I think this one is much better:
>
> [..] As you can see, all approaches have a downside, which is why there is no
> automatic detection, yet. You could also write the index into a configuration
> file, which is parsed when the lwIP process is started.
>
> Again, thank you very much.
>
> Best regards,
> Emmanuel
>
> --- On Wed, 2/4/09, Simon Goldschmidt <address@hidden> wrote:
>
> From: Simon Goldschmidt <address@hidden>
> Subject: Re: [lwip-users] lwip stack network adapter
> To: address@hidden, "Mailing list for lwIP users" <address@hidden>
> Date: Wednesday, February 4, 2009, 3:47 PM
>
>> [..] So, in
>> this situation, I need to manually check from one machine to another what
>> is the actual adapter it is using and update the PACKET_LIB_ADAPTER_NR. Do
>> I really need to do this? Or maybe lwIP supports automatic detection of
>> which adapter to use? Please advise.
>
> Since I wrote that part, I can tell for sure it doesn't support automatic
> detection. But of course you can implement that if you want. You can search 
> for
>
> - the GUID of the adapter (don't know if that helps you much)
> - the name of the adapter (could be difficult, too, as that name can be 
> changed
> by the user)
> - have some automatic fallback, but that would mean with a real and a virtual
> LAN, it could go wrong
> - rely on the company part of the adapter's MAC (that should be the same
> for all your virtual LANs)
>
> As you can see, all approaches have a downside, which is why there is no
> automatic detection, yet. You could also write the index into a configuration
> file, which is parsed when the lwIP process is started.
>
> After all, the win32 port was started as a development project. I don't
> know if it is safe to be used in a production environment (if that's what
> you are looking for).
>
> Simon
> --
> Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL
> für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> http://lists.gnu.org/pipermail/lwip-users/attachments/20090204/0d5c0621/attachment.html
>
> ------------------------------
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>
> End of lwip-users Digest, Vol 66, Issue 4
> *****************************************
>