On Thu, 13 Apr 2000, Retvari Gabor wrote:
- Thanks for the quick response!
- Here are some further comments:
-
- Jeff Kann wrote:
- >
- > On Thu, 13 Apr 2000, Retvari Gabor wrote:
- >
- > - Hi, Folks...
- > -
- > - I need your help very badly concerning SOCK_RAW socket options.
- > - Suppose an IP packet, which comprises REMOTE source and destination IP
- > - addresses (i.e., different from any of the local interfaces of the
- > - partiular router) - this packet happens to be an RSVP Path message. As
- > - the Router Alert option is enabled the incoming packet is caught and
- > - passed to a user space program (rsvpd). After processing this packet it
- > - has to be sent further but WITHOUT installing any static (new) gateways
- > - to the kernel routing table. The packet's destination address is a
- > - remote address (does not reside on any of the router's attached LANS -
- > - and this destination does not have any references in the kernel routing
- > - table), but we - somehow - know, which is the next hop address of this
- > - packet - but this must not be installed to the Kernel routing table.
- >
- > This sounds strange. If you don't have the route in the routing table,
- > how do you know which interface to forward the Path message out to?
-
- This is the responsibility of a QoS routing protocol module: e.g.:
- QoSPF, which tells rsvpd, where to forward the message through a Unix
- domain socket.
I was thinking in terms of RSRR (can you blame me?). RSRR does get the
route out of the kernel. If you implement another module to replace RSRR
and provide routing information to rsvpd, then yes, the route does not
have to be in the kernel routing table.
-
- > The
- > packet should be dropped, if the router doesn't know the route.
- >
- The Router Alert option assures, that before locally processing the
- packet in the kernel, it is forwarded to the user domain rsvpd program,
- it is not discarded...
Sorry I didn't make it clear. I meant the rsvpd daemon should drop the
packet (again, if RSRR didn't know where to route the packet since the
route is not in the kernel routing table).
-
- > - I enabled the IP_PKTINFO option:
- > -
- > - setsockopt(fd,SOL_IP,IP_PKTINFO, (char *) &so_on,sizeof(so_on));
- > -
- > - and I filled the 'struct in_pktinfo':
- > -
- > - ipi->ipi_ifindex = outgoing_if_index; /* Interface index */
- > - ipi->ipi_spec_dst.s_addr = next_hop_addr; /* Routing destination
- > - address */ - recall, this is a remote address with no reference in the
- > - kernel routing table...
- > - and I left ipi_addr (/* Header Destination address */) unconfigured.
- >
- > I am not sure if the PKTINTO stuff can be used here (because I've never
- > tried it), but you could have just bound the raw socket to the outgoing
- > interface (which you learned via routing) and send the packet with that
- > socket.
-
- I have a "common" socket for the entire traffic: I must not bind it to
- any interfaces...
-
Are you rewriting rsvp daemon codes? It appears to me that you are
changing the routing and IO models that the current rsvpd we have.
- > - Although the parameters seem to be correct, the 'sendmsg' returns -1,
- > - errno = 22 (EINVAL). Is the conception correct? Does the kernel perform
- > - routing table lookup, and the missing gateway causes the EINVAL
- > - (blackhole route)? Should I enable SO_DONTROUTE option as well?
-
-
- > - p.s.: is reading the interface identifier indices (if_index) by ioctl or
- > - by a netlink socket compatible? When building the "dummy network driver"
- > - (for PPP purposes) into the kernel these calls return different
- > - interface indices:
- > - ioctl: lo (if_index = 1), dummy (index = 2), eth0 (index = 3) etc.
- > - netlink socket: lo (if_index = 1), eth0 (index = 2!!!!!) etc.
- > -
- > - shouldn't interface indices be unambiguous?
- >
- > If you reboot the machine, do they come out with the same numbers?
- >
- Sure they do: netlink socket returns all interfaces (dummy, teql0 (???)
- etc.), ioctl does not...
Isn't this contrary to what you described earlier, that ioctl gave you
all, but netlink missed dummy?
-
- any more comments would be extremely appreciated...
-
- Thanks again: Gabor Retvari/BUTE
-
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGP 6.5.2
http://www.isi.edu/~kann/Kann.asc
-----END PGP PUBLIC KEY BLOCK-----
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
