Ticket #9845 (closed defect: fixed)

Opened 3 years ago

Last modified 3 years ago

Alternative to Create a new wireless network.

Reported by: reuben Owned by: erikos
Priority: high Milestone: 10.1.3
Component: sugar Version: Development build as of this date
Keywords: Cc: sridhar
Action Needed: no action Verified: no
Deployments affected: Blocked By:
Blocking:

Description

See: http://dev.sugarlabs.org/ticket/1610

Attachments

adhoc_default_networks.png (64.7 kB) - added by erikos 3 years ago.
Screenshot of the three default adhoc channels 1, 6, 11, conected to channel 6
adhoc_default_networks.patch (16.3 kB) - added by erikos 3 years ago.
First patch to demonstrate teh general approach
adhoc_default_networks_2.patch (22.2 kB) - added by erikos 3 years ago.
rename networks to 'Local Network [channel]', remove the create ad-hoc network functionality, work for suspend
ad_hoc_artwork.patch (7.4 kB) - added by erikos 3 years ago.
The icons, the channels are represented using the maya numerals
adhoc_default_networks_3.patch (24.0 kB) - added by erikos 3 years ago.
New patch, with maya numerals, and status if someone is listening on that network already
adhoc_default_networks_4.patch (24.0 kB) - added by erikos 3 years ago.
set ip4_config.method = 'link-local'
0001-Add-default-Ad-hoc-networks-9845.patch (44.9 kB) - added by erikos 3 years ago.
New patch based on what landed in master
logs.SHF8080225D.2010-08-20.09-04-02.tar.bz2 (316.2 kB) - added by mikus 3 years ago.
os851+rpms - XO-1 system auto-connected to ad-hoc rather than to mesh
0001-Add-default-Ad-hoc-networks-9845.2.patch (44.4 kB) - added by erikos 3 years ago.
Autoconnect after suspend

Change History

  Changed 3 years ago by Quozl

  • next_action changed from never set to design
  • component changed from not assigned to sugar
  • version changed from not specified to Development build as of this date

  Changed 3 years ago by Quozl

  • milestone changed from 1.5-software-final to 1.5-software-update

Ticket moved out of 1.5-software-final to 1.5-software-update as a result of a software manufacturing release triage meeting. Per ed, dsd, cjb, reuben, quozl.

Changed 3 years ago by erikos

Screenshot of the three default adhoc channels 1, 6, 11, conected to channel 6

Changed 3 years ago by erikos

First patch to demonstrate teh general approach

  Changed 3 years ago by erikos

  • owner changed from dsd to erikos

  Changed 3 years ago by erikos

I have sent a patch to the NM mailing list about a typo, that has some effect when creating adhoc-networks with a specified channel: http://mail.gnome.org/archives/networkmanager-list/2010-April/msg00127.html

A discussion about the open issues regarding this feature can be found here: http://lists.laptop.org/pipermail/devel/2010-April/028307.html

  Changed 3 years ago by erikos

The NM patch has been landed to master and the NETWORKMANAGER_0_7 branch http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=NETWORKMANAGER_0_7

You can find f11-rpms with the fix as well here: http://shell.sugarlabs.org/~erikos/NM/

Changed 3 years ago by erikos

rename networks to 'Local Network [channel]', remove the create ad-hoc network functionality, work for suspend

Changed 3 years ago by erikos

The icons, the channels are represented using the maya numerals

Changed 3 years ago by erikos

New patch, with maya numerals, and status if someone is listening on that network already

Changed 3 years ago by erikos

set ip4_config.method = 'link-local'

  Changed 3 years ago by martin.langhoff

Retriage as high?

follow-up: ↓ 8   Changed 3 years ago by mikus

Haven't yet actually tested collaboration, but in "mesh" my systems with build 650, build 802, build 300, and build 295py all see each other in Neighborhood View. [os180py systems see other os180py systems in "mesh" - but no other builds.] In my opinion, the "mesh" capability in os300/os301 is good enough -- who needs 'Create new wireless network' ?

in reply to: ↑ 7   Changed 3 years ago by Quozl

Replying to mikus:

who needs 'Create new wireless network' ?

Deployments that combine both XO-1 and XO-1.5 units, if XO-1.5 does not have mesh support.

(If XO-1.5 gains mesh support, then Create new wireless network would only remain useful for interoperating with older XO-1.5 builds, SoaS, and other laptops that can do ad-hoc.)

  Changed 3 years ago by martin.langhoff

  • priority changed from normal to high
  • milestone changed from 1.5-software-later to 10.1.2

Tentatively re-triaging --

Simon has newer patches at http://bugs.sugarlabs.org/ticket/1610 and the bug should be actively moving in the next few days.

  Changed 3 years ago by martin.langhoff

Also important to consider: #9895 Should we inhibit suspend when in ad-hoc?

The test cases there are excellent.

  Changed 3 years ago by Quozl

  • milestone changed from 10.1.2 to 10.1.3

We've decided to defer this to 10.1.3, because of schedule constraints

Changed 3 years ago by erikos

New patch based on what landed in master

  Changed 3 years ago by erikos

  • next_action changed from design to review

New rpms can be found at:

http://dev.laptop.org/~erikos/sugar-0.84.22-2.fc11.i586.rpm http://dev.laptop.org/~erikos/sugar-artwork-0.84.2-2.fc11.i586.rpm

Note: on XO-1.0 there will appear the Sugar Ad-hoc networks, too since the GConf option is not set there to false. This will happen in the builds later.

Test cases can be found at: http://wiki.sugarlabs.org/go/Features/Sugar_Adhoc_Networks#How_To_Test

  Changed 3 years ago by erikos

There is an open issue about re connecting to the channel after suspend: http://bugs.sugarlabs.org/ticket/2187

follow-up: ↓ 17   Changed 3 years ago by mikus

Installed the new rpms in two (customized) os851 systems - an XO-1.5 and an XO-1.

Environment started with five XO-1s connected through mesh on channel one. Brought up the XO-1.5 (with the new rpms). It showed me the three new icons in Neighborhood. Clicked on the channel-1 icon - that changed to have parentheses around it. Brought up an os180py XO-1 system (which I had a month ago used for testing connection to the XO-1.5). The os180py showed one (not three) local icon in Neighborhood, labeled "Ad-hoc Network 1". Clicked on that icon - it got parentheses around it. Satisfied myself that the XO-1.5 and the os180py system cound communicate with each other over the ad-hoc network.

Brought up the XO-1 that had the new rpms applied. Its Neighborhood showed six local icons - three for mesh and three for ad-hoc. That system auto-connected to the "Ad-hoc Network 1".

I would have preferred that XO-1 to have connected to the existing mesh of five XO-1 systems, rather than to the existing ad-hoc of two systems. Took system dump.

Changed 3 years ago by mikus

os851+rpms - XO-1 system auto-connected to ad-hoc rather than to mesh

follow-up: ↓ 16   Changed 3 years ago by mikus

Hours later, I powered down the os180py system, then went to Frame in the XO-1.5 system and clicked on 'Disconnect' in the ac-hoc icon's palette. [That left the environment without any Ad-hoc signal present.] The channel-1 icon in the XO-1.5's Neighborhood remained colored, rather than reverting to white (as the channel-6 and channel-11 icons were).

in reply to: ↑ 15 ; follow-up: ↓ 18   Changed 3 years ago by Quozl

Regarding the test cases provided:

start machine A and connect to the Ad-hoc network 6, start machine B without having been connected to an AP before. ... machine B should autoconnect to the Ad-hoc network 6

Pass. Additional delay experienced.

Machine B showed on the frame device icon palette and the mesh box an attempt to join mesh on channel 1 before a successful join of the ad-hoc network. It did autoconnect to ad-hoc network 6, but not before it tried to join mesh.

start the machine without having connected to an AP before ... the machine should autoconnect to Ad-hoc network 1

Pass and fail.

This worked for machine A (an XO-1.5), with only one AP nearby, but not for machine B (an XO-1) in the same circumstance. Machine B had connected to Mesh Network 1. According to frame device icon palette, iwconfig, and ifconfig. Machine B also showed an additional grey circle icon in frame. Machine A showed ad-hoc network 1 was occupied, though this wasn't reflected in iwlist scan results for either machine.

All the other test cases passed. Well done.

Regarding the design ... I disagree with Mikus, I think that the XO-1 should connect to the existing ad-hoc of two systems rather than the existing mesh of five XO-1 systems. This is so that in a rolling upgrade scenario, the new way of working is better supported than the old.

Replying to mikus:

The channel-1 icon in the XO-1.5's Neighborhood remained colored, rather than reverting to white (as the channel-6 and channel-11 icons were).

The test case says to allow 10-15 minutes after the ad-hoc signal has departed the environment. Did you allow that delay to occur?

As far as the design goes, I'd like the delay to be more like one minute than 10-15 minutes, but I don't believe this would block acceptance of the feature.

in reply to: ↑ 14   Changed 3 years ago by erikos

Replying to mikus:

Installed the new rpms in two (customized) os851 systems - an XO-1.5 and an XO-1. Environment started with five XO-1s connected through mesh on channel one. Brought up the XO-1.5 (with the new rpms). It showed me the three new icons in Neighborhood. Clicked on the channel-1 icon - that changed to have parentheses around it. Brought up an os180py XO-1 system (which I had a month ago used for testing connection to the XO-1.5). The os180py showed one (not three) local icon in Neighborhood, labeled "Ad-hoc Network 1". Clicked on that icon - it got parentheses around it. Satisfied myself that the XO-1.5 and the os180py system cound communicate with each other over the ad-hoc network. Brought up the XO-1 that had the new rpms applied. Its Neighborhood showed six local icons - three for mesh and three for ad-hoc. That system auto-connected to the "Ad-hoc Network 1". I would have preferred that XO-1 to have connected to the existing mesh of five XO-1 systems, rather than to the existing ad-hoc of two systems. Took system dump.

Thanks for testing.

Your results are expected. On XO-1s we decided that we do not display the Sugar Ad-hoc networks (the three icons) but the rpms don't reflect that. It is a GConf setting that triggers that, but this happens at build-level. Hence - your results of seeing the three mesh icons and the three Ad-hoc icons.

in reply to: ↑ 16 ; follow-up: ↓ 19   Changed 3 years ago by erikos

Thanks James for testing!

Replying to Quozl:

Regarding the test cases provided:

start machine A and connect to the Ad-hoc network 6, start machine B without having been connected to an AP before. ... machine B should autoconnect to the Ad-hoc network 6

Pass. Additional delay experienced. Machine B showed on the frame device icon palette and the mesh box an attempt to join mesh on channel 1 before a successful join of the ad-hoc network. It did autoconnect to ad-hoc network 6, but not before it tried to join mesh.

Did you test with XO-1 and XO-1.5? Please test with XO-1-5 only for now. As I said to mikus the GConf setting is not set in the rpms.

start the machine without having connected to an AP before ... the machine should autoconnect to Ad-hoc network 1

Pass and fail. This worked for machine A (an XO-1.5), with only one AP nearby, but not for machine B (an XO-1) in the same circumstance. Machine B had connected to Mesh Network 1. According to frame device icon palette, iwconfig, and ifconfig. Machine B also showed an additional grey circle icon in frame. Machine A showed ad-hoc network 1 was occupied, though this wasn't reflected in iwlist scan results for either machine.

Same here. Please test only with XO-1.5 for now.

in reply to: ↑ 18 ; follow-up: ↓ 20   Changed 3 years ago by Quozl

  • next_action changed from review to package

Replying to erikos:

Did you test with XO-1 and XO-1.5? Please test with XO-1-5 only for now. As I said to mikus the GConf setting is not set in the rpms.

Yes, as I said in my reply, one of the laptops, Machine B, was an XO-1. Neither your test cases nor your request for test mentioned a model restriction. I'm not aware of any GConf setting in the test case, and I really didn't understand your mention of it in your request for test. It seemed like an implementation detail.

Since all the other test cases passed, there does not seem to be any further need for testing.

in reply to: ↑ 19   Changed 3 years ago by erikos

Replying to Quozl:

Replying to erikos:

Did you test with XO-1 and XO-1.5? Please test with XO-1-5 only for now. As I said to mikus the GConf setting is not set in the rpms.

Yes, as I said in my reply, one of the laptops, Machine B, was an XO-1. Neither your test cases nor your request for test mentioned a model restriction. I'm not aware of any GConf setting in the test case, and I really didn't understand your mention of it in your request for test. It seemed like an implementation detail. Since all the other test cases passed, there does not seem to be any further need for testing.

Yeah, sorry if the request was not that clear. Thanks again for testing.

  Changed 3 years ago by erikos

To be able to test the collaboration between an XO-1.0 and an XO-1.5 using the Ad-hoc networks like described in [1] you can set the GConf key on the XO-1.0 machine [2] (can be done in the terminal activity).

Then you will not get the default Ad-hoc networks on the XO-1.0 but you will see the Ad-hoc networks created by a X0-1.5 machine like you would see any other Ad-hoc network and can connect to it.

[1] http://wiki.sugarlabs.org/go/Features/Sugar_Adhoc_Networks#Collaborate_between_XO-1.0_and_XO-1.5_without_infrastructure

[2] gconftool-2 --type=bool --set /desktop/sugar/network/adhoc false

  Changed 3 years ago by erikos

Another test for the new patch (rpms will be available soon, too):

|TestCase|

- boot machine and connect to an Ad-hoc network

- close the lid

- open the lid

---> machine should connect to an Ad-hoc network again (same logic like when booting the machine)

Changed 3 years ago by erikos

Autoconnect after suspend

  Changed 3 years ago by sridhar

  • cc sridhar added

  Changed 3 years ago by greenfeld

Tested using the following test RPMs from erikos:

  • sugar-0.84.22-2.fc11.i586.rpm
  • sugar-artwork-0.84.2-2.fc11.i586.rpm

Two XO 1.5 were used during testing, as well as one XO 1.0 and the test cases at http://wiki.sugarlabs.org/go/Features/Sugar_Adhoc_Networks

  Changed 3 years ago by erikos

Thanks for testing pushed as:

Sugar: http://git.sugarlabs.org/projects/sugar/repos/mainline/commits/824ac2a6a6dddf36c9f795cf0249eb5bebe60f54

Sugar-artwork: http://git.sugarlabs.org/projects/sugar-artwork/repos/mainline/commits/3ab8595d3995d4b825fbe33542019566c5f75db3

  Changed 3 years ago by erikos

  • next_action changed from package to test in build

Is available in os350.

  Changed 3 years ago by greenfeld

Tested in 10.1.3 os352:

  • In general everything seems to work.
  • The old Ad-hoc creation option found in the network icon's pop-up memu in Sugar's frame is gone in the formally built versions on both on XO-1 & 1.5's. Is this intentional? If disconnected from all networks we end up with a blank menu to look at (which should at least mention that we are "not connected to a network" or something like that).
  • The duplicate icon issue related to mesh networking still persists, as noted above by Quozl as well as in #10416. If the last non-mesh network connected to was an Ad-hoc one, its Mayan numeral icon will be displayed as disabled instead of an open circle.

  Changed 3 years ago by greenfeld

  • status changed from new to closed
  • next_action changed from test in build to no action
  • resolution set to fixed

Since erikos (I believe it was him in IRC, anyway) told me that removing the Ad-hoc creation option on both XO types was intentional, I am closing this as fixed since it is the main feature ticket, and the minor issue is in another ticket.

Note: See TracTickets for help on using tickets.