Subj : Re: Networking Questions
To : acn
From : Avon
Date : Fri Jun 18 2021 08:55 pm
On 18 Jun 2021 at 10:15a, acn pondered and said...
ac> Hallo Avon,
Hi, and thanks for the reply :)
ac> First, if you prefer "eth0" over "enp4sdfsd523", you can change this
ac> behaviour in the kernel commandline by adding these parameters:
ac> net.ifnames=0 biosdevname=0
I don't know how/where to do that in debian 10 sorry
ac> The enps432 devices get its name during bootup with the intention to be
ac> predictible, so that eth0 won't be eth1 on the next boot.
I don't mind using the name defined on boot, it's just getting it talking to
my rpi that's running the he.net tunnel that I think?? is the issue.
ac> On my BBS machine, I use the following lines in /etc/network/interfaces:
ac>
ac> ==== cut here for new monitor ====
ac> auto lo
ac> iface lo inet loopback
ac>
ac> auto eth0
ac> iface eth0 inet static
ac> address 192.168.14.85
ac> netmask 255.255.255.0
ac> gateway 192.168.14.1
ac> dns-search narnia.lan
ac> dns-nameservers 192.168.14.5 192.168.14.1
ac>
ac> iface eth0 inet6 static
ac> privext 0
ac> address 2001:470:540b::f1d0:2:240:5824/64
At the moment I have left mine as
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
avon@orac:/$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
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: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UP group default qlen 1000
link/ether 1c:6f:65:d7:70:04 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.131/24 brd 192.168.1.255 scope global noprefixroute enp4s0
valid_lft forever preferred_lft forever
inet6 2001:470:c:123::200/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::1e6f:65ff:fed7:7004/64 scope link noprefixroute
valid_lft forever preferred_lft forever
ac> I just noticed that in your "ip a" output, your inet6 entries have the
ac> option "noprefixroute" set.
ac> As far as I understand it, this means that no default route for this
ac> address has been (automatically) added.
This I think is my problem, and I've been trying to google and test possible
fixes all night, but so far no joy.
ac> So, if your problem persists, try looking at your IPv6 routing table
ac> using "route -n6" and search for your IPv6 default route, in my case it
Here's mine
avon@orac:/$ sudo route -n6
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
::1/128 :: U 256 2 0 lo
2001:470:c:123::/64 :: U 100 2 0
enp4s0
2001:470:c:123::/64 :: U 256 1 0
enp4s0
fe80::/64 :: U 100 1 0
enp4s0
::/0 2001:470:c:123::5 UG 100 5 0
enp4s0
::1/128 :: Un 0 7 0 lo
2001:470:c:123::200/128 :: Un 0 5 0
enp4s0
fe80::1e6f:65ff:fed7:7004/128 :: Un 0 3 0
enp4s0
ff00::/8 :: U 256 6 0
enp4s0
::/0 :: !n -1 1 0 lo
ac> How are you advertising your prefix in your LAN?
It's using Radvd on my Rpi which is on the LAN and is set up as the end point
for the he.net tunnel.
ac> In my case, my tunnel endpoint is on my DSL router (AVM FritzBox) and
ac> "router advertisement" is active here.
Rpi for me. in all my mucking about I must have once found a way for the
debian box to see the Rpi as it did pick up a dynamic IPv6 once and I could
ping that from outside my LAN... stuffed if I recall how now :(
ac> As far as I know, via router advertisement also the default gateway can
ac> be sent to the clients. Is this configured?
Don't know it's been years since I set the Pi up... the windows boxes work
fine I am cautious about touching the pi gateway/endpoint of the tunnel.
