> >The main question is that the atm code seems to change the interface
> >on a received packet arbitrarily. In sys/net/if_atmsubr.c, in
> >atm_input (around line 236 or so), in the #ifdef NATM section,
> >m->m_pkthdr.rcvif gets set to rxhand. 
> 
> Demux for ATM network interfaces is done in hardware (based on the VC
> number).   The code you are looking at is designed to take advantage of
> this (e.g. why do a linked list search (or hash search?) for a protcol 
> control block when the hardware has already told you what VC the data 
> belongs to?).
> 
> >But what is rxhand? 
> 
> rxhand is a cookie which was passed to the driver at the time the VC
> was opened (see PRU_CONNECT in netnatm/natm.c).   the driver blindly
> passes a VC's cookie to atm_input() as data comes in on that VC (this 
> is the code if sys/net/if_atmsubr.c you are looking at).   for IP
> this is not useful since we will get many different TCP/UDP connections
> on the same VC (so we need to look at the address and port number info
> in the IP header anyway).   thus, for IP rxhand (the cookie) will
> always be NULL.   when rxhand is NULL, nothing messes with 
> m_pkthdr.rcvif (i.e. the traditional case...).

So when the packet first comes in, nothing gets put into rcvif? Or
the real interface's ifnet's address goes there?

> however, for NATM we have one connection per VC.   we can let the
> hardware do all the demux work for us.  so, the netnatm protocol 
> passes the address of the NATM PCB in as the cookie.   the 
> m_pkthdr.rcvif gets overloaded with this cookie info (note "XXX"
> comments).  note that this behavior only happens with protocols that 
> ask for it (netnatm).
> 
> >Do we loose contact with the interface from which this packet came?
> 
> no, because a copy of the interface pointer is stored in the NATM
> protocol block (see "struct natmpcb" in netnatm/natm.h).  once
> you cast rxhand to a (struct natmpcb *) you have access to the ifnet
> pointer again.

Well, the point is that whenever we make a copy of an ifnet's address,
we need to incriment a reference count for the ifnet. When we're done,
we delete the ref. When all the references are gone, we delete the
ifnet.

So we need to be careful about (struct ifnet *)'s.

My idea had been that, like they're supposed to, the interface driver
would if_addref(ifp) after copying ifp to rcvif. More importantly, to
keep all of the protocol code clean, the if_delref would live in
MFREE (of course within a check to see that M_PKTHDR was asserted).

I'll look at the code more, but is the real interface put back before
the packet gets deleted?

> >Other q: I've got a tentative routine to walk the routing tables and
> >delete straggling routes. But I'm not sure how to actually delete the
> >route. I looked in the headers, and didn't see a routine for, "here's
> >the rtentry, delete it."
> 
> netnatm doesn't use the routing table.   however, for IP using ATM
> you have to add a static route to use a VC:
> 
> route add -iface 128.252.200.2 -link en0:1.0.0.4
> 
> when you add this route, the code in netinet/if_atm.c calls down
> to the hardware to enable the specified VC (in the above case it
> would say that 128.252.200.2 is on VCI 4 using AAL5).   when you are
> done with the VC you use a route delete.   the code in netinet/if_atm.c
> will then call down to the driver to disable the specified VC.
> 
> i'm not sure how that fits in with your if_detach plans.

Nor am I. :-) The idea here (which wasn't ATM specific) is that we need
to scour the routing tables to remove any dangling references to the
ifnet we're killing. We will have already kiled all the addresses on
the interface, but there can be other routes (for instance a link-level
arp result AFAIK).

I'm mainly puzzled about how to zap any such routes I find, and if
things like the associated address, need to die too.

Thanks for the info!

Take care,

Bill