[ECOS] DHCP problem solved

["Vijay Padiyar" <vijay_padiyar at hotmail dot com>]

Hi guys

We finally solved all the problems with the BOOTP/DHCP reply!!!

We made two changes:

FIRSTLY, we observed that the board took the IP address when the Tftpd32
DHCP server was used, but didn't work when the BOOTP Desktop server was
used. In the Ethereal capture, we observed that Tftpd32 BROADCASTS the
DHCP/BOOTP reply, whereas BOOTP Desktop UNICASTS it back to the requesting
MAC address. So as soon as we configured the BOOTP Desktop to always
broadcast the BOOTP reply, everything started working absolutely fine!

I guess the BOOTP application in the eCos networking stack broadcasts the
BOOTP request and then listens specifically for DHCP/BOOTP replies that are
broadcast, rather than unicast back to it.

SECONDLY, we observed that a lot of data was being displayed during the DHCP
configuration phase by way of 'Unknown option' tags. A sample of this can be
seen below in my original mail. For this, we made a change to the
'show_bootp' function in 'bootp_support.c'
(packages/net/common/current/src). We hardwired the vendor-specific options
display loop to display data only within a limit of 64 bytes, which is the
standard BOOTP vendor-specific area size. After that, we saw that the excess
options were removed, and the ones displayed matched with the options shown
in the Ethereal capture.

I guess, since we were using a DHCP server to respond to a BOOTP request, it
was sending much more data than by way of options than allowed by the BOOTP
protocol, and this was causing the BOOTP reply vendor options area to go
beyond the 64-byte limit. So this was the reason for displaying so many
'Unknown option' messages with lots of random data.

Below is our modified code:

--------------------------------------------------------------------------

void
show_bootp(const char *intf, struct bootp *bp)
{
    int i, len, count = 0;        // <--------- added 'count' variable to
check for                                                             //end
of vendor-specific options region
..
..
if (bp->bp_vend[0] == mincookie[0]) {            // Made it more specific
        diag_printf("  vendor-specific options:\n");
        op = &bp->bp_vend[4];

while ((*op != TAG_END) && (count < (BP_VEND_LEN-4))) {
                                                                        //
Checking for end of vendor
//options area
      count++;
                                                                        //
Increment count
    switch (*op) {
                case TAG_PAD:
..
..

-----------------------------------------------------------------------

Please send me your comments and suggestions on this.

Also, since we're also working on implementing the JFFS2 filesystem on our
board, I thought I'd mention that we managed to solve the problem by
inserting a DELAY in function 'flash_program_buf()' in flash_program_buf.c
(packages/devs/flash/intel/strata/current/src). Earlier the code was erasing
the entire '/dev/flash1' area PLUS our RedBoot code area and programming it
to 0x0080. As soon as we put this delay, it worked fine. Guess it was some
timing problem with our Flash memory.

----------------------------------------------------------------------

int
flash_program_buf(volatile flash_t *addr, flash_t *data, int len,
                  unsigned long block_mask, int buffer_size)
{
    volatile flash_t *ROM;
    volatile flash_t *BA;
..
..
BA[0] = FLASH_Reset;
        HAL_DELAY_US(10000);        // <---- Added delay here
        if (*addr++ != *data++) {
            stat = FLASH_ErrorNotVerified;
            break;
..
..

--------------------------------------------------------------------

Another mistake we were making was that we were building the jffs2.img file
with mkfs.jffs2 with the wrong pad size. Earlier it was 128 KB in size,
though the '/dev/flash1' JFFS2 partition was allocated 1 MB in eCos Config
Tool. We now padded it to 1 MB to get a 1 MB jffs2.img file and the problem
was solved.

mkfs.jffs2 --big-endian -r ./test -o jffs2.img -p 0x00100000        //1 MB
pad

corresponding to...

CYGNUM_IO_FLASH_BLOCK_LENGTH_1 = 0x00100000

Thanks all of you for your help!!!

Regards

Chandrashekhar Padiyar



----- Original Message -----
From: "Nick Garnett" <nickg@calivar.com>
To: "Chandrashekhar Padiyar" <chandrashekhar.padiyar@xaltedinc.com>
Sent: Saturday, October 09, 2004 1:42 PM
Subject: Re: [ECOS] problem with your DHCP server


>
>
> I'm not sure this email made it to Philippe Jounin, it looks like you
> sent it to <philippe@jouninnet> rather than <philippe@jounin.net>. You
> may want to resend it with a fixed destination.
>
>
> To me the problem looks like it is getting out of sync somehow and
> interpreting random data as BOOTP fields. Perhaps it is something as
> simple as the reply message being too large. Are you able to run
> ethereal or something on the server machine and snoop what the reply
> message really is? It might also help to dump out the received message
> in eCos just before the BOOTP code interprets it and see whether they
> match.
>
>
> "Chandrashekhar Padiyar" <chandrashekhar.padiyar@xaltedinc.com> writes:
>
> > Hi Philippe
> >
> > We are using your product Tftpd32, which also includes a DHCP server. We
are
> > using this DHCP server to assign an IP address to our board that uses
the
> > BOOTP protocol.
> >
> > In the vendor-specific options, our BOOTP implementation only recognizes
> > some fields, like Subnet Mask (code 1), Requested IP Address (code 50),
etc.
> > The remaining options are displayed as "Unknown option: ", followed by
the
> > description of the option (length specified in length field following
code
> > field).
> >
> > Now when the board displays these vendor-specific options, we find some
> > strange values for them. Some options like Subnet Mask are displayed
> > multiple times without any following data. Many other options have codes
> > that are not described in any RFCs, such as in the range 128-254. They
also
> > have quite long lengths, such as 250 bytes and so on. Some of these
fields
> > are Quote of the Day servers and Time servers, but have the same
unusually
> > long lengths.
> >
> > See data below:
> >
> > --------------------------------------------------------------------
> >
> > Unknown option: a/10.29: 216 0 0 0 0 0 10 46 56 0 12 140 240 0 12 141 80
0 0
> > 0 0
> >  0 0 0 0 0 0 0 0
> > Unknown option: 2/2.0:
> > Unknown option: 80/128.8: 0 0 0 0 0 0 0 0
> > Unknown option: 18/24.0:
> > Unknown option: 40/64.0:
> >         subnet mask:
> >         subnet mask:
> > Unknown option: 8/8.62: 212 0 0 0 0 0 0 0 0 0 8 67 232 0 0 0 0 0 0 0 0 0
0 0
> > 0 0
> >  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 50 0 0 0 0
0
> >         domain name: <Not a string: 0xB5198>
> >           host name: @
> > Unknown option: fe/254.251: 239 245 191 46 0 0 0 0 1 9 221 221 89 136
247
> > 222 23
> > 4 87 223 199 8 2 255 55 70 255 253 102 68 0 253 239 159 219 254 163 3 32
118
> > 197
> >  230 121 255 86 0 0 255 107 18 226 223 235 25 128 191 229 191 215 239
251
> > 192 0
> > 223 189 174 239 223 201 2 128 188 127 255 127 242 250 32 0 223 237 234
235
> > 255 1
> > 62 56 4 254 63 191 255 251 246 4 0 251 249 221 220 215 247 34 0 253 251
78
> > 190 1
> > 87 219 18 0 239 250 157 171 255 110 64 0 239 250 63 158 187 111 69 0 255
237
> > 237
> >  255 235 66 132 0 116 206 75 234 173 41 17 4 255 61 255 238 253 181 42
72
> > 245 23
> > 3 223 246 174 37 32 0 245 255 182 118 127 91 34 0 223 251 127 205 249
198 44
> > 1 2
> > 51 214 250 247 255 249 8 0 255 190 159 218 255 213 8 32 252 157 207 251
27
> > 227 0
> >  64 123 239 118 190 223 150 2 64 255 149 253 255 255 248 128 0 175 223
231
> > 170 2
> > 46 220 140 64 175 125 59 55 186 188 96 0 191 255 183 169 159 98 40 8 158
255
> > 230
> >  223 235 81 74 128 223 191 58 183 183
> > Unknown option: a6/166.68: 0 255 223 101 247 191 41 1 0 253 155 191 127
245
> > 113
> > 42 2 0 0 1 9 83 116 97 114 116 105 110 103 32 110 101 116 119 111 114
107 46
> > 46
> > 46 10 187 22 155 253 189 117 136 0 127 239 182 229 125 89 32 2 255 251
239
> > 37 24
> > 7 66 34 2 238 235 93
> > Unknown option: fa/250.251: 243 17 0 252 247 221 165 253 189 40 0 252
255
> > 220 22
> > 3 127 249 64 0 247 254 252 255 250 222 128 0 239 253 235 247 239 88 101
64
> > 255 2
> > 55 187 222 239 235 69 0 253 251 255 227 107 45 0 0 223 126 255 247 239
115
> > 97 32
> >  191 239 102 175 203 229 2 0 254 215 127 255 175 73 16 66 251 223 207
175
> > 255 86
> >  24 148 255 243 191 253 95 234 98 0 255 239 222 179 126 172 128 0 255
233
> > 239 15
> > 7 253 188 128 0 223 255 189 219 252 164 0 16 222 251 101 203 125 59 8 0
251
> > 173
> > 111 250 253 237 64 0 126 255 243 189 239 212 25 0 187 246 238 219 223
191 80
> > 8 1
> > 23 239 254 253 239 68 0 8 126 251 175 123 247 93 129 0 127 122 231 214
221
> > 214 1
> > 28 0 123 250 87 237 255 105 146 0 127 219 222 151 222 54 8 4 253 171 127
246
> > 230
> >  236 5 64 223 250 121 255 191 205 33 0 222 89 142 183 237 73 20 0 7 240
11
> > 177 1
> > 26 186 128 0 223 247 73 213 219 123 72 1 95 255 83 222 217 121 4 0 255
90
> > 187 25
> > 1 127 118 68 68 255 207 175 253 206 57 0 4
> > Unknown option: df/223.138: 186 251 207 170 17 0 191 254 91 215 109 107
1 0
> > 238
> > 174 201 223 187 233 48 0 255 238 250 251 119 219 8 0 255 223 89 223 255
170
> > 0 0
> > 255 127 109 191 239 247 34 17 222 127 123 187 223 26 136 0 63 191 218
222
> > 207 21
> > 7 40 8 199 180 251 159 221 197 42 64 255 235 237 203 253 173 17 0 255
231
> > 255 22
> > 3 191 73 8 0 253 255 145 189 255 251 128 0 251 93 235 227 219 76 128 0
246
> > 253 2
> > 38 230 221 239 137 0 255 253 199 254 213 172 160 0 223 233 53 255 255
101 0
> > 128
> > 223 220 253 254 172 213 26 0 235 238 238 239
> >
> > ------------------------------------------------------------------------
> >
> > Does your DHCP server send out such fields in response to BOOTP
requests? Or
> > you feel there could be some other problem, either with our code or
> > somewhere else?
> >
> > Regards
> >
> > Chandrashekhar Padiyar
> >
> >
> > --
> > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> >
> >
>
> --
> Nick Garnett                    eCos Kernel Architect
> http://www.ecoscentric.com/     The eCos and RedBoot experts
>
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss