lkml.org 
[lkml]   [1996]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: arp: SIOCSARP: No such device
Date
really kuznet@ms2.inr.ac.ru (inr-linux-kernel@ms2.inr.ac.ru) wrote:
: But why not "dev"? It would comply with "route" behaviour.
: Or route does not understand word "dev" too?

Well, because -i is used in ipfw. But as I said, it will be included in the
next arp-release.

: Sounds reasonable, but I believe that it is not worth to implement.
: Rationale: if HW address is address of your own ethernet, (common case
: for proxy arp) it is senseless to specify it. Moreover, it is
: not so simple to dig out its value :-)
:
: I make it as:
:
: arp -s 157.158.29.94 "" dev eth0 pub
:
: Is there an option in nettools? If not, please make it, it is very
: convenient.

Yes, there is a option "-D" which tells arp that u dont specify a HW-Address
but a device name:

arp -D -s 157.158.29.94 eth0 pub

The Problem is, that you still need to give the Device:

arp -i eth0 -D -s 157.158.29.94 eth0 pub

The reason why I want the KErnel to guess the device is
backward-compatibility:

arp -s 157.158.29.94 xx:xx:Xx:xx:xx:xx pub

should work.

If this works, -D will work, too, and you still can give a dev for special
cases.

[guessing in kernel]

: Moreover, I would not like to see some sort of guessing in ifconfig,
: route and arp utilities, they are "elementary" utilities interfacing to kernel,
: and when I type "route add x.y.z.w" I expect that route will make exactly
: this thing. (Now net-tools do not try to improve user input and
: it is very good) Kernel 2.0 still tries to make sence of this directive,
: I hope that 2.1 will stop this practice and REQUIRE both netmask and gateway
: or device specification.
My general policy is not to guess anythin in arp, thats why you will have to
specify

arp -i eth0 -D -s 157.158.29.94 eth0 pub

even if that looks very odd. But I think the KErnel should be a little bit
inteligent. Since the Kernel does device-guessing anyway, I think the check
for hardware address would make arp(8) happy.

: Let's leave P-n-P functions to configuration scripts and
: network managers with nice menus and pictures. Good?
The Problem is, that every changed functionality requires a lot of
sytem-managers and distributors to catch errors. For example the new
arp-code allows someone to elete pup and nonpub entries. Most of the scripts
with: "arp -d 1.2.3.4" will not work anymore. Therefore 1.33 will have 3
options:

"arp -d 1.2.3.4" deletes pub and nonpub entries, "arp -d 1.2.3.4 nopub"
deletes the unpublished entry and "arp -d 1.2.3.4 pub" deletes the published
one. Therefore one can use the new features, but the old functionality is
still given.

: I STRONGLY recommend this option. It takes sence to make
: a shorthand for this operation, f.e.
:
: arp -i eth0 -s default
or: arp -s default dev eth0

Yes, I will put that into 1.33 arp, also.

: And the last thing: it would be very convenient, if net-tools understood
: network addresses in CIDR form. F.e.
:
: route add 193.233.7.64 netmask 255.255.255.192 ...
:
: should be equivalent to:
:
: route add 193.233.7.64/26 ...

I have thought about that, too... I only need a clean way to do it, since I
use library calls to be completely Adress-family independent.

Greetings
Bernd
--
(OO) -- Bernd_Eckenfels@Wittumstrasse13.76646Bruchsal.de --
( .. ) ecki@lina.{inka.de,ka.sub.org} http://home.pages.de/~eckes/
o--o *plush* 2048/93600EFD eckes@irc +4972573817 *plush*
(O____O) If privacy is outlawed only Outlaws have privacy


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.028 / U:1.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site