Kim,<br><br><span class="gmail_quote"></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div>=>
Could you tell if you needed to reboot the AP and wait for it to settle
and reboot the XO -- each just once, but you would have to do the order
properly. It is my expectation that after setting up the AP, it would
need to be rebooted. And it makes sense to me that the XO would need
its file removed and then to be rebooted in order to 'see' it as a new
AP. This should be in the release note. Here is what I *think* the
release note should say (please make appropriate changes, etc and add
it to the Kqrelease):
</div><div><br>If there is a change to the configuration of your
infrastructure AP, then after making changes and rebooting the AP;
please delete the network config file and reboot the XO. (you might
want to put this in steps and say how to find the config file, etc)
</div></div></blockquote><div><br>
You are correct. First you delete the file, then you reboot. I updated it in the Kqrelease.<br>
<br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>
<div><br>=> I believe Dan's comments on this is that it is
probably just a UI bug and not affecting the functioning. If you agree
with that, then you should put a note in the bug about your thoughts
and re-assign it to 'Sugar' so the right person will look at it. I
would let it remain as 'high' priority until we know more. Also, can
you put a note in the release notes on this one.
</div>
</div></blockquote><div><br>
I agree, I also noted that in the bug. I rephrased it more clearly and forwarded it to sugar<br>
<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><span class="q"></span><div><br>=>
This looks great, Yani. I have a couple of questions and I added a few
notes. On the IP Addresses section, I don't believe that you get a
169.x.x.x address when connected to an Infrastructure AP. Normally you
would get a real IP address given to you by the DHCP on the internet
side of the infrastructure AP. Perhaps your AP (the airport extreme)
was not connected to the internet when you did your testing. </div></div></blockquote><div><br>
The ifconfig has 2 parts: msh0 and eth0<br>
<br>
eth0 Link encap:Ethernet HWaddr 00:17:C4:03:31:FB <br>
inet addr:<a href="http://18.85.18.23">18.85.18.23</a> Bcast:<a href="http://18.85.19.255">18.85.19.255</a> Mask:<a href="http://255.255.254.0">255.255.254.0</a> <-------this add is blank on mesh/link-local
<br>
inet6 addr: 2001:4830:2446:ff00:217:c4ff:fe03:31fb/64 Scope:Global now it has a 18.85.x.x<br>
inet6 addr: fe80::217:c4ff:fe03:31fb/64 Scope:Link<br>
.....<br>
<br>
msh0 Link encap:Ethernet HWaddr 00:17:C4:03:31:FB <br>
inet addr:<a href="http://169.254.7.84">169.254.7.84</a> Bcast:<a href="http://169.254.255.255">169.254.255.255</a> Mask:<a href="http://255.255.0.0">255.255.0.0</a> <------this add is always belongs to the mesh
<br>
inet6 addr: 2001:4830:2446:ff10:217:c4ff:fe03:31fb/64 Scope:Global it is either 169.254:local-link/MPP<br>
inet6 addr:
fe80::217:c4ff:fe03:31fb/64
or 172.x.x for school server<br>
...... <br>
<br>
Also, even if the AP is not connected to the internet the above would
not be unchanged. If you are referring to the Airport AP 18.85.x.x
would be substituted by the IP given by 10.0.x.y, with or without
internet connectivity.<br>
</div><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>
<div>Also, I'm pretty sure you will not get a 192.x.x.x from the
school server mesh. Usually you see 192.x.x.x from people setting up a
home wireless network. So I made some changes to that section of your
document.
</div>
</div></blockquote><div><br>
At the point the OLPC schoolserver operates at 172.x.x.x, but this is
just a convention. The 172.x,192.168.x,10.x are equivalent private
addresses and can be used with probability to another mesh somewhere
else. I just conformed this with Michalis.<br>
<br>
You can also have 10.0. or 192.168.or even 172.x.x as an "eth0" address when you connect to an AP, if it is configured so<br>
</div>So, I am most confident these changes must be recovered. <br>
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>
<div>I'm not sure your DNS check info (resolve.conf) is correct for
the case of 169.x.x.x. You say it is because the XO is connecting
through an MPP. But I think you might get the same resolv.conf if the
XO is 'hopping' from one XO to another to get to the School Server or
to an access point. 'Hopping' is not the same as MPP. Since you don't
mention anything about the scenario when one XO connects through
another XO to get to an AP or to the school server... then I'm thinking
there is one more case for you to explore. Or, maybe the case that you
couldn't explain, where there is no dns resolution, but you do have a
good IP and can ping by IP. Maybe that case if XO hopping. We can talk
about it some more later today or next week. </div>
</div></blockquote><div><br>
the resolv.conf is not related to hopping. I havent ever seen a 169
addrress as a dns, since we never have used an MPP, but I am pretty
confident thats how it would work when connecting to one. When an XO
acts as an MPP it creates a small DHCP server and stores locally the
DHCP database. When you send a DHCP request you will receive a reply
from the MPP with a 169.254 address for you to use. The address of the
MPP(which because of the mesh is 169.254 as well) will be your new DNS
and DHCP server.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>
<div>Your info on the gabble service concerns me, specifically the
part about it not being accurate. It would be good to spend some more
time on this to document a broken case and write up the bug; add
appropriate logs, etc. It is not going to be good if there is a local
jabber server (on the school server, for instance) and the laptops
can't decide if they should be talking local-link or through the jabber
server. I'm sure that will mess up tubes sharing.
</div>
</div></blockquote><div><br>
I agree, I just had another issue in Alex's XOs where two XOs where
connected to MediaLab802.11 but were still running salut. It was
displaying 18.85 and 169.254 XOs, which seemed they were all from this
room..this bug is very interesting! I had seen it in the past, but i
couldnt describe it.<br>
Even when on AP mode, the avahi, which runs in the background, still
creates the presence list from the mesh that its connected to (ch 6 in
this case).It can be accesed by "avahi-browse -t _presence._tcp"). But
, now it included 18.85 and 169 xos(bug 4193)<br>
</div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div>=>
Once you've explored a few of these things from this email, I would
like you to send it out to the devel mailing list for review. You might
get a few good suggestions on other things for the status program and
then figure out how to check it in so we can all use it for debug.
</div></div></blockquote><br>yani<br><br><br><br><br><div><span class="gmail_quote">On 10/12/07, <b class="gmail_sendername">Kim Quirk</b> <<a href="mailto:kim@laptop.org">kim@laptop.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Yani,<br>Lots of good work on this document! I've added my comments inline below.<br><br>Copying Alex for comments as well.<br><br>Kim<br><br><br><div><span class="q"><span class="gmail_quote">On 10/12/07, <b class="gmail_sendername">
Giannis Galanis</b> <<a href="mailto:galanis@laptop.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">galanis@laptop.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Kim,<br><br>A couple of things in case I forget later today,<br><br>First, concerning the storage of the WEP keys, deleting the nm/networks.cfg does not work. It is recreated after sometime. You must delete and reboot, before trying to reconnect to the AP. I think it is an important bug that the APs dont refresh in the neighbor screen when they are configured. I had to reboot more than 10 times to finish my tests for different types of WEP keys.(bug 4190)
</blockquote></span><div> <br>=> Could you tell if you needed to reboot the AP and wait for it to settle and reboot the XO -- each just once, but you would have to do the order properly. It is my expectation that after setting up the AP, it would need to be rebooted. And it makes sense to me that the XO would need its file removed and then to be rebooted in order to 'see' it as a new AP. This should be in the release note. Here is what I *think* the release note should say (please make appropriate changes, etc and add it to the Kqrelease):
</div><div><br>If there is a change to the configuration of your infrastructure AP, then after making changes and rebooting the AP; please delete the network config file and reboot the XO. (you might want to put this in steps and say how to find the config file, etc)
<br></div><span class="q"> <br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Concerning the authentication via password and not WEP key, it is as I described to you in my last email. In fact each manufacturer has its own hashing algorithm, so it is virtually impossible to try all combinations. We must come up with a convention(
e.g. only the airport algorithm or smth)</blockquote></span><div><br>=> We are in the business of the laptop and not the AP. So we are not going to be able to test with all the Access Points out there and all their configurations. What we can do is to document the ones we have tested (and the work arounds, as you found with the Airport Extreme); and make sure we invite others to add their support notes about any problems or advice for working with other APs.
<br></div><span class="q"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The 3 items(2 circles+battery) in the donut appeared again(4191), and I reported it for the second time, this time as "Wireless" not as "Network Manager" in case it goes through more efficiently. No one replied to the first bug, although it must be very important.
</blockquote></span><div><br>=> I believe Dan's comments on this is that it is probably just a UI bug and not affecting the functioning. If you agree with that, then you should put a note in the bug about your thoughts and re-assign it to 'Sugar' so the right person will look at it. I would let it remain as 'high' priority until we know more. Also, can you put a note in the release notes on this one.
<br></div><span class="q"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Finally, have a look at this page:<br><a href="http://wiki.laptop.org/go/Test_Network_Configuration" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://wiki.laptop.org/go/Test_Network_Configuration</a><br><br>It includes a detailed guide of how to examine your network, including MPP,
169.x addresses, Gabble/Salut etc. I have also included a script which collects all the useful information(resolv.conf, ip, jabber server.. etc) and displays it in a neat format.</blockquote></span><div><br>=> This looks great, Yani. I have a couple of questions and I added a few notes. On the IP Addresses section, I don't believe that you get a
169.x.x.x address when connected to an Infrastructure AP. Normally you would get a real IP address given to you by the DHCP on the internet side of the infrastructure AP. Perhaps your AP (the airport extreme) was not connected to the internet when you did your testing.
<br><br>Also, I'm pretty sure you will not get a 192.x.x.x from the school server mesh. Usually you see 192.x.x.x from people setting up a home wireless network. So I made some changes to that section of your document.
<br><br>I'm not sure your DNS check info (resolve.conf) is correct for the case of 169.x.x.x. You say it is because the XO is connecting through an MPP. But I think you might get the same resolv.conf if the XO is 'hopping' from one XO to another to get to the School Server or to an access point. 'Hopping' is not the same as MPP. Since you don't mention anything about the scenario when one XO connects through another XO to get to an AP or to the school server... then I'm thinking there is one more case for you to explore. Or, maybe the case that you couldn't explain, where there is no dns resolution, but you do have a good IP and can ping by IP. Maybe that case if XO hopping. We can talk about it some more later today or next week.
<br><br>Your info on the gabble service concerns me, specifically the part about it not being accurate. It would be good to spend some more time on this to document a broken case and write up the bug; add appropriate logs, etc. It is not going to be good if there is a local jabber server (on the school server, for instance) and the laptops can't decide if they should be talking local-link or through the jabber server. I'm sure that will mess up tubes sharing.
<br><br>The goal for each school deployment is for them to have their own local jabber server running. As a matter of fact, today we should have a jabber server running on the school server. So the fact that you only listed
<a href="http://jabber.laptop.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">jabber.laptop.org</a> and the UK jabber server means that either we still don't have a local jabber server... or its there and you just don't know how to get to it (either do I, by the way).
<br></div><span class="q"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">In the bottom of the page I have included a list of all the Mesh,Network pages I could find on the wiki. It would be a could idea to expand this list, and remove/update the obsolete or repeated information.
</blockquote></span><div><br>=> Great idea. For the items that you know are obsolete; go ahead and change them. If you don't know, let's try to find the answers so others can find these pages useful.<br><br>=> Yani, I really like your script to print out the important information. We should get that into a build so it is available to anyone who wants to run it. I think you should change the name, though, since 'status' is too vague. How about 'connectivity_status'?
<br><br>=> Once you've explored a few of these things from this email, I would like you to send it out to the devel mailing list for review. You might get a few good suggestions on other things for the status program and then figure out how to check it in so we can all use it for debug.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Good morning!<br><br>yani<br>
</blockquote></div><br>
</blockquote></div><br>