Update on the request for testing:<br><br>As per below, adaptors and cable have already been verified.<br><br>As base desired behaviour, verified XO1 running Build 802 auto-assigns itself an IPv4 169 address and is able to connect to a Windows machine.<br>
<br>Alas, on the testing phase:<br><br>Used two newly refreshed XO 1.0's at build 852, Booted into Sugar<br><br>Disabled radio from Control Panel.<br><br>Verified Network View map did not show the other XO.<br><br>ifconfig showed only loopback<br>
<br>Auto Power management always turned off<br><br>Plugged the USB adaptors into the XO's<br><br>Adaptors show up correctly in LSUSB, on USB 2.0 bus.<br><br>eth0 Interface created. No IP addresses assigned. Orange indicator lights come on and remain solid<br>
<br>Attached cross-over cable to each; orange and green lights illuminate, then flash, then continue to flash intermittently<br><br>No IP V4 auto-assigned addresses are created. Packets are beign sent and received, no packets are lost.<br>
<br>On both machines, IPV6 auto-assigned addresses have been created.<br><br>Ping6 between the two machines shows the machines communicating well.<br><br>However, network view map on both machines is still empty. Neither can see the other in that screen. Still no IPV4 addresses assigned.<br>
<br>All above testing done in root in the terminal from Sugar activity. Sorry, I dont know how to the step request of : "check Sugar frame for an IP address assignment". I also dont know how to check "collaboration through sharing", Sugar and I are just getting to know each other.<br>
<br>So, state at this moment of the test is that we can PING6 in both directions using th eth0 USB interface, but there is no IPV4 connectivity.<br><br>At the terminal prompt on each machine I issue the avahi autoupdate -D.<br>
<br>ifconfig now shows an eth0:avahi entry, with an IPV4 address in the 169.254 range. The addresses are unique. The machines now appear in each others' network view map screen. ping now works, ping6 still works.<br>
<br>That's the end of the 2 XO1s test<br><br>I repeat the entire test using 2xXO1.5's with 852. The results are identical.<br><br>Leaving one XO1.5 up with the demon killed, I try an Ubuntu 10.04 box and Fedora 11 box. Results are identical. IPv6 is auto-assigned, IPv4 auto-address assignment and connectivity requires the avahi-autoipd daemon to be run.<br>
<br>I repeat the tests three times with an XO 1.0 at 802, a Windows 7, and a Windows XP in turn as the second machines, again leaving the 1 XO 1.5/852 as the first box. In all these cases, the XO1/802, the Windows 7 and the Windows XP box, all assign themselves an 169 series IPv4 address, as well as an IPv6 address, without any need for command line. However, in each case the avahi-autoupdate -D must be run on the XO 1.5/852 to enable the eth0:avahi entry to come up and thus provide these three boxes an ability to communicate over IPv4.<br>
<br>I then repeat everything with 2 XO 1.0's at 359 and 2 XO 1.5's at 359 and the results are identical to the 852 tests above and the F11 and Ubuntu tests. IPv6 auto-addresses and connectivity is automatic, IPv4 requires avahi-autoipd.<br>
<br>Notes. <br><br>1) The Windows boxes use /128 subnet mask at IPv6, the Linux boxes use /64. As such, the ping6 command works depending on whether the Windows box comes up in the same subnet, otherwise sometimes a little spoof of the MAC address (which defines the last 4) works to allow IPv6.<br>
<br>2) It was not possible to turn off the wireless on the XO 1.0's running 802 by using the disable radio button on the control panel. I'm sure I could have disabled it from the command line; but , it was no big deal, as the other box used in the test (the one at 852) did have wireless off, and it could not be seen int the network view until the avahi-autoupdate was run there.<br>
<br>Other than the two Sugar steps that I don't know how to do, I think this maybe completes the request.<br><br>If so, let me know, and I'll return to USB2VGA and 3G data-stick testing. Otherwise feel free to give me more instructions.<br>
<br>Cheers<br><br>KG<br><br><br><br><br><br><br><br><br><br><br><br>.<br><br><br><br><br><br><br><br><br><br><br><br><div class="gmail_quote">On Sat, Dec 18, 2010 at 4:06 PM, Kevin Gordon <span dir="ltr"><<a href="mailto:kgordon420@gmail.com">kgordon420@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Folks:<br><br>Just writing to let you know that I'm still working on the test case : <a href="http://dev.laptop.org/ticket/10541#comment:2" target="_blank">http://dev.laptop.org/ticket/10541#comment:</a><br>
<br>I've set up two Windows machines each with a USB/Ethernet connector and a crossover cable and disabled all networking interfaces except the USB. They behave as expected : after a few seconds assigning the Windows APIPA 169 series addresses and communicate with each other using unique addresses. So, I now have verified that the hardware is solid. The USB adapters are the ZoWii's that were in the swag bag at the SFSU summit. Model ZU-80 Zoltantech is what they say on the outside, but they identify themselves n device manager as ASIX AX88772. Their USB id is 0b95:7720. <br>
<br>I have also done this hardware test by hooking the usb adapters to ports on a switch with no DHCP server, and here too the hardware functions as expected.<br><br>The reason I'm running behind is that I tried to downgrade my two F14/OS4 machines back to 802 to add to the test environment and ran in to problems reinstalling 802 with our customization version, using the old /bundles /boot/actos.zip type signed build method. It didn't seem to want to reboot and run the bundle install portion. However, it was determined that it was only not working on the XO's that had security permanently disabled. That took me a bit of time to figure out. Then, after the unsuccessful attempt to install 802, the x-key boot to OFW also no longer worked - i was at a bit of an impasse. So, I installed a full stable 852 with activities, , now had sugar and re-installed the developer key. I then I could reboot into OFW. <br>
<br>Alas, even though I brilliantly guessed the command, :-) I had to go find the actual format of the enable-security command so as not to get the unexpected end-of-line error. With the Serial number so conveniently appearing on the top of the OFW boot screen, security was renabled and I now have 2 XO 802's with full bundles using the above mentioned USB stick install. I now finally have the 6 XO's set up for the next phase. 2 at 802, 2 at 852, and 2 at 359. I also have one XO 1.5 at 852 and another one at 359 to test. I'll also be introducing a vanilla IBM Thinkpad with F11, fully updated, to see how it behaves when following James' zeroconf/avahi test plan.<br>
<br>So far, I can really only verify the initial successful base behaviour which gave rise to the discussion: that the USB adaptors work on the XO1 at 802, wherin a 169 address is successfully assigned automatically when an 802 XO1 is cross-over connected to a Windows machine via, or when connected to the switch.<br>
<br>So, bottom line: the rookie is a little behind in his work, but I am plodding along.<br><br>Cheers<br><font color="#888888"><br>KG<br>
</font></blockquote></div><br>