Re: [systemd-devel] Replacing nss-mdns with resolved

[Dan Williams]

On Fri, 2017-09-29 at 16:45 +0200, Sven Köhler wrote:
> Hi,
> 
> I want to replace nss-mdns with systemd-resolved. However, I am using
> NetworkManager, not systemd-networkd. NetworkManager is configured to
> pass all DNS-related information to systemd-resolved.
> 
> Unlike networkd, NetworkManager does currently not allow to configure
> the per-link MulticastDNS setting. Also, resolved.conf doesn't allow
> to
> change the default of the per-link MulticastDNS setting. Since the
> default is "no", MulticastDNS is essentially disabled for all links.
> 
> Is NetworkManager expected to configure the per-link settings?
> Are you thinking about adding a way to change the per-link defaults?

NM only knows about the DNS information it receives from upstream
servers or that's statically configured.  It doesn't do anything with
mDNS because that's not something that's provided by your DHCP server
or IPv6 router.

But systemd-resolved provides a full-featured D-Bus interface (which is
actually how NM sends the info to resolved) which you can easily use to
poke the setting, in combination with NM "dispatcher" scripts that run
whenever a link goes up or down or changes.  This is the entire point
of "dispatcher" scripts, to run custom events of your choice that NM
doesn't need specific options for.

Drop a small dispatcher script (see 'man NetworkManager' for details)
into /etc/NetworkManager/dispatcher.d which does something like:

#!/bin/bash
if [ "$2" != "up" -a "$2" != "dhcp4-change" ]; then
exit 0
fi

IFINDEX=$(cat /sys/class/net/${DEVICE_IP_IFACE}/ifindex
dbus-send --system --print-reply --dest=org.freedesktop.resolve1 \
/org/freedesktop/resolve1 \
org.freedesktop.resolve1.Manager.SetLinkMulticastDNS \
int32:${IFINDEX} string:yes

Yeah, that gets run every time the interface comes up, while it would
be better to just run that command when the interface is first known to
the kernel.  You could do that with udev rules pretty easily too.  But
doing it with NM dispatcher scripts allows you to control *which*
networks you want this enabled for, so that you can do it for your home
network but not a coffee shop (using the CONNECTION_UUID environment
variable).

Dan

> Running networkd just to configure the per-link settings seems
> redundant, but how would I configure networkd, so that it gets along
> with NetworkManager?
> 
> 
> Kind Regards,
>   Sven
> 
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Handling on network-connections and networkmanager

[Dan Williams]

On Sun, 2017-06-18 at 01:47 +0200, Jakob Schürz wrote:
> Hi there!
> 
> I didn't found anything about the following problem:
> There is network.target and network-online.target. In combination
> with
> NetworkManager network-online.target get started, when
> NetworkManager-wait-online.service exits successfull.
> 
> This is all ok, if i have a computer with permanent LAN/WLAN-
> connection.
> But it doesn't fit the needs for laptops moved in different networks.
> 
> I need NetworkManager, because i use LAN, WLAN, Modem-Connections as
> well as USB-Thetering. So a setup with networkd is not the best way
> in
> my case.
> 
> I have some ftp-mountpoints, which i have configured with automount
> and
> auto-unmounting after idle-time.
> When the automount is activated on boot, a simple ls on this
> mountpoint
> can block the whole system, when there is no network. So i bound the
> automount-unit to network-online.target with
> "BindsTo=network-online.target". This works fine. ls gives me an
> empty
> directory, when no network-connection is active, and gives me back
> the
> content of the mounted dir, when the network-connection is active.
> 
> BUT
> 
> When i stop the network-connection from the gnome-nm-applet, or when
> i'm
> sitting in a train and there is no network-connection possible (in
> case
> of a tunnel), the automount-unit should be stopped. But in normal
> configuration this never will happen.

NetworkManager has a "pre-down" capability via dispatcher scripts (see
man NetworkManager) that calls out to scripts in
/etc/NetworkManager/dispatcher.d when a network connection is
disconnected explicitly by the user.  You could use this to unmount
cleanly when using NM.  NM will block the actual network disconnection
until your script completes (subject to reasonable times of course).

Obviously, if the network connection drops unexpectedly this is not
possible, and the connection is already gone when your script runs.  So
the best possible way to solve all this is to ensure that your
filesystem driver can handle unexpected network dropouts cleanly.

Dan

> Do you have any suggestions, how to solve this problem?
> 
> I tried a solution:
> 
> i created a simple script, which checks the connection every minute.
> Is
> there a connection, and is this connection working (realized with a
> ping
> to a server in the internet), then network-online.target gets
> (re)started.
> If there is no connection, or the connection is not working (think
> about
> WLAN in a train in a tunnel, WLAN is working, but no connection to
> the
> internet is possible), network-online.target gets stopped.
> 
> Also a simple script in NetworkManager/dispatcher.d/, wich starts
> network-online.target, when a connection changes its state zu up, and
> stop this target, when a connection changes to down.
> 
> All services, which should stop on closing the network-connection
> have
> the dependency BindsTo=network-online.target
> 
> But i'm not sure, if this is a good solution to change the behaviour
> of
> network-online.target. Should i create a own target? Or is there
> another, better solution?
> 
> greets
> 
> jakob
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[Dan Williams]

On Tue, 2017-04-25 at 07:45 +, David Härdeman wrote:
> April 24, 2017 5:49 PM, "Dan Williams" <d...@redhat.com> wrote:
> > On Mon, 2017-04-24 at 16:50 +0200, Lennart Poettering wrote:
> > > On Fri, 21.04.17 13:22, David Herrmann (dh.herrm...@gmail.com)
> > > wrote:
> > > 
> > > > > > Anyway, gdbus bugs aside, it seems that the interfaces
> > > > > > reported by
> > > > > > sd-bus should match what gdbus does? (assuming, of course,
> > > > > > that gdbus
> > > > > > can be considered the "reference" implementation).
> > > > > 
> > > > > Does the appended patch fix your issue?
> > > > > (line-breaks might be screwed, sorry)
> > > > 
> > > > Haven't tried it yet, but just from reading the patch...it
> > > > seems
> > > > to do
> > > > the opposite of what I'd expect? I.e. add *more* interfaces?
> > > 
> > > This change makes sure all objects have the built-in interfaces
> > > reported at all times. The GetManagedObjects() call didn't report
> > > them
> > > so far.
> > > 
> > > Note that we really better report all interfaces an object
> > > supports. I
> > > don't know why glib does not do this, but I think it should.
> > > 
> > > Yeah, I#d agree with that. I think we should provide complete
> > > information, and that means including built-in interfaces in all
> > > our
> > > messages, in particular as some of them are optional. It appears
> > > to
> > > me, that gdbus should be changed here, not sd-bus...
> > 
> > It's not clear that the GNOME side was implemented correctly yet.
> > Would be nice to see the sample code.
> > 
> > Dan
> 
> My GNOME-based client was based on the gdbus-example-objectmanager-
> client.c so I hope it's correct, but sure, I'll try to pare down the
> GNOME/gdbus-based client code and the (sd-bus based) server code to
> two simple test cases and provide those later this week.

Cool.  I'd be happy to take a look at it.  It may well turn out to be a
gdbus bug, but without seeing the code it's not clear.

Dan
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[Dan Williams]

On Mon, 2017-04-24 at 16:50 +0200, Lennart Poettering wrote:
> On Fri, 21.04.17 13:22, David Herrmann (dh.herrm...@gmail.com) wrote:
> 
> > > > > Anyway, gdbus bugs aside, it seems that the interfaces
> > > > > reported by
> > > > > sd-bus should match what gdbus does? (assuming, of course,
> > > > > that gdbus
> > > > > can be considered the "reference" implementation).
> > > > 
> > > > Does the appended patch fix your issue?
> > > > (line-breaks might be screwed, sorry)
> > > 
> > > Haven't tried it yet, but just from reading the patch...it seems
> > > to do
> > > the opposite of what I'd expect? I.e. add *more* interfaces?
> > 
> > This change makes sure all objects have the built-in interfaces
> > reported at all times. The GetManagedObjects() call didn't report
> > them
> > so far.
> > 
> > Note that we really better report all interfaces an object
> > supports. I
> > don't know why glib does not do this, but I think it should.
> 
> Yeah, I#d agree with that. I think we should provide complete
> information, and that means including built-in interfaces in all our
> messages, in particular as some of them are optional. It appears to
> me, that gdbus should be changed here, not sd-bus...

It's not clear that the GNOME side was implemented correctly yet. 
Would be nice to see the sample code.

Dan
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Dan Williams]

On Wed, 2017-01-11 at 14:21 +0100, Christer Weinigel wrote:
> On 2017-01-10 19:55, Lars Knudsen wrote:
> > On Tue, Jan 10, 2017 at 7:08 PM, Dan Williams <d...@redhat.com
> > <mailto:d...@redhat.com>> wrote:
> > And we're quite happy to keep blacklisting specific VID/PID
> > combos we
> > know are not modems. Another possible solution is to greylist
> > devices
> > that happen to have webusb descriptors, such that they won't
> > get auto-
> > probed, but could be probed on-demand via D-Bus.  But I'd
> > rather that
> > happen via udev rules than MM trying to walk USB device
> > attributes and
> > parsing webusb descriptors.
> > 
> > Actually, that sounds like a very good compromise.  I remember my
> > own
> > struggles 3-4 years ago when I had to get a device working properly
> > on
> > ChromeOS and Ubuntu, where the firmware had to handle that the
> > first ~16
> > seconds it would *sometimes* get sent strange AT commands (the
> > probing)
> > all while the system thought it could already start speaking with
> > the
> > device over e.g. chrome.serial.  Eventually you (modemmanager) were
> > kind
> > enough to get our VID/PID listed and ChromeOS was quick to pick it
> > up
> > (~5-6 months to get in stable) and ubuntu so kind to upgrade to the
> > version of modemmanager including our blacklisting approx 2.5 years
> > later (sigh) ;)
> 
> Weird question: should modem manager really autoprobe _every_ serial
> device nowdays?  99% of the devices I connect to my laptop are not
> modems.  They are serial ports on development platforms, RS485
> interfaces, Arduinos with a FTDI, CP210x or CH341 USB-UART bridge,
> and
> so on.  Modems with a physical serial port are almost nonexistent
> today.
>  For me it's a pain in the back to have to update the blacklist of
> things modem manger shouldn't touch.

MM does already whitelist platform serial devices (eg, i8250 UART) and
already greylists USB<->serial adapters like FTDI and CP210x.

Unfortunately, you'd be surprised how many modems actually *do* get
hooked up with USB<->serial converters like FTDI and CP210x.  Modem
manufacturers often build these chips into devices so the modem looks
like USB but uses a generic VID/PID and a generic driver (FTDI).

If you have updates to the blacklist, we'd happily take them.

> Wouldn't it be better to whitelist known ḿodems and have modem
> manager
> ignore everything else?  Devices which are so new that modem manager
> don't know about them can be configured manually.

I ran a list of explicit modem VID/PID pairs in kernel drivers (like
option, qmi_wwan, sierra, hso, etc) 2 years ago and there were >1000
known WWAN modems.

That >1000 does *not* count attribute-matched devices like CDC ACM
devices, CDC WDM/ether, generic serial bridge modems (FTDI/CP210x), or
USB interface class/subclass/protocol matching which many Huawei
devices now use instead.  Whitelisting is simply not really an option,
unfortunately, as too many new modem devices actually do come out every
year.  Thankfully, many these days are MBIM (thanks to Windows 8+) or
QMI, but the embedded world still does a lot of serially-bridged
devices.

Dan

> At least to me that seems like a much more sane default.
> 
>   /Christer
> ___
> ModemManager-devel mailing list
> modemmanager-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Dan Williams]

On Tue, 2017-01-10 at 18:33 +0100, Greg KH wrote:
> On Tue, Jan 10, 2017 at 06:23:13PM +0100, Lars Knudsen wrote:
> > 
> > 
> > On Jan 10, 2017 18:19, "Greg KH"  wrote:
> > 
> > On Tue, Jan 10, 2017 at 06:04:46PM +0100, Lars Knudsen wrote:
> > > I figured that made most sense :)
> > >
> > > Still, it would be good if we could have a rule to not grab
> > the CDC
> > interface
> > > part if the device includes WebUSB functionality.
> > 
> > What exactly do you mean by "grab"?
> > 
> > MM probing :)
> 
> Probe should be fine, right?  Are you really thinking that MM needs
> to
> go "oh look, a cdc device, let's go look at all of the raw interfaces
> to
> ensure it really isn't a webusb device as well before I touch it!"
> 
> That way lies madness...
> 
> What's wrong with touching it?  The kernel already did, why would
> userspace care?

And we're quite happy to keep blacklisting specific VID/PID combos we
know are not modems. Another possible solution is to greylist devices
that happen to have webusb descriptors, such that they won't get auto-
probed, but could be probed on-demand via D-Bus.  But I'd rather that
happen via udev rules than MM trying to walk USB device attributes and
parsing webusb descriptors.

Dan

> > > The likelihood of a modem+WebUSB combo is so small that it
> > must fall
> > > in the category where potential rare exotic devices combining
> > it must
> > > be whitelisted and the rest be left alone.
> > 
> > I think you misunderstand just how crazy firmware authors can
> > be.  I'm
> > sure we will see those types of devices in the wild.
> > 
> > ...But realistically how many? Bothering 99.9% to support the
> > special case
> > seems less logical than just finding the 0.1% and whitelisting it
> > (if needed)
> 
> That's the joy of writing an operating system for all devices on the
> planet, those 0.1% can be a lot of devices :)
> 
> Anyway, I don't think there's much to do here just yet, let's wait
> and
> see just how bad these webusb devices end up looking like...
> 
> thanks,
> 
> greg k-h
> ___
> ModemManager-devel mailing list
> modemmanager-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Dan Williams]

On Tue, 2017-01-10 at 01:01 +0100, Lars Knudsen wrote:
> On Tue, Jan 10, 2017 at 12:47 AM, Lars Knudsen 
> wrote:
> 
> > A small update:  When the modemmanager finishes probing (~16 secs
> > after
> > connection) data seems to stop flowing in from the WebUSB bulk
> > endpoint
> > also.  It is, however, possible to reconnect and get data again -
> > so I need
> > to see if there should be anything in the mbed firmware causing
> > that
> > behavior or there is some sort of silent reset of
> > interfaces/endpoints
> > happening on the linux side when probing is done.
> > 
> 
> Had to separate the CDC and WebUSB serial control signals completely
> in the
> firmware driver. - now survives

Yes, if you expose two USB interfaces that can be bound by two
different drivers, then you must expect they could be used
independently.  Not only by MM, but by anything.

Most devices that expose multiple ttys (eg, modems) treat the ttys as
completely separate at the link layer (serial signals) but commands
issued on separate ttys obviously affect internal firmware state
concurrently.

Dan

> > 
> > On Tue, Jan 10, 2017 at 12:11 AM, Lars Knudsen 
> > wrote:
> > 
> > > I finally managed to make a configuration that *seems* to work
> > > and I
> > > realize that I may have had something else blocking the WebUSB
> > > interface
> > > (2) while modemmanager was communicating with the CDC_ACM
> > > interface (1).
> > > 
> > > I made a clean arbitrary VID/PID and get what seems to be a
> > > functioning
> > > WebUSB (now) while modemmanager sends "AT...AT..." to the CDC
> > > interface -
> > > so while I thought the modemmanager grabbed my WebUSB interface
> > > part, it
> > > must have been because of a faulty combination on my side - my
> > > apologies.
> > > WebUSB actually *does* seem to give immediate "bulk" access to a
> > > device
> > > otherwise claimed by modemmanager - a very nice option to have
> > > and sorry
> > > for the confusion I had that modemmanager grabbed more interfaces
> > > than it
> > > should have.
> > > 
> > > Still, the original request still stands and please tell me if
> > > it's a
> > > viable path:
> > > 
> > > 1.  If a device has a WebUSB descriptor, it's most probably *not*
> > > a modem
> > > - and should in stead be considered a device that in this rare
> > > case needs
> > > to be whitelisted (as modem), while defaulting to not being
> > > it.  This is to
> > > ease the usage from non-browsers to the same hardware, which can
> > > then
> > > happen immediately and not be required to fail and wait over the
> > > modemmanager probing period (30 sec?) - related to modemmanager
> > > 2. If a device has a WebUSB descriptor, at least the interface
> > > linked to
> > > WebUSB should be made accessible in user land by default so no
> > > average user
> > > has to figure out how to do udev rules - related to udev/systemd
> > > 
> > > my headers that seem to work now for the case above:
> > > 
> > > Bus 002 Device 089: ID 1209:d010 InterBiometrics
> > > Device Descriptor:
> > >   bLength18
> > >   bDescriptorType 1
> > >   bcdUSB   2.10
> > >   bDeviceClass0 (Defined at Interface level)
> > >   bDeviceSubClass 0
> > >   bDeviceProtocol 0
> > >   bMaxPacketSize064
> > >   idVendor   0x1209 InterBiometrics
> > >   idProduct  0xd010
> > >   bcdDevice0.01
> > >   iManufacturer   1 empriKit
> > >   iProduct2 empriKit|MOTION
> > >   iSerial 3 00.01
> > >   bNumConfigurations  1
> > >   Configuration Descriptor:
> > > bLength 9
> > > bDescriptorType 2
> > > wTotalLength   90
> > > bNumInterfaces  3
> > > bConfigurationValue 1
> > > iConfiguration  0
> > > bmAttributes 0xc0
> > >   Self Powered
> > > MaxPower  100mA
> > > Interface Descriptor:
> > >   bLength 9
> > >   bDescriptorType 4
> > >   bInterfaceNumber0
> > >   bAlternateSetting   0
> > >   bNumEndpoints   1
> > >   bInterfaceClass 2 Communications
> > >   bInterfaceSubClass  2 Abstract (modem)
> > >   bInterfaceProtocol  1 AT-commands (v.25ter)
> > >   iInterface  0
> > >   CDC Header:
> > > bcdCDC   1.10
> > >   CDC Call Management:
> > > bmCapabilities   0x03
> > >   call management
> > >   use DataInterface
> > > bDataInterface  1
> > >   CDC ACM:
> > > bmCapabilities   0x02
> > >   line coding and serial state
> > >   CDC Union:
> > > bMasterInterface0
> > > bSlaveInterface 1
> > >   Endpoint Descriptor:
> > > bLength 7
> > > bDescriptorType 5
> > > bEndpointAddress 

Re: [systemd-devel] WebUSB

[Dan Williams]

On Mon, 2017-01-09 at 20:05 +0100, Lars Knudsen wrote:
> For all practical reasons and looking ahead, I truly believe that
> there
> will be no reason to have a WebUSB header in any of the few coming
> modem
> devices (what are the stats on new USB CDC modems for these years in
> general? - still enough to justify a "blanket claim as modem"?) as
> having a
> functioning/practical webusb header requires an existing internet
> connection letting you access the hardware from a trusted URL.

Ok...  I'm clearly not putting together the pieces here.

When I read the spec at wicg.github.io, it's a bit light on actual use-
cases.  I get that; it's a protocol spec.  But having some context
would be useful.

Would any device type be a candidate for webusb?

Can you describe in a bit more detail how the WebUSB descriptors get
used by a UA?

Do they get exposed to the web app running in the UA?

What do the URLs get used for and could you give me some examples?  eg,
somebody writes a node.js library, hosts it at http://www.foobar.com/ca
meracontrol and only that URL is allowed to access a USB-connected
camera?

> In any case - even if some few would decide to try the combo - the
> far
> majority would not and the same logic (the user can just make a udev
> rule...Not sure how to explain my wife how ;)) to whitelist those
> would be
> the logical approach.
> 
> Even if it is decided that MM should still try to claim the CDC
> interface
> (which I think would be very wrong as a default in this case), the
> remaining WebUSB, custom class (yet CDC style), Bulk interface should
> be
> left untouched and available to user space browsers.
> 
> Btw on the Mac, they seem to have fixed it nicely by creating two
> logical
> tty devices and not claiming anything before the user tries to access
> either the modem one or pure data one (same physical interface -
> different
> protocol "on demand").

Can you describe this a bit more?  I'm not completely clear on what
this looks like.  Typically a 'tty' would only be used for AT-style
communication, since most modems these days don't use PPP-over-tty.

At least in the Mac/Windows world you typically install drivers and a
connection manager on first-plug and then, of course, you know from
then on that it's a modem or WiFi dongle or camera or whatever.  So
it's easy to not touch the device after that.

But on Linux, you typically don't do this for various reasons, so tools
like MM have to probe the device to find out it's a modem first, and
that clearly involves touching it.

But after the probing process, MM stops talking to the modem and does
nothing else until the user (or the desktop environment configuration)
tells MM to do something.

Dan

> On Jan 9, 2017 19:40, "Dan Williams" <d...@redhat.com> wrote:
> 
> > On Mon, 2017-01-09 at 19:22 +0100, Lars Knudsen wrote:
> > > On Jan 9, 2017 18:56, "Bjørn Mork" <bj...@mork.no> wrote:
> > > 
> > > > Lars Knudsen <lar...@gmail.com> writes:
> > > > 
> > > > > It seemed like if just one interface in the description list
> > > > > was
> > > > > somehow
> > > > > compliant with modem manager, the full device seemed claimed.
> > > > > 
> > > > > I may have missed something in my headers while
> > > > > experimenting.
> > > > > Can you
> > > > 
> > > > give
> > > > > an example of a header structure that will not be assumed to
> > > > > be a
> > > > > modem
> > > > 
> > > > by
> > > > > MM while still accessible as a proper CDC serial device -
> > > > > without
> > > > > blacklisting anything?
> > > > 
> > > > I am slowly starting to wonder if the concern is about
> > > > composite
> > > > devices
> > > > where you want a subset of the functions to be used in one
> > > > context
> > > > (MM)
> > > > and another subset to be used in another context (WebUSB)?  Is
> > > > this
> > > > correct?
> > > > 
> > > 
> > > Well, ideally, any WebUSB device that exposes a CDC interface
> > > (e.g.
> > > configured with [0]CDC INT, [1]CDC BULK and [2]WebUSB CDC/BULK)
> > > would:
> > > 
> > > 1) not be considered a modem (it would not make sense to do a
> > > modem
> > > including webusb headers - in the same device mode at least)
> > > 2) provide standard /dev/ttyUSBx serial functionality on the
> > > standard
> > > CDC
> > > endpoints (e.g. interface 1 above)
>

Re: [systemd-devel] WebUSB

[Dan Williams]

On Mon, 2017-01-09 at 19:22 +0100, Lars Knudsen wrote:
> On Jan 9, 2017 18:56, "Bjørn Mork"  wrote:
> 
> > Lars Knudsen  writes:
> > 
> > > It seemed like if just one interface in the description list was
> > > somehow
> > > compliant with modem manager, the full device seemed claimed.
> > > 
> > > I may have missed something in my headers while experimenting.
> > > Can you
> > 
> > give
> > > an example of a header structure that will not be assumed to be a
> > > modem
> > 
> > by
> > > MM while still accessible as a proper CDC serial device - without
> > > blacklisting anything?
> > 
> > I am slowly starting to wonder if the concern is about composite
> > devices
> > where you want a subset of the functions to be used in one context
> > (MM)
> > and another subset to be used in another context (WebUSB)?  Is this
> > correct?
> > 
> 
> Well, ideally, any WebUSB device that exposes a CDC interface (e.g.
> configured with [0]CDC INT, [1]CDC BULK and [2]WebUSB CDC/BULK)
> would:
> 
> 1) not be considered a modem (it would not make sense to do a modem
> including webusb headers - in the same device mode at least)
> 2) provide standard /dev/ttyUSBx serial functionality on the standard
> CDC
> endpoints (e.g. interface 1 above)
> 3) provide full user access to the WebUSB CDC/BULK interface (2
> above)

So I read the spec quickly but clearly not well enough.

Is the separate WebUSB interface parallel to the others in
functionality?  eg, it's just another conduit for the same information
as the other interfaces?  Or is it some other completely separate
protocol?

Let's take two-tty CDC-ACM, one cdc-ether modem normally controlled
with AT commands, like a Nokia 21M-02.  It exposes 8 interfaces; 3 ttys
and one ethernet device:

0 - cdc-acm commc
1 - cdc-acm data
2 - cdc-acm commc
3 - cdc-acm data
4 - cdc-acm commc
5 - cdc-acm data
6 - cdc-ether commc
7 - cdc-ether data

Now if that supported webusb, would you have:

8 - webusb

If that is true, then what is supposed to happen with this modem when
you plug it in?  Just because it has a WebUSB descriptor, should it be
automatically "claimed" by a running browser or such, and be
unavailable to the rest of the system?  Would all the ttys and ethernet
devs be re-permissioned to the browser user?

Or, could you expand on "it wouldn't make sense" to do a modem with
WebUSB descriptors?  Why not?

> What I was asking before is for an example header/configuration
> descriptors
> where MM would *not* pick up the CDC interface but the system still
> creating a /dev/ttyUSBx device (or ttyACMx - which it's called when
> MM is
> installed) - without creating blacklisting rules specifically for
> e.g.
> *that* VID/PID combo.

It depends. If MM is running and MM has been configured to probe
devices (which can be easily changed with udev rules) then MM will
probe and claim any device that it determines is a modem, including
devices that expose ttys that respond to queries like AT+GCAP
indicating they support WWAN standards.  Also including cdc-wdm devices
that speak QMI or MBIM or AT.

So it's certianly possible to configure the scenario you're trying, if
you use udev rules to blacklist devices or if you disable probing
entirely.

If you can write udev rules that detect the presence of a webusb
descriptor, then you can disable MM probing for that device too.

> When I was experimenting the last few days - this did not seem
> possible.  I
> had to completely wipe any indication of this device being CDC before
> MM
> stopped claiming it.  Surely, MM should not pick it up if the device
> indicates it doesn't have call functionality?

MM disregards the "call functionality" part because only Nokia and
Ericsson ever actually filled that in.  Nobody really cares about
getting the detailed parts of cdc-acm correct, and because there's no
real certification or anything, nobody bothered.  So these fields are
essentially useless in the real world.

Same reason some vendors put "0123456789abcdef" into the USB serial
number field for *every single device* of a given VID/PID.  You simply
cannot rely on vendors getting descriptors correct.

Dan

> > 
> > If so, then I believe you won't be able handle that in a single
> > configuration.  If you mix all functions in a single configuration
> > then
> > you are correct that MM will take control of the device based on
> > the
> > functions it (or the kernel) supports.
> > 
> > Split the function subsets in different configurations and make the
> > OS
> > and/or userspace select the active one if you need to support these
> > different use cases.  Anything else is going to be an endless mess
> > of
> > workarounds and quirk lists all over the place.
> > 
> > 
> > Bjørn
> > 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel 

Re: [systemd-devel] dhcp address change callback?

[Dan Williams]

On Mon, 2016-01-25 at 14:27 +0100, Lennart Poettering wrote:
> On Mon, 25.01.16 05:08, J Decker (d3c...@gmail.com) wrote:
> 
> > On Mon, Jan 25, 2016 at 4:43 AM, Lennart Poettering
> >  wrote:
> > > On Sat, 23.01.16 14:22, Johannes Ernst (johannes.er...@gmail.com)
> > > wrote:
> > > 
> > > > Is there a way to receive a callback when a dhcp client-side IP
> > > > address changes?
> > > > 
> > > > Use case: dynamic DNS update.
> > > 
> > > On Linux changes regarding IP configuration are reported via rtnl
> > > (aka
> > > routing netlink). This works regardless how the IP address was
> > > required, and without any extra API from networkd.
> > > 
> > 
> > that's somewhat more useful information than 'there's hooks in C
> > for
> > it' Is there some standard daemon that listens and can bind to
> > these
> > events?
> > And even so; can't a few lines (configuration defintion, a variable
> > to
> > store a scriptname, and a call to exec the script like using a
> > systemd
> > unit to setup a network be added to a single place that already
> > does
> > the change?  Even if it's a systemd service that's added that in
> > turn
> > listens to rtnl?
> 
> Well, in systemd, a couple of daemons subscribe to rtnl, including
> networkd and resolved among others. However, none of them provide you
> with a concept of hooks for invoking scripts when events happen.
> 
> NetworkManager provides you some support for this, and other daemons
> might too, but they also take over control of an interface
> completely,
> not sure if that's what you want.

While it would be nice to attach metadata to addresses to indicate that
an address came from DHCP or RA or PPP or LL or whatever, the kernel
has no facility for that so users are stuck asking management daemons
like networkd or NetworkManager where the address came from if they
need to know.

At least in NetworkManager's case, it will quite happily co-exist with
any additional addresses and/or routes you assign to the interface
statically or otherwise, and it will reflect those in its D-Bus API,
dispatcher script environment, and command-line tools like nmcli.

Dan
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] container virtual Ethernet link naming

[Dan Williams]

On Fri, 2015-10-09 at 12:53 -0700, Johannes Ernst wrote:
> man systemd-nspawn, section on --network-veth
> "The container side of the Ethernet link will be named 
> host0."
> 
> container> ip link
> ...
> 2: host0@if9:  mtu 1500 qdisc fq_codel state 
> UP mode DEFAULT group default qlen 1000
> link/ether ce:d3:4f:6c:44:5f brd ff:ff:ff:ff:ff:ff link-netnsid 0
> 
> Where does the @if9 come from, and what’s the naming scheme here?

It comes from /sbin/ip.  What's after the @ is the interface index of
the veth peer, so "if9" == interface index 9 and that tells you what the
peer link will be outside the container/namespace.  The stuff after the
@ isn't controlled by systemd/udev, the "if" prefix is hardcoded
in /sbin/ip.

Dan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd bridge masquerading

[Dan Williams]

On Thu, 2015-06-18 at 19:34 +0200, Lennart Poettering wrote:
 On Thu, 18.06.15 13:19, Dimitri John Ledkov (dimitri.j.led...@intel.com) 
 wrote:
 
  Without adding any veth / tap interfaces to the bridge. My expectation is
  for such a bridge to come up correctly. However in journalctl I get:
  
  br0  : Could not enable IP masquerading: Operation not supported
  br0  : Could not enable IP masquerading: Operation not supported
  br0  : link configured
  
  What's wrong, or I am doing something crazy?
 
 Load ip_tables.ko. systemd git will automatically load it at boot for you.
 
  Secondly, is there an API to manipulate networkd? Ideally i would like to
  add/remove tap interfaces that would be part of this bridge. The only way I
  found to do this is by e.g. dropping files to /run/systemd/network and
  restarting networkd service. That works fine, however this results in the
  bridge accumulating ip addresses, which is not nice.
 
 We currently lack a bus API for networkd. But we started designing
 something recently, but it's only plans, and the plans aren't even
 complete yet:
 
 http://fpaste.org/233667/34648285/

You should probably pick something other than
org.freedesktop.network1.Manager, since there's potential to be confused
with org.freedesktop.NetworkManager.  I'd suggest adding systemd
somewhere in there.

Dan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Help needed for optimizing my boot time

[Dan Williams]

On Thu, 2015-06-11 at 15:15 +0200, Francis Moreau wrote:
 On 06/11/2015 02:22 PM, Andrei Borzenkov wrote:
  On Thu, Jun 11, 2015 at 3:10 PM, Francis Moreau francis.m...@gmail.com 
  wrote:
  On 06/11/2015 01:40 PM, Andrei Borzenkov wrote:
  On Thu, Jun 11, 2015 at 2:26 PM, Francis Moreau francis.m...@gmail.com 
  wrote:
 
 $ systemd-analyze critical-chain
 
 graphical.target @7.921s
   multi-user.target @7.921s
 autofs.service @7.787s +132ms
   network-online.target @7.786s
 network.target @7.786s
   NetworkManager.service @675ms +184ms
 basic.target @674ms
   ...
 
  ...
  Is NetworkManager-wait-online.service enabled and active?
 
 
  It seems it's enabled but no more active:
 
  $ systemctl status NetworkManager-wait-online.service
  ● NetworkManager-wait-online.service - Network Manager Wait Online
 Loaded: loaded
  (/usr/lib/systemd/system/NetworkManager-wait-online.service; disabled;
  vendor preset: disabled)
 Active: inactive (dead) since Thu 2015-06-11 11:54:37 CEST; 1h 4min 
  ago
Process: 583 ExecStart=/usr/bin/nm-online -s -q --timeout=30
  (code=exited, status=0/SUCCESS)
   Main PID: 583 (code=exited, status=0/SUCCESS)
 
  Jun 11 11:54:30 cyclone systemd[1]: Starting Network Manager Wait 
  Online...
  Jun 11 11:54:37 cyclone systemd[1]: Started Network Manager Wait Online.
 
  This seems correct to me, doesn't it ?
 
 
  Actually it says disabled which makes me wonder why it run. But this
  is the service that is likely responsible for long time you observe.
 
  I think it runs because of this:
 
  $ ls /usr/lib/systemd/system/network-online.target.wants/
  NetworkManager-wait-online.service
 
  BTW, why isn't it showed by 'systemd-analyze critical-chain' ?
 
  
  My best guess is that it has no direct dependency on NetworkManager so
  it is not counted as part of chain. You could try adding
  
  After=NetworkManager.service
  
  to see if it changes anything in systemd-analyze output.
  
  If disabling it does ot help, you can try masking it (systemctl mask)
  for a test.
 
  Actually, I'm still not sure why autofs.service is waiting for
  network-online.target to be activated, IOW why this service has
  'After=network-online.target'.
 
  
  You can discuss it on autofs list; systemd is just a messenger here :)
  
 
 Well it's more a systemd configuration question. I think the
 'After=network-online.target' in its service file is not really needed.
 
 I tried to disable autofs service and got a similar issue with ntpd one
 (except network-online.target is not involved here):
 
   $ systemd-analyze critical-chain
   graphical.target @7.921s
 multi-user.target @7.921s
   ntpd.service @7.790s +20ms
 network.target @7.786s
   NetworkManager.service @675ms +184ms
 basic.target @674ms
 
   $ systemctl show ntpd -p After
   After=network.target...
 
 Does ntpd service really need 'After=network.target', not sure.

The 'network online' targets are really just there for ignorant services
that don't respond to network events themselves, that expect the network
to be up and running before they start.  Of course, those services don't
have any way to say *which* network interface they care about, so if you
have more than one interface in your system they still get it wrong.

But anyway, if ntpd or autofs can respond to network events using
netlink or listening on D-Bus to NetworkManager/connman/etc or getting
triggered by eg NetworkManager dispatcher scripts, then they probably
don't need to block on network-online.  But if they can't, and they
expect the network to be up and running before they start, then yes they
will block startup until some kind of networking is running.

Dan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Use a specific device ?

[Dan Williams]

On Thu, 2015-06-11 at 10:36 +0200, Jean-Christian de Rivaz wrote:
 Le 11. 06. 15 09:29, Bjørn Mork a écrit :
  Jean-Christian de Rivaz j...@eclis.ch writes:
  Le 10. 06. 15 23:37, Bjørn Mork a écrit :
  Jean-Christian de Rivaz j...@eclis.ch writes:
 
  There is not so
  much modem manufacturers and each of them don't even release a new
  product range per year.
  Ehh... I don't think we live on the same planet.  Did you know Toshiba
  is a modem manufacturer? Dell? HP? There are 43 (damn - I would have
  loved to see 42) different vendor IDs just in the option driver:
 
 bjorn@nemi:/usr/local/src/git/linux$ git grep -E '^#define.*VENDOR' 
  drivers/usb/serial/option.c |wc -l
 43
  Please provide a complete picture:
  git grep -E '^#define.*VENDOR' drivers/usb/serial/* | wc -l
  174
 
  Not a such bit number. There are various vendor/product database on
  the internet, I failed to identify a unmanageable number of modem on
  them.
  Please go ahead and complete the driver whitelists, then.  It will be
  appreciated.
 
 I am pleased by your welcome. It's now important to know if your view is 
 shared by the others key contributors of the ModemManager project, 
 because having a white list only will not be enough if the ModemManager 
 project is not willing to change code to use it.

I don't mind an optional whitelist scheme, but I don't really have the
time nor the inclination to maintain it.  And I worry that it will get
out-of-date very quickly and thus provide a sub-optimal experience for
the majority of users.  But sure, if you want to do that yourself
locally, that's fine.

  I tried to explain to you why a whitelist design makes an incomplete
  list into a failure, while a blaocklist based design ensures that stuff
  works whether the list is complete or not. That is something to take
  advantage of whenever you can.  It's also used in e.g. USB class drivers.
 
  But whatever.
 
  You are advocating a change here.  That's fine.  But you shouldn't
  expect everyone to jump at your redesign ideas just like that.  There
  ore often reasons for the existing design, and those who designed it
  have often been through multiple incarnations already.
 
  You haven't convinced me yet, to put it mildly...
 
 
 
 You can a least agree that I am not alone trying to find a solution:
 
 https://bugzilla.gnome.org/show_bug.cgi?id=688213
 https://bugs.freedesktop.org/show_bug.cgi?id=85007
 
 What's your observations that need to be addressed to get closer to an 
 acceptable solution ?

Updated that bug with some thoughts.

dan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Use a specific device ?

[Dan Williams]

On Thu, 2015-06-11 at 11:19 +0200, Jean-Christian de Rivaz wrote:
 Le 11. 06. 15 10:48, Bjørn Mork a écrit :
  Jean-Christian de Rivaz j...@eclis.ch writes:
 
  In my experience this is not true.  Many vendors, many of them no-name
  Asian ones, release many devices each year, especially when rebranding
  the same device between network operators.  Even in the United States
  there can be 3 or 4 models of the same hardware, differentiated only by
  firmware and external branding, but with different VID/PID combinations.
  Please provides real substantial example.
  Go look it up in the modem database you have access to.
 
 Why? You are the one pretending that this reality exists by your 
 experience, not me!
 
  You can use almost any modem present in any laptop as example, or any
  modem marketing name from any of the major asian vendors.  They will
  *all* have a number of different VID/PID combinations.  If you should
  happen to find an exception from this rule, then that would be a truly
  interesting device.
 
 
 I never pretending that that there was just a few VID/PID combinations. 
 I do pretend that the number of combinations is not completely out of 
 control like you try to present.

I guess our definitions of out-of-control are different then :)

The FCC database lists ~3396 FCCIDs, 164 of which have been granted so
far in 2015 alone, that are:

- PCS spectrum (eg 1850 - 1910mhz)
- Part 24E
- Class PCB - PCS Licensed Transmitter (not held to face or worn)
- original grants
- registered from 2003 - today

That does include some tablets, MiFis, and M2M devices.  So for a more
representative sample I did a query of all the FCC Grantee codes of all
the WWAN devices I have which gives me a total of 1039 devices from 24
different manufacturers.

These are very restrictive queries because:

1) they do not include devices *not* registered with the FCC, eg many
European/Asian/African devices that aren't intended for sale in the US
2) they only included devices registered for the US/Americas PCS band
(1900MHz)
3) the 1039 query only includes a couple of common manufacturers
4) this is for the FCC ID, not the VID/PID of the device.  Many devices
that are re-branded by OEMs (dell, quanta, HP, Acer, etc) will change
the VID/PID for the same hardware.  So a large number of these devices
will have multiple VID/PIDs.

I also have 15+ devices (from 6 or 7 manufacturers) that have no FCC
registration because they were never intended for sale in the US.  There
are also many whitebox devices.

We have 1118 unique USB IDs in option+sierra+qcaux+qcserial+qmi_wwan
kernel drivers.  Which means we're not even close to covering the USB
IDs of just US registered devices, and that doesn't even cover the
devices that are CDC-ACM, MBIM, or NCM and don't need IDs.

Dan


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Use a specific device ?

[Dan Williams]

On Tue, 2015-06-09 at 21:22 +0200, Jean-Christian de Rivaz wrote:
 Le 09. 06. 15 19:52, Dan Williams a écrit :
  On Tue, 2015-06-09 at 19:34 +0200, Jean-Christian de Rivaz wrote:
  Le 09. 06. 15 17:43, Dan Williams a écrit :
  On Fri, 2015-06-05 at 16:16 +0200, Jean-Christian de Rivaz wrote:
  Le 05. 06. 15 15:51, poma a écrit :
  On 05.06.2015 15:37, Jean-Christian de Rivaz wrote:
  Le 05. 06. 15 15:09, poma a écrit :
  On 05.06.2015 14:14, Jean-Christian de Rivaz wrote:
  Le 05. 06. 15 13:18, Aleksander Morgado a écrit :
  On Tue, May 26, 2015 at 12:19 AM, Jean-Christian de Rivaz 
  j...@eclis.ch wrote:
  I have a system where the modem have multiple /dev/ttyACMx ports 
  where x is
  not constant because of the dynamic nature of others serial 
  devices.
  It may be worth noting that a very similar issue with the one faced
  here is the one with network interface names, where interface names
  were created as kernel drivers probed the different interfaces, 
  ending
  up with eth0, eth1 and so on. Then, there would be network
  interface configurations for each network interface based on the 
  name,
  but no one really ensured that the name was the same upon reboots. 
  The
  solution provided by systemd to ensure that the proper configuration
  is applied always to the proper interface is to make the device 
  names
  predictable, see:
  http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
 
  This solution avoids the need of any other udev rules to e.g. create
  network interface names containing the device MAC address or what 
  not.
 
  I'm wondering whether the same could be applied not only to network
  interfaces, but also to ttyACMs, ttyUSBs and cdc-wdms, and end up
  having predictable tty names like e.g. /dev/ttyACMp0s20u4i0. Sure,
  those names are a nightmare to type, but they are predictable (e.g. 
  in
  this case by including the physical location of the connector of the
  hardware).
 
  This would be a wonderful solution. The only problem is when will 
  this
  feature be available in a stable Linux kernel widely used by all 
  majors
  distributions? Until this dream happens (probably not before severals
  years I guess), an other option must be implemented.
 
  Jean-Christian
  Face your broadband modem, live your dreams?
 
  Kay, when this would happen - Predictable Broadband Modem Interface 
  Names?
 
  I must emphasis that this solution will still not solve the 
  ModemManager
  problem of automatically probing any added serial devices, requiring 
  all
  non-modem serial device to add the ID_MM_IGNORE hack in udev rules. 
  This
  must change as soon as possible.
 
  Jean-Christian
 
  MM probing various hardware, not much of a news.
 
  But still a problem. The lack of proper use of udev by ModemManager
  What is proper use of udev here?
 
  Dan
 
  By looking on how others types of device are handled, udev should be
  used to detect the type of a device in a way to let the relevant
  application manage it if the kernel did not have already a way to detect
  the type of the device (by using USB HID for example). The goal in this
  case is to have modem devices handled by a modem application like
  ModemManager or Ofono.
 
  The most comfortable way for the users is to have a list of know devices
  type, usually based on some vendor and product id. This work generally
  very well for PCI and USB devices. The documentation should provide an
  easy way for a user to add and to submit to the project a new udev rule
  in case the product he use is not already in the list. The rules could
  be plain text udev rules under /lib/udev/rules.d/ (see for example
  40-libgphoto2-2.rules or 40-libsane.rules) or directly coded into the
  application like Ofono do for example, see
  http://git.kernel.org/cgit/network/ofono/ofono.git/tree/plugins/udevng.c#n1065.
  I personally much like the plain udev rule because it allow easy
  experiment without changing the source code of the application. For
  example the last new modem I use on a embedded system is working good
  enough for me with the generic ModemManager plugin so it would be nice
  to let support it by just add a line in a udev rules file.
 
  There are some cases where this is not enough, typically for the plain
  old ttyS* serial port and when the reported vendor and product id is
  just a generic serial port that can be connected physically to any
  serial device, not necessary a modem. In this case the distribution or
  the user should provides a udev rule to specify that there is a modem
  device connected to this particular serial port or to probe if there is
  a modem connected to it. Maybe he know the exact type of the modem,
  maybe he want to let the application probe the modem type, maybe he want
  to let the application detect if there is a modem or not. I have no
  strong opinion on how the distribution should set the default for this
  kind of ports, but I think this is important to let

Re: [systemd-devel] Use a specific device ?

[Dan Williams]

On Wed, 2015-06-10 at 20:52 +0200, Jean-Christian de Rivaz wrote:
 Le 10. 06. 15 16:36, Dan Williams a écrit :
  On Tue, 2015-06-09 at 21:22 +0200, Jean-Christian de Rivaz wrote:
 
  This black list, grey list, and white list system is a mess and have to
  die. No other application do that way because this is completely against
  the common sense. It like saying that by default every house is your and
  that the others have to send to you a list of the houses where you must
  not enter without invitation. All others applications use udev to select
  It's a simple numeric calculation.  The number of items in the whitelist
  would be far, far greater than the number of items in the blacklist.
  You also may not realize how many modems are released each year, how
  many manufacturers make them, and how many models/variants there are...
 
  The number of non-modems that are driven by the same drivers as modems
  (eg, cdc-acm, pl2xxx, ftdio) is much, much smaller than the number of
  modems driven by those same drivers, and so we blacklist them instead.
 
  Again, we will respond quickly to new requests for blacklist/greylist to
  ensure that ModemManager doesn't probe UPS or whatever.
 
 The various black/grey/white lists of ModemManager are together already 
 one of the top biggest udev rules list, and there are very incomplete 
 because there is a lot of industrial products that still use serial 
 ports for specific command and control. The first reason why the list is 
 not growing is that only a few peoples know that there need to blacklist 
 there non modem products. I completely disagree about the argument that 
 a white list will be too big. There is not so much modem manufacturers 
 and each of them don't even release a new product range per year. The 
 40-usb_modeswitch.rules required by some modems is not so big either. 
 Really this is not so different to the gphoto2 or sane udev rules lists.

In my experience this is not true.  Many vendors, many of them no-name
Asian ones, release many devices each year, especially when rebranding
the same device between network operators.  Even in the United States
there can be 3 or 4 models of the same hardware, differentiated only by
firmware and external branding, but with different VID/PID combinations.

 But most important is to understand that the current ModemManager is 
 abusing the udev concept and confusing the users. Are you really serious 
 when you ask a random people with a new UPS product to add a new udev 
 rule to the ModemManager project? I think you are so focused on 
 defending the current ModemManager abomination that you fail to see the 
 problem from the point of view of a common user. The length of a white 
 list is not an excuse to not fix the problem.

I'm sorry we disagree, and in a perfect world a simple whitelist would
suffice; I agree with you here.  But unfortunately it's not perfect, and
I know this well from the last 8 years working on ModemManager and its
predecessor.  I'm not sure there's anything more I can add to this
conversation.

Dan

  the appropriate device, not to reject inappropriate device. This is an
  abuse of the udev technical capabilities. Yes there exists a few other
  udev blacklist rules, but there are clearly for exceptional cases.
  ModemManager try to make the abuse a general concept and this is bad.
  Try to think I bit more globally and imagine the mess if every
  applications do that way. Imagine the /lib/udev/rules.d/ with only black
  list rules for every possible types of devices... Can you seriously
  thing that distributions and users will be happy with a such chaotic 
  system?
 
From the current /lib/udev/rules.d there is already 16 files for
  ModemManager only and 5 of them are just for black/grey/white list. This
  is ridiculous. The ID_MM_BLACKLIST idea was terribly wrong. I hope the
  ModemManager will understand that some transition would be an advantage
  for everyone.
  I don't agree.  A whitelist would have two consequences: (a) many, many
  modems would not work out of the box, and (b) we would be spending much
  more time updating already-out-of-date whitelists and kernel drivers
  than we would adding features and capabilities to ModemManager.
 
 
 As I have say before, please let the choice to the distributions and to 
 the users. I never asked to completely remove the auto probing feature 
 of ModemManager, I ask to have more control on it and to make it not the 
 only possible ModemManager mode of operation. A transition plan could be 
 to still auto probe by default udev rule but with a way that allow 
 reporting the modem vendor/product id if he is not already in the list. 
 This will solve (a). For (b), my point of view is exactly the opposite: 
 if ModemManager will allow to select the features set of a modem from a 
 udev rule using variable, then advanced users can try to enable more 
 features on a new modem by just writing a udev rule. Very powerful and 
 without having

Re: [systemd-devel] Use a specific device ?

[Dan Williams]

On Thu, 2015-06-11 at 00:40 +0200, Jean-Christian de Rivaz wrote:
 Le 10. 06. 15 23:37, Bjørn Mork a écrit :
  Jean-Christian de Rivaz j...@eclis.ch writes:
 
  There is not so
  much modem manufacturers and each of them don't even release a new
  product range per year.
  Ehh... I don't think we live on the same planet.  Did you know Toshiba
  is a modem manufacturer? Dell? HP? There are 43 (damn - I would have
  loved to see 42) different vendor IDs just in the option driver:
 
bjorn@nemi:/usr/local/src/git/linux$ git grep -E '^#define.*VENDOR' 
  drivers/usb/serial/option.c |wc -l
43
 
 Please provide a complete picture:
 git grep -E '^#define.*VENDOR' drivers/usb/serial/* | wc -l
 174
 
 Not a such bit number. There are various vendor/product database on the 
 internet, I failed to identify a unmanageable number of modem on them.
 
  Feel free to start updating the whitelists in vendor specific drivers
  like option, qcserial and qmi_wwan. Please let me know when those are
  complete.
 
  No, I don't seriously expect you to do that job.  Fact is that the
  whitelists are unmaintablable even when the scope is limited to one
  specific mode of Qualcomm based modems.  Keeping a semi-complete
  whitelist of all modems is not going to happen.
 
 
 I expected this reaction. The first problem was the fact that 
 ModemManager is unable to provide a stable name to NetworkManager 
 requiring a hack in the configuration that will not work anymore if 
 there more than a single modem. Instead of making some constructives 
 propositions to find a way to sole the problem clearly caused by 
 ModemManager, the project push all his effort to reject any critic and 

I think we all agree that the stable name thing is a problem, and in
fact I'm still open to your proposal there.

 constructive proposition. I proposed a way to make the transition to a 
 whitelist but you don't even comment on it: you seem only focused on 
 rejecting anything that can possibly fix the ModemManager problems.

But I do disagree that a whitelist is the correct way forward for modem
*identification*, which is a completely separate issue from the one
above that we all agree still needs to be solved.

Dan

  The 40-usb_modeswitch.rules required by some
  modems is not so big either.
  There are approximately a gazillion modem IDs which do *not* need mode
  switching.  But list size is irrelevant in any case.  See below.
 
 So why did the list exists?
 
  But most important is to understand that the current ModemManager is
  abusing the udev concept and confusing the users. Are you really
  serious when you ask a random people with a new UPS product to add a
  new udev rule to the ModemManager project?
  Why do they have to do that? Their UPS should work fine even if MM
  happens to probe it.
 
 So why did you need blacklist in the first place? The only fact that the 
 blacklist exists is a prove that users don't want probing for non modem 
 device. The UPS is maybe not the best example, but you can't deny the 
 reality of the blacklist.
 
  I think you are so focused
  on defending the current ModemManager abomination that you fail to see
  the problem from the point of view of a common user.
  So, let's try to agree what a common user wants.  My claim is that the
  common user wants *both* their UPS and 3G modem to work by default.
 
  The length of a
  white list is not an excuse to not fix the problem.
  Agreed.  The length is irrelevant. The problem is that the list will be
  incomplete, whether it is a blacklist or whitelist. We could probably
  discuss which one will be easiest to maintain, but that's really
  irrelevant too. The real question is what happens to the user
  requirements in the two cases, assuming that we don't have any prior
  knowledge of the devices (which is very likely for any device you can
  buy new in a store):
 
  whitelist:
UPS works
3G modem fails
 
  blacklist:
UPS works, but is unnecessarily probed by MM
3G modem works
 
  The choice is really simple, isn't it? MM does what it has to do.
 
 
 Now you have completely changed the situation that cause problem to a 
 situation where you don't see a problem. You may be happy doing this, 
 but the former problem is still there and unsolved.
 
 Jean-Christian
 
 ___
 ModemManager-devel mailing list
 modemmanager-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Use a specific device ?

[Dan Williams]

On Fri, 2015-06-05 at 16:16 +0200, Jean-Christian de Rivaz wrote:
 Le 05. 06. 15 15:51, poma a écrit :
  On 05.06.2015 15:37, Jean-Christian de Rivaz wrote:
  Le 05. 06. 15 15:09, poma a écrit :
  On 05.06.2015 14:14, Jean-Christian de Rivaz wrote:
  Le 05. 06. 15 13:18, Aleksander Morgado a écrit :
  On Tue, May 26, 2015 at 12:19 AM, Jean-Christian de Rivaz 
  j...@eclis.ch wrote:
  I have a system where the modem have multiple /dev/ttyACMx ports where 
  x is
  not constant because of the dynamic nature of others serial devices.
  It may be worth noting that a very similar issue with the one faced
  here is the one with network interface names, where interface names
  were created as kernel drivers probed the different interfaces, ending
  up with eth0, eth1 and so on. Then, there would be network
  interface configurations for each network interface based on the name,
  but no one really ensured that the name was the same upon reboots. The
  solution provided by systemd to ensure that the proper configuration
  is applied always to the proper interface is to make the device names
  predictable, see:
  http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
 
  This solution avoids the need of any other udev rules to e.g. create
  network interface names containing the device MAC address or what not.
 
  I'm wondering whether the same could be applied not only to network
  interfaces, but also to ttyACMs, ttyUSBs and cdc-wdms, and end up
  having predictable tty names like e.g. /dev/ttyACMp0s20u4i0. Sure,
  those names are a nightmare to type, but they are predictable (e.g. in
  this case by including the physical location of the connector of the
  hardware).
 
  This would be a wonderful solution. The only problem is when will this
  feature be available in a stable Linux kernel widely used by all majors
  distributions? Until this dream happens (probably not before severals
  years I guess), an other option must be implemented.
 
  Jean-Christian
  Face your broadband modem, live your dreams?
 
  Kay, when this would happen - Predictable Broadband Modem Interface Names?
 
  I must emphasis that this solution will still not solve the ModemManager
  problem of automatically probing any added serial devices, requiring all
  non-modem serial device to add the ID_MM_IGNORE hack in udev rules. This
  must change as soon as possible.
 
  Jean-Christian
 
 
  MM probing various hardware, not much of a news.
 
 
 But still a problem. The lack of proper use of udev by ModemManager 

What is proper use of udev here?

Dan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Use a specific device ?

[Dan Williams]

On Tue, 2015-06-09 at 19:34 +0200, Jean-Christian de Rivaz wrote:
 Le 09. 06. 15 17:43, Dan Williams a écrit :
  On Fri, 2015-06-05 at 16:16 +0200, Jean-Christian de Rivaz wrote:
  Le 05. 06. 15 15:51, poma a écrit :
  On 05.06.2015 15:37, Jean-Christian de Rivaz wrote:
  Le 05. 06. 15 15:09, poma a écrit :
  On 05.06.2015 14:14, Jean-Christian de Rivaz wrote:
  Le 05. 06. 15 13:18, Aleksander Morgado a écrit :
  On Tue, May 26, 2015 at 12:19 AM, Jean-Christian de Rivaz 
  j...@eclis.ch wrote:
  I have a system where the modem have multiple /dev/ttyACMx ports 
  where x is
  not constant because of the dynamic nature of others serial devices.
  It may be worth noting that a very similar issue with the one faced
  here is the one with network interface names, where interface names
  were created as kernel drivers probed the different interfaces, ending
  up with eth0, eth1 and so on. Then, there would be network
  interface configurations for each network interface based on the name,
  but no one really ensured that the name was the same upon reboots. The
  solution provided by systemd to ensure that the proper configuration
  is applied always to the proper interface is to make the device names
  predictable, see:
  http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
 
  This solution avoids the need of any other udev rules to e.g. create
  network interface names containing the device MAC address or what not.
 
  I'm wondering whether the same could be applied not only to network
  interfaces, but also to ttyACMs, ttyUSBs and cdc-wdms, and end up
  having predictable tty names like e.g. /dev/ttyACMp0s20u4i0. Sure,
  those names are a nightmare to type, but they are predictable (e.g. in
  this case by including the physical location of the connector of the
  hardware).
 
  This would be a wonderful solution. The only problem is when will this
  feature be available in a stable Linux kernel widely used by all majors
  distributions? Until this dream happens (probably not before severals
  years I guess), an other option must be implemented.
 
  Jean-Christian
  Face your broadband modem, live your dreams?
 
  Kay, when this would happen - Predictable Broadband Modem Interface 
  Names?
 
  I must emphasis that this solution will still not solve the ModemManager
  problem of automatically probing any added serial devices, requiring all
  non-modem serial device to add the ID_MM_IGNORE hack in udev rules. This
  must change as soon as possible.
 
  Jean-Christian
 
  MM probing various hardware, not much of a news.
 
  But still a problem. The lack of proper use of udev by ModemManager
  What is proper use of udev here?
 
  Dan
 
 
 By looking on how others types of device are handled, udev should be 
 used to detect the type of a device in a way to let the relevant 
 application manage it if the kernel did not have already a way to detect 
 the type of the device (by using USB HID for example). The goal in this 
 case is to have modem devices handled by a modem application like 
 ModemManager or Ofono.
 
 The most comfortable way for the users is to have a list of know devices 
 type, usually based on some vendor and product id. This work generally 
 very well for PCI and USB devices. The documentation should provide an 
 easy way for a user to add and to submit to the project a new udev rule 
 in case the product he use is not already in the list. The rules could 
 be plain text udev rules under /lib/udev/rules.d/ (see for example 
 40-libgphoto2-2.rules or 40-libsane.rules) or directly coded into the 
 application like Ofono do for example, see 
 http://git.kernel.org/cgit/network/ofono/ofono.git/tree/plugins/udevng.c#n1065.
  
 I personally much like the plain udev rule because it allow easy 
 experiment without changing the source code of the application. For 
 example the last new modem I use on a embedded system is working good 
 enough for me with the generic ModemManager plugin so it would be nice 
 to let support it by just add a line in a udev rules file.
 
 There are some cases where this is not enough, typically for the plain 
 old ttyS* serial port and when the reported vendor and product id is 
 just a generic serial port that can be connected physically to any 
 serial device, not necessary a modem. In this case the distribution or 
 the user should provides a udev rule to specify that there is a modem 
 device connected to this particular serial port or to probe if there is 
 a modem connected to it. Maybe he know the exact type of the modem, 
 maybe he want to let the application probe the modem type, maybe he want 
 to let the application detect if there is a modem or not. I have no 
 strong opinion on how the distribution should set the default for this 
 kind of ports, but I think this is important to let the choice to the 
 distributions and to the users on how the serial ports are acceded by 
 the application.

ModemManager ships defaults

Re: [systemd-devel] network interface down in container

[Dan Williams]

On Thu, 2015-04-30 at 11:44 +0200, Lennart Poettering wrote:
 On Thu, 30.04.15 10:01, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
 
  I used to boot the container this way :
  # systemd-nspawn --network-bridge=br0 -bD /path_to/my_container
  
  Is this correct?
 
 Looks fine.
 
  
  
*
  Now on the container side:
  
  Nothing configured. NetworkManager enabled, systemd-networkd enabled
  and started.
 
 NM doesn't really support being run in a container. 

FYI not really true, NM git master (upcoming 1.2) does support being run
without udev in a container...

Dan

  ---
  $ ip a
  2: host0: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN group
  default qlen 1000
  link/ether 0e:7f:c3:fb:25:b1 brd ff:ff:ff:ff:ff:ff
  -
  host0 is down
 
 Please check what networkctl status -a in the container shows. It
 should tell you whether networkd is configured to do anything.
 
 Also, what does journalctl -u systemd-networkd -n 200 show in the
 container?
 
 Lennart
 


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Basic network with Fedora conatiner

[Dan Williams]

On Wed, 2015-04-29 at 15:36 +0200, arnaud gaboury wrote:
 After installation of Fedora 22 container, the container (poppy) boots
 but no network.
 
 # journalctl -b -M poppy
 
 
 Apr 29 14:02:20 poppy firewalld[28]: 2015-04-29 14:02:20 ERROR:
 ebtables not usable, disabling ethernet bridge firewall.
 Apr 29 14:02:20 poppy NetworkManager[56]: warn  Could not get
 hostname: failed to read /etc/sysconfig/network
 Apr 29 14:02:20 poppy NetworkManager[56]: info  Acquired D-Bus
 service com.redhat.ifcfgrh1
 
 On host:
 
 ---
 $ ip a
 1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN
 group default
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
 inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
 2: enp7s0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast
 master br0 state UP group default qlen 1000
 link/ether 14:da:e9:b5:7a:88 brd ff:ff:ff:ff:ff:ff
 inet6 fe80::16da:e9ff:feb5:7a88/64 scope link
valid_lft forever preferred_lft forever
 3: br0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state
 UP group default
 link/ether b6:0c:00:22:f1:4a brd ff:ff:ff:ff:ff:ff
 inet 192.168.1.87/24 brd 192.168.1.255 scope global br0
valid_lft forever preferred_lft forever
 inet6 fe80::b40c:ff:fe22:f14a/64 scope link
valid_lft forever preferred_lft forever
 6: ve-poppy: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN
 group default qlen 1000
 link/ether 0e:9a:d7:18:a3:59 brd ff:ff:ff:ff:ff:ff
 
  % systemctl status systemd-networkd
 ● systemd-networkd.service - Network Service
Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service;
 enabled; vendor preset: enabled)
Active: inactive (dead) since Wed 2015-04-29 13:36:28 CEST; 32min ago
  Docs: man:systemd-networkd.service(8)
  Main PID: 493 (code=exited, status=0/SUCCESS)
Status: Shutting down...
 
 Apr 29 13:35:40 hortensia systemd[1]: Starting Network Service...
 Apr 29 13:35:40 hortensia systemd-networkd[493]: br0 : netdev 
 ready
 Apr 29 13:35:40 hortensia systemd-networkd[493]: Enumeration completed
 Apr 29 13:35:40 hortensia systemd[1]: Started Network Service.
 Apr 29 13:35:40 hortensia systemd-networkd[493]: enp7s0  :
 link configured
 Apr 29 13:35:40 hortensia systemd-networkd[493]: br0 :
 link configured
 Apr 29 13:35:42 hortensia systemd-networkd[493]: enp7s0  :
 gained carrier
 Apr 29 13:35:42 hortensia systemd-networkd[493]: br0 :
 gained carrier
 
 
 ---
 
 on container:
 
 $ ip a
 1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN
 group default
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
 inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
 2: host0: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN group
 default qlen 1000
 link/ether 0e:7f:c3:fb:25:b1 brd ff:ff:ff:ff:ff:ff
 
 $ systemctl status systemd-networkd
 ● systemd-networkd.service - Network Service
Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service;
 disabled; vendor preset: disabled)
Active: inactive (dead)
  Docs: man:systemd-networkd.service(8)
 ---
 
 My guess is that I need to get rid of Networkmanager on Fedora
 container and instead use systemd-networkd. Am I right ?

NM shouldn't be messing with the networking that anything else outside
of NM sets up.  It will co-exist and leave whatever else is managing the
container network alone (eg, systemd-networkd).  I think we'd need more
logs from systemd-networkd and NetworkManager to figure out what's going
on, plus the .network and .link files that you've created for
systemd-networkd.

Dan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

[Dan Williams]

On Sun, 2015-04-12 at 20:31 +0200, Lennart Poettering wrote:
 On Fri, 10.04.15 14:05, Dan Williams (d...@redhat.com) wrote:
 
 So idea would basically be that we provide in all three daemons calls
 like:
 
 SetAdditionalNTP(ias)
 SetAdditionalDNS(ia(uay)) 

I would strongly suggest using strings in the API for IP addresses, not
byte arrays.  
   
   Why so?
  
  It's much easier to use for languages other than C, like Python or JS or
  Ruby or dbus-send or even C in many cases.  We originally used binary
  addresses in the D-Bus interface for NetworkManager, and eventually
  found that was the wrong choice for these reasons.  It's also easier to
  pull in and out of D-Bus, with dbus-glib or GIO.  I'm not sure about
  sd_bus though.
 
 I am very much convinced that passing normalized data through dbus is
 the right thing. And that implies byte arrays for binary data such as
 IP addresses... We have structured data in dbus, that's pretty much
 the biggest benefit of dbus over raw sockets. We should use it and not
 chicken out, because our bindings suck and encode everything in
 formatted strings after all... If it's not easy to decode structured
 data with your bus binding, then the answer is to fix the bus binding,
 not to just revert to unstructured data.
 
Also, remember that we want to push domains too, for split
DNS in the VPN or other cases.  So it really should be something like:

SetAdditionalDNS(ia(sas))  (index, array[domain, array[server]])

what were the (uay) arguments you proposed?
   
   resolved supprots split DNS, but it will not allow multiple DNS
   servers with different domains on the same interface. Instead, you
   bind a set of DNS servers and a set of domains to an interface, and
   that's it, there's no further connection between servers and domains.
  
  If I understand correctly, this means you cannot direct *.foobar.com to
  one set of DNS servers,and *.baz.com to another set, assuming those are
  bound to the same interface?  Why not allow that?
 
 Well, resolved is not supposed to support every crazy set up people
 can think of. I mean, if they want that they can certainly run their
 own local DNS server. resolved is about figuring out the common
 usecases and covering them nicely and automatically, and little else.
 
   I fail to see the strong usecase for allowing per-server domains. I
   mean in the VPn case you have one explicit interface for the VPN
   connection, so this should be covered with the current design.
  
  IPSec doesn't give you an kernel netdev at all, it's just routing on an
  existing interface.  So for that interface, you'd have both the VPN
  servers and upstream servers, all bound to the same interface, and no
  ability to direct VPN domains to the VPN servers since they are all on
  the same interface?
 
 IPSec used in that mode does not convey DNS server info, does it? In
 that case it's supposed to be transparent, but with such domain server
 config it wouldn't be transparent after all...

It certainly can convey DNS information.  Try the Red Hat VPN servers
with libreswan for an example.  Your eth0 will now have the original,
DHCP/static/etc provided LAN DNS servers, and secondary VPN-provided DNS
servers that can be tied to one or more domains that the VPN also
provided.

Dan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Synchronization Between Services at Shutdown

[Dan Williams]

On Fri, 2015-04-03 at 14:01 +0200, Lennart Poettering wrote:
 On Thu, 02.04.15 15:04, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote:
 
  On 02/04/15 14:31, Lennart Poettering wrote:
   Hmm? I really don't see how the NFS vs wpa_supplicant issue has
   anything to do with dbus? NFS doesn't care about dbus at all...
  
  It does inasmuch as it requires networking to be up, which *might*
  require dbus (e.g. for NetworkManager).
 
 In this case you should make sure that NM stays up until the NFS
 shares are unmounted, and if NM wants to have dbus around until its
 very end it should use After=dbus.service. However NFS mounts and dbus
 have little to do with each other.

NM does not need D-Bus to be up and around, and it doesn't care if D-Bus
goes away.

The only issue with D-Bus going away is for interfaces that require
external management daemons, like WiFi or Bluetooth, where if those
daemons exit the interface must be shut down because they have much more
hands-on control that is essentially required for the interface to
operate.  Those daemons either need to not exit when D-Bus isn't
available, or they need to get ported to kdbus or something.

Dan

   You need to order wpa_supplicant and NM Before=remote-fs-pre.target
   and pull it it via Wants=remote-fs-pre.target.
  
  AIUI services with the default dependencies depend on
  remote-fs.target?
 
 No. local-fs.target is part of the default dependencies, but
 remote-fs.target is not.
 
  Distributions have historically supported NFS /usr and /var if
  networking is done via ifupdown or something, and used (the LSB
  equivalent of) remote-fs.target to represent that. NFS /usr or /var with
  NetworkManager or similar already didn't work, because that needs D-Bus,
  which needs /usr and /var.
 
 Split-out /usr is not supported by systemd unless already mounted in
 the initrd.
 
 Split-out /var is supported and does not have to be done in the
 initrd. It's incompatible of course with NM because NM needs dbus, and
 dbus needs /var.
 
  systemd mandates an initramfs that mounts /usr (which has thankfully
  made it into Debian 8, although for a while it didn't look as though
  that was going to happen), but AIUI /var is still something that comes
  up later?
 
 Yes.
 
  It's very easy to get into circular dependencies here; there's the
  remote filesystem issue, and also the fact that dbus-daemon wants to
  resolve users/groups, hence might need NIS or LDAP to be up. 
 
 Well, no, this is not supported.
 
 dbus is a late boot service, and it's difficult to change that. The
 major reason is bus activation: as long as dbus-daemon is running all
 its activatable names are activatable, and this easily results in
 deadlocks, since actually activating many of them would mean
 activating late boot services, which results in deadlocks all over the
 place. (simply because there is so much code that tries to contact
 some service if it can, but skips if it doesn't, that is run from udev
 rules or weird other early-boot stuff).
 
 In kdbus this problem goes away since bus name are not always
 actviatable, but can be made activatable only during later boot. With
 kdbus we can schedule when names become activtable, which dbus-daemon
 simply doesn't support.
 
  I personally consider some sort of automatically-synched local cache
  like sssd to be a far better answer than NIS or LDAP, and NFS root
  better than NFS /usr and/or /var, but I am not the only one whose
  opinion matters when considering whether a feature regression in
  distributions is acceptable.
 
 Well, the way this is supposed to work with systemd is that NIS/LDAP
 becomes available with the nss-user-lookup.target target, and user
 logins wait for that (as well as remote-fs.target). NIS/LDAP only adds
 real (i.e. human) users to the user database, and system users
 *must* exist all the time before that.
 
 Both remote-fs.target and nss-user-lookup.target are *not* included in
 basic.target but are pulled in later.
 
  I think the best solution might be a way for dbus-daemon --system to
  not be required to be Before early targets like sysinit.target (to avoid
  circular dependencies), but for it to survive until the final killing
  spree anyway. Does systemd have a way to say that, or are
  startup/shutdown dependencies always symmetric?
 
 Yes they are always symmetric.
 
 dbus-daemon cannot really be started before basic.target
 
  Please see https://bugs.freedesktop.org/show_bug.cgi?id=89847 for more
  on this; one possible hack is to have dbus.service's ExecStop not
  actually stop dbus-daemon, so that it stays around until the final
  killing spree just before /usr and /var are unmounted.
 
 Urks! Don't do that.
 
  I'm happy to modify dbus.service if that's (part or all of) the
  solution, but before I can do that we need to come up with a solution
  that doesn't cause new dependency cycles.
 
 Honestly, services should not require dbus to be around when shutting
 down. And if they do anyway, 

Re: [systemd-devel] Synchronization Between Services at Shutdown

[Dan Williams]

On Thu, 2015-04-02 at 15:04 +0100, Simon McVittie wrote:
 On 02/04/15 14:31, Lennart Poettering wrote:
  Hmm? I really don't see how the NFS vs wpa_supplicant issue has
  anything to do with dbus? NFS doesn't care about dbus at all...
 
 It does inasmuch as it requires networking to be up, which *might*
 require dbus (e.g. for NetworkManager).

NM requires wpa_supplicant running for WiFi because WiFi requires more
active management; the AP might go away, you might need to re-key, roam,
etc at any moment.  The supplicant can't really stop until you no longer
need the interface.  But in reality, (a) anyone mounting a rootfs over
WiFi is asking for trouble, and (b) why the F does NFS still not handle
network dropouts reliably?  But I digress.

  You need to order wpa_supplicant and NM Before=remote-fs-pre.target
  and pull it it via Wants=remote-fs-pre.target.
 
 AIUI services with the default dependencies depend on remote-fs.target?
 Distributions have historically supported NFS /usr and /var if
 networking is done via ifupdown or something, and used (the LSB
 equivalent of) remote-fs.target to represent that. NFS /usr or /var with
 NetworkManager or similar already didn't work, because that needs D-Bus,
 which needs /usr and /var.

NM hasn't needed dbus-daemon running for a long time in early boot, or
for any root-level operation.  So there's no requirement for /usr
or /var or anything else mounted, because root communication happens on
a private socket in /run.

wpa_supplicant does require dbus, since it has no private socket code.

Dan

 systemd mandates an initramfs that mounts /usr (which has thankfully
 made it into Debian 8, although for a while it didn't look as though
 that was going to happen), but AIUI /var is still something that comes
 up later?
 
 It's very easy to get into circular dependencies here; there's the
 remote filesystem issue, and also the fact that dbus-daemon wants to
 resolve users/groups, hence might need NIS or LDAP to be up. I
 personally consider some sort of automatically-synched local cache like
 sssd to be a far better answer than NIS or LDAP, and NFS root better
 than NFS /usr and/or /var, but I am not the only one whose opinion
 matters when considering whether a feature regression in distributions
 is acceptable.
 
 I think the best solution might be a way for dbus-daemon --system to
 not be required to be Before early targets like sysinit.target (to avoid
 circular dependencies), but for it to survive until the final killing
 spree anyway. Does systemd have a way to say that, or are
 startup/shutdown dependencies always symmetric?
 
 Please see https://bugs.freedesktop.org/show_bug.cgi?id=89847 for more
 on this; one possible hack is to have dbus.service's ExecStop not
 actually stop dbus-daemon, so that it stays around until the final
 killing spree just before /usr and /var are unmounted.
 
 I'm happy to modify dbus.service if that's (part or all of) the
 solution, but before I can do that we need to come up with a solution
 that doesn't cause new dependency cycles.
 
 S
 


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Synchronization Between Services at Shutdown

[Dan Williams]

On Thu, 2015-04-02 at 16:31 +0200, Martin Pitt wrote:
 Lennart Poettering [2015-04-02 15:31 +0200]:
  You need to order wpa_supplicant and NM Before=remote-fs-pre.target
  and pull it it via Wants=remote-fs-pre.target. With that in place
  during shutdown the mounts will be unmounted first, and NM/wpa only
  shut down after that.
 
 wpa_supplicant and NM already have Before=network.target which is even
 stronger. But that doesn't help -- it's D-Bus which we need to leave
 running longer, as dbus going down early tears down all dbus clients as well
 prematurely, thus rendering the above dependencies useless.

At least on the NM side, NM shouldn't be doing anything when dbus-daemon
exits, except logging something and trying to reconnect.  It shouldn't
touch network interfaces except those that require a management daemon,
like wpa_supplicant or Bluetooth or teamd, provided you use the internal
DHCP client.  But ethernet, bridge/bond/vlan/infiniband/etc should be
fine.  Obviously if the supplicant goes down, WiFi goes down, but
running something like NFS over WiFi is kinda asking for trouble, given
that NFS doesn't handle network dropouts well in the first place.

Dan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] No (more) OpenVPN on Debian8 (Jessie) - Thanks systemd ?!

[Dan Williams]

On Thu, 2015-03-05 at 16:00 +0100, system_error wrote:
 OK, thx!
 
 Am 05.03.2015 um 15:56 schrieb Tom Gundersen:
  This is i segfault in NetworkManager, so I would start by figuring
  that one out. Probably the NM mailing list may be able to help you
  better.

nm-connection-editor, to be precise, not NetworkManager itself.  Best to
transfer this discussion into bugzilla, or over to the NetworkManager
mailing list:

https://mail.gnome.org/mailman/listinfo/networkmanager-list

Dan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Mediacast to TV - MiracleCast - Open-Source Miracast - Wifi-Display on linux

[Dan Williams]

On Wed, 2015-02-04 at 00:47 +0100, poma wrote:
 On 03.02.2015 18:43, David Herrmann wrote:
  Hi
  
  On Tue, Feb 3, 2015 at 6:36 PM, poma pomidorabelis...@gmail.com wrote:
  On 02.02.2015 19:58, David Herrmann wrote:
  As I'm not really interested in hacking on network-managers, I've
  decided to stop working on MiracleCast. If, some day, there's a
  working P2P stack on linux, I might resurrect it. But it sounds more
  likely that I'll refer to the Intel solution (WYSIWIDI) instead.
  There're also gstreamer plugins for WFD now, so maybe give them a try?
 
 
  gst-rtsp-server-wfd
  https://github.com/Samsung/gst-rtsp-server-wfd/blob/master/README.md
 
  Pre-conditions:
 
  This module is running on established p2p connection with wifi direct, 
  which means that you have to setup this network environment to run this 
  module. I hope this link would be very helpful. ( 
  http://cgit.freedesktop.org/~dvdhrm/miracle )
 
  You are referring to them, they are referring to you. :)
  
  They provide a gstreamer plugin for Miracast, but quite frankly didn't
  bother hacking on Wifi P2P. Hence, they refer to my miracle-wifid hack
  to provide a P2P link. If NM provides a P2P API, you can just set it
  up via nmcli and then use the gst modules to run Miracast (or you can
  just use the ConnMan API right now).
  
  Thanks
  David
  
 
 
 Well at least there is an open RFE - Network Manager
 [enh] Add support for WiFi P2P (aka WiFi Direct)
 https://bugzilla.gnome.org/show_bug.cgi?id=734073
 
 And in this thread I see Patrik Flykt - ConnMan.
 Connman WiFi p2p API evaluation
 https://mail.gnome.org/archives/networkmanager-list/2015-January/msg00018.html
 
 Let's see if NetworkMan can learn from ConnMan. :)

Of course it can learn something :)  We'd rather have NetworkManager
share an API with ConnMan here instead of needlessly re-inventing the
wheel.  I think we came to quasi-agreement in the mail thread you link
to, but need to write up a final spec and get agreement from Patrik.
This might also be a good project for a community member to help out
with too.  So if anyone is interested in the NetworkManager side of
P2P/Direct (and I know some are) please raise your hand!

Dan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] network-online.target is not down when a physical network is down

[Dan Williams]

On Thu, 2015-01-22 at 19:51 +0300, Andrei Borzenkov wrote:
 В Thu, 22 Jan 2015 16:44:52 +0100
 Igor Bukanov i...@mir2.org пишет:
 
  For a service that should be shutdown when network is not available, I
  tried to use Requires=network-online.target . However, on Fedora 21
  with NetworkManager that does not work. When I switch off WiFi, the
  only connection on my laptop that can configure default IP route and
  setup /etc/resolv.conf, network-online.target still stays active and
  my service continues to run. Is it a bug in Fedora? If not, what is a
  canonical way to implement such dependency?
 
 
 No, it is not a bug. network-online was never intended to be used this
 way. It was intended to be used only during startup; when initial
 startup is finished, state of this service is largely irrelevant.
 
 network-online.target itself does absolutely nothing. It is provided as
 well known name for other services to order itself after; and you need
 to provide implementation that orders itself before.
 
 For NM implementation would be NetworkManager-wait-online.service that
 basically does nothing more than calling nm-online.
 
 Note that network down does not cause any change state in systemd.
 NetworkManager still runs. systemd itself does not watch or manages
 network, so it cannot initiate any actions here. I suppose you really
 want to hook systemctl stop/systemctl start in NetworkManager
 dispatcher framework.

Yeah, a dispatcher script (man NetworkManager has more info) will be
executed whenever any network interface is deconfigured by
NetworkManager.  You could use this, in combination with 'nmcli -f STATE
-t g' (which reports the NM state as a single word, eg connected or
disconnected or connecting), to determine when no network
connections are active, and then run 'systemctl stop your-service.

See also
http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/dispatcher

Dan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] network-online.target is not down when a physical network is down

[Dan Williams]

On Thu, 2015-01-22 at 21:17 +0100, Igor Bukanov wrote:
 Hm, checking nmcli -f STATE -t g does not work from a Networkmanager
 dispatcher script. If I disable WiFi, that gives in the dispatcher
 script connected (local only). If I enable WiFi, then in the
 dispatcher I have connected (site only). Only some moments later the
 state becomes connected, but on that transition from connected
 (site only) to connected the dispatcher script is not called.
 
 What is exactly connected (site only) ?

It means that you probably have connectivity detection enabled, and that
NetworkManager has not yet determined that you are connected to the
Internet (or that whatever URL you've given for connectivity detection
can be accessed).  But for the purposes of your service/script, you can
treat connected (site only) as connected; there is no IP
configuration difference between the two.

See 'man NetworkManager.conf' for more info on connectivity detection.

Dan

 On 22 January 2015 at 19:42, Dan Williams d...@redhat.com wrote:
  On Thu, 2015-01-22 at 19:51 +0300, Andrei Borzenkov wrote:
  В Thu, 22 Jan 2015 16:44:52 +0100
  Igor Bukanov i...@mir2.org пишет:
 
   For a service that should be shutdown when network is not available, I
   tried to use Requires=network-online.target . However, on Fedora 21
   with NetworkManager that does not work. When I switch off WiFi, the
   only connection on my laptop that can configure default IP route and
   setup /etc/resolv.conf, network-online.target still stays active and
   my service continues to run. Is it a bug in Fedora? If not, what is a
   canonical way to implement such dependency?
 
 
  No, it is not a bug. network-online was never intended to be used this
  way. It was intended to be used only during startup; when initial
  startup is finished, state of this service is largely irrelevant.
 
  network-online.target itself does absolutely nothing. It is provided as
  well known name for other services to order itself after; and you need
  to provide implementation that orders itself before.
 
  For NM implementation would be NetworkManager-wait-online.service that
  basically does nothing more than calling nm-online.
 
  Note that network down does not cause any change state in systemd.
  NetworkManager still runs. systemd itself does not watch or manages
  network, so it cannot initiate any actions here. I suppose you really
  want to hook systemctl stop/systemctl start in NetworkManager
  dispatcher framework.
 
  Yeah, a dispatcher script (man NetworkManager has more info) will be
  executed whenever any network interface is deconfigured by
  NetworkManager.  You could use this, in combination with 'nmcli -f STATE
  -t g' (which reports the NM state as a single word, eg connected or
  disconnected or connecting), to determine when no network
  connections are active, and then run 'systemctl stop your-service.
 
  See also
  http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/dispatcher
 
  Dan
 


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database

[Dan Williams]

On Tue, 2014-12-16 at 08:45 +0100, David Herrmann wrote:
 Hi
 
 On Mon, Dec 15, 2014 at 9:20 PM, Dan Williams d...@redhat.com wrote:
  On Mon, 2014-12-15 at 20:40 +0300, Andrei Borzenkov wrote:
  systemd tries to launch logind service which now waits for services it
  is ordered After and eventually times out.
 
  NM patch filed for review by NM dev team:
 
  https://bugzilla.gnome.org/show_bug.cgi?id=741572
 
 Thanks a lot!

Update: the patch has been reviewed and pushed to NM git master (will
eventually be 1.2), nm-1-0, and nm-0-9-10 branches.

Dan

  Also, I don't think logind should fail if there is no network; no reason
  for it to crash and burn just because everything isn't quite ready when
  it starts.  I presume it's got capability to deal with sporadic network
  outages, and that's not really different than waiting for networking to
  show up soon after it starts.  But not my department...
 
 When a user loggs in, we resolve the name to UID. As the initial
 logind binary was only used for login management, it was reasonable to
 avoid starting up before the nss-user-lookup is initialized. Now that
 systemd-logind provides other independent APIs, it might be ok to drop
 that requirement again.
 If the nss user lookup is not ready at the time someone logs in, we
 will print a warning and skip tracking that session. Sounds fine to
 me, but Lennart might have more comments.
 
 Thanks
 David


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database

[Dan Williams]

On Mon, 2014-12-15 at 16:11 +0100, Lennart Poettering wrote:
 On Sat, 13.12.14 10:09, Andrei Borzenkov (arvidj...@gmail.com) wrote:
 
  NetworkManager sets logind inhibitor lock to monitor for suspend
  events. So it implicitly requires logind to be present when NM
  starts.

NM doesn't actually require that, it just wants to know about the
signals that logind sends and have a chance to respond to them.  If
logind isn't running, NM shouldn't really care.  But perhaps expectation
is not matching reality in the code.

 Any idea what it needs the inhibitor for?

To be aware of suspend/resume events of course.  NM may want to
disconnect the network cleanly before suspending, and on resume may need
to clean up network connections and restart certain operations.

  logind is ordered after nss-user-lookup.target. If we have remote
user
  database, it means that logind depends on network to be up and
running.
  
  If network is provided by NetworkManager we have a loop.
  
  Due to the fact that NetworkManager service itself does not declare
  dependency on logind, it can be pretty hard to recognize.
  
  Any idea how it can be solved nicely? I can only think of delaying
  inhibitor logic in NM until logind is started. Not sure what side
  effects it may have.
 
 Yeah, I figure if they want to be able to run in early parts of boot
 they should watch logind's bus name and create their inhibitor only
 after it appears.

Does logind get D-Bus autolaunched?  NM is just creating a bus proxy for
the logind DBus service, and then attempting to call a D-Bus method on
logind to take an inhibitor.  It doesn't actually care that much about
the result, but NM doesn't pass G_DBUS_CALL_FLAGS_NO_AUTO_START to
prohibit logind from launching.

Perhaps NM is requesting logind to start through D-Bus autolaunch, but
since the network isn't up yet logind then fails itself?

Dan


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database

[Dan Williams]

On Mon, 2014-12-15 at 20:40 +0300, Andrei Borzenkov wrote:
 В Mon, 15 Dec 2014 11:34:17 -0600
 Dan Williams d...@redhat.com пишет:
 
  
  On Mon, 2014-12-15 at 16:11 +0100, Lennart Poettering wrote:
   On Sat, 13.12.14 10:09, Andrei Borzenkov (arvidj...@gmail.com) wrote:
   
NetworkManager sets logind inhibitor lock to monitor for suspend
events. So it implicitly requires logind to be present when NM
starts.
  
  NM doesn't actually require that, it just wants to know about the
  signals that logind sends and have a chance to respond to them.  If
  logind isn't running, NM shouldn't really care.  But perhaps expectation
  is not matching reality in the code.
  
   Any idea what it needs the inhibitor for?
  
  To be aware of suspend/resume events of course.  NM may want to
  disconnect the network cleanly before suspending, and on resume may need
  to clean up network connections and restart certain operations.
  
logind is ordered after nss-user-lookup.target. If we have remote
  user
database, it means that logind depends on network to be up and
  running.

If network is provided by NetworkManager we have a loop.

Due to the fact that NetworkManager service itself does not declare
dependency on logind, it can be pretty hard to recognize.

Any idea how it can be solved nicely? I can only think of delaying
inhibitor logic in NM until logind is started. Not sure what side
effects it may have.
   
   Yeah, I figure if they want to be able to run in early parts of boot
   they should watch logind's bus name and create their inhibitor only
   after it appears.
  
  Does logind get D-Bus autolaunched?
 
 Yes.
 
 NM is just creating a bus proxy for
  the logind DBus service, and then attempting to call a D-Bus method on
  logind to take an inhibitor.  It doesn't actually care that much about
  the result, but NM doesn't pass G_DBUS_CALL_FLAGS_NO_AUTO_START to
  prohibit logind from launching.
  
  Perhaps NM is requesting logind to start through D-Bus autolaunch, but
  since the network isn't up yet logind then fails itself?
  
 
 systemd tries to launch logind service which now waits for services it
 is ordered After and eventually times out.

NM patch filed for review by NM dev team:

https://bugzilla.gnome.org/show_bug.cgi?id=741572

Also, I don't think logind should fail if there is no network; no reason
for it to crash and burn just because everything isn't quite ready when
it starts.  I presume it's got capability to deal with sporadic network
outages, and that's not really different than waiting for networking to
show up soon after it starts.  But not my department...

Dan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [BUG] too many rfkill services

[Dan Williams]

On Thu, 2014-11-20 at 14:56 +0100, Michael Biebl wrote:
 2014-11-20 14:17 GMT+01:00 Lennart Poettering lenn...@poettering.net:
  On Tue, 18.11.14 18:37, Łukasz Stelmach (stl...@poczta.fm) wrote:
 
  Hi.
 
  Recently, after I had found an update for my BIOS, my desktop started to
  resume properly (before I could only suspend it). Kernel and systemd do
  their jobs fine. But they seem to have problem cooperating.
 
  For the record I use systemd 215, which means that the issue I describe
  here may have been fixed already.
 
  After several suspend/resumes systemctl shows more than three dozens of
  rfkill devices even though I've got only one BT and one WLAN.
 
  --8---cut here---start-8---
  systemd-rfkill@rfkill0.service   loaded active exitedLoad/Save RF Kill 
  Switch Status of rfkill0
  systemd-rfkill@rfkill1.service   loaded active exitedLoad/Save RF Kill 
  Switch Status of rfkill1
  systemd-rfkill@rfkill2.service  loaded active exitedLoad/Save RF Kill 
  Switch Status of rfkill4
  systemd-rfkill@rfkill3.service  loaded active exitedLoad/Save RF Kill 
  Switch Status of rfkill4
 
  [...]
 
  This really smells like a kernel bug. systemd gets the device names
  via udev from the kernel, hence it's probably some driver bug that
  creates these devices incorrectly.
 
  Nov 18 18:24:02 kotik systemd[1]: Stopping Load/Save RF Kill Switch Status 
  of rfkill9...
  Nov 18 18:24:02 kotik systemd[1]: systemd-rfkill@rfkill9.service: control 
  process exited, code=exited status=1
  Nov 18 18:24:02 kotik systemd[1]: Stopped Load/Save RF Kill Switch Status 
  of rfkill9.
  Nov 18 18:24:02 kotik systemd[1]: Unit systemd-rfkill@rfkill9.service 
  entered failed state.
  --8---cut here---end---8---
 
  The actual issue as I see it is that systemd does not stop and remove
  rfkill services that refer to nonexistent devices.
 
  Yes, we do not flush out information about failed services by default
  so that the admin can have a look and figure out what's going on. If
  this is not desired, then the binary path in ExecStart= should be
  prefixed with -...
 
  I think in this case (and by default) we should keep track of errors
  though, even if it is annoying. But systemd is really not the place to
  work around all possible kernel bugs...
 
 I had some rather interesting experience with the rfkill service as well.
 See [1]. Basically, running rfkill on one device, made the other device go 
 away.

That's normal behavior in the case of a platform rfkill device and a
device-specific rfkill device.  The platform rfkill functionality can
sometimes (often?) cut power to the device through BIOS and GPIOs, and
it will drop off the USB or PCI bus.  But the device itself can also
expose rfkill functionality through it's own drivers, that doesn't cause
it to drop off the bus.  This is your case with the USB-based Bluetooth
device and the BIOS-based platform killswitch.

Since the routing of all these rfkills is highly model specific, there
is no way to know that the platform rfkill has an affect on any other
device in a generic way.  That would have to be hardcoded into the
kernel and would be pretty awful to maintain.

Dan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] sd-dhcp-client: fix REBOOT state handling

[Dan Williams]

On Tue, 2014-11-04 at 11:20 -0600, Dan Williams wrote:
 client-secs wasn't getting set in the REBOOT state, causing
 an assertion.  REBOOT should work the same way as INIT, per
 RFC 2131:
 
  secs   2  Filled in by client, seconds elapsed since client
began address acquisition or renewal process.
 
 REBOOT is necessary because some DHCP servers (eg on
 home routers) do not hand back the same IP address unless the
 'ciaddr' field is filled with that address, which DISCOVER
 cannot do per the RFCs.  This leads to multiple leases
 on machine reboot or DHCP client restart.

Anyone had a chance to review this patch?

 ---
  src/libsystemd-network/sd-dhcp-client.c | 31 +--
  1 file changed, 13 insertions(+), 18 deletions(-)
 
 diff --git a/src/libsystemd-network/sd-dhcp-client.c 
 b/src/libsystemd-network/sd-dhcp-client.c
 index a8ec654..300fc38 100644
 --- a/src/libsystemd-network/sd-dhcp-client.c
 +++ b/src/libsystemd-network/sd-dhcp-client.c
 @@ -89,7 +89,6 @@ struct sd_dhcp_client {
  uint32_t mtu;
  uint32_t xid;
  usec_t start_time;
 -uint16_t secs;
  unsigned int attempt;
  usec_t request_sent;
  sd_event_source *timeout_t1;
 @@ -399,10 +398,12 @@ static int client_message_init(sd_dhcp_client *client, 
 DHCPPacket **ret,
  _cleanup_free_ DHCPPacket *packet;
  size_t optlen, optoffset, size;
  be16_t max_size;
 +usec_t time_now;
 +uint16_t secs;
  int r;
  
  assert(client);
 -assert(client-secs);
 +assert(client-start_time);
  assert(ret);
  assert(_optlen);
  assert(_optoffset);
 @@ -422,7 +423,15 @@ static int client_message_init(sd_dhcp_client *client, 
 DHCPPacket **ret,
  
  /* Although 'secs' field is a SHOULD in RFC 2131, certain DHCP 
 servers
 refuse to issue an DHCP lease if 'secs' is set to zero */
 -packet-dhcp.secs = htobe16(client-secs);
 +r = sd_event_now(client-event, clock_boottime_or_monotonic(), 
 time_now);
 +if (r  0)
 +return r;
 +assert(time_now = client-start_time);
 +
 +/* seconds between sending first and last DISCOVER
 + * must always be strictly positive to deal with broken servers */
 +secs = ((time_now - client-start_time) / USEC_PER_SEC) ? : 1;
 +packet-dhcp.secs = htobe16(secs);
  
  /* RFC2132 section 4.1
 A client that cannot receive unicast IP datagrams until its 
 protocol
 @@ -529,24 +538,12 @@ static int dhcp_client_send_raw(sd_dhcp_client *client, 
 DHCPPacket *packet,
  static int client_send_discover(sd_dhcp_client *client) {
  _cleanup_free_ DHCPPacket *discover = NULL;
  size_t optoffset, optlen;
 -usec_t time_now;
  int r;
  
  assert(client);
  assert(client-state == DHCP_STATE_INIT ||
 client-state == DHCP_STATE_SELECTING);
  
 -/* See RFC2131 section 4.4.1 */
 -
 -r = sd_event_now(client-event, clock_boottime_or_monotonic(), 
 time_now);
 -if (r  0)
 -return r;
 -assert(time_now = client-start_time);
 -
 -/* seconds between sending first and last DISCOVER
 - * must always be strictly positive to deal with broken servers */
 -client-secs = ((time_now - client-start_time) / USEC_PER_SEC) ? : 
 1;
 -
  r = client_message_init(client, discover, DHCP_DISCOVER,
  optlen, optoffset);
  if (r  0)
 @@ -963,10 +960,8 @@ static int client_start(sd_dhcp_client *client) {
  }
  client-fd = r;
  
 -if (client-state == DHCP_STATE_INIT) {
 +if (client-state == DHCP_STATE_INIT || client-state == 
 DHCP_STATE_INIT_REBOOT)
  client-start_time = now(clock_boottime_or_monotonic());
 -client-secs = 0;
 -}
  
  return client_initialize_events(client, client_receive_message_raw);
  }


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] sd-dhcp-lease: expose load/save functions

[Dan Williams]

On Tue, 2014-11-04 at 11:41 -0600, Dan Williams wrote:
 They're useful outside of networkd itself in the libsystemd-network
 library.

Anyone had a chance to review this patch?

 ---
  src/libsystemd-network/dhcp-lease-internal.h | 3 ---
  src/libsystemd-network/sd-dhcp-lease.c   | 4 ++--
  src/network/networkd-link.c  | 2 +-
  src/systemd/sd-dhcp-lease.h  | 3 +++
  4 files changed, 6 insertions(+), 6 deletions(-)
 
 diff --git a/src/libsystemd-network/dhcp-lease-internal.h 
 b/src/libsystemd-network/dhcp-lease-internal.h
 index b85b698..9e184ac 100644
 --- a/src/libsystemd-network/dhcp-lease-internal.h
 +++ b/src/libsystemd-network/dhcp-lease-internal.h
 @@ -78,9 +78,6 @@ int dhcp_lease_new(sd_dhcp_lease **ret);
  int dhcp_lease_parse_options(uint8_t code, uint8_t len, const uint8_t 
 *option,
void *user_data);
  
 -int dhcp_lease_save(sd_dhcp_lease *lease, const char *lease_file);
 -int dhcp_lease_load(const char *lease_file, sd_dhcp_lease **ret);
 -
  int dhcp_lease_set_default_subnet_mask(sd_dhcp_lease *lease);
  
  int dhcp_lease_set_client_id(sd_dhcp_lease *lease, const uint8_t *client_id,
 diff --git a/src/libsystemd-network/sd-dhcp-lease.c 
 b/src/libsystemd-network/sd-dhcp-lease.c
 index 3e338dc..0d74800 100644
 --- a/src/libsystemd-network/sd-dhcp-lease.c
 +++ b/src/libsystemd-network/sd-dhcp-lease.c
 @@ -581,7 +581,7 @@ int dhcp_lease_new(sd_dhcp_lease **ret) {
  return 0;
  }
  
 -int dhcp_lease_save(sd_dhcp_lease *lease, const char *lease_file) {
 +int sd_dhcp_lease_save(sd_dhcp_lease *lease, const char *lease_file) {
  _cleanup_free_ char *temp_path = NULL;
  _cleanup_fclose_ FILE *f = NULL;
  struct in_addr address;
 @@ -690,7 +690,7 @@ finish:
  return r;
  }
  
 -int dhcp_lease_load(const char *lease_file, sd_dhcp_lease **ret) {
 +int sd_dhcp_lease_load(const char *lease_file, sd_dhcp_lease **ret) {
  _cleanup_dhcp_lease_unref_ sd_dhcp_lease *lease = NULL;
  _cleanup_free_ char *address = NULL, *router = NULL, *netmask = NULL,
  *server_address = NULL, *next_server = NULL,
 diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
 index 26ef0fe..fcfbd3e 100644
 --- a/src/network/networkd-link.c
 +++ b/src/network/networkd-link.c
 @@ -1857,7 +1857,7 @@ int link_save(Link *link) {
  if (link-dhcp_lease) {
  assert(link-network);
  
 -r = dhcp_lease_save(link-dhcp_lease, link-lease_file);
 +r = sd_dhcp_lease_save(link-dhcp_lease, link-lease_file);
  if (r  0)
  goto fail;
  
 diff --git a/src/systemd/sd-dhcp-lease.h b/src/systemd/sd-dhcp-lease.h
 index 5fafc04..1b0207b 100644
 --- a/src/systemd/sd-dhcp-lease.h
 +++ b/src/systemd/sd-dhcp-lease.h
 @@ -48,4 +48,7 @@ int sd_dhcp_lease_get_routes(sd_dhcp_lease *lease, struct 
 sd_dhcp_route **routes
  int sd_dhcp_lease_get_client_id(sd_dhcp_lease *lease, const uint8_t 
 **client_id,
  size_t *client_id_len);
  
 +int sd_dhcp_lease_save(sd_dhcp_lease *lease, const char *lease_file);
 +int sd_dhcp_lease_load(const char *lease_file, sd_dhcp_lease **ret);
 +
  #endif


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] sd-dhcp-client: allow getting/setting the client ID

[Dan Williams]

On Tue, 2014-11-04 at 11:48 -0600, Dan Williams wrote:
 The client identifier can be in many different formats, not just
 the one that systemd creates from the Ethernet MAC address.  Non-
 ethernet interfaces have different client IDs formats too.  Users
 may also have custom client IDs that they wish to use to preserve
 lease options delivered by servers configured with the existing
 client ID.

Anyone had a chance to review this patch?

 ---
  src/libsystemd-network/sd-dhcp-client.c | 116 
 
  src/systemd/sd-dhcp-client.h|   4 ++
  2 files changed, 108 insertions(+), 12 deletions(-)
 
 diff --git a/src/libsystemd-network/sd-dhcp-client.c 
 b/src/libsystemd-network/sd-dhcp-client.c
 index 689163c..36f05ca 100644
 --- a/src/libsystemd-network/sd-dhcp-client.c
 +++ b/src/libsystemd-network/sd-dhcp-client.c
 @@ -38,6 +38,7 @@
  #include dhcp-lease-internal.h
  #include sd-dhcp-client.h
  
 +#define MAX_CLIENT_ID_LEN 32
  #define MAX_MAC_ADDR_LEN INFINIBAND_ALEN
  
  struct sd_dhcp_client {
 @@ -56,13 +57,33 @@ struct sd_dhcp_client {
  size_t req_opts_allocated;
  size_t req_opts_size;
  be32_t last_addr;
 -struct {
 -uint8_t type;
 -struct ether_addr mac_addr;
 -} _packed_ client_id;
  uint8_t mac_addr[MAX_MAC_ADDR_LEN];
  size_t mac_addr_len;
  uint16_t arp_type;
 +union {
 +struct {
 +uint8_t type; /* 0: Generic (non-LL) (RFC 2132) */
 +uint8_t data[MAX_CLIENT_ID_LEN];
 +} _packed_ gen;
 +struct {
 +uint8_t type; /* 1: Ethernet Link-Layer (RFC 2132) */
 +uint8_t haddr[ETH_ALEN];
 +} _packed_ eth;
 +struct {
 +uint8_t type; /* 2 - 254: ARP/Link-Layer (RFC 2132) 
 */
 +uint8_t haddr[0];
 +} _packed_ ll;
 +struct {
 +uint8_t type; /* 255: Node-specific (RFC 4361) */
 +uint8_t iaid[4];
 +uint8_t duid[MAX_CLIENT_ID_LEN - 4];
 +} _packed_ ns;
 +struct {
 +uint8_t type;
 +uint8_t data[MAX_CLIENT_ID_LEN];
 +} _packed_ raw;
 +} client_id;
 +size_t client_id_len;
  char *hostname;
  char *vendor_class_identifier;
  uint32_t mtu;
 @@ -201,8 +222,69 @@ int sd_dhcp_client_set_mac(sd_dhcp_client *client, const 
 uint8_t *addr,
  client-mac_addr_len = addr_len;
  client-arp_type = arp_type;
  
 -memcpy(client-client_id.mac_addr, addr, ETH_ALEN);
 -client-client_id.type = 0x01;
 +if (need_restart  client-state != DHCP_STATE_STOPPED)
 +sd_dhcp_client_start(client);
 +
 +return 0;
 +}
 +
 +int sd_dhcp_client_get_client_id(sd_dhcp_client *client, uint8_t *type,
 + const uint8_t **data, size_t *data_len) {
 +
 +assert_return(client, -EINVAL);
 +assert_return(type, -EINVAL);
 +assert_return(data, -EINVAL);
 +assert_return(data_len, -EINVAL);
 +
 +*type = 0;
 +*data = NULL;
 +*data_len = 0;
 +if (client-client_id_len) {
 +*type = client-client_id.raw.type;
 +*data = client-client_id.raw.data;
 +*data_len = client-client_id_len - 1;  /* -1 for 
 sizeof(type) */
 +}
 +
 +return 0;
 +}
 +
 +int sd_dhcp_client_set_client_id(sd_dhcp_client *client, uint8_t type,
 + const uint8_t *data, size_t data_len) {
 +DHCP_CLIENT_DONT_DESTROY(client);
 +bool need_restart = false;
 +
 +assert_return(client, -EINVAL);
 +assert_return(data, -EINVAL);
 +assert_return(data_len  0  data_len = MAX_CLIENT_ID_LEN, 
 -EINVAL);
 +
 +switch (type) {
 +case ARPHRD_ETHER:
 +if (data_len != ETH_ALEN)
 +return -EINVAL;
 +break;
 +case ARPHRD_INFINIBAND:
 +if (data_len != INFINIBAND_ALEN)
 +return -EINVAL;
 +break;
 +default:
 +break;
 +}
 +
 +if (client-client_id_len == data_len + 1 
 +client-client_id.raw.type == type 
 +memcmp(client-client_id.raw.data, data, data_len) == 0)
 +return 0;
 +
 +if (!IN_SET(client-state, DHCP_STATE_INIT, DHCP_STATE_STOPPED)) {
 +log_dhcp_client(client, Changing client ID on running DHCP 
 +client, restarting);
 +need_restart = true;
 +client_stop(client, DHCP_EVENT_STOP);
 +}
 +
 +client-client_id.raw.type = type

[systemd-devel] [PATCH] sd-dhcp-lease: load/save client ID

[Dan Williams]

The lease is usually tied to the client ID, so users of the
lease may want to know what client ID it was acquired with.
---
 src/libsystemd-network/dhcp-lease-internal.h |  5 +++
 src/libsystemd-network/sd-dhcp-client.c  | 16 
 src/libsystemd-network/sd-dhcp-lease.c   | 58 +++-
 src/systemd/sd-dhcp-lease.h  |  2 +
 4 files changed, 80 insertions(+), 1 deletion(-)

diff --git a/src/libsystemd-network/dhcp-lease-internal.h 
b/src/libsystemd-network/dhcp-lease-internal.h
index 8806351..9e184ac 100644
--- a/src/libsystemd-network/dhcp-lease-internal.h
+++ b/src/libsystemd-network/dhcp-lease-internal.h
@@ -70,6 +70,8 @@ struct sd_dhcp_lease {
 char *domainname;
 char *hostname;
 char *root_path;
+uint8_t *client_id;
+size_t client_id_len;
 };
 
 int dhcp_lease_new(sd_dhcp_lease **ret);
@@ -78,5 +80,8 @@ int dhcp_lease_parse_options(uint8_t code, uint8_t len, const 
uint8_t *option,
 
 int dhcp_lease_set_default_subnet_mask(sd_dhcp_lease *lease);
 
+int dhcp_lease_set_client_id(sd_dhcp_lease *lease, const uint8_t *client_id,
+ size_t client_id_len);
+
 DEFINE_TRIVIAL_CLEANUP_FUNC(sd_dhcp_lease*, sd_dhcp_lease_unref);
 #define _cleanup_dhcp_lease_unref_ _cleanup_(sd_dhcp_lease_unrefp)
diff --git a/src/libsystemd-network/sd-dhcp-client.c 
b/src/libsystemd-network/sd-dhcp-client.c
index 8503f19..b2b72be 100644
--- a/src/libsystemd-network/sd-dhcp-client.c
+++ b/src/libsystemd-network/sd-dhcp-client.c
@@ -1029,6 +1029,14 @@ static int client_handle_offer(sd_dhcp_client *client, 
DHCPMessage *offer,
 if (r  0)
 return r;
 
+if (client-client_id_len) {
+r = dhcp_lease_set_client_id(lease,
+ (uint8_t *) 
client-client_id.raw,
+ client-client_id_len);
+if (r  0)
+return r;
+}
+
 r = dhcp_option_parse(offer, len, dhcp_lease_parse_options, lease);
 if (r != DHCP_OFFER) {
 log_dhcp_client(client, received message was not an OFFER, 
ignoring);
@@ -1088,6 +1096,14 @@ static int client_handle_ack(sd_dhcp_client *client, 
DHCPMessage *ack,
 if (r  0)
 return r;
 
+if (client-client_id_len) {
+r = dhcp_lease_set_client_id(lease,
+ (uint8_t *) 
client-client_id.raw,
+ client-client_id_len);
+if (r  0)
+return r;
+}
+
 r = dhcp_option_parse(ack, len, dhcp_lease_parse_options, lease);
 if (r == DHCP_NAK) {
 log_dhcp_client(client, NAK);
diff --git a/src/libsystemd-network/sd-dhcp-lease.c 
b/src/libsystemd-network/sd-dhcp-lease.c
index 1a6add0..f046ac5 100644
--- a/src/libsystemd-network/sd-dhcp-lease.c
+++ b/src/libsystemd-network/sd-dhcp-lease.c
@@ -199,6 +199,7 @@ sd_dhcp_lease *sd_dhcp_lease_unref(sd_dhcp_lease *lease) {
 free(lease-dns);
 free(lease-ntp);
 free(lease-static_route);
+free(lease-client_id);
 free(lease);
 }
 
@@ -585,6 +586,8 @@ int sd_dhcp_lease_save(sd_dhcp_lease *lease, const char 
*lease_file) {
 _cleanup_fclose_ FILE *f = NULL;
 struct in_addr address;
 const struct in_addr *addresses;
+const uint8_t *client_id;
+size_t client_id_len;
 const char *string;
 uint16_t mtu;
 struct sd_dhcp_route *routes;
@@ -658,6 +661,18 @@ int sd_dhcp_lease_save(sd_dhcp_lease *lease, const char 
*lease_file) {
 if (r = 0)
 serialize_dhcp_routes(f, ROUTES, routes, r);
 
+r = sd_dhcp_lease_get_client_id(lease, client_id, client_id_len);
+if (r = 0) {
+_cleanup_free_ char *client_id_hex;
+
+client_id_hex = hexmem (client_id, client_id_len);
+if (!client_id_hex) {
+r = -ENOMEM;
+goto finish;
+}
+fprintf(f, CLIENTID=%s\n, client_id_hex);
+}
+
 r = 0;
 
 fflush(f);
@@ -679,7 +694,8 @@ int sd_dhcp_lease_load(sd_dhcp_lease **ret, const char 
*lease_file) {
 _cleanup_dhcp_lease_unref_ sd_dhcp_lease *lease = NULL;
 _cleanup_free_ char *address = NULL, *router = NULL, *netmask = NULL,
 *server_address = NULL, *next_server = NULL,
-*dns = NULL, *ntp = NULL, *mtu = NULL, *routes = 
NULL;
+*dns = NULL, *ntp = NULL, *mtu = NULL,
+*routes = NULL, *client_id_hex = NULL;
 struct in_addr addr;
 int r;
 
@@ -703,6 +719,7 @@ int sd_dhcp_lease_load(sd_dhcp_lease **ret, const char 
*lease_file) {

[systemd-devel] [PATCH v2] sd-dhcp-client: allow getting/setting the client ID

[Dan Williams]

The client identifier can be in many different formats, not just
the one that systemd creates from the Ethernet MAC address.  Non-
ethernet interfaces may have different client IDs formats.  Users
may also have custom client IDs that the wish to use to preserve
lease options delivered by servers configured with the existing
client ID.
---
 src/libsystemd-network/sd-dhcp-client.c | 117 
 src/systemd/sd-dhcp-client.h|   4 ++
 2 files changed, 109 insertions(+), 12 deletions(-)

diff --git a/src/libsystemd-network/sd-dhcp-client.c 
b/src/libsystemd-network/sd-dhcp-client.c
index 2906f2c..8503f19 100644
--- a/src/libsystemd-network/sd-dhcp-client.c
+++ b/src/libsystemd-network/sd-dhcp-client.c
@@ -38,6 +38,7 @@
 #include dhcp-lease-internal.h
 #include sd-dhcp-client.h
 
+#define MAX_CLIENT_ID_LEN 64  /* Arbitrary limit */
 #define MAX_MAC_ADDR_LEN INFINIBAND_ALEN
 
 struct sd_dhcp_client {
@@ -56,13 +57,33 @@ struct sd_dhcp_client {
 size_t req_opts_allocated;
 size_t req_opts_size;
 be32_t last_addr;
-struct {
-uint8_t type;
-struct ether_addr mac_addr;
-} _packed_ client_id;
 uint8_t mac_addr[MAX_MAC_ADDR_LEN];
 size_t mac_addr_len;
 uint16_t arp_type;
+union {
+struct {
+uint8_t type; /* 0: Generic (non-LL) (RFC 2132) */
+uint8_t data[MAX_CLIENT_ID_LEN];
+} _packed_ gen;
+struct {
+uint8_t type; /* 1: Ethernet Link-Layer (RFC 2132) */
+uint8_t haddr[ETH_ALEN];
+} _packed_ eth;
+struct {
+uint8_t type; /* 2 - 254: ARP/Link-Layer (RFC 2132) */
+uint8_t haddr[0];
+} _packed_ ll;
+struct {
+uint8_t type; /* 255: Node-specific (RFC 4361) */
+uint8_t iaid[4];
+uint8_t duid[MAX_CLIENT_ID_LEN - 4];
+} _packed_ ns;
+struct {
+uint8_t type;
+uint8_t data[MAX_CLIENT_ID_LEN];
+} _packed_ raw;
+} client_id;
+size_t client_id_len;
 char *hostname;
 char *vendor_class_identifier;
 uint32_t mtu;
@@ -200,8 +221,70 @@ int sd_dhcp_client_set_mac(sd_dhcp_client *client, const 
uint8_t *addr,
 client-mac_addr_len = addr_len;
 client-arp_type = arp_type;
 
-memcpy(client-client_id.mac_addr, addr, ETH_ALEN);
-client-client_id.type = 0x01;
+if (need_restart  client-state != DHCP_STATE_STOPPED)
+sd_dhcp_client_start(client);
+
+return 0;
+}
+
+int sd_dhcp_client_get_client_id(sd_dhcp_client *client, uint8_t *type,
+ const uint8_t **data, size_t *data_len) {
+
+assert_return(client, -EINVAL);
+assert_return(type, -EINVAL);
+assert_return(data, -EINVAL);
+assert_return(data_len, -EINVAL);
+
+*type = 0;
+*data = NULL;
+*data_len = 0;
+if (client-client_id_len) {
+*type = client-client_id.raw.type;
+*data = client-client_id.raw.data;
+*data_len = client-client_id_len -
+sizeof (client-client_id.raw.type);
+}
+
+return 0;
+}
+
+int sd_dhcp_client_set_client_id(sd_dhcp_client *client, uint8_t type,
+ const uint8_t *data, size_t data_len) {
+DHCP_CLIENT_DONT_DESTROY(client);
+bool need_restart = false;
+
+assert_return(client, -EINVAL);
+assert_return(data, -EINVAL);
+assert_return(data_len  0  data_len = MAX_CLIENT_ID_LEN, -EINVAL);
+
+switch (type) {
+case ARPHRD_ETHER:
+if (data_len != ETH_ALEN)
+return -EINVAL;
+break;
+case ARPHRD_INFINIBAND:
+if (data_len != INFINIBAND_ALEN)
+return -EINVAL;
+break;
+default:
+break;
+}
+
+if (client-client_id_len == data_len + sizeof 
(client-client_id.raw.type) 
+client-client_id.raw.type == type 
+memcmp(client-client_id.raw.data, data, data_len) == 0)
+return 0;
+
+if (!IN_SET(client-state, DHCP_STATE_INIT, DHCP_STATE_STOPPED)) {
+log_dhcp_client(client, Changing client ID on running DHCP 
+client, restarting);
+need_restart = true;
+client_stop(client, DHCP_EVENT_STOP);
+}
+
+client-client_id.raw.type = type;
+memcpy(client-client_id.raw.data, data, data_len);
+client-client_id_len = data_len + sizeof (client-client_id.raw.type);
 
 if 

Re: [systemd-devel] Changing configurations with networkd

[Dan Williams]

On Wed, 2014-07-23 at 16:46 +0200, Marcel Holtmann wrote:
 Hi Michael,
 
  I think the lease should be remembered and reused in this case.
  
  Hm, this sounds like a bug somewhere. When the new discover is sent
  out it should send the same identifying information to the server, and
  hence be given the same lease back again. Wireshark should tell you if
  the fault is networkd's or the DHCP server.
  
  I get the same address at first, but after several minutes the DHCP server
  decides to offer a new address. I should note, that I have a 10 minute
  lease time for debugging purposes, so that might make the problem more
  prominent. I'll see if I can figure out what happens here.
 
 look at your DHCP server and see what lease time it really hands out after 
 reboot.
 
 However this is between you and your DHCP server. If you configure a lease 
 time of 10 minutes, then that is the only guaranteed time for a given IP 
 address. There is no mandate that the server has to give you the same address 
 after 10 minutes when you ask again. It is valid to just get a different one. 
 And that many home routers try to give you back the same one does not mean 
 that they are required to do so.
 
 The nice DHCP servers will remember your Ethernet address and/or identity 
 information and give you back your old IP address. Either with the left over 
 lease time or with a brand new lease time. There is really no need to store 
 this information on disk. If the lease expired the information on disk are 
 stale as well. And since our DHCP implementation is so fast, it makes really 
 no difference.

Digging up an old thread because I just ran into this situation.

A so fast DHCP client doesn't help if the server doesn't cooperate,
and we don't control the DHCP server.

The router I was using (which isn't a dirt-cheap one) doesn't care about
the client ID or hardware address, it will only give you the same IP
address back if you send your old IP address in the 'ciaddr' field and
your lease is still valid.  And the 'ciaddr' field is zeroed on
DISCOVER, which means that to retrieve the same IP address/lease with
this router, REBOOT/RENEW is necessary.  I suspect that's likely the
case for quite a few more routers out there as well.  The router doesn't
have problems with other clients/OSs that I have found, just the systemd
DHCP code.

So it appears that to retrieve the same address again for as many
routers as possible, the lease details (lifetime, start time, last IP
address, client ID) should probably be stored somewhere for the client
to send later on reboot or service restart.

Dan

 It is safer start out with a brand new DHCP lease instead of having to deal 
 with renewal during boot. At least that way you know the DHCP server is still 
 there and you have a valid IP address. Just re-using a stored IP with a 
 left-over lease is not safe anyway. You never know what changed in the 
 network when you were off.
 
 Regards
 
 Marcel
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] sd-dhcp-client: fix REBOOT state handling

[Dan Williams]

client-secs wasn't getting set in the REBOOT state, causing
an assertion.  REBOOT should work the same way as INIT, per
RFC 2131:

 secs   2  Filled in by client, seconds elapsed since client
   began address acquisition or renewal process.

REBOOT is necessary because some DHCP servers (eg on
home routers) do not hand back the same IP address unless the
'ciaddr' field is filled with that address, which DISCOVER
cannot do per the RFCs.  This leads to multiple leases
on machine reboot or DHCP client restart.
---
 src/libsystemd-network/sd-dhcp-client.c | 31 +--
 1 file changed, 13 insertions(+), 18 deletions(-)

diff --git a/src/libsystemd-network/sd-dhcp-client.c 
b/src/libsystemd-network/sd-dhcp-client.c
index a8ec654..300fc38 100644
--- a/src/libsystemd-network/sd-dhcp-client.c
+++ b/src/libsystemd-network/sd-dhcp-client.c
@@ -89,7 +89,6 @@ struct sd_dhcp_client {
 uint32_t mtu;
 uint32_t xid;
 usec_t start_time;
-uint16_t secs;
 unsigned int attempt;
 usec_t request_sent;
 sd_event_source *timeout_t1;
@@ -399,10 +398,12 @@ static int client_message_init(sd_dhcp_client *client, 
DHCPPacket **ret,
 _cleanup_free_ DHCPPacket *packet;
 size_t optlen, optoffset, size;
 be16_t max_size;
+usec_t time_now;
+uint16_t secs;
 int r;
 
 assert(client);
-assert(client-secs);
+assert(client-start_time);
 assert(ret);
 assert(_optlen);
 assert(_optoffset);
@@ -422,7 +423,15 @@ static int client_message_init(sd_dhcp_client *client, 
DHCPPacket **ret,
 
 /* Although 'secs' field is a SHOULD in RFC 2131, certain DHCP servers
refuse to issue an DHCP lease if 'secs' is set to zero */
-packet-dhcp.secs = htobe16(client-secs);
+r = sd_event_now(client-event, clock_boottime_or_monotonic(), 
time_now);
+if (r  0)
+return r;
+assert(time_now = client-start_time);
+
+/* seconds between sending first and last DISCOVER
+ * must always be strictly positive to deal with broken servers */
+secs = ((time_now - client-start_time) / USEC_PER_SEC) ? : 1;
+packet-dhcp.secs = htobe16(secs);
 
 /* RFC2132 section 4.1
A client that cannot receive unicast IP datagrams until its protocol
@@ -529,24 +538,12 @@ static int dhcp_client_send_raw(sd_dhcp_client *client, 
DHCPPacket *packet,
 static int client_send_discover(sd_dhcp_client *client) {
 _cleanup_free_ DHCPPacket *discover = NULL;
 size_t optoffset, optlen;
-usec_t time_now;
 int r;
 
 assert(client);
 assert(client-state == DHCP_STATE_INIT ||
client-state == DHCP_STATE_SELECTING);
 
-/* See RFC2131 section 4.4.1 */
-
-r = sd_event_now(client-event, clock_boottime_or_monotonic(), 
time_now);
-if (r  0)
-return r;
-assert(time_now = client-start_time);
-
-/* seconds between sending first and last DISCOVER
- * must always be strictly positive to deal with broken servers */
-client-secs = ((time_now - client-start_time) / USEC_PER_SEC) ? : 1;
-
 r = client_message_init(client, discover, DHCP_DISCOVER,
 optlen, optoffset);
 if (r  0)
@@ -963,10 +960,8 @@ static int client_start(sd_dhcp_client *client) {
 }
 client-fd = r;
 
-if (client-state == DHCP_STATE_INIT) {
+if (client-state == DHCP_STATE_INIT || client-state == 
DHCP_STATE_INIT_REBOOT)
 client-start_time = now(clock_boottime_or_monotonic());
-client-secs = 0;
-}
 
 return client_initialize_events(client, client_receive_message_raw);
 }
-- 
1.9.3


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] sd-dhcp-lease: expose load/save functions

[Dan Williams]

They're useful outside of networkd itself in the libsystemd-network
library.
---
 src/libsystemd-network/dhcp-lease-internal.h | 3 ---
 src/libsystemd-network/sd-dhcp-lease.c   | 4 ++--
 src/network/networkd-link.c  | 2 +-
 src/systemd/sd-dhcp-lease.h  | 3 +++
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/libsystemd-network/dhcp-lease-internal.h 
b/src/libsystemd-network/dhcp-lease-internal.h
index b85b698..9e184ac 100644
--- a/src/libsystemd-network/dhcp-lease-internal.h
+++ b/src/libsystemd-network/dhcp-lease-internal.h
@@ -78,9 +78,6 @@ int dhcp_lease_new(sd_dhcp_lease **ret);
 int dhcp_lease_parse_options(uint8_t code, uint8_t len, const uint8_t *option,
   void *user_data);
 
-int dhcp_lease_save(sd_dhcp_lease *lease, const char *lease_file);
-int dhcp_lease_load(const char *lease_file, sd_dhcp_lease **ret);
-
 int dhcp_lease_set_default_subnet_mask(sd_dhcp_lease *lease);
 
 int dhcp_lease_set_client_id(sd_dhcp_lease *lease, const uint8_t *client_id,
diff --git a/src/libsystemd-network/sd-dhcp-lease.c 
b/src/libsystemd-network/sd-dhcp-lease.c
index 3e338dc..0d74800 100644
--- a/src/libsystemd-network/sd-dhcp-lease.c
+++ b/src/libsystemd-network/sd-dhcp-lease.c
@@ -581,7 +581,7 @@ int dhcp_lease_new(sd_dhcp_lease **ret) {
 return 0;
 }
 
-int dhcp_lease_save(sd_dhcp_lease *lease, const char *lease_file) {
+int sd_dhcp_lease_save(sd_dhcp_lease *lease, const char *lease_file) {
 _cleanup_free_ char *temp_path = NULL;
 _cleanup_fclose_ FILE *f = NULL;
 struct in_addr address;
@@ -690,7 +690,7 @@ finish:
 return r;
 }
 
-int dhcp_lease_load(const char *lease_file, sd_dhcp_lease **ret) {
+int sd_dhcp_lease_load(const char *lease_file, sd_dhcp_lease **ret) {
 _cleanup_dhcp_lease_unref_ sd_dhcp_lease *lease = NULL;
 _cleanup_free_ char *address = NULL, *router = NULL, *netmask = NULL,
 *server_address = NULL, *next_server = NULL,
diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
index 26ef0fe..fcfbd3e 100644
--- a/src/network/networkd-link.c
+++ b/src/network/networkd-link.c
@@ -1857,7 +1857,7 @@ int link_save(Link *link) {
 if (link-dhcp_lease) {
 assert(link-network);
 
-r = dhcp_lease_save(link-dhcp_lease, link-lease_file);
+r = sd_dhcp_lease_save(link-dhcp_lease, link-lease_file);
 if (r  0)
 goto fail;
 
diff --git a/src/systemd/sd-dhcp-lease.h b/src/systemd/sd-dhcp-lease.h
index 5fafc04..1b0207b 100644
--- a/src/systemd/sd-dhcp-lease.h
+++ b/src/systemd/sd-dhcp-lease.h
@@ -48,4 +48,7 @@ int sd_dhcp_lease_get_routes(sd_dhcp_lease *lease, struct 
sd_dhcp_route **routes
 int sd_dhcp_lease_get_client_id(sd_dhcp_lease *lease, const uint8_t 
**client_id,
 size_t *client_id_len);
 
+int sd_dhcp_lease_save(sd_dhcp_lease *lease, const char *lease_file);
+int sd_dhcp_lease_load(const char *lease_file, sd_dhcp_lease **ret);
+
 #endif
-- 
1.9.3


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] sd-dhcp-client: allow getting/setting the client ID

[Dan Williams]

The client identifier can be in many different formats, not just
the one that systemd creates from the Ethernet MAC address.  Non-
ethernet interfaces have different client IDs formats too.  Users
may also have custom client IDs that they wish to use to preserve
lease options delivered by servers configured with the existing
client ID.
---
 src/libsystemd-network/sd-dhcp-client.c | 116 
 src/systemd/sd-dhcp-client.h|   4 ++
 2 files changed, 108 insertions(+), 12 deletions(-)

diff --git a/src/libsystemd-network/sd-dhcp-client.c 
b/src/libsystemd-network/sd-dhcp-client.c
index 689163c..36f05ca 100644
--- a/src/libsystemd-network/sd-dhcp-client.c
+++ b/src/libsystemd-network/sd-dhcp-client.c
@@ -38,6 +38,7 @@
 #include dhcp-lease-internal.h
 #include sd-dhcp-client.h
 
+#define MAX_CLIENT_ID_LEN 32
 #define MAX_MAC_ADDR_LEN INFINIBAND_ALEN
 
 struct sd_dhcp_client {
@@ -56,13 +57,33 @@ struct sd_dhcp_client {
 size_t req_opts_allocated;
 size_t req_opts_size;
 be32_t last_addr;
-struct {
-uint8_t type;
-struct ether_addr mac_addr;
-} _packed_ client_id;
 uint8_t mac_addr[MAX_MAC_ADDR_LEN];
 size_t mac_addr_len;
 uint16_t arp_type;
+union {
+struct {
+uint8_t type; /* 0: Generic (non-LL) (RFC 2132) */
+uint8_t data[MAX_CLIENT_ID_LEN];
+} _packed_ gen;
+struct {
+uint8_t type; /* 1: Ethernet Link-Layer (RFC 2132) */
+uint8_t haddr[ETH_ALEN];
+} _packed_ eth;
+struct {
+uint8_t type; /* 2 - 254: ARP/Link-Layer (RFC 2132) */
+uint8_t haddr[0];
+} _packed_ ll;
+struct {
+uint8_t type; /* 255: Node-specific (RFC 4361) */
+uint8_t iaid[4];
+uint8_t duid[MAX_CLIENT_ID_LEN - 4];
+} _packed_ ns;
+struct {
+uint8_t type;
+uint8_t data[MAX_CLIENT_ID_LEN];
+} _packed_ raw;
+} client_id;
+size_t client_id_len;
 char *hostname;
 char *vendor_class_identifier;
 uint32_t mtu;
@@ -201,8 +222,69 @@ int sd_dhcp_client_set_mac(sd_dhcp_client *client, const 
uint8_t *addr,
 client-mac_addr_len = addr_len;
 client-arp_type = arp_type;
 
-memcpy(client-client_id.mac_addr, addr, ETH_ALEN);
-client-client_id.type = 0x01;
+if (need_restart  client-state != DHCP_STATE_STOPPED)
+sd_dhcp_client_start(client);
+
+return 0;
+}
+
+int sd_dhcp_client_get_client_id(sd_dhcp_client *client, uint8_t *type,
+ const uint8_t **data, size_t *data_len) {
+
+assert_return(client, -EINVAL);
+assert_return(type, -EINVAL);
+assert_return(data, -EINVAL);
+assert_return(data_len, -EINVAL);
+
+*type = 0;
+*data = NULL;
+*data_len = 0;
+if (client-client_id_len) {
+*type = client-client_id.raw.type;
+*data = client-client_id.raw.data;
+*data_len = client-client_id_len - 1;  /* -1 for sizeof(type) 
*/
+}
+
+return 0;
+}
+
+int sd_dhcp_client_set_client_id(sd_dhcp_client *client, uint8_t type,
+ const uint8_t *data, size_t data_len) {
+DHCP_CLIENT_DONT_DESTROY(client);
+bool need_restart = false;
+
+assert_return(client, -EINVAL);
+assert_return(data, -EINVAL);
+assert_return(data_len  0  data_len = MAX_CLIENT_ID_LEN, -EINVAL);
+
+switch (type) {
+case ARPHRD_ETHER:
+if (data_len != ETH_ALEN)
+return -EINVAL;
+break;
+case ARPHRD_INFINIBAND:
+if (data_len != INFINIBAND_ALEN)
+return -EINVAL;
+break;
+default:
+break;
+}
+
+if (client-client_id_len == data_len + 1 
+client-client_id.raw.type == type 
+memcmp(client-client_id.raw.data, data, data_len) == 0)
+return 0;
+
+if (!IN_SET(client-state, DHCP_STATE_INIT, DHCP_STATE_STOPPED)) {
+log_dhcp_client(client, Changing client ID on running DHCP 
+client, restarting);
+need_restart = true;
+client_stop(client, DHCP_EVENT_STOP);
+}
+
+client-client_id.raw.type = type;
+memcpy(client-client_id.raw.data, data, data_len);
+client-client_id_len = data_len + 1; /* +1 for sizeof(type) */
 
 if (need_restart  client-state != DHCP_STATE_STOPPED)
 sd_dhcp_client_start(client);

Re: [systemd-devel] [question] networkd: Any support for hooks?

[Dan Williams]

On Tue, 2014-11-04 at 19:40 +0100, Lennart Poettering wrote:
 BOn Tue, 04.11.14 19:07, Tomasz Torcz (to...@pipebreaker.pl) wrote:
 
  On Thu, Oct 02, 2014 at 08:36:10AM +0200, Lennart Poettering wrote:
   On Wed, 01.10.14 21:36, Cameron Norman (camerontnor...@gmail.com) wrote:
   
Hello,

ifupdown [1], NetworkManager, and WICD all support hooks for when a
 1;3409;0c   network interface is configured or deconfigured (before and 
 after
these actions).

Are there any plans to support something along these lines? If so,
what will that look like?

If there are no plans, how do networkd's developers feel about adding
the feature (will not merge, or will accept patches, etc.) ?
   
   Can you be more specific what precisely you intend to hook in there?
   I'd really prefer if we could find different solutions for the common
   usecases.
  
Example: I'd like to add interface to proper firewalld zone.
  Ideally it could be done by networkd itself (it just one dbus call:
  addInterface(in  s zone, in  s interface, …) based on new Zone=string
  setting in .netdev file.
Hook can determine which zone interface should belong to and call
  firewall-cmd --zone=zone --add-interface=interface
 
 If firewalld shall be dynamic then it really should listen to rtnl on
 its own. It's the wrong way round, you don't want to to call into
 higher level software from lower level one. It's the higher level
 software that should subscribe to changes from the lower level software.

firewalld can't get the information that WiFi network Starbucks should
be locked down more than your home network.  How is it supposed to get
that information just listening to rtnl or other kernel events?  The
kernel doesn't care; the only source of that information is the
connection manager.

Dan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] sd-dhcp6-client: fix off-by-two error in DUID length

[Dan Williams]

The duid data passed by the caller does not include the DUID type,
but sd_dhcp6_client_set_duid() was treating it like it did.
---
 src/libsystemd-network/sd-dhcp6-client.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/libsystemd-network/sd-dhcp6-client.c 
b/src/libsystemd-network/sd-dhcp6-client.c
index fa4f9b5..dbec1a2 100644
--- a/src/libsystemd-network/sd-dhcp6-client.c
+++ b/src/libsystemd-network/sd-dhcp6-client.c
@@ -200,19 +200,19 @@ int sd_dhcp6_client_set_duid(sd_dhcp6_client *client, 
uint16_t type, uint8_t *du
 
 switch (type) {
 case DHCP6_DUID_LLT:
-if (duid_len = sizeof(client-duid.llt))
+if (duid_len = sizeof(client-duid.llt) - 2)
 return -EINVAL;
 break;
 case DHCP6_DUID_EN:
-if (duid_len != sizeof(client-duid.en))
+if (duid_len != sizeof(client-duid.en) - 2)
 return -EINVAL;
 break;
 case DHCP6_DUID_LL:
-if (duid_len = sizeof(client-duid.ll))
+if (duid_len = sizeof(client-duid.ll) - 2)
 return -EINVAL;
 break;
 case DHCP6_DUID_UUID:
-if (duid_len != sizeof(client-duid.uuid))
+if (duid_len != sizeof(client-duid.uuid) - 2)
 return -EINVAL;
 break;
 default:
@@ -222,7 +222,7 @@ int sd_dhcp6_client_set_duid(sd_dhcp6_client *client, 
uint16_t type, uint8_t *du
 
 client-duid.raw.type = htobe16(type);
 memcpy(client-duid.raw.data, duid, duid_len);
-client-duid_len = duid_len;
+client-duid_len = duid_len + 2;  /* +2 for sizeof(type) */
 
 return 0;
 }
-- 
1.9.3


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] sd-dhcp-client: clean up raw socket sd_event_source when creating new UDP socket

[Dan Williams]

The raw socket sd_event_source used for DHCP server solicitations
was simply dropped on the floor when creating the new UDP socket
after a lease has been acquired.  Clean it up properly so we're
not still listening and responding to events on it.

---
 src/libsystemd-network/sd-dhcp-client.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/libsystemd-network/sd-dhcp-client.c 
b/src/libsystemd-network/sd-dhcp-client.c
index dc9b2c2..5472082 100644
--- a/src/libsystemd-network/sd-dhcp-client.c
+++ b/src/libsystemd-network/sd-dhcp-client.c
@@ -1310,6 +1310,9 @@ static int client_handle_message(sd_dhcp_client *client, 
DHCPMessage *message,
 if (r = 0) {
 client-timeout_resend =
 sd_event_source_unref(client-timeout_resend);
+client-receive_message =
+sd_event_source_unref(client-receive_message);
+client-fd = asynchronous_close(client-fd);
 
 if (IN_SET(client-state, DHCP_STATE_REQUESTING,
DHCP_STATE_REBOOTING))
-- 
1.9.3


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH v3] sd-dhcp-client: support non-Ethernet hardware addresses

[Dan Williams]

Like Infiniband.  See RFC 4390 section 2.1 for details on DHCP
and Infiniband; chaddr is zeroed, hlen is set to 0, and htype
is set to ARPHRD_INFINIBAND because IB hardware addresses
are 20 bytes in length.
---
v3: use arp_type for identifying client MAC address types, and
fix non-Ethernet hardware addresses in sd-dhcp6-client

 src/libsystemd-network/dhcp-internal.h | 10 ++--
 src/libsystemd-network/dhcp-network.c  | 54 ++
 src/libsystemd-network/dhcp-packet.c   |  8 ++--
 src/libsystemd-network/sd-dhcp-client.c| 74 +++---
 src/libsystemd-network/sd-dhcp-server.c|  8 ++--
 src/libsystemd-network/sd-dhcp6-client.c   | 34 ++
 src/libsystemd-network/test-dhcp-client.c  | 14 --
 src/libsystemd-network/test-dhcp-option.c  |  2 +-
 src/libsystemd-network/test-dhcp6-client.c |  8 +++-
 src/network/networkd-dhcp4.c   |  4 +-
 src/network/networkd-link.c| 12 +++--
 src/systemd/sd-dhcp-client.h   |  4 +-
 src/systemd/sd-dhcp6-client.h  |  4 +-
 13 files changed, 178 insertions(+), 58 deletions(-)

diff --git a/src/libsystemd-network/dhcp-internal.h 
b/src/libsystemd-network/dhcp-internal.h
index 1069c8a..d358a49 100644
--- a/src/libsystemd-network/dhcp-internal.h
+++ b/src/libsystemd-network/dhcp-internal.h
@@ -20,22 +20,25 @@
 
   You should have received a copy of the GNU Lesser General Public License
   along with systemd; If not, see http://www.gnu.org/licenses/.
 ***/
 
 #include stdint.h
 #include linux/if_packet.h
+#include net/if_arp.h
 #include net/ethernet.h
 
 #include socket-util.h
 
 #include sd-dhcp-client.h
 #include dhcp-protocol.h
 
-int dhcp_network_bind_raw_socket(int index, union sockaddr_union *link, 
uint32_t xid, struct ether_addr mac_addr);
+int dhcp_network_bind_raw_socket(int index, union sockaddr_union *link,
+ uint32_t xid, const uint8_t *mac_addr,
+ size_t mac_addr_len, uint16_t arp_type);
 int dhcp_network_bind_udp_socket(be32_t address, uint16_t port);
 int dhcp_network_send_raw_socket(int s, const union sockaddr_union *link,
  const void *packet, size_t len);
 int dhcp_network_send_udp_socket(int s, be32_t address, uint16_t port,
  const void *packet, size_t len);
 
 int dhcp_option_append(DHCPMessage *message, size_t size, size_t *offset, 
uint8_t overload,
@@ -43,16 +46,17 @@ int dhcp_option_append(DHCPMessage *message, size_t size, 
size_t *offset, uint8_
 
 typedef int (*dhcp_option_cb_t)(uint8_t code, uint8_t len,
 const uint8_t *option, void *user_data);
 
 int dhcp_option_parse(DHCPMessage *message, size_t len,
   dhcp_option_cb_t cb, void *user_data);
 
-int dhcp_message_init(DHCPMessage *message, uint8_t op, uint32_t xid, uint8_t 
type,
-  size_t optlen, size_t *optoffset);
+int dhcp_message_init(DHCPMessage *message, uint8_t op, uint32_t xid,
+  uint8_t type, uint16_t arp_type, size_t optlen,
+  size_t *optoffset);
 
 uint16_t dhcp_packet_checksum(uint8_t *buf, size_t len);
 
 void dhcp_packet_append_ip_headers(DHCPPacket *packet, be32_t source_addr,
uint16_t source, be32_t destination_addr,
uint16_t destination, uint16_t len);
 
diff --git a/src/libsystemd-network/dhcp-network.c 
b/src/libsystemd-network/dhcp-network.c
index 1ced5cf..29e9993 100644
--- a/src/libsystemd-network/dhcp-network.c
+++ b/src/libsystemd-network/dhcp-network.c
@@ -18,27 +18,31 @@
 ***/
 
 #include errno.h
 #include sys/types.h
 #include sys/socket.h
 #include string.h
 #include linux/if_packet.h
+#include linux/if_infiniband.h
 #include net/ethernet.h
 #include net/if_arp.h
 #include stdio.h
 #include unistd.h
 #include linux/filter.h
 
 #include socket-util.h
 
 #include dhcp-internal.h
 
-int dhcp_network_bind_raw_socket(int ifindex, union sockaddr_union *link,
- uint32_t xid, struct ether_addr mac_addr) {
-
+static int _bind_raw_socket(int ifindex, union sockaddr_union *link,
+uint32_t xid, const uint8_t *mac_addr,
+size_t mac_addr_len,
+const uint8_t *bcast_addr,
+const struct ether_addr *eth_mac,
+uint16_t arp_type, uint8_t dhcp_hlen) {
 struct sock_filter filter[] = {
 BPF_STMT(BPF_LD + BPF_W + BPF_LEN, 0), 
/* A - packet length */
 BPF_JUMP(BPF_JMP + BPF_JGE + BPF_K, sizeof(DHCPPacket), 1, 0), 
/* packet = DHCPPacket ? */
 BPF_STMT(BPF_RET + BPF_K, 0),  
/* ignore */
 BPF_STMT(BPF_LD + BPF_B + BPF_ABS, offsetof(DHCPPacket, 

Re: [systemd-devel] [PATCH] sd-dhcp-client: support non-Ethernet hardware addresses

[Dan Williams]

On Fri, 2014-10-03 at 16:10 +0300, Patrik Flykt wrote:
 On Fri, 2014-10-03 at 15:48 +0300, Patrik Flykt wrote:
  On Fri, 2014-09-26 at 15:15 -0500, Dan Williams wrote:
/* RFC2132 section 4.1.1:
   The client MUST include its hardware address in the ’chaddr’ 
   field, if
   -   necessary for delivery of DHCP reply messages.
   +   necessary for delivery of DHCP reply messages.  Non-Ethernet
   +   interfaces will leave 'chaddr' empty and use the client 
   identifier
   +   instead (eg, RFC 4390 section 2.1).
 */
   -memcpy(packet-dhcp.chaddr, client-client_id.mac_addr, 
   ETH_ALEN);
   +if (client-mac_addr_len == ETH_ALEN)
   +memcpy(packet-dhcp.chaddr, client-mac_addr, 
   ETH_ALEN);
  
  Sorry about the late review, but shouldn't this be more generic if
  written:
  if (client-mac_addr_len)
  memcpy(packet-dhcp.chaddr, client-mac_addr, 
  client-mac_addr_len);
  
  With that, all cases are covered. Which, AFAIK, are none in addition to
  ethernet. An assert() should check the given MAC address length at some
  point in the code so that it cannot be  16.
 
 And then I notice that infiniband has a MAC address length of 20. For
 all practical purposes this works as expected. Except if we want to go
 nitpicking when setting the MAC address and also require the address
 type to be supplied? Probably not...

sd_dhcp_client_set_mac() does have an 'arp_type' parameter that's cached
in the client struct, so that could be changed to:

if (client-arp_type == ARPHRD_ETHER)

if you'd like.

Dan


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] sd-dhcp-client: support non-Ethernet hardware addresses

[Dan Williams]

On Thu, 2014-10-02 at 16:39 +0200, Tom Gundersen wrote:
 On Fri, Sep 26, 2014 at 10:15 PM, Dan Williams d...@redhat.com wrote:
  Like Infiniband.  See RFC 4390 section 2.1 for details on DHCP
  and Infiniband; chaddr is zeroed, hlen is set to 0, and htype
  is set to ARPHRD_INFINIBAND because IB hardware addresses
  are 20 bytes in length.
 
 Sorry for taking time with this. Overall looks good, just minor comments 
 inline.
 
  ---
   src/libsystemd-network/dhcp-internal.h| 10 +++--
   src/libsystemd-network/dhcp-network.c | 54 -
   src/libsystemd-network/dhcp-packet.c  |  8 ++--
   src/libsystemd-network/sd-dhcp-client.c   | 66 
  +++
   src/libsystemd-network/sd-dhcp-server.c   |  8 ++--
   src/libsystemd-network/test-dhcp-client.c | 14 +--
   src/libsystemd-network/test-dhcp-option.c |  2 +-
   src/network/networkd-dhcp4.c  |  4 +-
   src/network/networkd-link.c   |  4 +-
   src/systemd/sd-dhcp-client.h  |  4 +-
   10 files changed, 130 insertions(+), 44 deletions(-)
 
  *** Testing appreciated
 
  diff --git a/src/libsystemd-network/dhcp-internal.h 
  b/src/libsystemd-network/dhcp-internal.h
  index 1069c8a..d358a49 100644
  --- a/src/libsystemd-network/dhcp-internal.h
  +++ b/src/libsystemd-network/dhcp-internal.h
  @@ -20,22 +20,25 @@
 
 You should have received a copy of the GNU Lesser General Public License
 along with systemd; If not, see http://www.gnu.org/licenses/.
   ***/
 
   #include stdint.h
   #include linux/if_packet.h
  +#include net/if_arp.h
   #include net/ethernet.h
 
   #include socket-util.h
 
   #include sd-dhcp-client.h
   #include dhcp-protocol.h
 
  -int dhcp_network_bind_raw_socket(int index, union sockaddr_union *link, 
  uint32_t xid, struct ether_addr mac_addr);
  +int dhcp_network_bind_raw_socket(int index, union sockaddr_union *link,
  + uint32_t xid, const uint8_t *mac_addr,
  + size_t mac_addr_len, uint16_t arp_type);
   int dhcp_network_bind_udp_socket(be32_t address, uint16_t port);
   int dhcp_network_send_raw_socket(int s, const union sockaddr_union *link,
const void *packet, size_t len);
   int dhcp_network_send_udp_socket(int s, be32_t address, uint16_t port,
const void *packet, size_t len);
 
   int dhcp_option_append(DHCPMessage *message, size_t size, size_t *offset, 
  uint8_t overload,
  @@ -43,16 +46,17 @@ int dhcp_option_append(DHCPMessage *message, size_t 
  size, size_t *offset, uint8_
 
   typedef int (*dhcp_option_cb_t)(uint8_t code, uint8_t len,
   const uint8_t *option, void *user_data);
 
   int dhcp_option_parse(DHCPMessage *message, size_t len,
 dhcp_option_cb_t cb, void *user_data);
 
  -int dhcp_message_init(DHCPMessage *message, uint8_t op, uint32_t xid, 
  uint8_t type,
  -  size_t optlen, size_t *optoffset);
  +int dhcp_message_init(DHCPMessage *message, uint8_t op, uint32_t xid,
  +  uint8_t type, uint16_t arp_type, size_t optlen,
  +  size_t *optoffset);
 
   uint16_t dhcp_packet_checksum(uint8_t *buf, size_t len);
 
   void dhcp_packet_append_ip_headers(DHCPPacket *packet, be32_t source_addr,
  uint16_t source, be32_t 
  destination_addr,
  uint16_t destination, uint16_t len);
 
  diff --git a/src/libsystemd-network/dhcp-network.c 
  b/src/libsystemd-network/dhcp-network.c
  index 1ced5cf..29e9993 100644
  --- a/src/libsystemd-network/dhcp-network.c
  +++ b/src/libsystemd-network/dhcp-network.c
  @@ -18,27 +18,31 @@
   ***/
 
   #include errno.h
   #include sys/types.h
   #include sys/socket.h
   #include string.h
   #include linux/if_packet.h
  +#include linux/if_infiniband.h
   #include net/ethernet.h
   #include net/if_arp.h
   #include stdio.h
   #include unistd.h
   #include linux/filter.h
 
   #include socket-util.h
 
   #include dhcp-internal.h
 
  -int dhcp_network_bind_raw_socket(int ifindex, union sockaddr_union *link,
  - uint32_t xid, struct ether_addr mac_addr) 
  {
  -
  +static int _bind_raw_socket(int ifindex, union sockaddr_union *link,
  +uint32_t xid, const uint8_t *mac_addr,
  +size_t mac_addr_len,
  +const uint8_t *bcast_addr,
  +const struct ether_addr *eth_mac,
  +uint16_t arp_type, uint8_t dhcp_hlen) {
   struct sock_filter filter[] = {
   BPF_STMT(BPF_LD + BPF_W + BPF_LEN, 0), 
  /* A - packet length */
   BPF_JUMP(BPF_JMP + BPF_JGE + BPF_K, sizeof(DHCPPacket), 1, 
  0), /* packet = DHCPPacket ? */
   BPF_STMT(BPF_RET

[systemd-devel] [PATCH] sd-dhcp6-client: support custom DUIDs

[Dan Williams]

The caller may have an existing DUID that it wants to use, and may
want to use some other DUID generation scheme than systemd's
default DUID-EN.
---
 src/libsystemd-network/sd-dhcp6-client.c | 43 +++-
 src/systemd/sd-dhcp6-client.h|  2 ++
 2 files changed, 33 insertions(+), 12 deletions(-)

diff --git a/src/libsystemd-network/sd-dhcp6-client.c 
b/src/libsystemd-network/sd-dhcp6-client.c
index c190b56..87a3198 100644
--- a/src/libsystemd-network/sd-dhcp6-client.c
+++ b/src/libsystemd-network/sd-dhcp6-client.c
@@ -35,14 +35,16 @@
 #include dhcp6-protocol.h
 #include dhcp6-internal.h
 #include dhcp6-lease-internal.h
 
 #define SYSTEMD_PEN 43793
 #define HASH_KEY SD_ID128_MAKE(80,11,8c,c2,fe,4a,03,ee,3e,d6,0c,6f,36,39,14,09)
 
+#define MAX_DUID_LEN 32
+
 struct sd_dhcp6_client {
 RefCount n_ref;
 
 enum DHCP6State state;
 sd_event *event;
 int event_priority;
 int index;
@@ -58,20 +60,16 @@ struct sd_dhcp6_client {
 sd_event_source *receive_message;
 usec_t retransmit_time;
 uint8_t retransmit_count;
 sd_event_source *timeout_resend;
 sd_event_source *timeout_resend_expire;
 sd_dhcp6_client_cb_t cb;
 void *userdata;
-
-struct duid_en {
-uint16_t type; /* DHCP6_DUID_EN */
-uint32_t pen;
-uint8_t id[8];
-} _packed_ duid;
+uint8_t duid[MAX_DUID_LEN];
+size_t duid_len;
 };
 
 static const uint16_t default_req_opts[] = {
 DHCP6_OPTION_DNS_SERVERS,
 DHCP6_OPTION_DOMAIN_LIST,
 DHCP6_OPTION_NTP_SERVER,
 };
@@ -143,14 +141,27 @@ int sd_dhcp6_client_set_mac(sd_dhcp6_client *client,
 memcpy(client-mac_addr, mac_addr, sizeof(client-mac_addr));
 else
 memset(client-mac_addr, 0x00, sizeof(client-mac_addr));
 
 return 0;
 }
 
+int sd_dhcp6_client_set_duid(sd_dhcp6_client *client, uint8_t *duid,
+ size_t duid_len)
+{
+assert_return(client, -EINVAL);
+assert_return(duid, -EINVAL);
+assert_return(duid_len  0  duid_len = MAX_DUID_LEN, -EINVAL);
+
+memcpy(client-duid, duid, duid_len);
+client-duid_len = duid_len;
+
+   return 0;
+}
+
 int sd_dhcp6_client_set_request_option(sd_dhcp6_client *client,
uint16_t option) {
 size_t t;
 
 assert_return(client, -EINVAL);
 assert_return(client-state == DHCP6_STATE_STOPPED, -EBUSY);
 
@@ -304,15 +315,15 @@ static int client_send_message(sd_dhcp6_client *client, 
usec_t time_now) {
 r = dhcp6_option_append(opt, optlen, DHCP6_OPTION_ORO,
 client-req_opts_len * sizeof(be16_t),
 client-req_opts);
 if (r  0)
 return r;
 
 r = dhcp6_option_append(opt, optlen, DHCP6_OPTION_CLIENTID,
-sizeof(client-duid), client-duid);
+client-duid_len, client-duid);
 if (r  0)
 return r;
 
 elapsed_usec = time_now - client-transaction_start;
 if (elapsed_usec  0x * USEC_PER_MSEC * 10)
 elapsed_time = htobe16(elapsed_usec / USEC_PER_MSEC / 10);
 else
@@ -612,15 +623,15 @@ static int client_parse_message(sd_dhcp6_client *client,
 case DHCP6_OPTION_CLIENTID:
 if (clientid) {
 log_dhcp6_client(client, %s contains multiple 
clientids,
  
dhcp6_message_type_to_string(message-type));
 return -EINVAL;
 }
 
-if (optlen != sizeof(client-duid) ||
+if (optlen != client-duid_len ||
 memcmp(client-duid, optval, optlen) != 0) {
 log_dhcp6_client(client, %s DUID does not 
match,
  
dhcp6_message_type_to_string(message-type));
 
 return -EINVAL;
 }
 clientid = true;
@@ -1112,17 +1123,24 @@ sd_dhcp6_client *sd_dhcp6_client_unref(sd_dhcp6_client 
*client) {
 
 return NULL;
 }
 
 return client;
 }
 
+struct duid_en {
+uint16_t type; /* DHCP6_DUID_EN */
+uint32_t pen;
+uint8_t id[8];
+} _packed_;
+
 int sd_dhcp6_client_new(sd_dhcp6_client **ret)
 {
 _cleanup_dhcp6_client_unref_ sd_dhcp6_client *client = NULL;
+struct duid_en *duid;
 sd_id128_t machine_id;
 int r;
 size_t t;
 
 assert_return(ret, -EINVAL);
 
 client = new0(sd_dhcp6_client, 1);
@@ -1134,25 +1152,26 @@ int sd_dhcp6_client_new(sd_dhcp6_client **ret)
 client-ia_na.type = DHCP6_OPTION_IA_NA;
 
 

[systemd-devel] [PATCH] sd-dhcp-client: support non-Ethernet hardware addresses

[Dan Williams]

Like Infiniband.  See RFC 4390 section 2.1 for details on DHCP
and Infiniband; chaddr is zeroed, hlen is set to 0, and htype
is set to ARPHRD_INFINIBAND because IB hardware addresses
are 20 bytes in length.
---
 src/libsystemd-network/dhcp-internal.h| 10 +++--
 src/libsystemd-network/dhcp-network.c | 54 -
 src/libsystemd-network/dhcp-packet.c  |  8 ++--
 src/libsystemd-network/sd-dhcp-client.c   | 66 +++
 src/libsystemd-network/sd-dhcp-server.c   |  8 ++--
 src/libsystemd-network/test-dhcp-client.c | 14 +--
 src/libsystemd-network/test-dhcp-option.c |  2 +-
 src/network/networkd-dhcp4.c  |  4 +-
 src/network/networkd-link.c   |  4 +-
 src/systemd/sd-dhcp-client.h  |  4 +-
 10 files changed, 130 insertions(+), 44 deletions(-)

*** Testing appreciated

diff --git a/src/libsystemd-network/dhcp-internal.h 
b/src/libsystemd-network/dhcp-internal.h
index 1069c8a..d358a49 100644
--- a/src/libsystemd-network/dhcp-internal.h
+++ b/src/libsystemd-network/dhcp-internal.h
@@ -20,22 +20,25 @@
 
   You should have received a copy of the GNU Lesser General Public License
   along with systemd; If not, see http://www.gnu.org/licenses/.
 ***/
 
 #include stdint.h
 #include linux/if_packet.h
+#include net/if_arp.h
 #include net/ethernet.h
 
 #include socket-util.h
 
 #include sd-dhcp-client.h
 #include dhcp-protocol.h
 
-int dhcp_network_bind_raw_socket(int index, union sockaddr_union *link, 
uint32_t xid, struct ether_addr mac_addr);
+int dhcp_network_bind_raw_socket(int index, union sockaddr_union *link,
+ uint32_t xid, const uint8_t *mac_addr,
+ size_t mac_addr_len, uint16_t arp_type);
 int dhcp_network_bind_udp_socket(be32_t address, uint16_t port);
 int dhcp_network_send_raw_socket(int s, const union sockaddr_union *link,
  const void *packet, size_t len);
 int dhcp_network_send_udp_socket(int s, be32_t address, uint16_t port,
  const void *packet, size_t len);
 
 int dhcp_option_append(DHCPMessage *message, size_t size, size_t *offset, 
uint8_t overload,
@@ -43,16 +46,17 @@ int dhcp_option_append(DHCPMessage *message, size_t size, 
size_t *offset, uint8_
 
 typedef int (*dhcp_option_cb_t)(uint8_t code, uint8_t len,
 const uint8_t *option, void *user_data);
 
 int dhcp_option_parse(DHCPMessage *message, size_t len,
   dhcp_option_cb_t cb, void *user_data);
 
-int dhcp_message_init(DHCPMessage *message, uint8_t op, uint32_t xid, uint8_t 
type,
-  size_t optlen, size_t *optoffset);
+int dhcp_message_init(DHCPMessage *message, uint8_t op, uint32_t xid,
+  uint8_t type, uint16_t arp_type, size_t optlen,
+  size_t *optoffset);
 
 uint16_t dhcp_packet_checksum(uint8_t *buf, size_t len);
 
 void dhcp_packet_append_ip_headers(DHCPPacket *packet, be32_t source_addr,
uint16_t source, be32_t destination_addr,
uint16_t destination, uint16_t len);
 
diff --git a/src/libsystemd-network/dhcp-network.c 
b/src/libsystemd-network/dhcp-network.c
index 1ced5cf..29e9993 100644
--- a/src/libsystemd-network/dhcp-network.c
+++ b/src/libsystemd-network/dhcp-network.c
@@ -18,27 +18,31 @@
 ***/
 
 #include errno.h
 #include sys/types.h
 #include sys/socket.h
 #include string.h
 #include linux/if_packet.h
+#include linux/if_infiniband.h
 #include net/ethernet.h
 #include net/if_arp.h
 #include stdio.h
 #include unistd.h
 #include linux/filter.h
 
 #include socket-util.h
 
 #include dhcp-internal.h
 
-int dhcp_network_bind_raw_socket(int ifindex, union sockaddr_union *link,
- uint32_t xid, struct ether_addr mac_addr) {
-
+static int _bind_raw_socket(int ifindex, union sockaddr_union *link,
+uint32_t xid, const uint8_t *mac_addr,
+size_t mac_addr_len,
+const uint8_t *bcast_addr,
+const struct ether_addr *eth_mac,
+uint16_t arp_type, uint8_t dhcp_hlen) {
 struct sock_filter filter[] = {
 BPF_STMT(BPF_LD + BPF_W + BPF_LEN, 0), 
/* A - packet length */
 BPF_JUMP(BPF_JMP + BPF_JGE + BPF_K, sizeof(DHCPPacket), 1, 0), 
/* packet = DHCPPacket ? */
 BPF_STMT(BPF_RET + BPF_K, 0),  
/* ignore */
 BPF_STMT(BPF_LD + BPF_B + BPF_ABS, offsetof(DHCPPacket, 
ip.protocol)), /* A - IP protocol */
 BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, IPPROTO_UDP, 1, 0),
/* IP protocol == UDP ? */
 BPF_STMT(BPF_RET + BPF_K, 0),  
/* ignore */
@@ -53,29 +57,29 @@ int 

Re: [systemd-devel] Networkd dhcp hostname override

[Dan Williams]

On Wed, 2014-08-13 at 18:55 -0700, Marcel Holtmann wrote:
 Hi Lennart,
 
  Now that networkd can send the systems hostname to the dhcp server, I 
  would find it useful to have an option to override the hostname that gets 
  sent.
  
  In my use case, I would like to setup a number of macvlans with different 
  hostnames.
  
  Something as simple as
  
  [DHCP]
  SendHostname=true
  Hostname=foo
  
  Sounds useful, though this could just be a single option
  SendHostname=foobar or so. If not set it sends the system hostname,
  otherwise the specified hostname. Or something like that.
 
 what would this be useful for? Either you send the hostname or you don't.
 
 I think what you are looking for is an option to set the Client ID. And when 
 that is set, then that is used. If it not set and SendHostname=true, the 
 hostname is used as Client ID. If SendHostname=false and Client ID is not 
 send, then none of them are send.

Typically the send-hostname thing is actually used for DNS updates,
where you send the hostname to the DHCP server, which then gives you a
lease and sends the hostname + IP to the DNS server, so that your
machine is accessible via DNS automatically.  I've never heard of it
being used as a Client ID, and AFAIK the send hostname and client ID
can both be used at the same time.

Dan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Networkd dhcp hostname override

[Dan Williams]

On Thu, 2014-08-14 at 14:29 -0700, Thomas Suckow wrote:
  Typically the send-hostname thing is actually used for DNS updates,
  where you send the hostname to the DHCP server, which then gives you a
  lease and sends the hostname + IP to the DNS server, so that your
  machine is accessible via DNS automatically.  I've never heard of it
  being used as a Client ID, and AFAIK the send hostname and client ID
  can both be used at the same time.
 Yes. In my network the Host Name dhcp option is used to configure dns. I am 
 attempting to use a single machine to operate several instances of the same 
 server. Therefore I need to bind each server to a unique IP. Currently I use 
 macvlan and dhcpcd to have the dns entries created.
 
 
  this means that allowing to provide a custom hostname that is not set via 
  hostname or hostnamectl makes no sense at all.
 
 I will agree that conventionally in the linux world the hostname is for the 
 system itself and not per interface.
 I suppose it needs to be decided whether it is tolerable for this convention 
 to be bent in networkd. Bridged virtual machines effectively do the same 
 thing, but one could argue it isn't really the same machine.
 
  Since you want to send your actual hostname.
 
 In this case I don't, I want to specify a custom host name for dhcp on a 
 specific interface.
 
  So current boolean for SendHostname is the right way to do this. In 
  addition someone might add a ClientId=foo option.
 
 I am not very familiar with the Client ID. It appears to only be useful to 
 change if you wanted multiple dhcp leases with the same hardware address, 
 which I have avoided with macvlans.

It's used as a general identifier of the client in any situation, so
that the server can pass back specific options.  Yes, this can be done
by looking at the client MAC address, but that's not sufficient in the
following cases:

1) non-Ethernet hardware addresses
2) dual-stack clients using DHCPv4 and DHCPv6
3) you change the NIC and want the same options
4) the NIC doesn't have a permanent MAC address

The client ID (and on the DHCPv6 side, the DUID) is the
single-identifier solution that should really be used instead of the MAC
address.

Dan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC PATCH] sd-dhcp-client: support non-Ethernet hardware addresses

[Dan Williams]

On Wed, 2014-08-06 at 11:22 -0500, Dan Williams wrote:
 Like Infiniband.  See RFC 4390 section 2.1 for details on DHCP
 and Infiniband; chaddr is zeroed, hlen is set to 0, and htype
 is set to ARPHRD_INFINIBAND because IB hardware addresses
 are 20 bytes in length.
 ---
 NOTE: because of how dhcp_network_bind_raw_socket() does its packet
 filter, it's not easy to change some of the checks it uses without
 having callers pass the actual values into the function, which seems
 redundant.  Thus I opted for the current approach, but that does
 add a warning about mixed declarations and code.  Can anyone think
 of a better way to do this?
 
 An possible improvement to sd_dhcp_client_set_mac() would be
 keying the MAC address length off 'arp_type' instead of
 specifying it explicitly.

Any comments on this approach Tom?  (or anyone else?)

Dan

  src/libsystemd-network/dhcp-internal.h| 10 +++--
  src/libsystemd-network/dhcp-network.c | 39 +++
  src/libsystemd-network/dhcp-packet.c  |  8 ++--
  src/libsystemd-network/sd-dhcp-client.c   | 63 
 +++
  src/libsystemd-network/sd-dhcp-server.c   |  6 +--
  src/libsystemd-network/test-dhcp-client.c | 14 +--
  src/libsystemd-network/test-dhcp-option.c |  2 +-
  src/network/networkd-link.c   |  9 -
  src/systemd/sd-dhcp-client.h  |  4 +-
  9 files changed, 116 insertions(+), 39 deletions(-)
 
 diff --git a/src/libsystemd-network/dhcp-internal.h 
 b/src/libsystemd-network/dhcp-internal.h
 index 1069c8a..d358a49 100644
 --- a/src/libsystemd-network/dhcp-internal.h
 +++ b/src/libsystemd-network/dhcp-internal.h
 @@ -20,22 +20,25 @@
  
You should have received a copy of the GNU Lesser General Public License
along with systemd; If not, see http://www.gnu.org/licenses/.
  ***/
  
  #include stdint.h
  #include linux/if_packet.h
 +#include net/if_arp.h
  #include net/ethernet.h
  
  #include socket-util.h
  
  #include sd-dhcp-client.h
  #include dhcp-protocol.h
  
 -int dhcp_network_bind_raw_socket(int index, union sockaddr_union *link, 
 uint32_t xid, struct ether_addr mac_addr);
 +int dhcp_network_bind_raw_socket(int index, union sockaddr_union *link,
 + uint32_t xid, const uint8_t *mac_addr,
 + size_t mac_addr_len, uint16_t arp_type);
  int dhcp_network_bind_udp_socket(be32_t address, uint16_t port);
  int dhcp_network_send_raw_socket(int s, const union sockaddr_union *link,
   const void *packet, size_t len);
  int dhcp_network_send_udp_socket(int s, be32_t address, uint16_t port,
   const void *packet, size_t len);
  
  int dhcp_option_append(DHCPMessage *message, size_t size, size_t *offset, 
 uint8_t overload,
 @@ -43,16 +46,17 @@ int dhcp_option_append(DHCPMessage *message, size_t size, 
 size_t *offset, uint8_
  
  typedef int (*dhcp_option_cb_t)(uint8_t code, uint8_t len,
  const uint8_t *option, void *user_data);
  
  int dhcp_option_parse(DHCPMessage *message, size_t len,
dhcp_option_cb_t cb, void *user_data);
  
 -int dhcp_message_init(DHCPMessage *message, uint8_t op, uint32_t xid, 
 uint8_t type,
 -  size_t optlen, size_t *optoffset);
 +int dhcp_message_init(DHCPMessage *message, uint8_t op, uint32_t xid,
 +  uint8_t type, uint16_t arp_type, size_t optlen,
 +  size_t *optoffset);
  
  uint16_t dhcp_packet_checksum(uint8_t *buf, size_t len);
  
  void dhcp_packet_append_ip_headers(DHCPPacket *packet, be32_t source_addr,
 uint16_t source, be32_t destination_addr,
 uint16_t destination, uint16_t len);
  
 diff --git a/src/libsystemd-network/dhcp-network.c 
 b/src/libsystemd-network/dhcp-network.c
 index 1ced5cf..4d82bcf 100644
 --- a/src/libsystemd-network/dhcp-network.c
 +++ b/src/libsystemd-network/dhcp-network.c
 @@ -18,26 +18,45 @@
  ***/
  
  #include errno.h
  #include sys/types.h
  #include sys/socket.h
  #include string.h
  #include linux/if_packet.h
 +#include linux/if_infiniband.h
  #include net/ethernet.h
  #include net/if_arp.h
  #include stdio.h
  #include unistd.h
  #include linux/filter.h
  
  #include socket-util.h
  
  #include dhcp-internal.h
  
 +/* Default broadcast address for IPoIB */
 +static const uint8_t ib_bcast_addr[20] = {
 +0x00, 0xff, 0xff, 0xff, 0xff, 0x12, 0x40, 0x1b,
 +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
 +0xff, 0xff, 0xff, 0xff
 +};
 +
  int dhcp_network_bind_raw_socket(int ifindex, union sockaddr_union *link,
 - uint32_t xid, struct ether_addr mac_addr) {
 + uint32_t xid, const uint8_t *mac_addr,
 + size_t mac_addr_len, uint16_t arp_type) {
 +struct ether_addr eth_mac = { { 0, 0, 0, 0, 0, 0

Re: [systemd-devel] [PATCH] sd-dhcp6-client: support custom DUIDs

[Dan Williams]

On Tue, 2014-08-12 at 01:12 +0200, Tom Gundersen wrote:
 On Wed, Aug 6, 2014 at 6:17 PM, Dan Williams d...@redhat.com wrote:
  The caller may have an existing DUID that it wants to use, and may
  want to use some other DUID generation scheme than systemd's
  default DUID-EN.
 
 I have no objections a priori to this patch. But what is the use case?
 Is there some DUID scheme that is preferable to DUID-EN that we could
 simply use unconditionally, or do you really depend on the possibility
 of customizing it?

The DUID is like the v4 Client ID; it's the way to identify a specific
client so that you hand out specific options.  There may also be
installations that have existing configuration where the DUID is already
specified, and when changing the DHCP client suddenly everything would
get renumbered.  If you replace a machine with another machine, perhaps
you don't want to use whatever new DUID systemd would generate with
DUID-EN, but you want to use the old DUID.  I'm reluctant to just
mandate a specific DUID scheme mostly for the configuration reasons
above, but also because there are at least 4 DUID RFCs and it's not
clear to me which one is really better.

Dan

  ---
   src/libsystemd-network/sd-dhcp6-client.c   | 52 
  +++---
   src/libsystemd-network/test-dhcp6-client.c |  4 +--
   src/network/networkd-link.c|  2 +-
   src/systemd/sd-dhcp6-client.h  |  2 +-
   4 files changed, 38 insertions(+), 22 deletions(-)
 
  diff --git a/src/libsystemd-network/sd-dhcp6-client.c 
  b/src/libsystemd-network/sd-dhcp6-client.c
  index c6c82eb..8123dc8 100644
  --- a/src/libsystemd-network/sd-dhcp6-client.c
  +++ b/src/libsystemd-network/sd-dhcp6-client.c
  @@ -35,14 +35,16 @@
   #include dhcp6-protocol.h
   #include dhcp6-internal.h
   #include dhcp6-lease-internal.h
 
   #define SYSTEMD_PEN 43793
   #define HASH_KEY 
  SD_ID128_MAKE(80,11,8c,c2,fe,4a,03,ee,3e,d6,0c,6f,36,39,14,09)
 
  +#define MAX_DUID_LEN 32
  +
   struct sd_dhcp6_client {
   RefCount n_ref;
 
   enum DHCP6State state;
   sd_event *event;
   int event_priority;
   int index;
  @@ -57,20 +59,16 @@ struct sd_dhcp6_client {
   sd_event_source *receive_message;
   usec_t retransmit_time;
   uint8_t retransmit_count;
   sd_event_source *timeout_resend;
   sd_event_source *timeout_resend_expire;
   sd_dhcp6_client_cb_t cb;
   void *userdata;
  -
  -struct duid_en {
  -uint16_t type; /* DHCP6_DUID_EN */
  -uint32_t pen;
  -uint8_t id[8];
  -} _packed_ duid;
  +uint8_t duid[MAX_DUID_LEN];
  +size_t duid_len;
   };
 
   static const uint16_t default_req_opts[] = {
   DHCP6_OPTION_DNS_SERVERS,
   DHCP6_OPTION_DOMAIN_LIST,
   DHCP6_OPTION_NTP_SERVER,
   };
  @@ -300,15 +298,15 @@ static int client_send_message(sd_dhcp6_client 
  *client) {
   r = dhcp6_option_append(opt, optlen, DHCP6_OPTION_ORO,
   client-req_opts_len * sizeof(be16_t),
   client-req_opts);
   if (r  0)
   return r;
 
   r = dhcp6_option_append(opt, optlen, DHCP6_OPTION_CLIENTID,
  -sizeof(client-duid), client-duid);
  +client-duid_len, client-duid);
   if (r  0)
   return r;
 
   r = dhcp6_network_send_udp_socket(client-fd, all_servers, 
  message,
 len - optlen);
   if (r  0)
   return r;
  @@ -585,15 +583,15 @@ static int client_parse_message(sd_dhcp6_client 
  *client,
   case DHCP6_OPTION_CLIENTID:
   if (clientid) {
   log_dhcp6_client(client, %s contains 
  multiple clientids,

  dhcp6_message_type_to_string(message-type));
   return -EINVAL;
   }
 
  -if (optlen != sizeof(client-duid) ||
  +if (optlen != client-duid_len ||
   memcmp(client-duid, optval, optlen) != 0) {
   log_dhcp6_client(client, %s DUID does not 
  match,

  dhcp6_message_type_to_string(message-type));
 
   return -EINVAL;
   }
   clientid = true;
  @@ -1059,47 +1057,65 @@ sd_dhcp6_client 
  *sd_dhcp6_client_unref(sd_dhcp6_client *client) {
 
   return NULL;
   }
 
   return client;
   }
 
  -int sd_dhcp6_client_new(sd_dhcp6_client **ret)
  +struct duid_en {
  +uint16_t type; /* DHCP6_DUID_EN */
  +uint32_t pen;
  +uint8_t id[8

[systemd-devel] [PATCH] sd-dhcp6-client: support custom DUIDs

[Dan Williams]

The caller may have an existing DUID that it wants to use, and may
want to use some other DUID generation scheme than systemd's
default DUID-EN.
---
 src/libsystemd-network/sd-dhcp6-client.c   | 52 +++---
 src/libsystemd-network/test-dhcp6-client.c |  4 +--
 src/network/networkd-link.c|  2 +-
 src/systemd/sd-dhcp6-client.h  |  2 +-
 4 files changed, 38 insertions(+), 22 deletions(-)

diff --git a/src/libsystemd-network/sd-dhcp6-client.c 
b/src/libsystemd-network/sd-dhcp6-client.c
index c6c82eb..8123dc8 100644
--- a/src/libsystemd-network/sd-dhcp6-client.c
+++ b/src/libsystemd-network/sd-dhcp6-client.c
@@ -35,14 +35,16 @@
 #include dhcp6-protocol.h
 #include dhcp6-internal.h
 #include dhcp6-lease-internal.h
 
 #define SYSTEMD_PEN 43793
 #define HASH_KEY SD_ID128_MAKE(80,11,8c,c2,fe,4a,03,ee,3e,d6,0c,6f,36,39,14,09)
 
+#define MAX_DUID_LEN 32
+
 struct sd_dhcp6_client {
 RefCount n_ref;
 
 enum DHCP6State state;
 sd_event *event;
 int event_priority;
 int index;
@@ -57,20 +59,16 @@ struct sd_dhcp6_client {
 sd_event_source *receive_message;
 usec_t retransmit_time;
 uint8_t retransmit_count;
 sd_event_source *timeout_resend;
 sd_event_source *timeout_resend_expire;
 sd_dhcp6_client_cb_t cb;
 void *userdata;
-
-struct duid_en {
-uint16_t type; /* DHCP6_DUID_EN */
-uint32_t pen;
-uint8_t id[8];
-} _packed_ duid;
+uint8_t duid[MAX_DUID_LEN];
+size_t duid_len;
 };
 
 static const uint16_t default_req_opts[] = {
 DHCP6_OPTION_DNS_SERVERS,
 DHCP6_OPTION_DOMAIN_LIST,
 DHCP6_OPTION_NTP_SERVER,
 };
@@ -300,15 +298,15 @@ static int client_send_message(sd_dhcp6_client *client) {
 r = dhcp6_option_append(opt, optlen, DHCP6_OPTION_ORO,
 client-req_opts_len * sizeof(be16_t),
 client-req_opts);
 if (r  0)
 return r;
 
 r = dhcp6_option_append(opt, optlen, DHCP6_OPTION_CLIENTID,
-sizeof(client-duid), client-duid);
+client-duid_len, client-duid);
 if (r  0)
 return r;
 
 r = dhcp6_network_send_udp_socket(client-fd, all_servers, message,
   len - optlen);
 if (r  0)
 return r;
@@ -585,15 +583,15 @@ static int client_parse_message(sd_dhcp6_client *client,
 case DHCP6_OPTION_CLIENTID:
 if (clientid) {
 log_dhcp6_client(client, %s contains multiple 
clientids,
  
dhcp6_message_type_to_string(message-type));
 return -EINVAL;
 }
 
-if (optlen != sizeof(client-duid) ||
+if (optlen != client-duid_len ||
 memcmp(client-duid, optval, optlen) != 0) {
 log_dhcp6_client(client, %s DUID does not 
match,
  
dhcp6_message_type_to_string(message-type));
 
 return -EINVAL;
 }
 clientid = true;
@@ -1059,47 +1057,65 @@ sd_dhcp6_client *sd_dhcp6_client_unref(sd_dhcp6_client 
*client) {
 
 return NULL;
 }
 
 return client;
 }
 
-int sd_dhcp6_client_new(sd_dhcp6_client **ret)
+struct duid_en {
+uint16_t type; /* DHCP6_DUID_EN */
+uint32_t pen;
+uint8_t id[8];
+} _packed_;
+
+int sd_dhcp6_client_new(sd_dhcp6_client **ret, uint8_t *duid, size_t duid_len)
 {
 _cleanup_dhcp6_client_unref_ sd_dhcp6_client *client = NULL;
 sd_id128_t machine_id;
 int r;
 size_t t;
 
 assert_return(ret, -EINVAL);
+if (duid)
+assert_return(duid_len  0  duid_len  MAX_DUID_LEN, 
-EINVAL);
+else
+assert_return(duid_len == 0, -EINVAL);
 
 client = new0(sd_dhcp6_client, 1);
 if (!client)
 return -ENOMEM;
 
 client-n_ref = REFCNT_INIT;
 
 client-ia_na.type = DHCP6_OPTION_IA_NA;
 
 client-index = -1;
 
 client-fd = -1;
 
 /* initialize DUID */
-client-duid.type = htobe16(DHCP6_DUID_EN);
-client-duid.pen = htobe32(SYSTEMD_PEN);
+if (duid) {
+memcpy(client-duid, duid, duid_len);
+client-duid_len = duid_len;
+} else {
+struct duid_en *en = (struct duid_en *) client-duid;
 
-r = sd_id128_get_machine(machine_id);
-if (r  0)
-return r;
+en-type = htobe16(DHCP6_DUID_EN);
+en-pen = htobe32(SYSTEMD_PEN);
 
-/* a bit 

[systemd-devel] [RFC PATCH] sd-dhcp-client: support non-Ethernet hardware addresses

[Dan Williams]

Like Infiniband.  See RFC 4390 section 2.1 for details on DHCP
and Infiniband; chaddr is zeroed, hlen is set to 0, and htype
is set to ARPHRD_INFINIBAND because IB hardware addresses
are 20 bytes in length.
---
NOTE: because of how dhcp_network_bind_raw_socket() does its packet
filter, it's not easy to change some of the checks it uses without
having callers pass the actual values into the function, which seems
redundant.  Thus I opted for the current approach, but that does
add a warning about mixed declarations and code.  Can anyone think
of a better way to do this?

An possible improvement to sd_dhcp_client_set_mac() would be
keying the MAC address length off 'arp_type' instead of
specifying it explicitly.

 src/libsystemd-network/dhcp-internal.h| 10 +++--
 src/libsystemd-network/dhcp-network.c | 39 +++
 src/libsystemd-network/dhcp-packet.c  |  8 ++--
 src/libsystemd-network/sd-dhcp-client.c   | 63 +++
 src/libsystemd-network/sd-dhcp-server.c   |  6 +--
 src/libsystemd-network/test-dhcp-client.c | 14 +--
 src/libsystemd-network/test-dhcp-option.c |  2 +-
 src/network/networkd-link.c   |  9 -
 src/systemd/sd-dhcp-client.h  |  4 +-
 9 files changed, 116 insertions(+), 39 deletions(-)

diff --git a/src/libsystemd-network/dhcp-internal.h 
b/src/libsystemd-network/dhcp-internal.h
index 1069c8a..d358a49 100644
--- a/src/libsystemd-network/dhcp-internal.h
+++ b/src/libsystemd-network/dhcp-internal.h
@@ -20,22 +20,25 @@
 
   You should have received a copy of the GNU Lesser General Public License
   along with systemd; If not, see http://www.gnu.org/licenses/.
 ***/
 
 #include stdint.h
 #include linux/if_packet.h
+#include net/if_arp.h
 #include net/ethernet.h
 
 #include socket-util.h
 
 #include sd-dhcp-client.h
 #include dhcp-protocol.h
 
-int dhcp_network_bind_raw_socket(int index, union sockaddr_union *link, 
uint32_t xid, struct ether_addr mac_addr);
+int dhcp_network_bind_raw_socket(int index, union sockaddr_union *link,
+ uint32_t xid, const uint8_t *mac_addr,
+ size_t mac_addr_len, uint16_t arp_type);
 int dhcp_network_bind_udp_socket(be32_t address, uint16_t port);
 int dhcp_network_send_raw_socket(int s, const union sockaddr_union *link,
  const void *packet, size_t len);
 int dhcp_network_send_udp_socket(int s, be32_t address, uint16_t port,
  const void *packet, size_t len);
 
 int dhcp_option_append(DHCPMessage *message, size_t size, size_t *offset, 
uint8_t overload,
@@ -43,16 +46,17 @@ int dhcp_option_append(DHCPMessage *message, size_t size, 
size_t *offset, uint8_
 
 typedef int (*dhcp_option_cb_t)(uint8_t code, uint8_t len,
 const uint8_t *option, void *user_data);
 
 int dhcp_option_parse(DHCPMessage *message, size_t len,
   dhcp_option_cb_t cb, void *user_data);
 
-int dhcp_message_init(DHCPMessage *message, uint8_t op, uint32_t xid, uint8_t 
type,
-  size_t optlen, size_t *optoffset);
+int dhcp_message_init(DHCPMessage *message, uint8_t op, uint32_t xid,
+  uint8_t type, uint16_t arp_type, size_t optlen,
+  size_t *optoffset);
 
 uint16_t dhcp_packet_checksum(uint8_t *buf, size_t len);
 
 void dhcp_packet_append_ip_headers(DHCPPacket *packet, be32_t source_addr,
uint16_t source, be32_t destination_addr,
uint16_t destination, uint16_t len);
 
diff --git a/src/libsystemd-network/dhcp-network.c 
b/src/libsystemd-network/dhcp-network.c
index 1ced5cf..4d82bcf 100644
--- a/src/libsystemd-network/dhcp-network.c
+++ b/src/libsystemd-network/dhcp-network.c
@@ -18,26 +18,45 @@
 ***/
 
 #include errno.h
 #include sys/types.h
 #include sys/socket.h
 #include string.h
 #include linux/if_packet.h
+#include linux/if_infiniband.h
 #include net/ethernet.h
 #include net/if_arp.h
 #include stdio.h
 #include unistd.h
 #include linux/filter.h
 
 #include socket-util.h
 
 #include dhcp-internal.h
 
+/* Default broadcast address for IPoIB */
+static const uint8_t ib_bcast_addr[20] = {
+0x00, 0xff, 0xff, 0xff, 0xff, 0x12, 0x40, 0x1b,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0xff, 0xff, 0xff, 0xff
+};
+
 int dhcp_network_bind_raw_socket(int ifindex, union sockaddr_union *link,
- uint32_t xid, struct ether_addr mac_addr) {
+ uint32_t xid, const uint8_t *mac_addr,
+ size_t mac_addr_len, uint16_t arp_type) {
+struct ether_addr eth_mac = { { 0, 0, 0, 0, 0, 0 } };
+uint8_t dhcp_hlen = 0;
+
+assert_return(mac_addr_len  0, -EINVAL);
+
+if (arp_type == ARPHRD_ETHER) {
+assert_return(mac_addr_len == ETH_ALEN, -EINVAL);
+memcpy(eth_mac, 

[systemd-devel] [PATCH] networkd: set route protocol

[Dan Williams]

All routes added by networkd are currently set RTPROT_BOOT, which according
to the kernel means Route installed during boot (rtnetlink.h).  But this
is not always the case as networkd changes routing after boot too.  Since
the kernel gives more detailed protocols, use them.

With this patch, user-configured static routes now use RTPROT_STATIC (which
they are) and DHCP routes use RTPROT_DHCP.  There is no define for IPv4LL
yet, so those are installed as RTPROT_STATIC (though perhaps RTPROT_RA is
better?).

Signed-off-by: Dan Williams d...@redhat.com
---
 src/libsystemd/sd-rtnl/rtnl-message.c |  5 +++--
 src/libsystemd/sd-rtnl/test-rtnl.c|  2 +-
 src/network/networkd-link.c   | 12 ++--
 src/network/networkd-route.c  | 10 +++---
 src/network/networkd.h|  3 ++-
 src/systemd/sd-rtnl.h |  2 +-
 6 files changed, 20 insertions(+), 14 deletions(-)

diff --git a/src/libsystemd/sd-rtnl/rtnl-message.c 
b/src/libsystemd/sd-rtnl/rtnl-message.c
index 7f2e398..c50d0ea 100644
--- a/src/libsystemd/sd-rtnl/rtnl-message.c
+++ b/src/libsystemd/sd-rtnl/rtnl-message.c
@@ -129,15 +129,16 @@ int sd_rtnl_message_route_set_scope(sd_rtnl_message *m, 
unsigned char scope) {
 
 rtm-rtm_scope = scope;
 
 return 0;
 }
 
 int sd_rtnl_message_new_route(sd_rtnl *rtnl, sd_rtnl_message **ret,
-  uint16_t nlmsg_type, int rtm_family) {
+  uint16_t nlmsg_type, int rtm_family,
+  unsigned char rtm_protocol) {
 struct rtmsg *rtm;
 int r;
 
 assert_return(rtnl_message_type_is_route(nlmsg_type), -EINVAL);
 assert_return(rtm_family == AF_INET || rtm_family == AF_INET6, 
-EINVAL);
 assert_return(ret, -EINVAL);
 
@@ -150,15 +151,15 @@ int sd_rtnl_message_new_route(sd_rtnl *rtnl, 
sd_rtnl_message **ret,
 
 rtm = NLMSG_DATA((*ret)-hdr);
 
 rtm-rtm_family = rtm_family;
 rtm-rtm_scope = RT_SCOPE_UNIVERSE;
 rtm-rtm_type = RTN_UNICAST;
 rtm-rtm_table = RT_TABLE_MAIN;
-rtm-rtm_protocol = RTPROT_BOOT;
+rtm-rtm_protocol = rtm_protocol;
 
 return 0;
 }
 
 int sd_rtnl_message_link_set_flags(sd_rtnl_message *m, unsigned flags, 
unsigned change) {
 struct ifinfomsg *ifi;
 
diff --git a/src/libsystemd/sd-rtnl/test-rtnl.c 
b/src/libsystemd/sd-rtnl/test-rtnl.c
index 082c9e4..4b6e533 100644
--- a/src/libsystemd/sd-rtnl/test-rtnl.c
+++ b/src/libsystemd/sd-rtnl/test-rtnl.c
@@ -128,15 +128,15 @@ static void test_address_get(sd_rtnl *rtnl, int ifindex) {
 
 static void test_route(void) {
 _cleanup_rtnl_message_unref_ sd_rtnl_message *req;
 struct in_addr addr, addr_data;
 uint32_t index = 2, u32_data;
 int r;
 
-r = sd_rtnl_message_new_route(NULL, req, RTM_NEWROUTE, AF_INET);
+r = sd_rtnl_message_new_route(NULL, req, RTM_NEWROUTE, AF_INET, 
RTPROT_STATIC);
 if (r  0) {
 log_error(Could not create RTM_NEWROUTE message: %s, 
strerror(-r));
 return;
 }
 
 addr.s_addr = htonl(INADDR_LOOPBACK);
 
diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
index 0a6f524..b9c3902 100644
--- a/src/network/networkd-link.c
+++ b/src/network/networkd-link.c
@@ -477,15 +477,15 @@ static int link_enter_set_routes(Link *link) {
 if (r  0  r != -ENOENT) {
 log_warning_link(link, IPV4LL error: no address: %s,
 strerror(-r));
 return r;
 }
 
 if (r != -ENOENT) {
-r = route_new_dynamic(route);
+r = route_new_dynamic(route, RTPROT_STATIC);
 if (r  0) {
 log_error_link(link, Could not allocate 
route: %s,
strerror(-r));
 return r;
 }
 
 route-family = AF_INET;
@@ -513,22 +513,22 @@ static int link_enter_set_routes(Link *link) {
 if (r  0  r != -ENOENT) {
 log_warning_link(link, DHCP error: could not get 
gateway: %s,
  strerror(-r));
 return r;
 }
 
 if (r = 0) {
-r = route_new_dynamic(route);
+r = route_new_dynamic(route, RTPROT_DHCP);
 if (r  0) {
 log_error_link(link, Could not allocate 
route: %s,
strerror(-r));
 return r;
 }
 
-r = route_new_dynamic(route_gw);
+r = route_new_dynamic(route_gw, RTPROT_DHCP);
 if (r  0

[systemd-devel] [PATCH v2] networkd: set route protocol

[Dan Williams]

All routes added by networkd are currently set RTPROT_BOOT, which according
to the kernel means Route installed during boot (rtnetlink.h).  But this
is not always the case as networkd changes routing after boot too.  Since
the kernel gives more detailed protocols, use them.

With this patch, user-configured static routes now use RTPROT_STATIC (which
they are) and DHCP routes use RTPROT_DHCP.  There is no define for IPv4LL
yet, so those are installed as RTPROT_STATIC (though perhaps RTPROT_RA is
better?).

Signed-off-by: Dan Williams d...@redhat.com
---
v2: rebase missed one case of RTPROT_DHCP; now fixed

 src/libsystemd/sd-rtnl/rtnl-message.c |  5 +++--
 src/libsystemd/sd-rtnl/test-rtnl.c|  2 +-
 src/network/networkd-link.c   | 14 +++---
 src/network/networkd-route.c  | 10 +++---
 src/network/networkd.h|  3 ++-
 src/systemd/sd-rtnl.h |  2 +-
 6 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/src/libsystemd/sd-rtnl/rtnl-message.c 
b/src/libsystemd/sd-rtnl/rtnl-message.c
index 7f2e398..c50d0ea 100644
--- a/src/libsystemd/sd-rtnl/rtnl-message.c
+++ b/src/libsystemd/sd-rtnl/rtnl-message.c
@@ -129,15 +129,16 @@ int sd_rtnl_message_route_set_scope(sd_rtnl_message *m, 
unsigned char scope) {
 
 rtm-rtm_scope = scope;
 
 return 0;
 }
 
 int sd_rtnl_message_new_route(sd_rtnl *rtnl, sd_rtnl_message **ret,
-  uint16_t nlmsg_type, int rtm_family) {
+  uint16_t nlmsg_type, int rtm_family,
+  unsigned char rtm_protocol) {
 struct rtmsg *rtm;
 int r;
 
 assert_return(rtnl_message_type_is_route(nlmsg_type), -EINVAL);
 assert_return(rtm_family == AF_INET || rtm_family == AF_INET6, 
-EINVAL);
 assert_return(ret, -EINVAL);
 
@@ -150,15 +151,15 @@ int sd_rtnl_message_new_route(sd_rtnl *rtnl, 
sd_rtnl_message **ret,
 
 rtm = NLMSG_DATA((*ret)-hdr);
 
 rtm-rtm_family = rtm_family;
 rtm-rtm_scope = RT_SCOPE_UNIVERSE;
 rtm-rtm_type = RTN_UNICAST;
 rtm-rtm_table = RT_TABLE_MAIN;
-rtm-rtm_protocol = RTPROT_BOOT;
+rtm-rtm_protocol = rtm_protocol;
 
 return 0;
 }
 
 int sd_rtnl_message_link_set_flags(sd_rtnl_message *m, unsigned flags, 
unsigned change) {
 struct ifinfomsg *ifi;
 
diff --git a/src/libsystemd/sd-rtnl/test-rtnl.c 
b/src/libsystemd/sd-rtnl/test-rtnl.c
index 082c9e4..4b6e533 100644
--- a/src/libsystemd/sd-rtnl/test-rtnl.c
+++ b/src/libsystemd/sd-rtnl/test-rtnl.c
@@ -128,15 +128,15 @@ static void test_address_get(sd_rtnl *rtnl, int ifindex) {
 
 static void test_route(void) {
 _cleanup_rtnl_message_unref_ sd_rtnl_message *req;
 struct in_addr addr, addr_data;
 uint32_t index = 2, u32_data;
 int r;
 
-r = sd_rtnl_message_new_route(NULL, req, RTM_NEWROUTE, AF_INET);
+r = sd_rtnl_message_new_route(NULL, req, RTM_NEWROUTE, AF_INET, 
RTPROT_STATIC);
 if (r  0) {
 log_error(Could not create RTM_NEWROUTE message: %s, 
strerror(-r));
 return;
 }
 
 addr.s_addr = htonl(INADDR_LOOPBACK);
 
diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
index 0a6f524..5b70578 100644
--- a/src/network/networkd-link.c
+++ b/src/network/networkd-link.c
@@ -411,15 +411,15 @@ static int link_set_dhcp_routes(Link *link) {
 log_warning_link(link, DHCP error: could not get 
routes: %s, strerror(-n));
 return n;
 }
 
 for (i = 0; i  n; i++) {
 _cleanup_route_free_ Route *route = NULL;
 
-r = route_new_dynamic(route);
+r = route_new_dynamic(route, RTPROT_DHCP);
 if (r  0) {
 log_error_link(link, Could not allocate route: %s,
strerror(-r));
 return r;
 }
 
 route-family = AF_INET;
@@ -477,15 +477,15 @@ static int link_enter_set_routes(Link *link) {
 if (r  0  r != -ENOENT) {
 log_warning_link(link, IPV4LL error: no address: %s,
 strerror(-r));
 return r;
 }
 
 if (r != -ENOENT) {
-r = route_new_dynamic(route);
+r = route_new_dynamic(route, RTPROT_STATIC);
 if (r  0) {
 log_error_link(link, Could not allocate 
route: %s,
strerror(-r));
 return r;
 }
 
 route-family = AF_INET;
@@ -513,22 +513,22 @@ static int link_enter_set_routes(Link *link) {
 if (r  0  r != -ENOENT) {
 log_warning_link(link, DHCP error: could

[systemd-devel] [PATCH] dhcp-network: remove unused DHCP6_STATE_RS

[Dan Williams]

Probably a left-over from when router solicitations were
requested in the DHCP6 code.  But since they are now separate,
this state is no longer needed.

Signed-off-by: Dan Williams d...@redhat.com
---
 src/libsystemd-network/dhcp6-protocol.h  | 1 -
 src/libsystemd-network/sd-dhcp6-client.c | 4 
 2 files changed, 5 deletions(-)

diff --git a/src/libsystemd-network/dhcp6-protocol.h 
b/src/libsystemd-network/dhcp6-protocol.h
index e9ae598..eaa6717 100644
--- a/src/libsystemd-network/dhcp6-protocol.h
+++ b/src/libsystemd-network/dhcp6-protocol.h
@@ -67,15 +67,14 @@ enum {
 DHCP6_DUID_EN   = 2,
 DHCP6_DUID_LL   = 3,
 DHCP6_DUID_UUID = 4,
 };
 
 enum DHCP6State {
 DHCP6_STATE_STOPPED = 0,
-DHCP6_STATE_RS  = 1,
 DHCP6_STATE_SOLICITATION= 2,
 DHCP6_STATE_REQUEST = 3,
 DHCP6_STATE_BOUND   = 4,
 DHCP6_STATE_RENEW   = 5,
 DHCP6_STATE_REBIND  = 6,
 };
 
diff --git a/src/libsystemd-network/sd-dhcp6-client.c 
b/src/libsystemd-network/sd-dhcp6-client.c
index 4f60578..13bed67 100644
--- a/src/libsystemd-network/sd-dhcp6-client.c
+++ b/src/libsystemd-network/sd-dhcp6-client.c
@@ -289,15 +289,14 @@ static int client_send_message(sd_dhcp6_client *client) {
 r = dhcp6_option_append_ia(opt, optlen, client-lease-ia);
 if (r  0)
 return r;
 
 break;
 
 case DHCP6_STATE_STOPPED:
-case DHCP6_STATE_RS:
 case DHCP6_STATE_BOUND:
 return -EINVAL;
 }
 
 r = dhcp6_option_append(opt, optlen, DHCP6_OPTION_ORO,
 client-req_opts_len * sizeof(be16_t),
 client-req_opts);
@@ -442,15 +441,14 @@ static int client_timeout_resend(sd_event_source *s, 
uint64_t usec,
 }
 max_retransmit_duration = expire * USEC_PER_SEC;
 }
 
 break;
 
 case DHCP6_STATE_STOPPED:
-case DHCP6_STATE_RS:
 case DHCP6_STATE_BOUND:
 return 0;
 }
 
 if (max_retransmit_count 
 client-retransmit_count = max_retransmit_count) {
 client_stop(client, DHCP6_EVENT_RETRANS_MAX);
@@ -839,15 +837,14 @@ static int client_receive_message(sd_event_source *s, int 
fd, uint32_t revents,
 break;
 
 case DHCP6_STATE_BOUND:
 
 break;
 
 case DHCP6_STATE_STOPPED:
-case DHCP6_STATE_RS:
 return 0;
 }
 
 if (r = 0) {
 log_dhcp6_client(client, Recv %s,
  dhcp6_message_type_to_string(message-type));
 }
@@ -870,15 +867,14 @@ static int client_start(sd_dhcp6_client *client, enum 
DHCP6State state)
 sd_event_source_unref(client-timeout_resend_expire);
 client-timeout_resend = sd_event_source_unref(client-timeout_resend);
 client-retransmit_time = 0;
 client-retransmit_count = 0;
 
 switch (state) {
 case DHCP6_STATE_STOPPED:
-case DHCP6_STATE_RS:
 case DHCP6_STATE_SOLICITATION:
 
 r = client_ensure_iaid(client);
 if (r  0)
 return r;
 
 r = dhcp6_network_bind_udp_socket(client-index, NULL);
-- 
1.9.3


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd fails to get DHCPv4 lease with disabled IPv6

[Dan Williams]

On Tue, 2014-07-15 at 17:17 +0200, Lennart Poettering wrote:
 On Mon, 14.07.14 15:38, Dan Williams (d...@redhat.com) wrote:
 
  But that brings up another question; I don't think systemd-networkd is
  currently capable of ensuring a machine is completely configured when RA
  is enabled, because it doesn't handle RDNSS and DNSSD options from the
  RA response.  The kernel can't handle those, because those require
  writing to /etc/resolv.conf (or a caching nameserver), which the kernel
  obviously doesn't do.  But neither does systemd-networkd.
 
 systemd-resolved subscribes to networkd state and writes out those
 files. It's simply a matter of making networkd pass the RDNSS/DNSSL
 records to resolved, too.

Will resolved grow an interface that other services can use to push that
information down to it, in addition to the existing approach of
listening to networkd events in /run/systemd/netif and then parsing
systemd network config/lease files?

Dan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd fails to get DHCPv4 lease with disabled IPv6

[Dan Williams]

On Mon, 2014-07-14 at 11:06 -0700, David Timothy Strauss wrote:
 On Sun, Jul 6, 2014 at 3:32 PM, Tom Gundersen t...@jklm.no wrote:
  yes is a synonym for both and no for none.
 
 These are odd semantics, given that IPv6 is completely configurable
 using router advertisements for even DNS information (that is, no DHCP
 whatsoever). Perhaps the option should be Autoconfig= with options for
 DHCPv4, DHCPv6, and RA and yes meaning all?

Except that systemd-networkd doesn't do anything with RA at all, other
than soliciting an RA to see if DHCPv6 is requested by the router.  The
kernel handles all the RA processing, address assignment, and route
assignment.  So having an Autoconfig option for RA wouldn't make any
sense unless systemd somehow grew the capability to turn off kernel RA
handling.

But that brings up another question; I don't think systemd-networkd is
currently capable of ensuring a machine is completely configured when RA
is enabled, because it doesn't handle RDNSS and DNSSD options from the
RA response.  The kernel can't handle those, because those require
writing to /etc/resolv.conf (or a caching nameserver), which the kernel
obviously doesn't do.  But neither does systemd-networkd.

Dan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 1/2] dhcp-network: add check for DHCP.chaddr

[Dan Williams]

On Thu, 2014-06-19 at 18:59 +0200, Michal Sekletar wrote:
 Check that received DHCP packets actually include our MAC address in
 chaddr field. BPF interpreter has 32 bit wide registers but MAC address
 is 48 bits long so we have to do check in two steps.

And if the MAC address is not 48 bits (Infiniband) or the interface type
doesn't really have a MAC address (PPP/PPPoE)?  DHCP can be used in both
cases...  If anything, the code that uses the MAC address should be
if-ed so it only executes when a MAC address is provided.

Dan

 ---
  src/libsystemd-network/dhcp-internal.h|  3 ++-
  src/libsystemd-network/dhcp-network.c | 15 +--
  src/libsystemd-network/sd-dhcp-client.c   |  4 ++--
  src/libsystemd-network/test-dhcp-client.c |  2 +-
  4 files changed, 18 insertions(+), 6 deletions(-)
 
 diff --git a/src/libsystemd-network/dhcp-internal.h 
 b/src/libsystemd-network/dhcp-internal.h
 index 03cc824..fd86a70 100644
 --- a/src/libsystemd-network/dhcp-internal.h
 +++ b/src/libsystemd-network/dhcp-internal.h
 @@ -24,12 +24,13 @@
  
  #include stdint.h
  #include linux/if_packet.h
 +#include net/ethernet.h
  
  #include socket-util.h
  
  #include dhcp-protocol.h
  
 -int dhcp_network_bind_raw_socket(int index, union sockaddr_union *link, 
 uint32_t xid);
 +int dhcp_network_bind_raw_socket(int index, union sockaddr_union *link, 
 uint32_t xid, struct ether_addr mac_addr);
  int dhcp_network_bind_udp_socket(be32_t address, uint16_t port);
  int dhcp_network_send_raw_socket(int s, const union sockaddr_union *link,
   const void *packet, size_t len);
 diff --git a/src/libsystemd-network/dhcp-network.c 
 b/src/libsystemd-network/dhcp-network.c
 index d7ba0ef..e5fd6a8 100644
 --- a/src/libsystemd-network/dhcp-network.c
 +++ b/src/libsystemd-network/dhcp-network.c
 @@ -33,7 +33,7 @@
  #include dhcp-internal.h
  
  int dhcp_network_bind_raw_socket(int index, union sockaddr_union *link,
 - uint32_t xid) {
 + uint32_t xid, struct ether_addr mac_addr) {
  struct sock_filter filter[] = {
  BPF_STMT(BPF_LD + BPF_W + BPF_LEN, 0),   
   /* A - packet length */
  BPF_JUMP(BPF_JMP + BPF_JGE + BPF_K, sizeof(DHCPPacket), 1, 0),   
   /* packet = DHCPPacket ? */
 @@ -56,7 +56,18 @@ int dhcp_network_bind_raw_socket(int index, union 
 sockaddr_union *link,
  BPF_STMT(BPF_LD + BPF_W + BPF_ABS, offsetof(DHCPPacket, 
 dhcp.xid)),/* A - client identifier */
  BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, xid, 1, 0),  
   /* client identifier == xid ? */
  BPF_STMT(BPF_RET + BPF_K, 0),
   /* ignore */
 -/* TODO: match chaddr */
 +BPF_STMT(BPF_LD + BPF_IMM, htobe32(*((unsigned int *) 
 mac_addr))),/* A - 4 bytes of client's MAC */
 +BPF_STMT(BPF_MISC + BPF_TAX, 0), 
   /* X - A */
 +BPF_STMT(BPF_LD + BPF_W + BPF_ABS, offsetof(DHCPPacket, 
 dhcp.chaddr)), /* A - 4 bytes of MAC from dhcp.chaddr */
 +BPF_STMT(BPF_ALU + BPF_XOR + BPF_X, 0),  
   /* A xor X */
 +BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, 0, 1, 0),
   /* A == 0 ? */
 +BPF_STMT(BPF_RET + BPF_K, 0),
   /* ignore */
 +BPF_STMT(BPF_LD + BPF_IMM, htobe16(*((unsigned short *) (((char 
 *) mac_addr) + 4, /* A - remainder of client's MAC */
 +BPF_STMT(BPF_MISC + BPF_TAX, 0), 
   /* X - A */
 +BPF_STMT(BPF_LD + BPF_H + BPF_ABS, offsetof(DHCPPacket, 
 dhcp.chaddr) + 4), /* A - remainder of MAC from dhcp.chaddr */
 +BPF_STMT(BPF_ALU + BPF_XOR + BPF_X, 0),  
   /* A xor X */
 +BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, 0, 1, 0),
   /* A == 0 ? */
 +BPF_STMT(BPF_RET + BPF_K, 0),
   /* ignore */
  BPF_STMT(BPF_LD + BPF_W + BPF_ABS, offsetof(DHCPPacket, 
 dhcp.magic)),  /* A - DHCP magic cookie */
  BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, DHCP_MAGIC_COOKIE, 1, 0),
   /* cookie == DHCP magic cookie ? */
  BPF_STMT(BPF_RET + BPF_K, 0),
   /* ignore */
 diff --git a/src/libsystemd-network/sd-dhcp-client.c 
 b/src/libsystemd-network/sd-dhcp-client.c
 index c1af6df..d44cad2 100644
 --- a/src/libsystemd-network/sd-dhcp-client.c
 +++ b/src/libsystemd-network/sd-dhcp-client.c
 @@ -719,7 +719,7 @@ static int client_start(sd_dhcp_client *client) {
  
  client-xid = random_u32();
  
 -   

Re: [systemd-devel] [PATCH 00/24] Initial DHCPv6 client support

[Dan Williams]

On Fri, 2014-06-13 at 16:44 +0300, Patrik Flykt wrote:
   Hi,
 
 This patch set provides initial DHCPv6 client support for
 systemd-networkd. It adds support for ICMPv6 Router Solicitation sending
 and Router Advertisment receiving and the very basic Solicit, Advertise,
 Request and Reply message transactions. Networkd is able to start DHCPv6
 negotiation for a link, but doesn't yet do anything with the result.
 
 As only the initial DHCPv6 client side support is implemented, this patch
 set omits the following features specified in RFC 3315:
  - Rapid Commit in the Solicit message
  - Information Request, should the router only announce the availability
of Other information
  - Reacquiring of an address, i.e. Renew, Rebind, etc.
  - Temporary adresses, option requesting, elapsed time options
  - DHCPv6 authentication
 
 ...and a few more that I for sure have forgotten from this list. The
 intent is to have the remaining parts essential for the protocol
 functionality to be done as quickly as possible after this patch set.
 
 On startup, the DHCPv6 client implementation sends Router Soliciations
 in order to receive Router Advertisments. Only the Managed/Other flags
 in the Router Advertisment are currently used, any prefix information
 is currently ignored. ICMPv6 and a basic test case is handled by patches
 02-04 with the basic DHCPv6 library and test case provided in patches 01
 and 08.

For future consumers of the library, can the RA/RS behavior be
selectively disabled?

Dan

 Machine-specific DUID and IAID identifiers are created in patches 05-07.
 The DUID is used to uniquely identify the machine with the IAID
 identifying a particular interface. The DUID is based on the machine ID
 and the IAID on interface name from udev or, if run in a container, the
 interface MAC address. Credits for implementing this part of the code
 goes to Tom.
 
 With identifiers created, the DHCPv6 message (re)transmission is provided
 by patch 09 and enhanced in turn with patches 12 and 22 where Solicit
 and Reply message handling is implemented, respectively. Support for DHCPv6
 option appending and parsing is provided in patches 10 and 15, separated
 due to implementation complexity of the IA option and need of DHCPv6 lease
 handling code provided by patch 14.
 
 The remaining patches add DHCPv6 message processing one message at a time
 with the required state changes and retransmission restarting. A client
 test program is provided, it should hopefully prevent possible bugs with
 later commits.
 
 As with the DHCPv4 code, also with DHCPv6 it again became evident that
 borrowing code 1:1 from ConnMan wasn't really an option. The main loop
 syntax and systemd coding style is different enough to prevent any direct
 copying. On the positive side the ConnMan implementation exists and works
 very well making it possible to thoroughly dissect the DHCPv6 messaging
 going back and forth between the client and the server.
 
 
 Have fun while reviewing,
 
 
  Patrik 
 
 
 
 Patrik Flykt (22):
   sd-dhcp6-client: Add initial DHCPv6 client files
   sd-dhcp6-client: Add Router Solicitation and Advertisement support
   sd-dhcp6-client: Add initial Router Advertisement test case
   sd-dhcp6-client: Initialize Router Solicitation on startup
   sd-dhcp6-client: Add DHCPv6 IAID functionality
   sd-dhcp6-client: Add basic DHCPv6 test cases
   sd-dhcp6-client: Add DHCPv6 client Solicitation timeout handling
   sd-dhcp6-client: Add basic DHCPv6 option handling
   sd-dhcp6-client: Add functions to bind to DHCPv6 UDP socket
   sd-dhcp6-client: Add DHCPv6 Solicit message creation and sending
   sd-dhcp6-client: Add RA and DHCPv6 Solicit test case
   sd-dhcp6-lease: Add DHCPv6 lease handling
   sd-dhcp6-client: Add IA Address option parsing
   sd-dhcp6-client: Receive and parse Advertise messages
   sd-dhcp6-lease: Add functions for accessing lease and addresses
   sd-dhcp6-client: Add test case for Advertise message parsing
   sd-dhcp6-client: Update start function to take a state
   sd-dhcp6-client: Add Request message sending
   sd-dhcp6-client: Add Advertise sending for test cases
   sd-dhcp6-client: Receive and parse a reply and set T1 and T2 timers
   sd-dhcp6-client: Add reply sending for test
   networkd: Add initial DHCPv6 support
 
 Tom Gundersen (2):
   sd-dhcp6-client: Initialize DUID
   network-internal: split out net_get_name()
 
  Makefile.am   |   38 +-
  src/libsystemd-network/dhcp6-internal.h   |   79 ++
  src/libsystemd-network/dhcp6-lease-internal.h |   57 ++
  src/libsystemd-network/dhcp6-network.c|  194 +
  src/libsystemd-network/dhcp6-option.c |  314 
  src/libsystemd-network/dhcp6-protocol.h   |  124 +++
  src/libsystemd-network/icmp6-nd.c |  317 
  src/libsystemd-network/icmp6-nd.h |   59 ++
  src/libsystemd-network/network-internal.c |   26 +-
  src/libsystemd-network/network-internal.h |1 +
  

Re: [systemd-devel] [PATCH 00/24] Initial DHCPv6 client support

[Dan Williams]

On Fri, 2014-06-13 at 18:38 +0200, Tom Gundersen wrote:
 On Fri, Jun 13, 2014 at 6:26 PM, Dan Williams d...@redhat.com wrote:
  On Fri, 2014-06-13 at 16:44 +0300, Patrik Flykt wrote:
Hi,
 
  This patch set provides initial DHCPv6 client support for
  systemd-networkd. It adds support for ICMPv6 Router Solicitation sending
  and Router Advertisment receiving and the very basic Solicit, Advertise,
  Request and Reply message transactions. Networkd is able to start DHCPv6
  negotiation for a link, but doesn't yet do anything with the result.
 
  As only the initial DHCPv6 client side support is implemented, this patch
  set omits the following features specified in RFC 3315:
   - Rapid Commit in the Solicit message
   - Information Request, should the router only announce the availability
 of Other information
   - Reacquiring of an address, i.e. Renew, Rebind, etc.
   - Temporary adresses, option requesting, elapsed time options
   - DHCPv6 authentication
 
  ...and a few more that I for sure have forgotten from this list. The
  intent is to have the remaining parts essential for the protocol
  functionality to be done as quickly as possible after this patch set.
 
  On startup, the DHCPv6 client implementation sends Router Soliciations
  in order to receive Router Advertisments. Only the Managed/Other flags
  in the Router Advertisment are currently used, any prefix information
  is currently ignored. ICMPv6 and a basic test case is handled by patches
  02-04 with the basic DHCPv6 library and test case provided in patches 01
  and 08.
 
  For future consumers of the library, can the RA/RS behavior be
  selectively disabled?
 
 No objections from me, but out of interest, what is your desired
 behaviour here? Will this option be exposed to the user, or do you
 have some other way to determine whether or not to do RA/RS, or do you
 simply do it in a different way?

Two reasons:

1) We're already using libndp to do RS/RA in NM, and I'm sure we'd be
open to switching over in the future, but more importantly:

2) IPv6 RA/RS has no relationship with DHCP per-se, it's a provider of
some information that DHCP might want to use (the M/O bit) but that's
all. As such it makes no real sense to tie the two together, because
RS/RA is used in many more circumstances than DHCP is used.  I'm talking
about dhcp_network_icmp6_send_router_solicitation() and
dhcp_network_icmp6_bind_router_solicitation() mostly.

So best would be to keep the RS/RA bits completely separate from the
DHCP bits, but then consume the RS/RA stuff from the DHCP code.  That's
not going to adversely affect time-to-address if properly architected.

I know you probably don't care much about other DHCP clients, but we're
fighting this same battle with dhcpcd (on Debian mostly) which tries
really, really hard to be everything-and-the-kitchen-sink, and also
unconditionally does RS/RA when DHCPv6 is requested.

Dan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 02/24] sd-dhcp6-client: Add Router Solicitation and Advertisement support

[Dan Williams]

On Fri, 2014-06-13 at 16:44 +0300, Patrik Flykt wrote:
 Provide functions to bind the ICMPv6 socket to the approriate interface
 and set multicast sending and receiving according to RFC 3493, section
 5.2. and RFC 3542, sections 3. and 3.3. Filter out all ICMPv6 messages
 except Router Advertisements for the socket in question according to
 RFC 3542, section 3.2.
 
 Send Router Solicitations to the all routers multicast group as
 described in RFC 4861, section 6. and act on the received Router
 Advertisments according to section 6.3.7.
 
 Implement a similar API for ICMPv6 handling as is done for DHCPv4 and
 DHCPv6.

Two comments:

1) usage of struct ether_addr may prevent correct operation on
non-ethernet links, like Infiniband or PPP or GRE.  They don't have
6-byte MAC addresses, so anywhere that currently uses a MAC address I'd
suggest passing u8*, u8 len instead, to allow for non-ethernet links.
See ndisc_fill_addr_option() in the kernel...

2) as I replied to Tom, could we keep RS/RA code together and not tie it
with DHCP stuff, since they aren't really related?  DHCP is the consumer
of the M/O bits, but if DHCP isn't requested at all by the router via
the M/O bits, there's no reason for DHCP to ever be involved in the
process.  I think it would be better to keep them fully separate.

Thanks!
Dan

 ---
  Makefile.am |   8 +-
  src/libsystemd-network/dhcp6-internal.h |  29 +++
  src/libsystemd-network/dhcp6-network.c  | 131 +
  src/libsystemd-network/icmp6-nd.c   | 317 
 
  src/libsystemd-network/icmp6-nd.h   |  59 ++
  5 files changed, 543 insertions(+), 1 deletion(-)
  create mode 100644 src/libsystemd-network/dhcp6-internal.h
  create mode 100644 src/libsystemd-network/dhcp6-network.c
  create mode 100644 src/libsystemd-network/icmp6-nd.c
  create mode 100644 src/libsystemd-network/icmp6-nd.h
 
 diff --git a/Makefile.am b/Makefile.am
 index 4ff9f5a..a8b5b79 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -2518,7 +2518,13 @@ libsystemd_network_la_SOURCES = \
   src/libsystemd-network/ipv4ll-packet.c \
   src/libsystemd-network/ipv4ll-internal.h \
   src/libsystemd-network/network-internal.c \
 - src/libsystemd-network/network-internal.h
 + src/libsystemd-network/network-internal.h \
 + src/systemd/sd-dhcp6-client.h \
 + src/libsystemd-network/sd-dhcp6-client.c \
 + src/libsystemd-network/icmp6-nd.h \
 + src/libsystemd-network/icmp6-nd.c \
 + src/libsystemd-network/dhcp6-internal.h \
 + src/libsystemd-network/dhcp6-network.c
  
  libsystemd_network_la_LIBADD = \
   libudev-internal.la \
 diff --git a/src/libsystemd-network/dhcp6-internal.h 
 b/src/libsystemd-network/dhcp6-internal.h
 new file mode 100644
 index 000..52283d7
 --- /dev/null
 +++ b/src/libsystemd-network/dhcp6-internal.h
 @@ -0,0 +1,29 @@
 +/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
 +
 +#pragma once
 +
 +/***
 +  This file is part of systemd.
 +
 +  Copyright (C) 2014 Intel Corporation. All rights reserved.
 +
 +  systemd is free software; you can redistribute it and/or modify it
 +  under the terms of the GNU Lesser General Public License as published by
 +  the Free Software Foundation; either version 2.1 of the License, or
 +  (at your option) any later version.
 +
 +  systemd is distributed in the hope that it will be useful, but
 +  WITHOUT ANY WARRANTY; without even the implied warranty of
 +  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 +  Lesser General Public License for more details.
 +
 +  You should have received a copy of the GNU Lesser General Public License
 +  along with systemd; If not, see http://www.gnu.org/licenses/.
 +***/
 +
 +#include net/ethernet.h
 +
 +#define log_dhcp6_client(p, fmt, ...) log_meta(LOG_DEBUG, __FILE__, 
 __LINE__, __func__, DHCPv6 CLIENT:  fmt, ##__VA_ARGS__)
 +
 +int dhcp_network_icmp6_bind_router_solicitation(int index);
 +int dhcp_network_icmp6_send_router_solicitation(int s, const struct 
 ether_addr *ether_addr);
 diff --git a/src/libsystemd-network/dhcp6-network.c 
 b/src/libsystemd-network/dhcp6-network.c
 new file mode 100644
 index 000..53ce23d
 --- /dev/null
 +++ b/src/libsystemd-network/dhcp6-network.c
 @@ -0,0 +1,131 @@
 +/***
 +  This file is part of systemd.
 +
 +  Copyright (C) 2014 Intel Corporation. All rights reserved.
 +
 +  systemd is free software; you can redistribute it and/or modify it
 +  under the terms of the GNU Lesser General Public License as published by
 +  the Free Software Foundation; either version 2.1 of the License, or
 +  (at your option) any later version.
 +
 +  systemd is distributed in the hope that it will be useful, but
 +  WITHOUT ANY WARRANTY; without even the implied warranty of
 +  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 +  Lesser General Public License for more details.
 +
 +  You should have received a copy of the GNU Lesser General Public 

Re: [systemd-devel] Systemd-networkd, default route and multiple interfaces

[Dan Williams]

On Fri, 2014-06-06 at 10:52 -0400, Leonid Isaev wrote:
 Hi,
 
 On 06/06, Lennart Poettering wrote:
  Date: Fri, 6 Jun 2014 15:43:21 +0200
  From: Lennart Poettering lenn...@poettering.net
  To: Mantas Mikulėnas graw...@gmail.com
  Cc: systemd Mailing List systemd-devel@lists.freedesktop.org
  Subject: Re: [systemd-devel] Systemd-networkd, default route and multiple
   interfaces
  User-Agent: Leviathan/19.8.0 [zh] (Cray 3; I; Solaris 4.711; Console)
  
  On Wed, 04.06.14 00:29, Mantas Mikulėnas (graw...@gmail.com) wrote:
  
   
   On Tue, Jun 3, 2014 at 9:58 PM, Lennart Poettering
   lenn...@poettering.net wrote:
   
On Mon, 02.06.14 21:02, Tom Gundersen (t...@jklm.no) wrote:
   
 On Mon, Jun 2, 2014 at 8:47 PM, Reventlov
 contact+systemd...@volcanis.me wrote:
  Since network files are applied to links whenever the links
  appear, how do systemd manage the disappearance of a default 
  route ?

 You can have several default routes, so we just configure them all and
 let the kernel handle it for us. We probably should improve the config
 options to make it possible to override the priority of the routes.
   
Windows initializes the route metric value for each route from the
speed of the interface. If there are multiple links and for one we
know it's a gigabit ethernet link, and the other is a 54mbit wlan link,
then the former would automatically get preference... it's a bit black
magic, but kinda cool black magic i think...
   
that said, i am not sure we even have a sane API to determine the speed
of links... maybe ethtool reports it at least for wired ethernet? but
for wlan?
   
   Both `iwconfig dev` and `iw dev link` report the link speed (one
   using the old wext and the other nl80211, I think?).
   
   No idea about all the other link types that Linux supports though.
  
  As long as we'd only have to check ethtool for wired ethernet and the
  wireless stack for wireless ethernet and can cover 70% of all devices
  with that, this sounds like the right thing to do for me...
 
 Note, however, that wlan link speed can fluctuate in time. At least that's 
 what
 happens with eduroam at our university (mostly cisco APs).

Wifi speeds are constantly recalculated by the driver/firmware based on
the RF environment, no matter when moving or standing still.  So the
farther away from the AP you are, or the more interference there is, the
slower your speed will be as your device attempts to increase
reliability of data transfer against interference or faint signal.

Dan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Manager and systemd-networkd.service

[Dan Williams]

On Wed, 2014-04-16 at 08:39 +0200, Thomas Bächler wrote:
 Am 16.04.2014 06:10, schrieb Andy Johnson:
  Hello, systemd-devel,
  
  I saw this in the manpage of systemd-networkd.service (in the systemd git 
  tree)
  
  systemd-networkd.service, systemd-networkd — Network manager
  
  My question is: is systemd-networkd.service a replacement for the
  Network Manager
 
 No. networkd is aimed at configuration file based static network setups.
 It is supposed to be suitable for early boot (initrd) and for automatic
 network setup in containers and VMs. It is unlikely to ever include
 support for wifi.
 
 On a desktop or server with a single LAN connection, networkd may be a
 good choice. On a laptop that dynamically switches between LAN, Wifi,
 bluetooth-based tethering and networking via pidgeons, you want to use
 something like NetworkManager.
 
 See Tom Gundersen's G+ posts on the topic, he explains the goal and
 design of networkd in great detail.

Obviously NetworkManager and networkd will be installed on the same
system at times, and we (the NetworkManager team) have spent a lot of
time in the past year or two making NetworkManager more aware of changes
made by other processes, and we expect NetworkManager to recognize and
handle these changes as part of its normal workflow even without setting
any devices to unmanaged mode.  We intend to continue enhancing that.

So the long and short of it is that nothing obsoletes NetworkManager,
and we (the NetworkManager) team expect NetworkManager to cooperate with
external tools that make changes to networking, be they networkd, manual
changes with /sbin/ip, libvirt, neutron, custom scripts, ifup/ifdown,
whatever.

Dan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd questions

[Dan Williams]

On Tue, 2013-11-12 at 23:19 +0100, Tom Gundersen wrote:
 Hi Dan,
 
 On Tue, Nov 12, 2013 at 10:38 PM, Dan Williams d...@redhat.com wrote:
  1) what is lacking in other userspace solutions (NetworkManager,
  ConnMan, wicked, initscripts, etc) that requires
  yet-another-network-daemon?
 
 Without criticizing any of the existing solutions, some of the things

To be honest, it would be helpful for you to raise your concerns at
least with NetworkManager, since many of the concerns that we've heard
about running in smaller and enterprise environments have recently been
addressed, or are longstanding misconceptions of things NM did in the
past but has not done for years.

 that motivated my interest in this is that I think we need: something
 easily configured via plain configuration files by a sysadmin,

NM uses .ini-style files in /etc for all configuration these days, and
also has plugins for reading distro-specific configuration files if the
user wants those.

 something that would take a limited amount of space (including its
 dependencies) so it could be reasonably used in an initrd, something

What are your space constraints in terms of both disk space and RSS
usage?

 which would be fast/efficient, so not e.g. calling out to external
 tools/daemons for stuff like dhcp/ipv4ll.

What are your requirements for being fast/efficient?  How long do you
require a DHCP exchange to take, on average?  How long do you require
IPv4LL addressing to take, on average?  How much worse than these
requirements are existing solutions?

 Essentially, I see us taking over from what initscripts (and similar
 solutions in various distributions) are currently doing, and
 peacefully coexisting with connman and networkmanager for the
 foreseeable future. Hopefully we'll manage to cooperate on overlapping
 functionality, but I think it is a bit early in the game to start
 discussing that yet.
 
  2) do you expect that systemd-networkd will grow to include bridge,
  bond, and team setup?  how about other enterprise/server interface
  types like macvlan/vtap, tun/tap, gre, vxlan, ovs, etc?  All these are
  enterprise things that typically won't change during a specific bootup,
  but which static servers increasingly use.  If you don't expect these
  to be supported, why not?
 
 Most of these things we expect to support eventually. We'll have to
 discuss on a case-by-case precisely which ones.

At some point, when doing most of these things, systemd-networkd
becomes another first-tier network management daemon like the 6 or 8
that already exist.  Is that the intention?  Is it useful to have two
different services that both do the same thing?

Dan

  3) Is there expected to be D-Bus interfaces for controlling or
  monitoring the network interfaces and configuration data?  If not, why
  not?
 
 This is expected, yes. At first we will at least expose the state of
 the networks/links, and later also allow them to be configured. All
 this would be via dbus.


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd-networkd questions

[Dan Williams]

Hi,

Having watched the discussion over the past week or so, I'm left with a
few questions:

1) what is lacking in other userspace solutions (NetworkManager,
ConnMan, wicked, initscripts, etc) that requires
yet-another-network-daemon?

2) do you expect that systemd-networkd will grow to include bridge,
bond, and team setup?  how about other enterprise/server interface
types like macvlan/vtap, tun/tap, gre, vxlan, ovs, etc?  All these are
enterprise things that typically won't change during a specific bootup,
but which static servers increasingly use.  If you don't expect these
to be supported, why not?

3) Is there expected to be D-Bus interfaces for controlling or
monitoring the network interfaces and configuration data?  If not, why
not?

Thanks,
Dan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd kills mdmon if it was started manually by user

[Dan Williams]

On Tue, Feb 8, 2011 at 9:28 AM, Lennart Poettering
lenn...@poettering.net wrote:
 On Tue, 08.02.11 16:54, Andrey Borzenkov (arvidj...@mail.ru) wrote:

  a) mdmon is perfectly capable of restarting, it is already used to
  take over mdmon launched in initrd. The problem is to know when to
  restart - i.e. when respective libraries are changed. This is a job
  for package management in distribution. It is already employed for
  glibc, systemd and some others and can just as well be employed for
  mdmon. And this is totally unrelated to systemd :)
 
  Really, you are sying there is a synchronous way to make mdmon reexec
  itself? How does that work?
 

 I am not sure whether it qualifies as synchronous, but mdmon
 --takeover will kill any existing mdmon for this and start monitoring
 itself.

 I wonder if this is really fully synchronous, i.e. that a) there is no
 point in time where mdmon is not running during this restart and b) the
 mdmom --takeover command returns when the new daemon is fully up, and
 not right-away.

  Well, the root file systems cannot be unmounted, only remounted.
 
  So, is there a way to invoke mdmon so that it flushes all metadata
  changes to disk and immediately terminates then this should be all we
  need for a clean solution. We'd then shutdown the normal instances of
  mdmon down like any other daemon and simply invoke this metadata
  flushing command as part of late shutdown.


 Hmm ... it looks like you just need to

 start mdmon
 do mdadm --wait-clean

 After this you can kill mdmon again (assuming decide is no more in
 use).


 Well, it would be nice if the md utils would offer something doing this
 without spawning multiple processes and killing them again.


/me wonders why his raid5 resyncs every boot on Fedora 15 and has
found this old thread.

I'm tempted to:

1/ teach ignore_proc() to scan for pid files in /dev/md/ (MDMON_DIR on Fedora)
2/ arrange for mdadm --wait-clean --scan to be called after all
filesytems have been mounted read only

...but a few things strike me.  This does not seem to be what was
being proposed above.  Systemd does not treat dm devices like a
service and takes care to shut them down explicitly (but in that case
there is an api that it can call).  Is it time for a libmd.so,  so
systemd can invoke the --wait-clean --scan process itself?  Probably
simpler to just SIGTERM mdmon and wait for it.

--
Dan
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel