I do not understand this suggestion.  It seems to be doing exactly what
NetDevice::GetChannel says it will do.

(In reply to comment #1)
> I do not understand this suggestion.  It seems to be doing exactly what
> NetDevice::GetChannel says it will do.

Are you allowed to return 0 from this method ? Yes, but only _before_ the
device is connected to a channel. It could be argued that not being connected
to a channel is allowed only as a transient state during topology setup which
means that you should not return 0 _during_ simulation, because, honestly, an
unconnected device should not exist ever once you are past Simulator::Run.

Maybe what really makes sense here is to return 0 initially and a channel
pointer once the device has been successfully associated to its host device. 

Does any of this matter ? I don't know: I merely pointed out something which
looked like a good idea to me. Feel free to ignore it.

I think that the real issue is that there is no way to know what is "on the
other side" of a channel connected to an emulation-type device.  It seems that
there is a special case there that may or may not need addressing depending on
the context.  Then the question is how to you decide when you have run across
the special case of possibly many reachable devices on a channel/network with
only one net device on it, and that you need to deal with it?

It seemed to me that returning zero had exactly the right implications and was
the easiest way to check for a network "leaving" ns-3.  If we create a fake
channel, we could give it a property that it was a fake channel; but this
involved some kind of test for "fakeness" to discern the special case.  If you
default to returning a "fake" channel, it allows higher level code to assume
that the channel is "real" and make possibly very wrong assumptions about
topology that could lead to hard-to-find problems much later on.

The simplest and most fail-safe thing seemed to me to be to return a zero
pointer saying, "the concept of ns-3 channel doesn't mean anything here."  If
you are using the channel, chances are you are looking for something on the
other side.  It seems good to flag this case in an obvious way.

Virtual net devices will not have a channel either; e.g. Gustavo's tap device:

Ptr<Channel>
VirtualNetDevice::GetChannel (void) const
{
  return Ptr<Channel> ();
}

Seems like either we need to create a new ABC for virtual devices or just
change the doxygen to account for this possibility.  I'd vote for the latter.

changeset: b322b179c5f6