[U-Boot-Users] [PATCH] DHCP Client Fix

[U-Boot-Users] [PATCH] DHCP Client Fix

[Justin Flammia]

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 

[U-Boot-Users] [PATCH] DHCP Client Fix

[Wolfgang Denk]

Dear Justin,

in message <4155D0DA4B6B044891B3F19311C7E7B89C45E4@EXCHANGE1.886llc.local> you wrote:
> 
> 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

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

> 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.

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

[U-Boot-Users] [PATCH] DHCP Client Fix

[Ben Warren]

Wolfgang Denk wrote:
> Dear Justin,
>
> in message <4155D0DA4B6B044891B3F19311C7E7B89C45E4@EXCHANGE1.886llc.local> you wrote:
>   
>> 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
>>     
>
> 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).
>
>   
>> 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.
>>     
>
> I'm waiting for feedback (or a pull request?) from the network
> custodian.
>
> Ben???
>
>   
This looks promising.  I'll provide feedback after doing some testing 
tomorrow.

regards,
Ben

[U-Boot-Users] Return values from u-boot to standalone application.

[Leonid]

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.

[U-Boot-Users] Return values from u-boot to standalone application.

[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: u-boot-users-bounces@lists.sourceforge.net
[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 

[U-Boot-Users] Return values from u-boot to standalone application.

[Laurent Pinchart]

Hi Leonid,
On Monday 29 October 2007 14:34, Leonid wrote:
> 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.

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

[U-Boot-Users] Return values from u-boot to standalone application.

[Leonid]

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,
On Monday 29 October 2007 14:34, Leonid wrote:
> 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.

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

[U-Boot-Users] Return values from u-boot to standaloneapplication.

[Leonid]

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: u-boot-users-bounces@lists.sourceforge.net [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,
On Monday 29 October 2007 14:34, Leonid wrote:
> 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.

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

[U-Boot-Users] [PATCH] DHCP Client Fix

[Justin Flammia]

Ben,

Just a note...one of the ways that I came up with this solution that is presented in this patch was from observing a Fedora Linux machine and an Apple MacBook Pro interact with the same routers because these computers were able to get an IP address through either Linksys DHCP server consistently.  There were some differences in the data that was included in each of the DHCP negotiation packets but it was the difference you see in the patch that allowed U-Boot to work with the new firmware. After doing some research on DHCP IP assignments, this seemed like a viable solution according to the spec.

Justin


>Wolfgang Denk wrote:
>>Dear Justin,
>>
>>in message <4155D0DA4B6B044891B3F19311C7E7B89C45E4@EXCHANGE1.886llc.local> you wrote:
>>  
>>>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
>>>    
>>
>>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).
>>
>>
>>>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.
>>>    
>>>
>>
>>I'm waiting for feedback (or a pull request?) from the network
>>custodian.
>>
>>Ben???
>>
>>
>This looks promising.  I'll provide feedback after doing some testing tomorrow.
>
>regards,
>Ben  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20071029/75d5c9c1/attachment.htm 

[U-Boot-Users] [PATCH] DHCP Client Fix

[Justin Flammia]

commit e6e505eae94ed721e123e177489291fc4544b7b8
Author: Justin Flammia <jflammia@savantav.com>
Date:   Mon Oct 29 17:19:03 2007 -0400

    Found a bug in the way the DHCP Request packet is built, where the IP address
    that is offered by the server is bound to prematurely. This patch is a fix of
    that bug where the IP address offered by the DHCP server is not used until
    after the DHCP ACK from the server is received.

Signed-off-by: Justin Flammia <jflammia@savantav.com>
---
 net/bootp.c |   11 +++++++----
 1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/net/bootp.c b/net/bootp.c
index 749d3e5..cfe6f8d 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -850,9 +850,9 @@ static void DhcpSendRequestPkt(Bootp_t *bp_offer)
 	bp->bp_hlen = HWL_ETHER;
 	bp->bp_hops = 0;
 	bp->bp_secs = htons(get_timer(0) / CFG_HZ);
-	NetCopyIP(&bp->bp_ciaddr, &bp_offer->bp_ciaddr); /* both in network byte order */
-	NetCopyIP(&bp->bp_yiaddr, &bp_offer->bp_yiaddr);
-	NetCopyIP(&bp->bp_siaddr, &bp_offer->bp_siaddr);
+	/* Do not set the client IP, your IP, or server IP yet, since it hasn't been ACK'ed by
+	 * the server yet */
+
 	/*
 	 * RFC3046 requires Relay Agents to discard packets with
 	 * nonzero and offered giaddr
@@ -870,7 +870,9 @@ static void DhcpSendRequestPkt(Bootp_t *bp_offer)
 	/*
 	 * Copy options from OFFER packet if present
 	 */
-	NetCopyIP(&OfferedIP, &bp->bp_yiaddr);
+
+	/* Copy offered IP into the parameters request list */
+	NetCopyIP(&OfferedIP, &bp_offer->bp_yiaddr);
 	extlen = DhcpExtended((u8 *)bp->bp_vend, DHCP_REQUEST, NetDHCPServerIP, OfferedIP);
 
 	pktlen = BOOTP_SIZE - sizeof(bp->bp_vend) + extlen;
@@ -980,3 +982,4 @@ void DhcpRequest(void)
 #endif
 
 #endif
+
-- 
1.5.0.6
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20071029/13441c84/attachment.htm