Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #191283 > unrolled thread

stretch and DNS name resolution service for other devices on a LAN

Back to article view | Back to linux.debian.user

Contents

  stretch and DNS name resolution service for other devices on a LAN "D. R. Evans" <doc.evans@gmail.com> - 2018-01-18 22:40 +0100
    Re: stretch and DNS name resolution service for other devices on a  LAN Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-01-18 22:50 +0100
      Re: stretch and DNS name resolution service for other devices on a  LAN "D. R. Evans" <doc.evans@gmail.com> - 2018-01-19 06:20 +0100
        Re: stretch and DNS name resolution service for other devices on a  LAN Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-01-19 21:10 +0100
    Re: stretch and DNS name resolution service for other devices on a  LAN Greg Wooledge <wooledg@eeg.ccf.org> - 2018-01-18 22:50 +0100
      Re: stretch and DNS name resolution service for other devices on a  LAN "D. R. Evans" <doc.evans@gmail.com> - 2018-01-19 06:20 +0100
      Re: stretch and DNS name resolution service for other devices on a  LAN Andy Hawkins <andy@gently.org.uk> - 2018-01-19 12:50 +0100
        Re: stretch and DNS name resolution service for other devices on a  LAN john doe <johndoe65534@mail.com> - 2018-01-19 13:10 +0100
          Re: stretch and DNS name resolution service for other devices on a  LAN Andy Hawkins <andy@gently.org.uk> - 2018-01-19 13:30 +0100
            Re: stretch and DNS name resolution service for other devices on a  LAN Michael Stone <mstone@debian.org> - 2018-01-19 15:10 +0100
              Re: stretch and DNS name resolution service for other devices on a  LAN Andy Hawkins <andy@gently.org.uk> - 2018-01-19 15:30 +0100
        Re: stretch and DNS name resolution service for other devices on a  LAN Greg Wooledge <wooledg@eeg.ccf.org> - 2018-01-19 14:50 +0100
          Re: stretch and DNS name resolution service for other devices on a  LAN Michael Stone <mstone@debian.org> - 2018-01-19 15:10 +0100
          Re: stretch and DNS name resolution service for other devices on a  LAN Andy Hawkins <andy@gently.org.uk> - 2018-01-19 15:20 +0100
            Re: stretch and DNS name resolution service for other devices on a  LAN Rob van der Putten <rob@sput.nl> - 2018-01-19 16:20 +0100
              Re: stretch and DNS name resolution service for other devices on a  LAN Michael Stone <mstone@debian.org> - 2018-01-19 17:40 +0100
              Re: stretch and DNS name resolution service for other devices on a  LAN Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-01-19 20:40 +0100
          Re: stretch and DNS name resolution service for other devices on a  LAN David Wright <deblis@lionunicorn.co.uk> - 2018-01-19 16:20 +0100
            Re: stretch and DNS name resolution service for other devices on a  LAN Andy Hawkins <andy@gently.org.uk> - 2018-01-22 18:30 +0100
              Re: stretch and DNS name resolution service for other devices on a  LAN David Wright <deblis@lionunicorn.co.uk> - 2018-01-22 23:30 +0100
                Re: stretch and DNS name resolution service for other devices on a  LAN Andy Hawkins <andy@gently.org.uk> - 2018-01-23 10:30 +0100
                  Re: stretch and DNS name resolution service for other devices on a  LAN Curt <curty@free.fr> - 2018-01-23 12:20 +0100
                    Re: stretch and DNS name resolution service for other devices on a  LAN Joe <joe@jretrading.com> - 2018-01-23 14:50 +0100
                      Re: stretch and DNS name resolution service for other devices on a  LAN David Wright <deblis@lionunicorn.co.uk> - 2018-01-23 15:50 +0100
                        Re: stretch and DNS name resolution service for other devices on a  LAN Andy Hawkins <andy@gently.org.uk> - 2018-01-23 17:10 +0100
                          Re: stretch and DNS name resolution service for other devices on a  LAN David Wright <deblis@lionunicorn.co.uk> - 2018-01-23 18:10 +0100
                            Re: stretch and DNS name resolution service for other devices on a  LAN Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-01-23 21:00 +0100
                              Re: stretch and DNS name resolution service for other devices on a  LAN David Wright <deblis@lionunicorn.co.uk> - 2018-02-22 23:00 +0100
                                Re: stretch and DNS name resolution service for other devices on a  LAN Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-02-24 10:00 +0100
                                  Re: stretch and DNS name resolution service for other devices on a   LAN Curt <curty@free.fr> - 2018-02-24 11:10 +0100
                                  Re: stretch and DNS name resolution service for other devices on a  LAN David Wright <deblis@lionunicorn.co.uk> - 2018-02-25 18:40 +0100
                                    Re: stretch and DNS name resolution service for other devices on a  LAN Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-02-27 21:00 +0100
                                      Re: stretch and DNS name resolution service for other devices on a  LAN David Wright <deblis@lionunicorn.co.uk> - 2018-02-28 18:20 +0100
                                        Re: stretch and DNS name resolution service for other devices on a  LAN Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-02-28 19:50 +0100
                                          Re: stretch and DNS name resolution service for other devices on a  LAN David Wright <deblis@lionunicorn.co.uk> - 2018-02-28 21:20 +0100
                                            Re: stretch and DNS name resolution service for other devices on a  LAN Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-03-03 00:00 +0100
                                              Re: stretch and DNS name resolution service for other devices on a  LAN David Wright <deblis@lionunicorn.co.uk> - 2018-03-04 20:30 +0100

Page 2 of 2 — ← Prev page 1 [2]

#191424 — Re: stretch and DNS name resolution service for other devices on a LAN

Hi,
In article <20180122185135.GA12212@alum>,
           David Wright<deblis@lionunicorn.co.uk> wrote:
>> You should be able to do that with IPv4 too. If DHCP address allocation
>> fails,
>
> Elaborate on this please. What do you mean by "fails".
> What am I meant to want to fail?

If a host that's expecting to receive its address via DHCP receives no response from the
DHCP server, it should fall back automatically to a 'link local' address.

Andy

[toc] | [prev] | [next] | [standalone]

#191428 — Re: stretch and DNS name resolution service for other devices on a LAN

On 2018-01-23, Andy Hawkins <andy@gently.org.uk> wrote:
> Hi,
> In article <20180122185135.GA12212@alum>,
>            David Wright<deblis@lionunicorn.co.uk> wrote:
>>> You should be able to do that with IPv4 too. If DHCP address allocation
>>> fails,
>>
>> Elaborate on this please. What do you mean by "fails".
>> What am I meant to want to fail?
>
> If a host that's expecting to receive its address via DHCP receives no response from the
> DHCP server, it should fall back automatically to a 'link local' address.

Is this what you're referring to ("an IPv4 address within the 169.254/16
prefix that is valid for communication with other devices connected to
the same physical (or logical) link," failing--or in the absence
of--automatic or manual assignment)?

https://tools.ietf.org/html/rfc3927

> Andy
>
>


-- 
“True terror is to wake up one morning and discover that your high school class
is running the country.” – Kurt Vonnegut

[toc] | [prev] | [next] | [standalone]

#191433 — Re: stretch and DNS name resolution service for other devices on a LAN

On Tue, 23 Jan 2018 11:12:41 +0000 (UTC)
Curt <curty@free.fr> wrote:

> On 2018-01-23, Andy Hawkins <andy@gently.org.uk> wrote:
> > Hi,
> > In article <20180122185135.GA12212@alum>,
> >            David Wright<deblis@lionunicorn.co.uk> wrote:  
> >>> You should be able to do that with IPv4 too. If DHCP address
> >>> allocation fails,  
> >>
> >> Elaborate on this please. What do you mean by "fails".
> >> What am I meant to want to fail?  
> >
> > If a host that's expecting to receive its address via DHCP receives
> > no response from the DHCP server, it should fall back automatically
> > to a 'link local' address.  
> 
> Is this what you're referring to ("an IPv4 address within the
> 169.254/16 prefix that is valid for communication with other devices
> connected to the same physical (or logical) link," failing--or in the
> absence of--automatic or manual assignment)?
> 
> https://tools.ietf.org/html/rfc3927

Indeed so. It ensures that if the DHCP server temporarily suffers a
problem, any Windows machine on the network (I have no data for Linux)
that gets rebooted stands absolutely zero chance of communicating with
any network machine which hasn't been rebooted. The idea that the
previous working address (even within the lease period), or the
[Windows] manually entered 'alternate' address should be tried does not
arise.

I would hope that the Linux network management utilities take a more
intelligent view of the situation, I haven't yet had cause to find out.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#191434 — Re: stretch and DNS name resolution service for other devices on a LAN

On Tue 23 Jan 2018 at 13:41:31 (+0000), Joe wrote:
> On Tue, 23 Jan 2018 11:12:41 +0000 (UTC)
> Curt <curty@free.fr> wrote:
> 
> > On 2018-01-23, Andy Hawkins <andy@gently.org.uk> wrote:
> > > Hi,
> > > In article <20180122185135.GA12212@alum>,
> > >            David Wright<deblis@lionunicorn.co.uk> wrote:  
> > >>> You should be able to do that with IPv4 too. If DHCP address
> > >>> allocation fails,  
> > >>
> > >> Elaborate on this please. What do you mean by "fails".
> > >> What am I meant to want to fail?  
> > >
> > > If a host that's expecting to receive its address via DHCP receives
> > > no response from the DHCP server, it should fall back automatically
> > > to a 'link local' address.  
> > 
> > Is this what you're referring to ("an IPv4 address within the
> > 169.254/16 prefix that is valid for communication with other devices
> > connected to the same physical (or logical) link," failing--or in the
> > absence of--automatic or manual assignment)?
> > 
> > https://tools.ietf.org/html/rfc3927
> 
> Indeed so. It ensures that if the DHCP server temporarily suffers a
> problem, any Windows machine on the network (I have no data for Linux)
> that gets rebooted stands absolutely zero chance of communicating with
> any network machine which hasn't been rebooted. The idea that the
> previous working address (even within the lease period), or the
> [Windows] manually entered 'alternate' address should be tried does not
> arise.
> 
> I would hope that the Linux network management utilities take a more
> intelligent view of the situation, I haven't yet had cause to find out.

This would all be a step in the wrong direction here. Point (2) was
that using IPv6 over CAT5 avoids swamping the router. (Of course,
that's already been snipped out of the thread.) If the DHCP server
is down, then the router is down, and there are no links to anywhere
except the CAT5 cable I've just connected.

So why would I worry about whether the IPv4 had reconfigured itself
when I've got a perfectly good dedicated IPv6 link between the two
computers? And why should I be worrying about DHCP failures?—the
only time my router is dead is during power cuts.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#191436 — Re: stretch and DNS name resolution service for other devices on a LAN

Hi,

In article <20180123144327.GA6815@alum>,
           David Wright<deblis@lionunicorn.co.uk> wrote:
> This would all be a step in the wrong direction here. Point (2) was
> that using IPv6 over CAT5 avoids swamping the router. (Of course,
> that's already been snipped out of the thread.) If the DHCP server
> is down, then the router is down, and there are no links to anywhere
> except the CAT5 cable I've just connected.
>
> So why would I worry about whether the IPv4 had reconfigured itself
> when I've got a perfectly good dedicated IPv6 link between the two
> computers? And why should I be worrying about DHCP failures?—the
> only time my router is dead is during power cuts.

You were giving your reasoning for using IPv6 as being able to handle direct
cable connections between devices.

I was simply explaining that you don't need IPv6 to do this, as IPv4 will
probably fall back to 'link local' addresses if they receive no response
from a DHCP server (which they won't, as all they're connected to is some
other PC). 

Both devices will allocate themselves an address in the 'link local' range,
and these addresses can then be used for communicating between the devices.

Andy

[toc] | [prev] | [next] | [standalone]

#191438 — Re: stretch and DNS name resolution service for other devices on a LAN

On Tue 23 Jan 2018 at 16:06:01 (-0000), Andy Hawkins wrote:
> Hi,
> 
> In article <20180123144327.GA6815@alum>,
>            David Wright<deblis@lionunicorn.co.uk> wrote:
> > This would all be a step in the wrong direction here. Point (2) was
> > that using IPv6 over CAT5 avoids swamping the router. (Of course,
> > that's already been snipped out of the thread.) If the DHCP server
> > is down, then the router is down, and there are no links to anywhere
> > except the CAT5 cable I've just connected.
> >
> > So why would I worry about whether the IPv4 had reconfigured itself
> > when I've got a perfectly good dedicated IPv6 link between the two
> > computers? And why should I be worrying about DHCP failures?—the
> > only time my router is dead is during power cuts.
> 
> You were giving your reasoning for using IPv6 as being able to handle direct
> cable connections between devices.
> 
> I was simply explaining that you don't need IPv6 to do this, as IPv4 will
> probably fall back to 'link local' addresses if they receive no response
> from a DHCP server (which they won't, as all they're connected to is some
> other PC). 

You still don't quite understand what I'm doing, so here's a diagram
(needs monospace font):

[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.

… but meanwhile *I* can carry on using them both on the Internet
while transfers are taking place, and the TVs are unaffected by
any excessive traffic through the router.

In the case where a desktop is wired to the router, then just that
PC would lose its connectivity to all other machines (except
[My Laptop] of course) during a CAT5 connection (assuming it had
just the usual single ethernet port).

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#191441 — Re: stretch and DNS name resolution service for other devices on a LAN

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.

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. 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. IMO, simple static configuration with 
a ULA prefix, or with a global prefix if you own one, would be much 
reliable.

So Andy is right : you could use IPv4 for this. But rather with static 
configuration than unpredictable APIPA assignments.

[toc] | [prev] | [next] | [standalone]

#192919 — Re: stretch and DNS name resolution service for other devices on a LAN

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. 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 see, Greg only considered IPv6 in terms of the number of addresses
in the IPv4 private ranges, whereas I have this other valuable use.

> 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.)

> 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, having
to edit a MAC in one bash file and push it out to my hosts is hardly
a burden after logging in to the router and typing or pasting things
there. (I hate systems that barely allow you time to sneeze before
they require logging in again.)

> 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.

> 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. The whole point of plugging in a CAT5 cable is
to avoid hogging wireless bandwidth.

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).

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#193020 — Re: stretch and DNS name resolution service for other devices on a LAN

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.

>> 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.

>> 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.

>> 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.

>> 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.

> 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".

[toc] | [prev] | [next] | [standalone]

#193029 — Re: stretch and DNS name resolution service for other devices on a LAN

On 2018-02-24, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
>
> Anyway, we have a saying here which roughly translates to : "you cannot 
> force an unthirsty donkey to drink".

I looked it up (because neither me nor hubby--de vieille souche--recognized
it right off).

 On ne saurait faire boire un âne qui n’a pas soif.

Donkeys being noted for their obstinacy.

We say: You can lead a horse to water but you can't make it drink.

Not *quite* the same; but after all, we cowboys can't ride no donkey
into the sunset.

(A sexist variation: You can lead a girl to Vassar but you can't make
her think.)


-- 
“Be yourself; everyone else is already taken.”
-Oscar Wilde

[toc] | [prev] | [next] | [standalone]

#193092 — 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.

[toc] | [prev] | [next] | [standalone]

#193190 — 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.

[toc] | [prev] | [next] | [standalone]

#193232 — Re: stretch and DNS name resolution service for other devices on a LAN

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.

[toc] | [prev] | [next] | [standalone]

#193235 — Re: stretch and DNS name resolution service for other devices on a LAN

Le 28/02/2018 à 18:14, David Wright a écrit :
> 
> $ 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

Fine. You could also add "allow-hotplug eth0" in case eth0 would be 
discovered late.

> $ ip a
> 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

The IPv4 address is not configured on eth0. No need to check the 
connectivity with ping, it won't work until the IPv4 addresses are 
configured on both ethernet interfaces.

After adding the iface stanza, did you restart the system, or start the 
interface with "ifup -a" ?

[toc] | [prev] | [next] | [standalone]

#193237 — Re: stretch and DNS name resolution service for other devices on a LAN

On Wed 28 Feb 2018 at 19:42:27 (+0100), Pascal Hambourg wrote:
> Le 28/02/2018 à 18:14, David Wright a écrit :
> >
> >$ 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
> 
> Fine. You could also add "allow-hotplug eth0" in case eth0 would be
> discovered late.

OK. Tried that here. The   ip a   is before and after connecting the cable.

$ cat /etc/network/interfaces /etc/network/interfaces.d/directcable-hot-plug 
# 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

allow-hotplug 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: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 00:1c:23:3b:9f:34 brd ff:ff:ff:ff:ff:ff
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
$ 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
$ 

> >$ ip a
> >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
> 
> The IPv4 address is not configured on eth0. No need to check the
> connectivity with ping, it won't work until the IPv4 addresses are
> configured on both ethernet interfaces.
> 
> After adding the iface stanza, did you restart the system, or start
> the interface with "ifup -a" ?

Yes. AFAIK there's no clean way to restart networking, so I've always
rebooted at both ends after making any change.

# ifup -a
# ifup eth0
ifup: interface eth0 already configured
# 

If I reboot but forget to disconnect the cable, then the machines
come up in a deadly embrace, ie each is the default IPv4 gateway
for the other, by way of the cable. OTOH in the absence of
/etc/interfaces.d/directcable or /etc/interfaces.d/directcable-hot-plug,
the machines come up normally, with their gateway through the wlan0
interface, but also able to transfer files or login to one another
through the already connected cable. I just tested that from this
laptop two floors below them both.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#193287 — Re: stretch and DNS name resolution service for other devices on a LAN

Le 28/02/2018 à 21:13, David Wright a écrit :
>>> #
>>> # /etc/interfaces.d/directcable for west 2018-02-25
>>>
>>> auto eth0
>>> iface eth0 inet static
>>>    address 192.168.2.15/24
>>
>> Fine. You could also add "allow-hotplug eth0" in case eth0 would be
>> discovered late.
> 
> OK. Tried that here. The   ip a   is before and after connecting the cable.
(...)
> allow-hotplug eth0
> iface eth0 inet static
>    address 192.168.2.15/24

Note : I wrote "also", not "instead".

> 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

Something went wrong. eth0 is up but the IPv4 address defined in 
/etc/interfaces.d/directcable is not configured.

Could you post the output of

ifdown -v eth0
ifup -v eth0

[toc] | [prev] | [next] | [standalone]

#193321 — Re: stretch and DNS name resolution service for other devices on a LAN

On Fri 02 Mar 2018 at 23:56:02 (+0100), Pascal Hambourg wrote:
> Le 28/02/2018 à 21:13, David Wright a écrit :
> >>>#
> >>># /etc/interfaces.d/directcable for west 2018-02-25
> >>>
> >>>auto eth0
> >>>iface eth0 inet static
> >>>   address 192.168.2.15/24
> >>
> >>Fine. You could also add "allow-hotplug eth0" in case eth0 would be
> >>discovered late.
> >
> >OK. Tried that here. The   ip a   is before and after connecting the cable.
> (...)
> >allow-hotplug eth0
> >iface eth0 inet static
> >   address 192.168.2.15/24
> 
> Note : I wrote "also", not "instead".

Restored.

> >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
> 
> Something went wrong. eth0 is up but the IPv4 address defined in
> /etc/interfaces.d/directcable is not configured.
> 
> Could you post the output of
> 
> ifdown -v eth0
> ifup -v eth0

[…]
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
[…]
# ifdown -v eth0
Parsing file /etc/network/interfaces.d/directcable
ifdown: interface eth0 not configured
# ifup -v eth0
Parsing file /etc/network/interfaces.d/directcable
Configuring interface eth0=eth0 (inet)
run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/ethtool
run-parts: executing /etc/network/if-pre-up.d/linux-wlan-ng-pre-up
run-parts: executing /etc/network/if-pre-up.d/wireless-tools
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
ip addr add 192.168.2.15/255.255.255.0 broadcast 192.168.2.255    dev eth0 label eth0
ip link set dev eth0   up

run-parts --exit-on-error --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/000resolvconf
run-parts: executing /etc/network/if-up.d/avahi-autoipd
run-parts: executing /etc/network/if-up.d/avahi-daemon
run-parts: executing /etc/network/if-up.d/ethtool
run-parts: executing /etc/network/if-up.d/mountnfs
run-parts: executing /etc/network/if-up.d/openssh-server
run-parts: executing /etc/network/if-up.d/openvpn
run-parts: executing /etc/network/if-up.d/upstart
run-parts: executing /etc/network/if-up.d/wpasupplicant
Configuring interface eth0=eth0 (inet)
run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/ethtool
run-parts: executing /etc/network/if-pre-up.d/linux-wlan-ng-pre-up
run-parts: executing /etc/network/if-pre-up.d/wireless-tools
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
ip addr add 192.168.2.15/255.255.255.0 broadcast 192.168.2.255    dev eth0 label eth0
RTNETLINK answers: File exists
Failed to bring up eth0.
# 
[…]
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
    inet 192.168.2.15/24 brd 192.168.2.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::21c:23ff:fe3b:9f34/64 scope link 
       valid_lft forever preferred_lft forever
[…]
$ ip r
default via 192.168.1.1 dev wlan0 
169.254.0.0/16 dev eth0  scope link  metric 1000 
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.15 
192.168.2.0/24 dev eth0  proto kernel  scope link  src 192.168.2.15 
$ 

So, yes, that allows commands like this to work:

$ scp -p /etc/network/interfaces.d/directcable root@192.168.2.10:/tmp

leaving just the two problems:

a) if the cable is connected at boot, the machines' normal default
   routes don't come up properly, but they're only able to connect
   with each other,
b) I have to down and up the interface as root before making transfers.

which leads me to see no reason for withdrawing my original remark:

"I have one valuable use for IPv6 which is point-to-point connections.
I plug a CAT5 cable into the two ends and use predefined functions
to bulk-transfer files with scp."

but just to point out what I didn't make explicit six weeks ago:

1) you don't have to change anything as root in /etc,
2) you don't need root access for configuring the interfaces
   before doing transfers,
3) it's unimportant whether the CAT5 cable is connected at other
   times (particularly when booting).

So I'll be ignoring the Keep Off The Grass signs. Really.

Cheers,
David.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web