Bugs and more

Fri Oct 12 12:05:58 EDT 2007

Kim,

=> 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):
>
> 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)
>

You are correct. First you delete the file, then you reboot. I updated it in
the Kqrelease.

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

I agree, I also noted that in the bug. I rephrased it more clearly and
forwarded it to sugar

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

The ifconfig has 2 parts: msh0 and eth0

eth0      Link encap:Ethernet  HWaddr 00:17:C4:03:31:FB
          inet addr:18.85.18.23  Bcast:18.85.19.255  Mask:255.255.254.0
<-------this add is blank on mesh/link-local
          inet6 addr: 2001:4830:2446:ff00:217:c4ff:fe03:31fb/64
Scope:Global            now it has a 18.85.x.x
          inet6 addr: fe80::217:c4ff:fe03:31fb/64 Scope:Link
          .....

msh0      Link encap:Ethernet  HWaddr 00:17:C4:03:31:FB
          inet addr:169.254.7.84  Bcast:169.254.255.255  Mask:255.255.0.0
<------this add is always belongs to the mesh
          inet6 addr: 2001:4830:2446:ff10:217:c4ff:fe03:31fb/64
Scope:Global           it is either 169.254:local-link/MPP
          inet6 addr:
fe80::217:c4ff:fe03:31fb/64
or 172.x.x for school server
          ......

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.

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

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.

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

So, I am most confident these changes must be recovered.

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

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

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

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

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

yani

On 10/12/07, Kim Quirk <kim at laptop.org> wrote:
>
> Yani,
> Lots of good work on this document! I've added my comments inline below.
>
> Copying Alex for comments as well.
>
> Kim
>
>
> On 10/12/07, Giannis Galanis <galanis at laptop.org> wrote:
> >
> > Kim,
> >
> > A couple of things in case I forget later today,
> >
> > 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)
>
>
> => 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):
>
> 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)
>
>
> > 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)
>
>
> => 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.
>
> 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.
>
>
> => 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.
>
> Finally, have a look at this page:
> > http://wiki.laptop.org/go/Test_Network_Configuration
> >
> > 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.
>
>
> => 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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
> jabber.laptop.org 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).
>
> 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.
>
>
> => 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.
>
> => 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'?
>
> => 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.
>
> Good morning!
> >
> > yani
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20071012/2a4741c2/attachment.html>