On Tue 27 Feb 2018 at 20:59:17 (+0100), Pascal Hambourg wrote:
> 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.
Yes, I'm agreeing with you, and indicating that I don't use any
methods for changing the MAC (which I have heard of people doing).
> >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 ?
It's not connected now. There are times when it has been.
That's not the point. You brought up the subject of replacing
interface cards. I was just saying that maintaining MAC
addresses is relatively easy on the computers and difficult
on the router. I can't just scp a file of configuration stuff
into the router.
But this is irrelevant to what I'm trying to do. Replacing
interface cards has nothing to do with why I am, or am not, using
IPv6 to transfer information through a CAT5 cable.
> >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 this is what I'm trying to do with your help.
> >>>>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.
That'll come later when I've succeeded with IP addresses.
> The same applies to ULA IPv6 addresses, except you have to get a
> (free) ULA prefix before.
Well, if you wean me off IPv6, I can forget about doing that.
> >>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.
To convince me, it's got to work. The British expression is
You can lead a horse to water but you can't make him drink.
So you're leading:
$ cat /etc/network/interfaces /etc/network/interfaces.d/directcable
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
#
# /etc/interfaces.d/directcable for west 2018-02-25
auto eth0
iface eth0 inet static
address 192.168.2.15/24
#
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group
default qlen 1000
link/ether 00:1c:23:3b:9f:34 brd ff:ff:ff:ff:ff:ff
inet6 fe80::21c:23ff:fe3b:9f34/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group
default qlen 1000
link/ether 00:1c:bf:d5:28:76 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.15/24 brd 192.168.1.255 scope global wlan0
valid_lft forever preferred_lft forever
inet6 fe80::21c:bfff:fed5:2876/64 scope link
valid_lft forever preferred_lft forever
$ ping6 -c 2 fe80::2c0:9fff:fe44:15b5%eth0
PING fe80::2c0:9fff:fe44:15b5%eth0(fe80::2c0:9fff:fe44:15b5) 56 data bytes
64 bytes from fe80::2c0:9fff:fe44:15b5: icmp_seq=1 ttl=64 time=0.381 ms
64 bytes from fe80::2c0:9fff:fe44:15b5: icmp_seq=2 ttl=64 time=0.407 ms
--- fe80::2c0:9fff:fe44:15b5%eth0 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.381/0.394/0.407/0.013 ms
$ ping -c 2 192.168.2.10
PING 192.168.2.10 (192.168.2.10) 56(84) bytes of data.
← times out
here
--- 192.168.2.10 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1009ms
$ ping -c 2 -I eth0 192.168.2.10
ping: Warning: source address might be selected on device other than eth0.
PING 192.168.2.10 (192.168.2.10) from 192.168.1.15 eth0: 56(84) bytes of data.
>From 192.168.1.15 icmp_seq=1 Destination Host Unreachable
>From 192.168.1.15 icmp_seq=2 Destination Host Unreachable
--- 192.168.2.10 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1008ms
pipe 2
$
So the problem seems to be getting a 192.168.2. address onto eth0 for
IPv4 to use. Everything looks similar (and is configured similarly)
at the other end of the cable which I can log into either with
ssh -X acer.local or ssh -X fe80::2c0:9fff:fe44:15b5%eth0
Cheers,
David.
