Re: [U-Boot] [PATCH 00/28] Add link-local addressing support
Dear Joe Hershberger, Link-local support allows the bootloader to get a usable network address regardless of network environment. Given that bootloaders may not always have access to a DHCP server, this functionality makes accessing it in those environments easier. It is also referred to as zero-configuration IP. The following script allows the network to be configured for DHCP, link-local, and static IP addresses configurably by the environment using dhcpenabled and linklocalenabled. #define CONFIG_EXTRA_ENV_SETTINGS \ ipconfigcmd=if test \\\$dhcpenabled\\\ -ne 0; \ then \ dhcpfail=0;dhcp || dhcpfail=1;\ else \ dhcpfail=-1; \ fi; \ if test \\\$linklocalenabled\\\ -ne 0 -a\ \\\$dhcpfail\\\ -ne 0; \ then \ linklocal;\ llfail=0; \ else \ llfail=-1;\ fi; \ if test \\\$llfail\\\ -ne 0 -a \ \\\$dhcpfail\\\ -ne 0; \ then \ setenv ipaddr $sipaddr; \ setenv netmask $snetmask; \ setenv gatewayip $sgatewayip; \ fi;\0 \ Some refactoring of net/ was done to make adding link-local support cleaner as well as generally improving the readability and organization of the code. Tested on da850_am18xxevm Tested on MPC8313ERDB_33 check-patch No warnings or errors (depends on ignoring CONSIDER_KSTRTO) MAKEALL -a powerpc No additional warnings or errors beyond master MAKEALL -a arm No additional warnings or errors beyond master git-test-sequence Cleanly bisectable Code-size affects on MPC8313ERDB_33 shown below cat sizeofMCP8313 make BUILD_DIR=/tmp/u-boot-build/ ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- USE_PRIVATE_LIBGG=yes distclean /dev/null \ make BUILD_DIR=/tmp/u-boot-build/ ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- MPC8313ERDB_33_config /dev/null \ make BUILD_DIR=/tmp/u-boot-build/ ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- USE_PRIVATE_LIBGG=yes /dev/null \ powerpc-linux-gnu-size /tmp/u-boot-build/u-boot git-test-sequence origin/master.. './sizeofMCP8313' Testing ./sizeofMCP8313 HEAD is now at 4dbe8d8 net: Remove volatile from all of net except the eth driver interface textdata bss dec hex filename 264917 24880 42104 331901 5107d /tmp/u-boot-build/ppc/u-boot Passed: 90ea672853753b5a4244db60d095e5f99cdcfe7d. Testing ./sizeofMCP8313 HEAD is now at 92893c4 net: cosmetic: checkpatch compliance text data bss dec hex filename 264917 24880 42104 331901 5107d /tmp/u-boot-build/ppc/u-boot Passed: 12b0b6e953406a1ed98d1c4dd9701078d1dfe00d. Testing ./sizeofMCP8313 HEAD is now at d6c19a3 net: Move mv64x6x_eth_initialize() to board_eth_init() textdata bss dec hex filename 264917 24880 42104 331901 5107d /tmp/u-boot-build/ppc/u-boot Passed: cf9f493ab5d08a282ec9905797fa58d82b15714d. Testing ./sizeofMCP8313 HEAD is now at 52403e8 net: Make the MAC-seeded random number generator available to /net text data bss dec hex filename 264917 24880 42104 331901 5107d /tmp/u-boot-build/ppc/u-boot Passed: a92c9c9e8f68337a78ee2d7c6775299d7c057b52. Testing ./sizeofMCP8313 HEAD is now at ff86c81 net: Move CDP out of net.c text data bss dec hex filename 264917 24880 42104 331901 5107d /tmp/u-boot-build/ppc/u-boot Passed: 9bf01065cb04c34e43cc5d56162aa2dac9d61f3e. Testing ./sizeofMCP8313 HEAD is now at da1998d net: Move ARP out of net.c text data bss dec hex filename 265045 24928 42104 332077 5112d /tmp/u-boot-build/ppc/u-boot Passed: 621d67b8c6126ef6510d0a2b2c06ce410cd60327. Testing ./sizeofMCP8313 HEAD is now at 408b8ab net: Move PING out of net.c text data bss dec hex filename 265237 24976 42096 332309 51215 /tmp/u-boot-build/ppc/u-boot Passed: e8aaa7382de39137c91809ba2e121f87338627d5. Testing
Re: [U-Boot] [PATCH 00/28] Add link-local addressing support
On Mar 31, 2012, at 4:11 PM, Marek Vasut marek.va...@gmail.com wrote: is it correct you're the new network custodian in uboot? Yes, that is correct. Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/28] Add link-local addressing support
Dear Joe Hershberger, On Mar 31, 2012, at 4:11 PM, Marek Vasut marek.va...@gmail.com wrote: is it correct you're the new network custodian in uboot? Yes, that is correct. Hey, welcome abroad! :-) btw. I reassigned most of the net patches in patchwork to you, hope you don't mind. Joe Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/28] Add link-local addressing support
On Mar 31, 2012, at 5:40 PM, Marek Vasut ma...@denx.de wrote: Dear Joe Hershberger, On Mar 31, 2012, at 4:11 PM, Marek Vasut marek.va...@gmail.com wrote: is it correct you're the new network custodian in uboot? Yes, that is correct. Hey, welcome abroad! :-) btw. I reassigned most of the net patches in patchwork to you, hope you don't mind. Don't mind at all. Quite the opposite actually. Thank you. Easier to find the patches to potentially merge. Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/28] Add link-local addressing support
On Thursday 26 January 2012 04:21:21 Stefano Babic wrote: On 26/01/2012 00:40, Joe Hershberger wrote: I have a basic question about your patchset. RFC3927 requires that addresses are continuosly checked to avoid conflicts - this is a strict requirement. True. It cannot be 100% compliant in every use-case. It is important that these limitations are well documented Any time we are processing NetLoop, we will handle conflict correctly. Yes, but NetLoop is running only when there some activity on the network. isn't that the only time that matters ? if we're sitting at the command prompt, then u-boot has the network pretty much shut off (doesn't respond to ARP let alone anything higher). as soon as we try to do network communication, we are compliant again. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/28] Add link-local addressing support
On 03/02/2012 12:34, Mike Frysinger wrote: On Thursday 26 January 2012 04:21:21 Stefano Babic wrote: On 26/01/2012 00:40, Joe Hershberger wrote: I have a basic question about your patchset. RFC3927 requires that addresses are continuosly checked to avoid conflicts - this is a strict requirement. True. It cannot be 100% compliant in every use-case. It is important that these limitations are well documented Any time we are processing NetLoop, we will handle conflict correctly. Yes, but NetLoop is running only when there some activity on the network. isn't that the only time that matters ? if we're sitting at the command prompt, then u-boot has the network pretty much shut off (doesn't respond to ARP let alone anything higher). This is true, but what does happen with a second / multiple boards on the network ? Some of them can steal the same ip address because our board does not answer and conflicts are not solved. At least, I am expecting that some ip address suddenly changes and that can be some inconsistencies in ARP tables. Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/28] Add link-local addressing support
On Friday 03 February 2012 11:19:22 Stefano Babic wrote: On 03/02/2012 12:34, Mike Frysinger wrote: On Thursday 26 January 2012 04:21:21 Stefano Babic wrote: On 26/01/2012 00:40, Joe Hershberger wrote: I have a basic question about your patchset. RFC3927 requires that addresses are continuosly checked to avoid conflicts - this is a strict requirement. True. It cannot be 100% compliant in every use-case. It is important that these limitations are well documented Any time we are processing NetLoop, we will handle conflict correctly. Yes, but NetLoop is running only when there some activity on the network. isn't that the only time that matters ? if we're sitting at the command prompt, then u-boot has the network pretty much shut off (doesn't respond to ARP let alone anything higher). This is true, but what does happen with a second / multiple boards on the network ? Some of them can steal the same ip address because our board does not answer and conflicts are not solved. At least, I am expecting that some ip address suddenly changes and that can be some inconsistencies in ARP tables. as soon as the conflict occurs, wouldn't that get detected then ? u-boot not actively responding to a few requests isn't really all that different from the packets getting dropped by say a busy hub. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/28] Add link-local addressing support
On 26/01/2012 00:40, Joe Hershberger wrote: I have a basic question about your patchset. RFC3927 requires that addresses are continuosly checked to avoid conflicts - this is a strict requirement. True. It cannot be 100% compliant in every use-case. It is important that these limitations are well documented Any time we are processing NetLoop, we will handle conflict correctly. Yes, but NetLoop is running only when there some activity on the network. In the case of actually doing something on the network, (generally happens at least some of the time the device is on the network) conflicts are monitored for. In the use case for the devices I use this on, I also run NetConsole, which means the NetLoop is always being run. In that case, it is compliant with the RFC. Right - I think this is the best case. I can imagine we can get conflicts, when several targets are running at the same time in u_boot and they are attached to a network where local-link addressing is active. Then we can have two or more system using the same ip address, making the network unreliable. That is true. I believe there are some cases you could contrive that could allow a device to pick the same address as another device, but it is quite unlikely. Initial address selections are based on MAC-seeded random number, making it hard to get a conflicting address in general. It depends on the number of devices attached to the network - in a small environment, it is not probable. Anyway, if we document well how this feature should be used and which are the limitations, anybody is warned about its usage and about the best conditions to run the feature. Which are the limitations of this implementation ? They should also described in your patchset, maybe with a README file. Is is thought to connect the target directly to a PC ? The most likely use-case is connecting directly to a PC, I have supposed also this is the best use-case. but it also works on any generic network. I added documentation to the README. Ok - please add a separate file doc/README.link-local (or whatever filename you want) Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/28] Add link-local addressing support
On 20/01/2012 01:53, Joe Hershberger wrote: Link-local support allows the bootloader to get a usable network address regardless of network environment. Given that bootloaders may not always have access to a DHCP server, this functionality makes accessing it in those environments easier. It is also referred to as zero-configuration IP. Hi Joe, I have a basic question about your patchset. RFC3927 requires that addresses are continuosly checked to avoid conflicts - this is a strict requirement. However, it is clear we cannot comply with this requirement. The protocol runs once and there is not a background process to check for conflicts. I can imagine we can get conflicts, when several targets are running at the same time in u_boot and they are attached to a network where local-link addressing is active. Then we can have two or more system using the same ip address, making the network unreliable. Which are the limitations of this implementation ? They should also described in your patchset, maybe with a README file. Is is thought to connect the target directly to a PC ? Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/28] Add link-local addressing support
Hi Stefano, On Wed, Jan 25, 2012 at 4:27 AM, Stefano Babic sba...@denx.de wrote: On 20/01/2012 01:53, Joe Hershberger wrote: Link-local support allows the bootloader to get a usable network address regardless of network environment. Given that bootloaders may not always have access to a DHCP server, this functionality makes accessing it in those environments easier. It is also referred to as zero-configuration IP. Hi Joe, I have a basic question about your patchset. RFC3927 requires that addresses are continuosly checked to avoid conflicts - this is a strict requirement. True. It cannot be 100% compliant in every use-case. However, it is clear we cannot comply with this requirement. The protocol runs once and there is not a background process to check for conflicts. Any time we are processing NetLoop, we will handle conflict correctly. In the case of actually doing something on the network, (generally happens at least some of the time the device is on the network) conflicts are monitored for. In the use case for the devices I use this on, I also run NetConsole, which means the NetLoop is always being run. In that case, it is compliant with the RFC. I can imagine we can get conflicts, when several targets are running at the same time in u_boot and they are attached to a network where local-link addressing is active. Then we can have two or more system using the same ip address, making the network unreliable. That is true. I believe there are some cases you could contrive that could allow a device to pick the same address as another device, but it is quite unlikely. Initial address selections are based on MAC-seeded random number, making it hard to get a conflicting address in general. It would have to be a pretty congested 169.254.0.0 network. In addition, any time both devices run NetLoop at the same time as each other, the conflict will be detected and handled. Which are the limitations of this implementation ? They should also described in your patchset, maybe with a README file. Is is thought to connect the target directly to a PC ? The most likely use-case is connecting directly to a PC, but it also works on any generic network. I added documentation to the README. I can add a note about the potential for non-compliance if NetLoop is not run. Best regards, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
