Re: connecting to two networks simultaneously on buster
- Date: Fri, 24 Aug 2018 16:08:38 -0400
- From: Lee <ler762@xxxxxxxxx>
- Subject: Re: connecting to two networks simultaneously on buster
On 8/24/18, David Wright <deblis@xxxxxxxxxxxxxxxxx> wrote:
> I don't think I understand any part of your answer as it has too many
> promouns (this and thats) and not enough nouns (specifics).
> On Fri 24 Aug 2018 at 13:50:50 (+0200), Vincent Lefevre wrote:
>> On 2018-08-22 19:09:24 -0500, David Wright wrote:
>> > On Wed 22 Aug 2018 at 10:29:01 (+1000), Zenaan Harkness wrote:
>> > > Static configuration is by necessity (basically) custom setup - i.e.
>> > > requires manual intervention.
>> > >
>> > > Automatic means the above /e/n/i lines would look like this instead:
>> > >
>> > > # the USB network for my Gemini
>> > > auto enp0s29u1u1
>> > > iface enp0s29u1u1 inet dhcp
>> > >
>> > >
>> > > But of course for network-manager, it would by default use dhcp, and
>> > > you would not manually configure for DHCP in your /e/n/i file.
>> > >
>> > > Always remember you can do an in-foreground one shot DHCP like so:
>> > >
>> > > sudo dhclient -d enp0s29u1u1
>> > >
>> > > which has the benefit that you can easily kill it as desired with a
>> > > CTRL-c, AND you can monitor its output immediately, AND you will see
>> > > immediately if you got the device/ interface name wrong. What's not
>> > > to like?
>> > I'm not sure I understand using DHCP to get the ipaddr for the
>> > network running through the USB connection. Could you explain?
>> That's the usual way to do it,
> Where is the DHCP server running that hands out the dynamic address?
There isn't one. DHCP client requests an address, doesn't get one,
falls back to
rfc-3927 Dynamic Configuration of IPv4 Link-Local Addresses
caveat: I just tried it on my laptop running debian & not only did it
not work, it declared the ethernet interface down & removed the ipv6
link-local address!!! But my experience w/ debian is measured in
days, so hopefully it's just something I've got configured wrong & not
an OS deficiency.
>> because you don't necessarily know
>> what IP address you should get, and it can entirely be dynamic.
> Where does "should" come into this?
I'm guessing that "should" is that you need an unused address on the
DHCP can figure that out for you & "should" fall back to a link-local
address (ipv4: 169.254.0.0/16) if the dhcp client doesn't get an
If anyone knows how to make that happen on Debian, please share
>> Moreover, one often wants to do this to use the phone's modem,
>> and this will also set up a default route automatically (but this
>> is not what you want, AFAIK).
> So "this" process, whatever it is, doesn't do the correct thing. and
> yet we were asked "What's not to like?".
If debian can get you an ipv4 link-local address if dhcp fails _and_
you can configure an interface route metric to prefer wireless
routes.. yeah, it ain't all that bad.
> Nevertheless, I'd like to
> know what "this" process is as it should be the answer to my
> knuckle-rapping problem which is very similar to the OP's:
> . two computers connected to a wireless router with IPv4,
> . a direct link between the two computers (CAT5 cable in my case),
> . the direct link must (de)configure itself when the cable is
which is normal auto-sense
> . the direct link must never get set up as the default route,
Can you configure an interface route metric such that wireless routes
are used for everything except the ethernet interface subnet? (works
for me on windows)
Maybe you'll never use the ethernet connection for internet access,
but I do sometimes & it's nice when everything Just Works: wireless
routes take precedence but when there's no wireless and dhcp gets me
an address on the ethernet connection I can still get out to the
internet without having to do or change anything.
> . that's Never, even if the computers are booted while the CAT5 cable
> is attached but the router's wireless signal is temporarily absent.
> I do this very simply, just by using IPv6 over the cable:
> but what's being discussed in this thread should be able to do
> what was demanded by the anti-IPv6linklocals.
If I couldn't get an ipv6 assignment @work then yes,
is the way to go. But @home?? unless there's some other motivation
for using a globally unique address, it's totally not worth the
get out the popcorn time: Want to watch the anti-IPv6linklocals
explode? Have them read rfc 7404
Using Only Link-Local Addressing inside an IPv6 Network