* [ECOS] RedBoot TFTP last block ack oddness
@ 2005-09-08 15:19 David Vrabel
2005-09-08 18:55 ` Andrew Dyer
0 siblings, 1 reply; 6+ messages in thread
From: David Vrabel @ 2005-09-08 15:19 UTC (permalink / raw)
To: ecos-discuss
[-- Attachment #1: Type: text/plain, Size: 675 bytes --]
Hi,
RedBoot's TFTP client has two oddities when ack'ing the last data block.
1. It fails to ack the last data block when loading ELF images if
there's trailing data after the last section it loads (more correctly,
it fails to ack the first block it doesn't want). For example, if an
image had a trailing .comment section.
2. Normally, two ack's are sent for the last block. I'm thinking the
tftp_ack() in tftp_stream_close() is unnecessary?
Attached are some packet captures summaries showing this.
David Vrabel
--
David Vrabel, Design Engineer
Arcom, Clifton Road Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK Web: http://www.arcom.com/
[-- Attachment #2: redboot-tftp-packets.txt --]
[-- Type: text/plain, Size: 2082 bytes --]
Sample packet capture of loading an ELF image:
RedBoot> load redboot-vulcan-v1i5-ram.elf
No. Time Source Destination Protocol Info
1 0.000000 10.2.39.40 10.2.2.14 TFTP Read Request, File: redboot-vulcan-v1i5-ram.elf, Transfer type: OCTET
2 0.009258 10.2.2.14 10.2.39.40 TFTP Data Packet, Block: 1
3 0.010083 10.2.39.40 10.2.2.14 TFTP Acknowledgement, Block: 1
4 0.010193 10.2.2.14 10.2.39.40 TFTP Data Packet, Block: 2
5 0.010893 10.2.39.40 10.2.2.14 TFTP Acknowledgement, Block: 2
[...]
1438 0.684266 10.2.2.14 10.2.39.40 TFTP Data Packet, Block: 719
1439 0.685045 10.2.39.40 10.2.2.14 TFTP Acknowledgement, Block: 719
1440 0.685076 10.2.2.14 10.2.39.40 TFTP Data Packet, Block: 720
1441 0.688509 10.2.39.40 10.2.2.14 TFTP Acknowledgement, Block: 720
1442 0.688556 10.2.2.14 10.2.39.40 TFTP Data Packet, Block: 721 (last)
1443 5.689069 10.2.2.14 10.2.39.40 TFTP Data Packet, Block: 721 (last)
1444 10.690189 10.2.2.14 10.2.39.40 TFTP Data Packet, Block: 721 (last)
1445 15.691244 10.2.2.14 10.2.39.40 TFTP Data Packet, Block: 721 (last)
1446 20.692337 10.2.2.14 10.2.39.40 TFTP Data Packet, Block: 721 (last)
Sample packet capture of loading a raw image:
RedBoot> load -r -b %{FREEMEMLO} 600B
No. Time Source Destination Protocol Info
1 0.000000 10.2.39.40 10.2.2.14 TFTP Read Request, File: 600B, Transfer type: OCTET
2 0.003572 10.2.2.14 10.2.39.40 TFTP Data Packet, Block: 1
3 0.004294 10.2.39.40 10.2.2.14 TFTP Acknowledgement, Block: 1
4 0.004371 10.2.2.14 10.2.39.40 TFTP Data Packet, Block: 2 (last)
5 0.004832 10.2.39.40 10.2.2.14 TFTP Acknowledgement, Block: 2
6 0.007925 10.2.39.40 10.2.2.14 TFTP Acknowledgement, Block: 2
7 0.007961 10.2.2.14 10.2.39.40 ICMP Destination unreachable (Port unreachable)
[-- Attachment #3: Type: text/plain, Size: 148 bytes --]
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] RedBoot TFTP last block ack oddness
2005-09-08 15:19 [ECOS] RedBoot TFTP last block ack oddness David Vrabel
@ 2005-09-08 18:55 ` Andrew Dyer
2005-09-08 19:13 ` Gary Thomas
2005-09-09 13:19 ` David Vrabel
0 siblings, 2 replies; 6+ messages in thread
From: Andrew Dyer @ 2005-09-08 18:55 UTC (permalink / raw)
To: David Vrabel; +Cc: ecos-discuss
On 9/8/05, David Vrabel <dvrabel@arcom.com> wrote:
> Hi,
>
> RedBoot's TFTP client has two oddities when ack'ing the last data block.
>
> 1. It fails to ack the last data block when loading ELF images if
> there's trailing data after the last section it loads (more correctly,
> it fails to ack the first block it doesn't want). For example, if an
> image had a trailing .comment section.
Perhaps this: http://sourceware.org/ml/ecos-discuss/2004-03/msg00148.html
patch would help. I don't think it ever went in to cvs, but it's been
way too long to
remember.
--
Hardware, n.:
The parts of a computer system that can be kicked.
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] RedBoot TFTP last block ack oddness
2005-09-08 18:55 ` Andrew Dyer
@ 2005-09-08 19:13 ` Gary Thomas
2005-09-09 13:19 ` David Vrabel
1 sibling, 0 replies; 6+ messages in thread
From: Gary Thomas @ 2005-09-08 19:13 UTC (permalink / raw)
To: Andrew Dyer; +Cc: David Vrabel, eCos Discussion
On Thu, 2005-09-08 at 13:55 -0500, Andrew Dyer wrote:
> On 9/8/05, David Vrabel <dvrabel@arcom.com> wrote:
> > Hi,
> >
> > RedBoot's TFTP client has two oddities when ack'ing the last data block.
> >
> > 1. It fails to ack the last data block when loading ELF images if
> > there's trailing data after the last section it loads (more correctly,
> > it fails to ack the first block it doesn't want). For example, if an
> > image had a trailing .comment section.
>
> Perhaps this: http://sourceware.org/ml/ecos-discuss/2004-03/msg00148.html
> patch would help. I don't think it ever went in to cvs, but it's been
> way too long to
> remember.
Indeed, it does not seem like it has been applied (sorry if I
missed it, or however this happened). Anyway, David if you can
try this and see if it helps (hopefully solves) the problems
you reported, I'll make sure and apply it now.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] RedBoot TFTP last block ack oddness
2005-09-08 18:55 ` Andrew Dyer
2005-09-08 19:13 ` Gary Thomas
@ 2005-09-09 13:19 ` David Vrabel
2005-09-09 13:27 ` Gary Thomas
1 sibling, 1 reply; 6+ messages in thread
From: David Vrabel @ 2005-09-09 13:19 UTC (permalink / raw)
To: ecos-discuss
[-- Attachment #1: Type: text/plain, Size: 770 bytes --]
Andrew Dyer wrote:
> On 9/8/05, David Vrabel <dvrabel@arcom.com> wrote:
>>
>>RedBoot's TFTP client has two oddities when ack'ing the last data block.
>>
>>1. It fails to ack the last data block when loading ELF images if
>>there's trailing data after the last section it loads (more correctly,
>>it fails to ack the first block it doesn't want). For example, if an
>>image had a trailing .comment section.
>
> Perhaps this: http://sourceware.org/ml/ecos-discuss/2004-03/msg00148.html
> patch would help.
That did the trick. Thanks, Andrew.
Gary, a reworked patch against recent CVS is attached.
David Vrabel
--
David Vrabel, Design Engineer
Arcom, Clifton Road Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK Web: http://www.arcom.com/
[-- Attachment #2: redboot-tftp-load-elf-ack-fix --]
[-- Type: text/plain, Size: 6294 bytes --]
Index: ecos-working/packages/redboot/current/ChangeLog
===================================================================
--- ecos-working.orig/packages/redboot/current/ChangeLog 2005-09-05 16:24:00.000000000 +0100
+++ ecos-working/packages/redboot/current/ChangeLog 2005-09-09 10:57:58.000000000 +0100
@@ -1,3 +1,16 @@
+2005-09-09 Andrew Dyer <adyer@righthandtech.com>
+
+ * src/load.c: add calls to redboot_getc_terminate before exiting
+ load_elf_image() in various error scenarios, change the final call
+ to redboot_getc_terminate to have the error flag set. This will
+ cause a tftp nak and close down the connection since for ELF files
+ we don't read the whole content but end the connection when the
+ runnable parts are in.
+
+ * src/net/tftp_client.c: add tftp_error() to send an error back to
+ the server. define tftp_stream_terminate() and pass it into the
+ redboot interface.
+
2005-09-03 Andrew Lunn <andrew.lunn@ascom.ch>
* cdl/redboot.cdl: White space changes to aid readability.
Index: ecos-working/packages/redboot/current/include/net/tftp_support.h
===================================================================
--- ecos-working.orig/packages/redboot/current/include/net/tftp_support.h 2002-07-01 21:55:28.000000000 +0100
+++ ecos-working/packages/redboot/current/include/net/tftp_support.h 2005-09-09 10:53:21.000000000 +0100
@@ -87,6 +87,7 @@
extern int tftp_stream_open(connection_info_t *info, int *err);
extern int tftp_stream_read(char *buf, int len, int *err);
extern void tftp_stream_close(int *err);
+extern void tftp_stream_terminate(bool abort, int (*getc)(void));
extern char *tftp_error(int err);
#define TFTP_TIMEOUT_PERIOD 5
Index: ecos-working/packages/redboot/current/src/load.c
===================================================================
--- ecos-working.orig/packages/redboot/current/src/load.c 2004-09-19 14:01:54.000000000 +0100
+++ ecos-working/packages/redboot/current/src/load.c 2005-09-09 10:56:10.000000000 +0100
@@ -307,6 +307,7 @@
// Read the header
if (_read(getc, (unsigned char *)&ehdr, sizeof(ehdr)) != sizeof(ehdr)) {
diag_printf("Can't read ELF header\n");
+ redboot_getc_terminate(true);
return 0;
}
offset += sizeof(ehdr);
@@ -318,15 +319,18 @@
#endif
if (ehdr.e_type != ET_EXEC) {
diag_printf("Only absolute ELF images supported\n");
+ redboot_getc_terminate(true);
return 0;
}
if (ehdr.e_phnum > MAX_PHDR) {
diag_printf("Too many program headers\n");
+ redboot_getc_terminate(true);
return 0;
}
while (offset < ehdr.e_phoff) {
if ((*getc)() < 0) {
diag_printf(SHORT_DATA);
+ redboot_getc_terminate(true);
return 0;
}
offset++;
@@ -334,6 +338,7 @@
for (phx = 0; phx < ehdr.e_phnum; phx++) {
if (_read(getc, (unsigned char *)&phdr[phx], sizeof(phdr[0])) != sizeof(phdr[0])) {
diag_printf("Can't read ELF program header\n");
+ redboot_getc_terminate(true);
return 0;
}
#if 0 // DEBUG
@@ -376,6 +381,7 @@
if (offset > phdr[phx].p_offset) {
if ((phdr[phx].p_offset + len) < offset) {
diag_printf("Can't load ELF file - program headers out of order\n");
+ redboot_getc_terminate(true);
return 0;
}
addr += offset - phdr[phx].p_offset;
@@ -383,6 +389,7 @@
while (offset < phdr[phx].p_offset) {
if ((*getc)() < 0) {
diag_printf(SHORT_DATA);
+ redboot_getc_terminate(true);
return 0;
}
offset++;
@@ -400,6 +407,7 @@
#endif
if ((ch = (*getc)()) < 0) {
diag_printf(SHORT_DATA);
+ redboot_getc_terminate(true);
return 0;
}
*addr++ = ch;
@@ -422,7 +430,10 @@
entry_address = ehdr.e_entry;
}
- redboot_getc_terminate(false);
+ // nak everything to stop the transfer, since redboot
+ // usually doesn't read all the way to the end of the
+ // elf files.
+ redboot_getc_terminate(true);
if (addr_offset) diag_printf("Address offset = %p\n", (void *)addr_offset);
diag_printf("Entry point: %p, address range: %p-%p\n",
(void*)entry_address, (void *)load_address, (void *)load_address_end);
Index: ecos-working/packages/redboot/current/src/net/tftp_client.c
===================================================================
--- ecos-working.orig/packages/redboot/current/src/net/tftp_client.c 2004-04-23 21:38:18.000000000 +0100
+++ ecos-working/packages/redboot/current/src/net/tftp_client.c 2005-09-09 11:11:34.000000000 +0100
@@ -158,10 +158,49 @@
return 0;
}
+static int
+tftp_error_ack(int *err, short code, char *msg)
+{
+ struct tftphdr *hdr = (struct tftphdr *)tftp_stream.data;
+
+ if (strlen(msg) > (SEGSIZE-1)) {
+ *(msg + SEGSIZE) = NULL;
+ }
+
+ if (tftp_stream.packets_received > 0) {
+ hdr->th_opcode = htons(ERROR);
+ hdr->th_code = code;
+ strcpy(&hdr->th_data, msg);
+ if (__udp_sendto(tftp_stream.data, (5 + strlen(msg)),
+ &tftp_stream.from_addr, &tftp_stream.local_addr) < 0) {
+ // Problem sending ACK
+ *err = TFTP_NETERR;
+ return -1;
+ }
+ }
+ return 0;
+}
+
void
tftp_stream_close(int *err)
{
- tftp_ack(err);
+ if (tftp_stream.open == true) {
+ tftp_ack(err);
+ tftp_stream.open = false;
+ }
+}
+
+void
+tftp_stream_terminate(bool abort,
+ int (*getc)(void))
+{
+ int err;
+
+ if (abort)
+ tftp_error_ack(&err, EUNDEF, "redboot tftp_stream_terminate");
+ else
+ tftp_ack(&err);
+
tftp_stream.open = false;
}
@@ -274,6 +313,6 @@
// RedBoot interface
//
GETC_IO_FUNCS(tftp_io, tftp_stream_open, tftp_stream_close,
- 0, tftp_stream_read, tftp_error);
+ tftp_stream_terminate, tftp_stream_read, tftp_error);
RedBoot_load(tftp, tftp_io, true, true, 0);
[-- Attachment #3: Type: text/plain, Size: 148 bytes --]
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] RedBoot TFTP last block ack oddness
2005-09-09 13:19 ` David Vrabel
@ 2005-09-09 13:27 ` Gary Thomas
2005-09-12 9:41 ` Stefan Sommerfeld
0 siblings, 1 reply; 6+ messages in thread
From: Gary Thomas @ 2005-09-09 13:27 UTC (permalink / raw)
To: David Vrabel; +Cc: ecos-discuss
On Fri, 2005-09-09 at 14:19 +0100, David Vrabel wrote:
> Andrew Dyer wrote:
> > On 9/8/05, David Vrabel <dvrabel@arcom.com> wrote:
> >>
> >>RedBoot's TFTP client has two oddities when ack'ing the last data block.
> >>
> >>1. It fails to ack the last data block when loading ELF images if
> >>there's trailing data after the last section it loads (more correctly,
> >>it fails to ack the first block it doesn't want). For example, if an
> >>image had a trailing .comment section.
> >
> > Perhaps this: http://sourceware.org/ml/ecos-discuss/2004-03/msg00148.html
> > patch would help.
>
> That did the trick. Thanks, Andrew.
>
> Gary, a reworked patch against recent CVS is attached.
Close - the ChangeLog entry was stale :-)
Applied now.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] RedBoot TFTP last block ack oddness
2005-09-09 13:27 ` Gary Thomas
@ 2005-09-12 9:41 ` Stefan Sommerfeld
0 siblings, 0 replies; 6+ messages in thread
From: Stefan Sommerfeld @ 2005-09-12 9:41 UTC (permalink / raw)
To: ecos-discuss
Hi,
It looks like it doesn't work correctly. I still get tftp timeouts and the
port will not be freed (transfer port constantly counting up).
Another question regarding zlib: If i try to load a gzip compressed file
via tftp i always get "file not found". Uploading via xmodem work
correctly.
Bye...
----- Original Message -----
From: "Gary Thomas" <gary@mlbassoc.com>
To: "David Vrabel" <dvrabel@arcom.com>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Freitag, 9. September 2005 15:26
Subject: Re: [ECOS] RedBoot TFTP last block ack oddness
> On Fri, 2005-09-09 at 14:19 +0100, David Vrabel wrote:
>> Andrew Dyer wrote:
>> > On 9/8/05, David Vrabel <dvrabel@arcom.com> wrote:
>> >>
>> >>RedBoot's TFTP client has two oddities when ack'ing the last data
>> >>block.
>> >>
>> >>1. It fails to ack the last data block when loading ELF images if
>> >>there's trailing data after the last section it loads (more correctly,
>> >>it fails to ack the first block it doesn't want). For example, if an
>> >>image had a trailing .comment section.
>> >
>> > Perhaps this:
>> > http://sourceware.org/ml/ecos-discuss/2004-03/msg00148.html
>> > patch would help.
>>
>> That did the trick. Thanks, Andrew.
>>
>> Gary, a reworked patch against recent CVS is attached.
>
> Close - the ChangeLog entry was stale :-)
>
> Applied now.
>
> --
> ------------------------------------------------------------
> Gary Thomas | Consulting for the
> MLB Associates | Embedded world
> ------------------------------------------------------------
>
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-09-12 9:41 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-09-08 15:19 [ECOS] RedBoot TFTP last block ack oddness David Vrabel
2005-09-08 18:55 ` Andrew Dyer
2005-09-08 19:13 ` Gary Thomas
2005-09-09 13:19 ` David Vrabel
2005-09-09 13:27 ` Gary Thomas
2005-09-12 9:41 ` Stefan Sommerfeld
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).