DHCP Client Fix

I recently upgraded the firmware on some of my old Linksys WRT54G routers (version 5) from firmware version 1.0.6 to firmware version 1.02.2, both of which are released by Linksys and U-Boot was no longer able to get an IP address using DHCP. However, with the older firmware (version 1.0.6), U-Boot was still able to get an IP through DHCP.

Using a hub and a packet sniffer, I was able to locate the problem. The U-Boot code will bind to an IP address offered by the DHCP server prematurely and the DHCP server will not respond with an ACK, rendering the system without an IP address. This is no longer valid when using a Linksys router as DHCP server. I modified the code to operate the way the Linux DHCP client does by not binding to the offered IP until the DHCP client receives the ACK sent by the server, ending the conversation. After making the appropriate changes, DCHP service was restored for all flavors of the Linksys firmware that I have available (v 1.02.2 and v1.0.6 for the version 5 router, v8.00.2 for the version 8 router). It has also been tested on an AirPort Extreme router running DHCP.

Attached is the patch with the code changes that were made. Any feed back would be appreciated.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20071019/367760be/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bootp.patch
Type: application/octet-stream
Size: 999 bytes
Desc: bootp.patch
Url : http://lists.denx.de/pipermail/u-boot/attachments/20071019/367760be/attachment.obj

Dear Justin,

I have to admit that I'm not sure if this is a bug in U-Boot or in the Linksys router (which I have under special observation as they explicitely and intentionally violate the U-Boot GPL).

I'm waiting for feedback (or a pull request?) from the network custodian.

Ben???

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
365 Days of drinking Lo-Cal beer.                       = 1 Lite-year

This looks promising. I'll provide feedback after doing some testing tomorrow.

regards,
Ben

Hi:

I have created u-boot standalone application and exported some string functions (like strlen()). The application is working (doesn't fail) but values which exported functions are returning don't look right. For example, this printf() in standalone application

    printf ("cmdparse:%u line=%s len=%d\n", __LINE__, line,

strlen(line));

prints the following line:

cmdparse:407 line=help len=553684153

meaning strlen() return code is wrong. Same thing happens with strchr() and other functions I have exported.

Am I doing something wrong? How can I get correct return values from u-boot to standalone application?

Thanks,

Leonid.

Sorry, I forgot to mention that I'm using at91rm9200 CPU (ARM9 from Atmel) and u-boot version is 1.2.0 official release. May be there are some known issues with standalone application for ARM? Stack getting corrupted?

My code is but small variation of standard hello_world (attached) and here is output:

U-Boot$ tftp 21000000 $image_path/hello_world.bin; go 21000000; TFTP from server 192.168.0.108; our IP address is 192.168.0.205 Filename 'leonid/ref/images/hello_world.bin'.
Load address: 0x21000000
Loading: #
done
Bytes transferred = 620 (26c hex)
## Starting application at 0x21000000 ...
Example expects ABI version 3
Actual U-Boot ABI version 3
Hello World
argc = 1
argv[0] = "21000000"
argv[1] = "<NULL>"
main:48 line=help len=553648684
Hit any key to exit ...

## Application terminated, rc = 0x0
U-Boot$

Application is compiled to run from the address 0x21000000 which is the middle of RAM.

Thanks,

Leonid.

-----Original Message-----
From: [email protected] [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf Of Leonid
Sent: Sunday, October 28, 2007 11:01 PM
To: u-boot-users at lists.sourceforge.net
Subject: [U-Boot-Users] Return values from u-boot to standalone application.

Hi:

I have created u-boot standalone application and exported some string functions (like strlen()). The application is working (doesn't fail) but values which exported functions are returning don't look right. For example, this printf() in standalone application

    printf ("cmdparse:%u line=%s len=%d\n", __LINE__, line,

strlen(line));

prints the following line:

cmdparse:407 line=help len=553684153

meaning strlen() return code is wrong. Same thing happens with strchr() and other functions I have exported.

Am I doing something wrong? How can I get correct return values from u-boot to standalone application?

Thanks,

Leonid.

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hello_world.c
Type: application/octet-stream
Size: 1540 bytes
Desc: hello_world.c
Url : http://lists.denx.de/pipermail/u-boot/attachments/20071029/822d5a17/attachment.obj

Hi Leonid,

For what it's worth, 553648684 is 0x2100022c in hex, which is in the middle of your application's memory. This either means you end up feeding the function address to printf instead of calling the function, or you got a stack/calling convention issue.

Best regards,

Laurent Pinchart
CSE Semaphore Belgium

Chauss?e de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

Hi, Laurent:

You are right regarding value. The interesting thing though is that functions which have been exported by u-boot traditionally (say, getenv() or getc()) return correct value in standalone application.

However all string related functions I have tried to export (strlen(), strchr(), etc...) are not so. I think I did everything the same way it's done for other functions...

Thanks,

Leonid.

-----Original Message-----
From: Laurent Pinchart [mailto:laurentp at cse-semaphore.com]
Sent: Monday, October 29, 2007 6:47 AM
To: u-boot-users at lists.sourceforge.net
Cc: Leonid
Subject: Re: [U-Boot-Users] Return values from u-boot to standalone application.

Hi Leonid,

For what it's worth, 553648684 is 0x2100022c in hex, which is in the middle of your application's memory. This either means you end up feeding the function address to printf instead of calling the function, or you got a stack/calling convention issue.

Best regards,

Laurent Pinchart
CSE Semaphore Belgium

Chauss?e de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

The problem was in the order of gd->jt[] array initialization. I did it too early and in common/exports.c it was filled by dummy function address.

Thanks,

Leonid.

-----Original Message-----
From: [email protected] [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf Of Leonid
Sent: Monday, October 29, 2007 7:45 AM
To: Laurent Pinchart; u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] Return values from u-boot to standaloneapplication.

Hi, Laurent:

You are right regarding value. The interesting thing though is that functions which have been exported by u-boot traditionally (say, getenv() or getc()) return correct value in standalone application.

However all string related functions I have tried to export (strlen(), strchr(), etc...) are not so. I think I did everything the same way it's done for other functions...

Thanks,

Leonid.

-----Original Message-----
From: Laurent Pinchart [mailto:laurentp at cse-semaphore.com]
Sent: Monday, October 29, 2007 6:47 AM
To: u-boot-users at lists.sourceforge.net
Cc: Leonid
Subject: Re: [U-Boot-Users] Return values from u-boot to standalone application.

Hi Leonid,

For what it's worth, 553648684 is 0x2100022c in hex, which is in the middle of your application's memory. This either means you end up feeding the function address to printf instead of calling the function, or you got a stack/calling convention issue.

Best regards,

--
Laurent Pinchart
CSE Semaphore Belgium

Chauss?e de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users