Diff between "route" command's -iface and -interface options.

[Gary W. Swearingen]

Anbody familiar with the "route" command's -iface and -interface
options? The man page is rather sketchy about -interface or the
difference bewteen the two. /usr/43src/sbin/route/route.c has the
following possibly-relevant code. I can't find where the constants are
defined.

case K_IFACE:
case K_INTERFACE:
iflag++;
break;

Can anyone improve my confidence that these options do the same thing?
I'll write a PR to clarify the man page, but I hate to rely on my poor
C code literacy. Or should I track down a recent route.c committer?

To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message

[Ruslan Ermilov]

On Sun, Sep 30, 2001 at 03:36:20PM -0700, Gary W. Swearingen wrote:
> Anbody familiar with the "route" command's -iface and -interface
> options? The man page is rather sketchy about -interface or the
> difference bewteen the two. /usr/43src/sbin/route/route.c has the
> following possibly-relevant code. I can't find where the constants are
> defined.
>
> case K_IFACE:
> case K_INTERFACE:
> iflag++;
> break;
>
> Can anyone improve my confidence that these options do the same thing?
>

They are synonyms, and also have a side effect on accepting "gateway"
argument in the "interface" address format. The constants are defined
in generated keywords.h.

> I'll write a PR to clarify the man page, but I hate to rely on my poor
> C code literacy. Or should I track down a recent route.c committer?
>

Yes, please. You just hit him. :-)

Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
r...@sunbay.com Sunbay Software AG,
r...@FreeBSD.org FreeBSD committer,
+380.652.512.251 Simferopol, Ukraine

http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age

[Gary W. Swearingen]

Thanks for responding. For reference, you said:

> They are synonyms, and also have a side effect on accepting "gateway"
> argument in the "interface" address format.

1) I plan to insert a line in the "flags" table thusly:

-iface ~RTF_GATEWAY - destination is directly reachable
-interface - a synonym for -iface
-static RTF_STATIC - manually added route

2) I plan to change this existing paragraph:

If the destination is directly reachable via an interface requiring no
intermediary system to act as a gateway, the -interface modifier should
be specified; the gateway given is the address of this host on the common
network, indicating the interface to be used for transmission. Alter-
nately, if the interface is point to point the name of the interface
itself may be given, in which case the route remains valid even if the
local or remote addresses change.

From what you said above and from some "route" commands I've seen, it
looks like the "gateway" argument should be an interface name when
-iface/-interface is used and so I'm confused by "the gateway given is
the address of this host on the common network" phrase, especially as
contrasted to the latter use of "name of the interface itself" for p-to-p.
Being bold enough to guess it's either very unclear or simply wrong, I
propose this alternate paragraph:

If the destination is directly reachable via an interface requiring no
intermediary system to act as a gateway, the -iface (or equivilant
-interface) modifier should be used and the gateway should be specified
as the interface name; the route then remains valid even if the local or
remote addresses change.

OK? I hope that doesn't cut too much. I'm not sure what's "must" and
what's "may" for either multi-cast or point-to-point, and I waffled with
"should" for both. If it should say more, I'll need some guidance.

3) If I ever make time to try to clear up some other things in this man
page, should I communicate directly with you before writing PRs or
should I just write the PRs (maybe after getting input from -questions
or -stable)?

Thanks.

[Ruslan Ermilov]

On Mon, Oct 01, 2001 at 11:56:27AM -0700, Gary W. Swearingen wrote:
> Thanks for responding. For reference, you said:
>
> > They are synonyms, and also have a side effect on accepting "gateway"
> > argument in the "interface" address format.
>
> 1) I plan to insert a line in the "flags" table thusly:
>
> -iface ~RTF_GATEWAY - destination is directly reachable
> -interface - a synonym for -iface
> -static RTF_STATIC - manually added route
>

OK.

> 2) I plan to change this existing paragraph:
>
> If the destination is directly reachable via an interface requiring no
> intermediary system to act as a gateway, the -interface modifier should
> be specified; the gateway given is the address of this host on the common
> network, indicating the interface to be used for transmission. Alter-
> nately, if the interface is point to point the name of the interface
> itself may be given, in which case the route remains valid even if the
> local or remote addresses change.
>
> From what you said above and from some "route" commands I've seen, it
> looks like the "gateway" argument should be an interface name when
> -iface/-interface is used and so I'm confused by "the gateway given is
> the address of this host on the common network" phrase, especially as
> contrasted to the latter use of "name of the interface itself" for p-to-p.
> Being bold enough to guess it's either very unclear or simply wrong, I
> propose this alternate paragraph:
>
> If the destination is directly reachable via an interface requiring no
> intermediary system to act as a gateway, the -iface (or equivilant
> -interface) modifier should be used and the gateway should be specified
> as the interface name; the route then remains valid even if the local or
> remote addresses change.
>
> OK? I hope that doesn't cut too much. I'm not sure what's "must" and
> what's "may" for either multi-cast or point-to-point, and I waffled with
> "should" for both. If it should say more, I'll need some guidance.
>

Not quite. The original paragraph is pretty correct. "gateway" SHOULD
NOT be specified as "interface name", but it CAN BE. It still makes
sense to use "the address of this host on the common network", as it
is then recorded as the IFA address of this route. With this interface
configuration,

: # ifconfig rl0 inet
: rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
: inet 192.168.4.115 netmask 0xffffff00 broadcast 192.168.4.255
: inet 192.168.4.200 netmask 0xffffffff broadcast 192.168.4.200

the following command will add a route to the 10 network, using the
192.168.4.200 as the source address:

: # route add -net 10 -iface 192.168.4.200
: add net 10: gateway 192.168.4.200
: # route -vn get -net 10
: u: inet 10.0.0.0; u: link ; RTM_GET: Report Metrics: len 172, pid: 0, seq 1, errno 0, flags:<UP,GATEWAY,STATIC>
: locks: inits:
: sockaddrs: <DST,NETMASK,IFP>
: 10.0.0.0 (0) 0 ff
: route to: 10.0.0.0
: destination: 10.0.0.0
: mask: 255.0.0.0
: interface: rl0
: flags: <UP,DONE,CLONING,STATIC,PRCLONING>
: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
: 0 0 0 0 0 0 1500 -68
:
: locks: inits:
: sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA>
: 10.0.0.0 255.0.0.0 rl0:0.c0.df.3.2d.79 192.168.4.200
^^^^^^^^^^^^^

I.e., the command will route 10 network through the ARP on the attached
rl0 physical network, and any unnamed (source IP address is unfilled)
IP packets going to that network will have 192.168.4.200 as a source
address.

> 3) If I ever make time to try to clear up some other things in this man
> page, should I communicate directly with you before writing PRs or
> should I just write the PRs (maybe after getting input from -questions
> or -stable)?
>

You can try me first.

Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
r...@sunbay.com Sunbay Software AG,
r...@FreeBSD.org FreeBSD committer,
+380.652.512.251 Simferopol, Ukraine

http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age

To Unsubscribe: send mail to majo...@FreeBSD.org