Ticket #2383 (closed defect: wontfix)

Opened 7 years ago

Last modified 6 years ago

Laptop not scanning for mesh; can't connect to the XO on an AP

Reported by: kimquirk Owned by: dcbw
Priority: blocker Milestone: Trial-3
Component: network manager Version:
Keywords: Cc: zack, jg
Action Needed: Verified: yes
Deployments affected: Blocked By:
Blocking:

Description

Build 528

I connected one XO to my local WEP enabled AP. It is sitting on channel 6. When I look at iwconfig, the mesh is also sitting on channel 6.

Then when I boot up a second XO, it sits on mesh channel 1 and doesn't seem to scan around for that mesh that would let it connect to XO1 with the AP. I seems like it is connect with a mesh on channel 1 even though there is nothing else on channel 1. Either it doesn't see the mesh advertisements on channel 6, or it isn't scanning.

I think it isn't scanning because I typed iwconfig many times over the course of a few minutes and it is always on channel 1. When I did that in the past, I could see it sit on channel 2, then channel 3, etc. This took a long time to get through all the channels, but it would eventually connect to my XO on the AP of channel 6. So I think this is a regression bug.

Change History

Changed 7 years ago by dcbw

There's two distinct issues here:

1) A fix went into NetworkManager that will show up in the Sunday builds for scanning behavior. NM was sometimes forgetting to scan when it should have. Second, a kernel driver fix which Marcelo and I are verifying is needed to make the scan behavior less hacky, which compounded the NetworkManager problem that's already been fixed. That should land on Monday (or Sunday if dilinger is around tonight).

2) If an XO is connected to an encrypted access point, no other XOs will recognize and use that XO as an XO-MPP. This is because when an XO is connected to an encrypted AP, _everything_ is encrypted, even the mesh for that XO. So the other XOs have no idea what encryption key to use, nor do they have any idea how to pick a key. Right now, they can pick the key based on SSID, but the mesh doesn't have SSIDs at all. This is simply a limitation of the mesh right now, and is unlikely to be resolved any time soon.

You can have two XOs on channel 6, on connected to an encrypted AP (and so that XO's mesh interface is also encrypted), and one connected to an unencrypted AP (so that XO's mesh interface is not encrypted). The two XOs will _not_ be able to see each other at all.

We are recommending that layer 2 (ie wireless layer) encryption _not_ be used. We fully intend to encourage and use layer 3 (ie application layer) encryption/security. Layer 2 encryption is not sufficient by itself anyway.

Changed 7 years ago by dcbw

One way to fix problem #2 is to abuse mesh beacons to advertise the SSID and BSSID of the AP to which the eth interface is connected, which would allow other XOs to have a faint hope of detecting the right encryption key like they do now for infrastructure APs. However, we don't want to abuse mesh beacons too much because it's unclear how they relate to the in-progress 802.11s standard.

Changed 7 years ago by Zack

... I had no idea we had such a limitation as the one you described in #2. Is this documented somewhere? It definitely should be :)

Also, later 3 encryption is only possible where offered. Is data transmitted while collaborating on an activity encrypted?

Changed 7 years ago by kimquirk

  • cc zack, jg added
  • milestone changed from Untriaged to Trial-3

I agree that this was not known to the test group (and perhaps others) before this weekend. We need to make sure people understand that if they want to use the mesh with one connection to the infrastructure AP, that the AP cannot use WEP or WPA.

An individual XO can connect to the AP, but the MPP mesh will not work.

I'm moving this bug to Trial-3 for more discussion -- either a fix, or proper documentation so people don't 'sell' this feature.

Part 1 should be fixed in latest build, so if it isn't, I will open a new bug.

Changed 7 years ago by jg

  • keywords relnote added

Changed 7 years ago by kimquirk

  • status changed from new to closed
  • verified set
  • resolution set to wontfix

Closing.

Changed 6 years ago by kimquirk

  • keywords relnote removed
Note: See TracTickets for help on using tickets.