netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nolan Leake <nolan@cumulusnetworks.com>
To: Jim <jim876@xs4all.nl>
Cc: netdev@vger.kernel.org
Subject: Re: tap0 device stopped working in 2.6.36 (ok in 2.6.35)
Date: Sat, 23 Oct 2010 12:39:20 -0700	[thread overview]
Message-ID: <1287862760.7499.225.camel@voxel> (raw)
In-Reply-To: <4CC2DB2C.3060908@xs4all.nl>

On Sat, 2010-10-23 at 14:55 +0200, Jim wrote:
> After some checking noticed that apparently link isn't ready:
>  modprobe tun
>  tunctl -b
>  ifconfig tap0 192.168.20.1 up
> Gives:
> [   26.411932] ADDRCONF(NETDEV_UP): tap0: link is not ready
> 
> Bisected it all the way to this commit:
> 
> =================
> 
> # git bisect good
> bee31369ce16fc3898ec9a54161248c9eddb06bc is the first bad commit
> commit bee31369ce16fc3898ec9a54161248c9eddb06bc
> Author: Nolan Leake <nolan@cumulusnetworks.com>
> Date:   Tue Jul 27 13:53:43 2010 +0000
> 
>     tun: keep link (carrier) state up to date
> 
>     Currently, only ethtool can get accurate link state of a tap device.
>     With this patch, IFF_RUNNING and IF_OPER_UP/DOWN are kept up to date as
>     well.
> 
>     Signed-off-by: Nolan Leake <nolan@cumulusnetworks.com>
>     Signed-off-by: David S. Miller <davem@davemloft.net>

Hello Jim,

Thank you for the report and the bisect.  Please allow me to explain the
intention of this patch.

Previous to this patch, tun.c only kept the ethtool link state up to
date.  IFF_ and IF_OPER_ state were always RUNNING and UP, respectively.

Ethtool link state was (and is) controlled by mapping "tun device FD
open" to link up, and "tun device FD closed" to link down.  Obviously if
you've just used tunctl to create a tap device, and no process has yet
opened the /dev/net/tun backing FD, then this method establishes the
link as down.  Ethtool on a kernel that predates this patch will confirm
this.

What this patch does is make the IFF_RUNNING/IFF_OPER_UP state also
match this interpretation of link state.  Making RUNNING and OPER_UP
consistent with ethtool's concept of link state is, I believe,
consistent with how other ethernet devices work.  The presence of a
process that is sending and receiving packets via the tap device is a
decent analog of link-state for a physical ethernet device.

Could your use-case be solved by a udev rule that assigns the IP address
when the link state changes to UP/RUNNING?

If this is a common way to use tap devices, one possible solution is to
make newly created but unattached tap devices default to UP/RUNNING (and
presumably ethtool link-up, for consistency), and then only begin
accurately reporting link state for subsequent open/closes of
the /dev/net/tun device.

- nolan

  reply	other threads:[~2010-10-23 19:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-23 12:55 tap0 device stopped working in 2.6.36 (ok in 2.6.35) Jim
2010-10-23 19:39 ` Nolan Leake [this message]
2010-10-24  9:59   ` Jim
2010-10-27  1:18     ` Nolan Leake
2010-10-27 16:09       ` Jim
2010-10-27 17:48         ` Nolan Leake
2010-10-27 17:52           ` David Miller
2010-11-03 23:10         ` Nolan Leake
2010-11-04 20:17           ` Jim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1287862760.7499.225.camel@voxel \
    --to=nolan@cumulusnetworks.com \
    --cc=jim876@xs4all.nl \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).