From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: uberscubajim@gmail.com Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id da588ee9 for ; Mon, 11 Sep 2017 12:09:50 +0000 (UTC) Received: from mail-wr0-f181.google.com (mail-wr0-f181.google.com [209.85.128.181]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 0d84a1dc for ; Mon, 11 Sep 2017 12:09:50 +0000 (UTC) Received: by mail-wr0-f181.google.com with SMTP id o42so14280194wrb.3 for ; Mon, 11 Sep 2017 05:35:56 -0700 (PDT) Return-Path: Subject: Re: Timing issue (?) with wg-quick up on Raspberry Pi B+ To: "Jason A. Donenfeld" References: <1e1740c3-f8cf-2ee2-d842-749b687cb737@gmail.com> <07621915-a53a-03f3-9c75-b7e7d188d109@gmail.com> <59B5C95F.50508@gmail.com> From: Jim Darby Message-ID: Date: Mon, 11 Sep 2017 13:35:54 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C49051A3A7A4AA368735E5AC" Cc: WireGuard mailing list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------C49051A3A7A4AA368735E5AC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Nailed it! Specifically, you were spot on about the /etc/default/ifplugd file and its HOTPLUG_INTERFACES line. Changing that to HOTPLUG_INTERFACES="eth0 eth1" meant that it just worked out of the box. In fact, I suspect that eth0 could be omitted because it's part of the hardware (eth1 is a USB dongle so hotplugging may be useful). I'd prefer a way to specifically /exclude/ wg* interfaces rather then include the known ones but that may be too complex. I hope this discussion and its solution will be a useful part of the WireGuard documentation. It'll hopefully stop others becoming confused in the future. Many thanks for your help in resolving this! I'm very much enjoying playing with WireGuard. I heard about it during your talk at FOSDEM by the way. Regards, Jim. On 11/09/17 01:52, Jason A. Donenfeld wrote: > I figured it out. ifplugd clears all addresses when bringing up an > interface: > > void interface_up(int fd, char *iface) { > ... >         ((struct sockaddr_in *)(&ifr.ifr_addr))->sin_addr.s_addr = > INADDR_ANY; >         if (ioctl(fd, SIOCSIFADDR, &ifr) < 0) { > ... > } > > Since wg-quick sets the address before bringing it up, this running in > between is problematic. One workaround in wg-quick would be for me to > reverse the order of setting the IP and bringing it up, but this > introduces other races I'm not very fond of introducing. So, rather, > we should address the larger question: why on earth is ifplugd being > started when wg0 is added? > > Sep 10 23:57:51 janus ifplugd(wg0)[14109]: ifplugd 0.28 initializing. > Sep 10 23:57:51 janus ifplugd(wg0)[14109]: Using interface > wg0/00:00:00:00:00:00 > Sep 10 23:57:51 janus ifplugd(wg0)[14109]: Using detection mode: > IFF_RUNNING > > What causes it to be launched here? Digging a bit deeper, it looks > like ifplugd is being launched by a udev rule which calls a Debian > file called ifplugd.agent. It is in here that unholy hotplugging occurs. > > I don't actually have a Debian system running to fish around and see, > but my guess is that you have a file /etc/default/ifplugd that has in > it HOTPLUG_INTERFACES=all. If you change this to > HOTPLUG_INTERFACES="wlan0 eth0" or something more restrictive, things > might work better. Just a guess. --------------C49051A3A7A4AA368735E5AC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Nailed it!

Specifically, you were spot on about the /etc/default/ifplugd file and its HOTPLUG_INTERFACES line. Changing that to HOTPLUG_INTERFACES="eth0 eth1" meant that it just worked out of the box.

In fact, I suspect that eth0 could be omitted because it's part of the hardware (eth1 is a USB dongle so hotplugging may be useful). I'd prefer a way to specifically exclude wg* interfaces rather then include the known ones but that may be too complex.

I hope this discussion and its solution will be a useful part of the WireGuard documentation. It'll hopefully stop others becoming confused in the future.

Many thanks for your help in resolving this! I'm very much enjoying playing with WireGuard. I heard about it during your talk at FOSDEM by the way.

Regards,

Jim.


On 11/09/17 01:52, Jason A. Donenfeld wrote:
I figured it out. ifplugd clears all addresses when bringing up an interface:

void interface_up(int fd, char *iface) {
...
        ((struct sockaddr_in *)(&ifr.ifr_addr))->sin_addr.s_addr = INADDR_ANY;
        if (ioctl(fd, SIOCSIFADDR, &ifr) < 0) {
...
}

Since wg-quick sets the address before bringing it up, this running in between is problematic. One workaround in wg-quick would be for me to reverse the order of setting the IP and bringing it up, but this introduces other races I'm not very fond of introducing. So, rather, we should address the larger question: why on earth is ifplugd being started when wg0 is added?

Sep 10 23:57:51 janus ifplugd(wg0)[14109]: ifplugd 0.28 initializing.
Sep 10 23:57:51 janus ifplugd(wg0)[14109]: Using interface wg0/00:00:00:00:00:00
Sep 10 23:57:51 janus ifplugd(wg0)[14109]: Using detection mode: IFF_RUNNING

What causes it to be launched here? Digging a bit deeper, it looks like ifplugd is being launched by a udev rule which calls a Debian file called ifplugd.agent. It is in here that unholy hotplugging occurs.

I don't actually have a Debian system running to fish around and see, but my guess is that you have a file /etc/default/ifplugd that has in it HOTPLUG_INTERFACES=all. If you change this to HOTPLUG_INTERFACES="wlan0 eth0" or something more restrictive, things might work better. Just a guess.

--------------C49051A3A7A4AA368735E5AC--