Thanks Stefano, On 10/07/2014 07:36 AM, Stefano Babic wrote: > Hi Eric, > > On 06/10/2014 18:41, Eric Nelson wrote: > >>> I understand the use case, but it does not always work (I mean, in all >>> network configurations) and we regret generally having IP addresses hard >>> coded in the default configuration. >>> >> >> Can you clarify which parts (mac/IP address/both) are a problem? >> >> The 'usb_ether' is kind of an odd beast, in that it's a link-local >> protocol, which is why the the IP addresses aren't read from or written >> to a persistent environment. > > This is not completely true. I mean, I understand that you want to have > such as situation, with addresses valid only in the link host / target. > > However, if a customer / user has a PC belonging to the 10.0.0.0/24 > network, there is a conflict. And this is not a rare case, because as I > have seen in companies 10.0.0.0/8 are used more often as 192.168.0.0/16. > > You can have two interface (ethernet and USB) acting on the same address > range and packets originally sent to network are readdressed to the > target, letting the customer without network. > > I understand that you want to provide is a special case - but as you can > see, you cannot cover all cases by setting a hard coded address. >
Right. I've also seen that. It seems that 169.254.x.x is more appropriate. http://tools.ietf.org/html/rfc3927 >> >> Our goal was to only require configuration of one side of the link >> (the USB Host). It seems that without implementing a DHCP **server**, >> this is the most convenient. > > If you really want, why don't you use a script as a 6x_ ? usbrecover can > load initially a script setting the network addresses, without > hardcoding to the u-boot image. > Chicken and egg.... The goal for usbrecover was/is to allow access to on-board storage (SATA on Nitrogen6x, eMMC on Nitrogen6_Max) Thankfully, the "ums" utility now functions nicely for that purpose without using IP. A kernel gadget still performs much better though (~2x), since you can interleave writes to storage with USB I/O. >> >> The mac addresses above are ours, and we can confirm that they are >> not in use on any other hardware, > > I know that and it is exactly the same we had in the past with other > boards. Customers can buy more as one instance of the boards, having > then multiple boards with the same MAC address - and very bad case. > >> so they're guaranteed to be unique >> unless you happen to hook up multiple of our boards to a Host at the >> same time. > > Yes, exactly. Why do you want to restrict your sales chances ? :-D > This (and all of our patches) is an attempt to increase sales by making life easier on users. > Seriously, hard coding mac and network addresses was strictly rejected - > even if after your patch I have found a couple of boards doing that > (maybe it was not seen during review, see for example v38b.h). > Understood. >> >> Since the configuration of network adapters on most hosts is based >> on mac addresses, hard-coding these prevents the need to re-configure >> each time a new board is connected to a host. > > I understand that hard coding makes life easier, but I am not convinced > it is the correct way to do, specially with IP addresses. > Right. Perhaps when we have some spare time we could write a DHCP server component to get closer to auto-configuration, although it's not clear how that would interact with other commands. I appreciate your time in review and commenting. Regards, Eric _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot