What use case for? You could also attach your dispatcher script.

The case where I need it and use it every day.

The script I use contains some private information so I cannot attach it here, but it is similar to this one I found on the OpenMoko wiki:

http://wiki.openmoko.org/wiki/Plug-and-Play_USB_Networking

The link is good enough. But I would be happy to see a description of the use case
and what do you expect from it.

Should 'shared to other computers without DHCP and with different address' just set up IP MASQUERADE? Maybe you could still post your script with private data removed?

I don't think many devices would set up its default route without DHCP and I actually don't remember freerunner doing this.

+1 from me for this feature.

Actually, every device which uses default OpenEmbedded config does that. I'm using SHR on Neo Freerunner and on Nokia N900 and both do that - default route for usb0 is always active and every other available route (GPRS, WiFi...) has higher priority. And usb0 interface has static IP configuration, of course.

That's usb0 configuration on Freerunner:

auto usb0
iface usb0 inet static
        address 192.168.7.2
        netmask 255.255.255.0
        network 192.168.7.0
        gateway 192.168.7.1

And that's usb0 configuration from /etc/network/interfaces on laptop:

iface usb0 inet static
    address 192.168.7.1
    netmask 255.255.255.0
    network 192.168.7.0
    up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.7.0/24 &
    up echo 1 > /proc/sys/net/ipv4/ip_forward &
    up iptables -P FORWARD ACCEPT &
    down iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.7.0/24 &

I've just started using Network Manager on my laptop after very long time of resistance ("my shell scripts can do BETTER!" :D) and actually I'm really impressed, as that's the only thing I need which I found missing. Good work!

Thanks for your description.

> That's usb0 configuration on Freerunner:
> 
> auto usb0
> iface usb0 inet static
>         address 192.168.7.2
>         netmask 255.255.255.0
>         network 192.168.7.0
>         gateway 192.168.7.1

OK then. It's a static configuration with preconfigured nonexistent
gateway. They might have done better with standard DHCP if they wanted to connect to a gateway. What if I want to connect two freerunners?

> And that's usb0 configuration from /etc/network/interfaces on laptop:
> 
> iface usb0 inet static
>     address 192.168.7.1
>     netmask 255.255.255.0
>     network 192.168.7.0

So far this is just ordinary static configuration.

>     up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.7.0/24 &
>     down iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.7.0/24 &

Currently, you are configuring it with shell command magic anyway and it requires specific IP addresses. I don't think we need this sort of magic
in the GUI and I'm tempted to say that we don't even need it in the text-based
configuration files.

>     up echo 1 > /proc/sys/net/ipv4/ip_forward &

This is also OK as NM will IMO currently not disable this under any circumstances.

>     up iptables -P FORWARD ACCEPT &

Out of scope of NM. But you can put it in the dispatcher script, too.

> I've just started using Network Manager on my laptop after very long time of
> resistance ("my shell scripts can do BETTER!" :D) and actually I'm really
> impressed, as that's the only thing I need which I found missing. Good work!

Thanks!

So, please use static network configuration and add an executable script to /etc/NetworkManager/dispatcher.d, check $1 (interface) and $2 (up/down) and script whatever you need to get your NAT rules and forwarding and report
to us if this method is good enough :).

(In reply to comment #5)
> OK then. It's a static configuration with preconfigured nonexistent
> gateway. They might have done better with standard DHCP if they wanted to
> connect to a gateway. What if I want to connect two freerunners?

The problem is that usb0 interface on FR doesn't report at all if cable is plugged or unplugged. And that config is supposed to be device generic - OE supports many different machines. On some devices some deamons could fake that with checking for battery charging or some other magic, but on some others it may be not possible at all.

Connecting two Freerunners would require one of them to be in USB host mode, and that would create new interface for that.
 
> So far this is just ordinary static configuration.

Yes, that's the thing. I would like to set connection sharing with just ordinary static configuration, without DHCP. For now NM assumes that when I want to share connection, then I want to use DHCP for that. In this case that's not true.

And there's even no way to configure that DHCP service. What if I want to share connection with some device which does not support DHCP at all? ;D

About other shell command magic... actually, I don't know if all of this is really required. I just want connection sharing with static IP and since those commands work I just left them that way.

> So, please use static network configuration and add an executable script to
> /etc/NetworkManager/dispatcher.d, check $1 (interface) and $2 (up/down) and
> script whatever you need to get your NAT rules and forwarding and report
> to us if this method is good enough :).

For me that's good enough, but you know... it still would be nice to have, as setting IP configuration on my interface is pretty basic functionality - and now I can't do that at all if I use it for connection sharing.

> The problem is that usb0 interface on FR doesn't report at all if cable is
> plugged or unplugged.

Then that's more amateurish than I imagined.

> Connecting two Freerunners would require one of them to be in USB host mode,
> and that would create new interface for that.

That's not what I meant. Just try to connect two freerunners to one computer.

> Yes, that's the thing. I would like to set connection sharing with just
> ordinary static configuration, without DHCP.

Correct. Then do it :).

> For now NM assumes that when I
> want to share connection, then I want to use DHCP for that. In this case that's not true.

The 'share connections' feature is well defined. It's a method to quicky turn
a computer to an IPv4 NAT DHCP device. Nothing less, nothing more. If you want to redesign method=shared, you could. But you have to think again about all the usecases and about the GUIs that are used for that.

> And there's even no way to configure that DHCP service. What if I want to share
> connection with some device which does not support DHCP at all? ;D

If they don't support DHCP at all, it can't cause them any harm. Anyway DHCP is the standard way to autoconfigure IPv4.

> About other shell command magic... actually, I don't know if all of this is
> really required. I just want connection sharing with static IP and since those
> commands work I just left them that way.
> 
> > So, please use static network configuration and add an executable script to
> > /etc/NetworkManager/dispatcher.d, check $1 (interface) and $2 (up/down) and
> > script whatever you need to get your NAT rules and forwarding and report
> > to us if this method is good enough :).
> 
> For me that's good enough, but you know... it still would be nice to have, as
> setting IP configuration on my interface is pretty basic functionality - and
> now I can't do that at all if I use it for connection sharing.

Of course you can. With the method=static and dispatcher.d above. It's the same you were doing with ifupdown configuration.

Changing the headline so it better describes what this bug is about. Will consult other developers and decide later.

(In reply to comment #7)
> > The problem is that usb0 interface on FR doesn't report at all if cable is
> > plugged or unplugged.
> 
> Then that's more amateurish than I imagined.

This behaviour was common in embedded world these days. BTW, despite of being able to detect USB cable, Maemo on Nokia N900 does exactly the same - it has static IP configuration.

> > For now NM assumes that when I
> > want to share connection, then I want to use DHCP for that. In this case that's not true.
> 
> The 'share connections' feature is well defined. It's a method to quicky turn
> a computer to an IPv4 NAT DHCP device. Nothing less, nothing more. If you want
> to redesign method=shared, you could. But you have to think again about all the
> usecases and about the GUIs that are used for that.

Understood.

> Of course you can. With the method=static and dispatcher.d above. It's the same
> you were doing with ifupdown configuration.

Yes, I can - this bug from my POV is just a feature proposition for being able to do that from GUI. You can accept that or not, I'm just giving you my opinion that this is a thing that I would expect from NM to handle out of the box. If you don't agree with me, I'm ok with that, as I already have setup that works for me ;)

> Yes, I can - this bug from my POV is just a feature proposition for being able
> to do that from GUI.

That's a completely new information you haven't stated before. NetworkManager is not a GUI tool to configure networks :). It's a network configuration daemon
with text-based configuration, D-Bus interface and some tools that are built on top of it while only some of them are being maintained by the same project (nmcli, nm-applet and nm-connection-editor).

I'm afraid this will be opposed because this is not what the connection sharing was meant to be. It was there for user's that can't type 'iptables -L something'
and that don't understand IP addresses :).

And even if we do implement this in nm-connection-editor, you may or may not be happy with that as I don't even know whether you are using it or not. Gnome 3 has its own configuration tool (and KDE has one too).

> You can accept that or not, I'm just giving you my opinion

Sure.

> that this is a thing that I would expect from NM to handle out of the box.

I would not expect NM to fiddle with connection sharing at all :).

> you don't agree with me, I'm ok with that, as I already have setup that works
> for me ;)

Good. We'll see.

(In reply to comment #9)
> That's a completely new information you haven't stated before. NetworkManager
> is not a GUI tool to configure networks :). It's a network configuration daemon
> with text-based configuration, D-Bus interface and some tools that are built on
> top of it while only some of them are being maintained by the same project
> (nmcli, nm-applet and nm-connection-editor).
> 
> And even if we do implement this in nm-connection-editor, you may or may not be
> happy with that as I don't even know whether you are using it or not. Gnome 3
> has its own configuration tool (and KDE has one too).

I'm aware. But before such tools can use that, it has to be supported in NM and its dbus interface, as first step ;)

> I'm aware. But before such tools can use that, it has to be supported in NM and
> its dbus interface, as first step ;)

From the sysadmin's point of view, features like this should never be available to ordinary users through GUI :). They will break just any networks they will join
with just one stupid checkbox checked. And what more, if they can tweak the IP, it may work for them at the same time they break it for others. That is the worst case :).

The Shared DHCP code has always reserved 8 addresses at the beginning of the range for "static" addressing, something I haven't seen mentioned here.  That seems to fit your use-case; you can assign your other device an addresses in that range and it'll never conflict with the DHCP-provided addresses.  Does that solve your issue WRT to static addressing for the moment?

But I also went ahead and implemented the customized addressing config in the 'ap' branch.  That code automatically figures out the DHCP address range from the IP address you give it, and reserves 1/10th of the addresses for static addressing, depending on how many addresses are available, with a maximum of 8 static addresses.

If you give it 192.168.1.1/24 it'll start DHCP at 192.168.1.10.

If you give it 192.168.1.23/26 it'll start at 192.168.1.27, because there are 39 addresses available above .23 (but fewer below, so it uses above), and it reserves 1/10th of those.

So in your situation when the commit gets merged, you could either (a) continue using your current config and let other devices use one of the 8 static addresses, or (b) if you need more, set a higher host address like 192.168.1.50/24 and let other devices use anything below 50.

cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=ap

Great! Don't know about original reporter, but for me it seems like that's exactly what I wanted - thanks a lot :)

Was the 'ap' branch merged already?

yes

Which version will this feature get released in? Or is it already released?

Finally got around to resurrecting my PPC32 install so I could test the address bitwise calculations on a BE arch.

Now pushed to dcbw/shared-ip and posted for review.

(In reply to comment #18)
> Finally got around to resurrecting my PPC32 install so I could test the address
> bitwise calculations on a BE arch.
> 
> Now pushed to dcbw/shared-ip and posted for review.

Reviewed and pushed my suggestions as !fixup

ACK

(In reply to comment #18)
> Finally got around to resurrecting my PPC32 install so I could test the address
> bitwise calculations on a BE arch.
> 
> Now pushed to dcbw/shared-ip and posted for review.

... and you could reference this BZ URL in the commit message?

skimmed quickly because I'm pretty sure I reviewed this code before, a long time ago. anyway, looks ok

Merged to master as 32a001f526c182fa70ede92ffc360112eb7fe9c6