Alessandro Rubini wrote:
>> Were you going to send an update for Ben?
>>
>
> Yes, but I was waiting for your confirmation. Will do tomorrow.
>
> /alessandro
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-
> Were you going to send an update for Ben?
Yes, but I was waiting for your confirmation. Will do tomorrow.
/alessandro
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
On Fri 31 Jul 2009 03:46, Alessandro Rubini pondered:
> Thanks for your comments.
>
> >> +#ifndef CONFIG_TFTP_MAXBLOCK
> >> +#define CONFIG_TFTP_MAXBLOCK 16384
> >
> > It is more than tftp - nfs could also use the same.
>
> Yes, I know. But most users are tftp ones. And if you want an even
> num
> What I'm talking about is:
> - start a tftp file transfer.
> - CNTR-C it, causing a partial reassembly to done.
> - start a new transfer.
Yes, exactly the case I observed. But you are not guaranteed a partial
reassembly happens, as you should be ctrl-c-ing at the exact right
time.
> All I d
On Fri 31 Jul 2009 03:46, Alessandro Rubini pondered:
> > For some reason - why I'm ping flooding when tftping a large file (with
> > large tftp block size) - things hang. If I set the block size to under
> > the MTU - it works fine. Do you get the same?
>
> Didn't try, and I can't do that today.
On Fri 31 Jul 2009 10:02, Alessandro Rubini pondered:
> >> Is the target replying to all pings?
> >
> > Yes. And I can see the same in wireshark.
>
> Ah. I see. Strange...
>
> >> > What is missing in the reassembly code (that is described in RFC815)
> >> > is the timer. (quote from the RFC):
>
>> Is the target replying to all pings?
>
> Yes. And I can see the same in wireshark.
Ah. I see. Strange...
>> > What is missing in the reassembly code (that is described in RFC815)
>> > is the timer. (quote from the RFC):
>> > --
>> > The final part of the algorithm is some
On Fri 31 Jul 2009 08:16, Alessandro Rubini pondered:
> >> or simply your
> >> ether+uboot can't keep up with the data rate.
> >
> > That doesn't explain, why does it work, when there is no fragmentation???
>
> Well, with no fragmentation there is less traffic. Each tftp packet is
> one patch, i
>> or simply your
>> ether+uboot can't keep up with the data rate.
>
> That doesn't explain, why does it work, when there is no fragmentation???
Well, with no fragmentation there is less traffic. Each tftp packet is
one patch, instead of a burst of packets (intermixed with pings).
Is the target
On Fri 31 Jul 2009 03:46, Alessandro Rubini pondered:
> > For some reason - why I'm ping flooding when tftping a large file
> > (with large tftp block size) - things hang. If I set the block size
> > to under the MTU - it works fine. Do you get the same?
>
> Didn't try, and I can't do that today
Thanks for your comments.
>> +#ifndef CONFIG_TFTP_MAXBLOCK
>> +#define CONFIG_TFTP_MAXBLOCK 16384
>
> It is more than tftp - nfs could also use the same.
Yes, I know. But most users are tftp ones. And if you want an even
number (like 16k) as a tftp packet you need to add the headers and the
sequ
On Thu 30 Jul 2009 05:02, Alessandro Rubini pondered:
> The defragmenting code is enabled by CONFIG_IP_DEFRAG. The code
> is useful for TFTP transfers, so the static reassembly buffer is sized
> based on CONFIG_TFTP_MAXBLOCK (default is 16kB).
>
> The packet buffer is used as an array of "hole" st
The defragmenting code is enabled by CONFIG_IP_DEFRAG. The code
is useful for TFTP transfers, so the static reassembly buffer is sized
based on CONFIG_TFTP_MAXBLOCK (default is 16kB).
The packet buffer is used as an array of "hole" structures, acting as
a double-linked list. Each new fragment can
13 matches
Mail list logo
