Re: stretch and DNS name resolution service for other devices on a LAN
On Sat 24 Feb 2018 at 09:49:27 (+0100), Pascal Hambourg wrote:
> Le 22/02/2018 à 22:57, David Wright a écrit :
> >On Tue 23 Jan 2018 at 20:56:31 (+0100), Pascal Hambourg wrote:
> >>Le 23/01/2018 à 18:08, David Wright a écrit :
> >>>
> >>>[My Laptop] --- wireless connection IPv4 --- [Router] --- Internet Modem
> >>> | / |
> >>> | CAT5 cable IPv6 / |
> >>> | / | wireless/wired
> >>>[My Desktop] --- wireless connection IPv4 __/ | connections
> >>> | IPv4
> >>> |
> >>> [TVs]
> >>>
> >>>>Both devices will allocate themselves an address in the 'link local' range,
> >>>>and these addresses can then be used for communicating between the devices.
> >>
> >>They can, but they should not be used with application-layer
> >>protocols. Really. IPv6 link local addresses are not meant for this.
> >
> >Well, I won't argue with this as I don't know what they were
> >originally meant for.
>
> They are meant to be used with low level IPv6 services (automatic
> configuration, neighbour discovery...)
>
> >However, I don't see why I have them if I'm
> >not allowed to use them when I find a good reason to. I didn't pay
> >good money just to stare at the numbers in ip address show.
>
> You did not pay any money for IPv6 link local addresses.
It's an expression. They hand one a newspaper when one gets on the
transAtlantic flight. When one's wife says "You could leave that on
the seat for the next person boarding", one might reply "I didn't pay
good money just to leave the crossword behind".
> >>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?
> >>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. 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.
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.
> >>IMO, simple
> >>static configuration with a ULA prefix, or with a global prefix if
> >>you own one, would be much reliable.
> >
> >So what would be involved in setting that up? I have no idea where
> >to start. I can't believe it's as simple as 1,2,3 below.
>
> Get a ULA prefix. Online generators are available on the web.
> Pick up two host addresses in the prefix.
> Statically assign an address to the two interface in
> /etc/network/interfaces or any other network manager.
I'll try that when I've got IPv4 working, as that would make
all of Andy, Greg and yourself happy.
> >>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
#
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)?
> >If I use IPv6, this is all I have to do to transfer large files at
> >CAT5 speeds:
> >
> >1) plug a CAT5 cable into ethernet ports at each machine,
> >2) on the source, type: <TargetHost>6 <filenames>
> >3) when finished, remove the cable.
> >
> >The wireless interface is unaware of any change, so I can still use
> >the WAN, or even connect to the other host through its normal wireless
> >route and, say, initiate transfers in the opposite direction (which
> >has the advantage that such a connection stays up after the cable has
> >been removed).
>
> Same with IPv4.
>
> Anyway, we have a saying here which roughly translates to : "you
> cannot force an unthirsty donkey to drink".
Some sort of passing insult? The reason I've used IPv6 is because
someone here suggested it a few years ago, it worked, and so I set
it up in my startup files. Now I hope to demonstrate to myself that
the method works with IPv4.
Cheers,
David.
Reply to: