Re: stretch and DNS name resolution service for other devices on a LAN
Le 25/02/2018 à 18:35, David Wright a écrit :
On Sat 24 Feb 2018 at 09:49:27 (+0100), Pascal Hambourg wrote:
On disadvantage is that these addresses are not globally unique (the
link local prefix exists on all interfaces) and must be appended
with an interface name.
Not an issue here. The only change I have made since you commented
on this in August 2016 is that I now sed the output of
ip -o link show
to pick up the name of the ethernet interface. (The file that defines
my IPv6 functions is shared with wheezy/jessie/stretch hosts, and
"eth0" doesn't cut it any more.)
Hackish.
Why is this any more hackish than just setting net.ifnames=0
and sticking with eth0?
net.ifnames=0 is system configuration. Having to extract an interface
name by its MAC address at the application level is a kludge. No regular
user application should need to deal with interface names or MAC
addresses. That's what IP addresses and hostnames are for.
The second disadvantage is that if the
interface is replaced for whatever reason, the interface name may
change and the MAC address will change. The link local addresses is
based on the MAC addresses, so it will change too.
Well, as the MAC addresses are all configured in my router,
No, A MAC address is configured in the ethernet adapter NVRAM.
Besides, The two interfaces we are discussing about are not
connected to any router.
AIUI the MAC addresses are "burnt" into the card.
Just what I said. Programmed into an NVRAM on the card.
I then have to copy
the MAC addresses into the router by hand so that it can dispense the
correct IP numbers when devices connect to it.
IIUC the ethernet interface is not connected to the router. How could
the router dispense anything to it ?
The point I am making is that were I to be replacing interfaces
all the time, it would still be easier to keep the MAC references
up to date in my bash functions than in the router configuration pages.
Even easier and much cleaner would be to update the system configuration
instead of user scripts.
So Andy is right : you could use IPv4 for this. But rather with
static configuration than unpredictable APIPA assignments.
Of course I could, but then I've got to interfere with the routing
table to prevent the file transfers going through the default
wireless interface.
You can't be more wrong. With the static configuration of a pair of
IPv4 addresses in a distinct prefix at both ends of the ethernet
link the traffic between these addresses would flow through the
ethernet link.
OK, so I would do something like this, would I?
# cat /etc/network/interfaces.d/directcable
auto eth0
iface eth0 inet static
address 192.168.2.123/24
Of course. Just make sure the prefix is distinct from the router's one
to avoid any routing conflict.
No need to bother with things such as "I only need a pair of host
addresses so I am going to define a /30 prefix". There are plenty of
private addresses available, so keep it simple.
with the appropriate values for eth0 and 123 at each end,
connect a cable and then type
$ scp /etc/network/interfaces.d/directcable username@192.168.2.222:/tmp/
to effect a file transfer (after the ssh dialog)?
Yes.
Additionally, you can define hostnames for both addresses in /etc/hosts
on both hosts and use these instead of the IP addresses.
The same applies to ULA IPv6 addresses, except you have to get a (free)
ULA prefix before.
Anyway, we have a saying here which roughly translates to : "you
cannot force an unthirsty donkey to drink".
Some sort of passing insult?
No, it is just an expression, like "I didn't pay good money". It means
that I can't convince you if you don't want to be convinced.
Reply to: