* [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).