[mc1322x] Fragmented packets: could not allocate a queuebuf

[Daniel Berenguer]

Thanks David but I'm not sure that the problem is in tunslip6. The
problem is being reported by my tftp client, a customized version of
the udp-client example that accepts up to 512-byte data packets. I'm
now doing some additional tests in order to get a better idea about
the problem.

Daniel.


On 21 July 2010 00:31, David Kopf <dak664 at embarqmail.com> wrote:
> That tunslip6.c I posted has an option -d <msec> for spacing output packets,
> needed to slow down the back-to-back ACK and http GET sent to the raven
> webserver (might be fixed now with the recent changes).  1280 bytes pings
> worked before that, single pings with no problem, multiple pings required a
> 400 msec delay. Without the latter, my error messages indicated command
> buffer overrun in the econotag (might be fixed with the recent changes).
>
>
> ----- Original Message ----- From: "Daniel Berenguer"
> <dberenguer at usapiens.com>
> To: <mc1322x at devl.org>
> Sent: Tuesday, July 20, 2010 6:08 PM
> Subject: [mc1322x] Fragmented packets: could not allocate a queuebuf
>
>
>> Following my tests about sending fragmented UDP packets...
>>
>> Receiving multiple data packets of 512 bytes seems to cause the
>> following Contiki run-time error:
>> queuebuf_new_from_packetbuf: could not allocate a queuebuf
>>
>> The first receptions work just fine - hence my initial happiness :-) -
>> but later transmissions end by encountering the above error. I've
>> tested with smaller packets and I'm not able to reproduce the problem.
>> Maybe 1300 bytes is too much for a single packet ??
>>
>> I'm now trying to know whether this problem could be due to some kind
>> of "time" overlap between incoming packets...
>>
>
>