See also bug #719852.

Working on this one now.

Created attachment 283136 [details] [review]
Patch to add AP mode to editing wifi connection

Still missing is a patch to set mode to AP if supported when creating new shared connections. Now it is as default set to adhoc.

Created attachment 283165 [details] [review]
Patch to use AP mode if possible for new shared wifi connections

With these two patches against master branch, it seems to work for me.

So those two patches will work, though I haven't reviewed them completely yet.  Thanks for working on this.

The one blocker issue though, is that a few properties in other pages are invalid with mode AP.  So when when the user picks "AP" mode in the editor, we need to do a few things:

1) change the IPv4 method to "shared" if it's "auto"
2) change the IPv6 method to "ignore" (since we don't support shared here yet) if it's "auto" or "dhcp-only"
3) remove or disable the "auto", "auto (addresses only)" options from the IPv4 Method dropdown
4) remove or disable the "auto", "auto (addresses only)", and "auto (dhcp)" options from the IPv6 Method dropdown
5) remove or disable the "WPA Enterprise", "Dynamic WEP", and "LEAP" options from the "WiFi Security" dropdown menu and set the method to "WPA & WPA2 Personal" if it's one of the removed methods
6) disable the BSSID entry in the WiFi page

I had actually started some of this in the dcbw/ap branch upstream in git, but because of some of the complexity of the above I hadn't gotten very far.  One approach I thought of was to allow each editor page to listen for changes on the NMConnection object and update it's own properties, and I think that could work, but we'd need to be careful about infinite loops since updating a property in response to an update of course signals another update...

I'm happy to offer any guidance that you need, if you've got a bit more time to iterate these patches?

Ah, unfortunately I did not see the branch. Now we probably should merge them getting the best of each.

Anyway, this seems more complicated than I thought; that AP mode would behave mostly like ad-hoc mode.

1) why? I guess it should be possible to set up an AP for sharing a network between different clients using private network(s), not only for sharing some other network with it. If you use the create network menu item, it is set, but when creating a new network manually, you should have full control over the settings that are compatible.

2) Same here as for 1). Seems it is set to automatic with create new network command. Is it sufficient that it is set to ignored here?

3) ok
4) ok
5) ok

5) similar to ad-hoc, should be simple

6) yupp, same as for ad-hoc

(In reply to comment #7)
> Ah, unfortunately I did not see the branch. Now we probably should merge them
> getting the best of each.
> 
> Anyway, this seems more complicated than I thought; that AP mode would behave
> mostly like ad-hoc mode.
> 
> 1) why? I guess it should be possible to set up an AP for sharing a network
> between different clients using private network(s), not only for sharing some
> other network with it. If you use the create network menu item, it is set, but
> when creating a new network manually, you should have full control over the
> settings that are compatible.

If you create an AP then you are the access point (obviously) and you are the management entity for that network.  It doesn't make a ton of sense to have a client that connects to your AP provide addressing and DNS routing on the network, since that client can come and go at will.  Thus, something on your AP machine should be providing addressing.  Yes, you could use static addressing if you really wanted to, but you'd still need to run a local caching nameserver and NAT if you wanted to allow access to upstream connections.

WRT to "Automatic" addressing, for NM that specifically means DHCP for IPv4, or router advertisements for IPv6.  That makes no sense for an AP where there is no upstream connection, because there is no DHCP server or IPv6 router on the wifi network.  There needs to be some addressing available at the moment that the AP network is created, either static or "shared" (which is really static, but also includes the NAT + dnsmasq stuff).

> 2) Same here as for 1). Seems it is set to automatic with create new network
> command. Is it sufficient that it is set to ignored here?

Yes, for now.  To enable 'shared' we have to set up IPv6 prefix delegation and run radvd on the shared network to send out router advertisements to the other machines on the WiFi network, and that's not implemented yet...

> 3) ok
> 4) ok
> 5) ok
> 
> 5) similar to ad-hoc, should be simple

Yeah.

> 6) yupp, same as for ad-hoc

Yeah.

The only complication is when you change the mode back and forth for the IP configuration pages.  That requires some communication between pages, becuase they need to update based on dynamic changes in a different page.

One way to do that would be to watch the 'changed' signal on the NMConnection object that's passed into the page in ce_page_[ip4 | ip6 | wifi | etc]_new(); making sure to keep a reference to the NMConnection in the private data for that page too, and g_clear_object() in dispose() for that page as well.  Then whenever the 'changed' signal fires, you could nm_connection_get_setting_wireless() and then check the mode with nm_setting_wireless_get_mode() and then update the IPv4 and IPv6 UI in response to that.

I don't think it would be too much code; does this all make sense? Thanks!

*** Bug 738441 has been marked as a duplicate of this bug. ***

I'm slowly working on the method change indication thing, and I decided to do it slightly differently than the previous comment, in that the type-specific (eg WiFi, VPN, GSM/CDMA/etc) pages themselves get to say what IP methods they support, instead of packing all that logic into page-ip4/page-ip6 where it doesn't really belong.

I noticed that the KDE version ("NetworkManagement"?) of this dialog (which seems to have a very similar GUI) has got AP mode added. This might serve as an source of ideas for UI behavior/logic for the Gnome version.

Also it should be verified that that code is following the same constraints outlined above in this bug report.

This got implemented but tagged as a different bug.

*** This bug has been marked as a duplicate of bug 755663 ***