On Fri, Mar 17, 2023 at 8:55 PM Timothy M Butterworth <
timothy.m.butterwo...@gmail.com> wrote:
> All,
>
> I have two network interfaces on my PC and I want to route the stub
> interface to the internet facing interface and perform Masquerading. My
> Internet facing NIC is
All,
I have two network interfaces on my PC and I want to route the stub
interface to the internet facing interface and perform Masquerading. My
Internet facing NIC is set to use zone drop and my inside facing zone is
set to use zone trusted.
# enable routing
echo 1 > /proc/sys/net/i
Am Fri, Mar 03, 2023 at 10:09:42PM +0700 schrieb Max Nikulin:
> On 02/03/2023 22:27, Christoph Brinkhaus wrote:
> > Am Thu, Mar 02, 2023 at 09:26:33PM +0700 schrieb Max Nikulin:
> > > On 28/02/2023 17:25, Christoph Brinkhaus wrote:
> > > > I will just inform about the status. Everything is fine now
On 02/03/2023 22:27, Christoph Brinkhaus wrote:
Am Thu, Mar 02, 2023 at 09:26:33PM +0700 schrieb Max Nikulin:
On 28/02/2023 17:25, Christoph Brinkhaus wrote:
I will just inform about the status. Everything is fine now. A word
about systemd-networkd-wait-online: With this service running there
h
Am Thu, Mar 02, 2023 at 09:26:33PM +0700 schrieb Max Nikulin:
> On 28/02/2023 17:25, Christoph Brinkhaus wrote:
> > I will just inform about the status. Everything is fine now. A word
> > about systemd-networkd-wait-online: With this service running there
> > has been even a delay of 1-2 seconds wh
On 28/02/2023 17:25, Christoph Brinkhaus wrote:
I will just inform about the status. Everything is fine now. A word
about systemd-networkd-wait-online: With this service running there
has been even a delay of 1-2 seconds when switching from one console
to a different one (the consoles when X is n
Am Sun, Feb 26, 2023 at 01:21:07PM -0600 schrieb David Wright:
Hello David and Max,
> On Sun 26 Feb 2023 at 19:08:01 (+0100), Christoph Brinkhaus wrote:
> > Am Sun, Feb 26, 2023 at 10:33:19PM +0700 schrieb Max Nikulin:
> > > On 25/02/2023 19:49, Christoph Brinkhaus wrote:
> > > > Now there are no
Hi.
On Mon, Feb 27, 2023 at 10:53:24PM +0100, Geert Stappers wrote:
> (Meanwhile solved with denyinterface in /etc/dhcpcd.conf)
>
>
> > Long story short, consider running "systemctl mask dhcpcd" unless you
> > need dhcpcd to work in a way described above.
>
> The laptop does need to ha
`journalctl --boot`?
> > > > Feb 24 22:24:21 trancilo dhcpcd[1175]: ovs-system: probing for an
> > > > IPv4LL address
> > > > Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: using IPv4LL address
> > > > 169.254.201.7
> > > > Feb 24 22
On Sun 26 Feb 2023 at 19:08:01 (+0100), Christoph Brinkhaus wrote:
> Am Sun, Feb 26, 2023 at 10:33:19PM +0700 schrieb Max Nikulin:
> > On 25/02/2023 19:49, Christoph Brinkhaus wrote:
> > > Now there are no messages reported by journald as above.
> >
> > I am curious if fixing unbound and so networ
Am Sun, Feb 26, 2023 at 10:33:19PM +0700 schrieb Max Nikulin:
> On 25/02/2023 19:49, Christoph Brinkhaus wrote:
> > Now there are no messages reported by journald as above.
>
> I am curious if fixing unbound and so network-online.target helped to avoid
> 169.254.x.y address in your case. Can fetch
t
> networkctl status ovs-system
This long thread seems to be turning into a game of 20 Questions.
It would be nice to see some of the OP's configuration, rather
than just a few log extracts and a "How do I get rid of …".
As it is, the OP has said "no more route 169.25
Am Sun, Feb 26, 2023 at 10:33:19PM +0700 schrieb Max Nikulin:
> On 25/02/2023 19:49, Christoph Brinkhaus wrote:
> > Now there are no messages reported by journald as above.
>
> I am curious if fixing unbound and so network-online.target helped to avoid
> 169.254.x.y address in your case.
I am no
On 25/02/2023 19:49, Christoph Brinkhaus wrote:
Now there are no messages reported by journald as above.
I am curious if fixing unbound and so network-online.target helped to
avoid 169.254.x.y address in your case. Can fetchmail work without a
kludge you added to achieve some delay? My expect
On 26/02/2023 18:18, Geert Stappers wrote:
AIUI is systemd-networkd the main player, dhcpcd some helper
and NetworkManager for contact with user.
First of all, I would not touch dhcpcd.conf for a while.
Is it assumed that ovs-system should get its IP address from DHCP?
If I understand it corr
s-system: soliciting a DHCP lease
> > > ...
> > > Feb 24 22:24:21 trancilo dhcpcd[1175]: ovs-system: probing for an IPv4LL
> > > address
> > > Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: using IPv4LL address
> > > 169.254.201.7
> > > Fe
LL
> > address
> > Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: using IPv4LL address
> > 169.254.201.7
> > Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: adding route to
> > 169.254.0.0/16
>
> Let's try a straightforward approach for
ress
> 169.254.201.7
> Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: adding route to
> 169.254.0.0/16
Let's try a straightforward approach for starters:
echo denyinterfaces ovs-system >> /etc/dhcpcd.conf
Reco
...
Feb 24 22:24:16 trancilo dhcpcd[1175]: ovs-system: soliciting a DHCP lease
...
Feb 24 22:24:21 trancilo dhcpcd[1175]: ovs-system: probing for an IPv4LL address
Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: using IPv4LL address
169.254.201.7
Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs
Am Fri, Feb 24, 2023 at 07:41:26PM +0100 schrieb Christoph Brinkhaus:
I reply to myself thanking Max.
> Am Fri, Feb 24, 2023 at 10:09:34PM +0700 schrieb Max Nikulin:
> > On 22/02/2023 23:45, Christoph Brinkhaus wrote:
> > > Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin:
> > > > On
On Fri, Feb 24, 2023 at 9:51 PM David Wright wrote:
>
> On Fri 24 Feb 2023 at 22:43:49 (+0100), Geert Stappers wrote:
> > [...]
> I see you rebooted, and you get the same address. It's ambiguous as
> to why: it could have been stored, which makes things more efficient
> when a number of machines
gt; Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name Version Architecture Description
> +++-==---
On 25/02/2023 04:43, Geert Stappers wrote:
Having `apt purge avahi-autoipd` still gets me "auto IPv4 address"
Ideas how to avoid it are welcome.
Have you checked "journalctl --boot" for logs which component assigns
169.254.x.y address and for various errors related to network?
I am not fam
Architecture Description
+++-==---=
un avahi-autoipd(no description available)
$ uptime
22:45:25 up 1 min, 1 user, load average: 0.02, 0.04, 0.05
$ ip route | grep system
169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004
$
Groeten
Geert Stappers
--
Silence is hard to parse
On Fri 24 Feb 2023 at 19:41:26 (+0100), Christoph Brinkhaus wrote:
> Am Fri, Feb 24, 2023 at 10:09:34PM +0700 schrieb Max Nikulin:
> > On 22/02/2023 23:45, Christoph Brinkhaus wrote:
> > > Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin:
> > > > On 22/02/2023 01:26, Christoph Brinkhaus
Am Fri, Feb 24, 2023 at 10:09:34PM +0700 schrieb Max Nikulin:
> On 22/02/2023 23:45, Christoph Brinkhaus wrote:
> > Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin:
> > > On 22/02/2023 01:26, Christoph Brinkhaus wrote:
> > > > [Unit]
> > > > Description=A remote mail retrieval and forw
On 22/02/2023 23:45, Christoph Brinkhaus wrote:
Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin:
On 22/02/2023 01:26, Christoph Brinkhaus wrote:
[Unit]
Description=A remote mail retrieval and forwarding utility
After=network-online.target opensmtpd.service unbound.service
Requires=
On 22/02/2023 19:40, Greg Wooledge wrote:
On Wed, Feb 22, 2023 at 02:04:58PM -0500, Jeffrey Walton wrote:
Maybe the 'w' is not matching anything.
I thought eth0 and wlan0 went the way of the dinosaurs. I thought with
Consistent Network Device Names and biosdevname, the name will begin
with a
On Wed, Feb 22, 2023 at 02:04:58PM -0500, Jeffrey Walton wrote:
> Maybe the 'w' is not matching anything.
>
> I thought eth0 and wlan0 went the way of the dinosaurs. I thought with
> Consistent Network Device Names and biosdevname, the name will begin
> with a 'p' or 'em', not a 'w', and based on
On Wed, Feb 22, 2023 at 1:43 PM David Wright wrote:
>
> On Tue 21 Feb 2023 at 13:48:58 (-0500), Jeffrey Walton wrote:
> > On Tue, Feb 21, 2023 at 1:26 PM Christoph Brinkhaus
> > wrote:
> > > [...]
> > > > But backing up... I suspect there's something wrong with your static
> > > > ip address assi
On Wed 22 Feb 2023 at 17:45:40 (+0100), Christoph Brinkhaus wrote:
> Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin:
> > On 22/02/2023 01:26, Christoph Brinkhaus wrote:
> > > > > I have no idea if it is possible to estimate a DHCP response
> > > > > time.
> >
> > Since static IP addr
etworkd from systemd-networking, and (b) purged of avahi
packages to eliminate 169.254.x.y addresses. So I'm not sure what
there is to fix here.
But (a) raises the question of what systemd was running /before/,
which was presumably what was giving rise to 169.254.x.y addresses.
And, while I ca
Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin:
> On 22/02/2023 01:26, Christoph Brinkhaus wrote:
> > > > I have no idea if it is possible to estimate a DHCP response
> > > > time.
>
> Since static IP address is assigned, it does not matter. I expected DHCP
> configuration and that d
On 22/02/2023 01:26, Christoph Brinkhaus wrote:
I have no idea if it is possible to estimate a DHCP response
time.
Since static IP address is assigned, it does not matter. I expected DHCP
configuration and that delay may be noticed in `journalctl -b 0` logs.
[Unit]
Description=A remote mail
On Tue, Feb 21, 2023 at 01:48:58PM -0500, Jeffrey Walton wrote:
> On Tue, Feb 21, 2023 at 1:26 PM Christoph Brinkhaus
> wrote:
> > [...]
> > > But backing up... I suspect there's something wrong with your static
> > > ip address assignment. The address is already taken, the netmask is
> > > wrong,
On Tue, Feb 21, 2023 at 1:26 PM Christoph Brinkhaus
wrote:
> [...]
> > But backing up... I suspect there's something wrong with your static
> > ip address assignment. The address is already taken, the netmask is
> > wrong, or the gateway is wrong.
> >
> > Looking back through this thread, I did no
Am Tue, Feb 21, 2023 at 01:06:01PM -0500 schrieb Jeffrey Walton:
> On Tue, Feb 21, 2023 at 12:45 PM Christoph Brinkhaus
> wrote:
> > Am Tue, Feb 21, 2023 at 11:00:56PM +0700 schrieb Max Nikulin:
> > > On 20/02/2023 21:44, Christoph Brinkhaus wrote:
> > > > Am Mon, Feb 20, 2023 at 09:59:20AM +0700
Hi.
On Tue, Feb 21, 2023 at 06:44:38PM +0100, Christoph Brinkhaus wrote:
> I have no idea if it is possible to estimate a DHCP response time.
sudo nmap --script broadcast-dhcp-discover
Reco
On Tue, Feb 21, 2023 at 12:45 PM Christoph Brinkhaus
wrote:
> Am Tue, Feb 21, 2023 at 11:00:56PM +0700 schrieb Max Nikulin:
> > On 20/02/2023 21:44, Christoph Brinkhaus wrote:
> > > Am Mon, Feb 20, 2023 at 09:59:20AM +0700 schrieb Max > > > > Perhaps to
> > > get rid of 169.254.x.y addresses, it
Am Tue, Feb 21, 2023 at 11:00:56PM +0700 schrieb Max Nikulin:
> On 20/02/2023 21:44, Christoph Brinkhaus wrote:
> > Am Mon, Feb 20, 2023 at 09:59:20AM +0700 schrieb Max Nikulin:
Hello Max,
> > > Perhaps to get rid of 169.254.x.y addresses, it is enough to properly
> > > configure network interfac
On 20/02/2023 21:44, Christoph Brinkhaus wrote:
Am Mon, Feb 20, 2023 at 09:59:20AM +0700 schrieb Max Nikulin:
Perhaps to get rid of 169.254.x.y addresses, it is enough to properly
configure network interface, either to ensure that DHCP server is available
or to assign a static address. After tha
On 2023-02-19 at 11:21, Geert Stappers wrote:
> Hi,
>
> Having installed package openvswitch-switch and doing `ip route` I do get
>
> 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004
>
>
> What can be done to prevent that "zeroconf"
On Mon, Feb 20, 2023 at 9:28 AM wrote:
>[...]
> --
> rhk
>
> (sig revised 20221206)
>
> If you reply: snip, snip, and snip again; leave attributions; avoid HTML;
> avoid top posting; and keep it "on list". (Oxford comma (and semi-colon)
> included at no charge.) If you revise the topic, change t
Am Mon, Feb 20, 2023 at 09:59:20AM +0700 schrieb Max Nikulin:
Hi Max,
> On 19/02/2023 23:35, Christoph Brinkhaus wrote:
> > Am Sun, Feb 19, 2023 at 05:21:47PM +0100 schrieb Geert Stappers:
> > > Having installed package openvswitch-switch and doing `ip route` I do get
> >
On Monday, February 20, 2023 04:05:19 AM to...@tuxteam.de wrote:
> On Mon, Feb 20, 2023 at 02:42:59AM -0500, Jeffrey Walton wrote:
> > On Mon, Feb 20, 2023 at 2:27 AM wrote:
> [...]
>
> > > That's what Microsoft calls them. I prefer the RFC's IP4LL.
> >
> > And Wireshark (https://wiki.wireshark.
On Mon, Feb 20, 2023 at 02:42:59AM -0500, Jeffrey Walton wrote:
> On Mon, Feb 20, 2023 at 2:27 AM wrote:
[...]
> > That's what Microsoft calls them. I prefer the RFC's IP4LL.
>
> And Wireshark (https://wiki.wireshark.org/APIPA.md) and Cisco
> (https://study-ccna.com/apipa-automatic-private-ip-a
On Mon, Feb 20, 2023 at 2:27 AM wrote:
>
> On Mon, Feb 20, 2023 at 12:53:25AM -0500, Jeffrey Walton wrote:
> > On Sun, Feb 19, 2023 at 11:22 AM Geert Stappers
> > wrote:
> > >
> > > Having installed package openvswitch-switch and doing `ip route` I do get
On Mon, Feb 20, 2023 at 12:53:25AM -0500, Jeffrey Walton wrote:
> On Sun, Feb 19, 2023 at 11:22 AM Geert Stappers wrote:
> >
> > Having installed package openvswitch-switch and doing `ip route` I do get
> >
> > 169.254.0.0/16 dev ovs-system scope link src 169.254.2
On Sun, Feb 19, 2023 at 11:22 AM Geert Stappers wrote:
>
> Having installed package openvswitch-switch and doing `ip route` I do get
>
> 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004
Those are called "APIPA's". Automatic Private IP Address
the ovs-system
network device? My guess is that there will be no 169.254.x.y address
and route when this failure is fixed.
I am unsure if it is possible to configure avahi-autoipd (or another
zeroconf daemon actually running) to ignore specific nework interface.
The following is unrelated to
On Mon 20 Feb 2023 at 09:59:20 (+0700), Max Nikulin wrote:
> On 19/02/2023 23:35, Christoph Brinkhaus wrote:
> > Am Sun, Feb 19, 2023 at 05:21:47PM +0100 schrieb Geert Stappers:
> > > Having installed package openvswitch-switch and doing `ip route` I do get
> > >16
On 19/02/2023 23:35, Christoph Brinkhaus wrote:
Am Sun, Feb 19, 2023 at 05:21:47PM +0100 schrieb Geert Stappers:
Having installed package openvswitch-switch and doing `ip route` I do get
169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004
Please have a look at https
Am Sun, Feb 19, 2023 at 07:57:56PM +0100 schrieb Geert Stappers:
Hi Geert,
> On Sun, Feb 19, 2023 at 12:21:36PM -0500, Stefan Monnier wrote:
> > >> Having installed package openvswitch-switch and doing `ip route` I do get
> > >> 169.254.0.0/16 dev ovs-system scope li
On Sun, Feb 19, 2023 at 12:21:36PM -0500, Stefan Monnier wrote:
> >> Having installed package openvswitch-switch and doing `ip route` I do get
> >> 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004
> >>
> >> What can be done to pre
>> Having installed package openvswitch-switch and doing `ip route` I do get
>> 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004
>>
>> What can be done to prevent that "zeroconf"
>> configures interface `ovs-system`?
>
> Pleas
Am Sun, Feb 19, 2023 at 05:21:47PM +0100 schrieb Geert Stappers:
Hello Geert,
> Having installed package openvswitch-switch and doing `ip route` I do get
> 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004
>
> What can be done to prevent that "zeroc
Hi,
Having installed package openvswitch-switch and doing `ip route` I do get
169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004
What can be done to prevent that "zeroconf"
configures interface `ovs-system`?
Groeten
Geert Stappers
--
Silence is hard to parse
On 2022-12-11 23:59, Jason Bigelow wrote:
I haven't experienced similar issues on Windows and Android devices on
the
same LAN, so I'm thinking it's an issue with my Debian Machine.
Scratch that, I have just figured out that nothing in the house seems to
work
on IPv6, not the Windows machines
On 2022-12-12 06:26, Georgi Naplatanov wrote:
Try to comment or delete the following line:
ip6-privacy=2
Kind regards
Georgi
Unfortunately that hasn't helped:
$ host -6 localhost
;; communications error to 2620:0:ccc::2#53: timed out
;; communications error to 2620:0:ccc::2#53: timed out
On 12/11/22 20:12, Jason Bigelow wrote:
On 2022-12-12 04:32, Georgi Naplatanov wrote:
Hi Jason,
how did you configure your Ethernet card - with Network Manager or?
Please provide configuration.
The above errors means that your system is configured to use DNS
server on localhost (IPv6 - ::1)
On 2022-12-12 04:32, Georgi Naplatanov wrote:
Hi Jason,
how did you configure your Ethernet card - with Network Manager or?
Please provide configuration.
The above errors means that your system is configured to use DNS
server on localhost (IPv6 - ::1) and connection was refused. So this
is
brary
ii libnl-3-200:amd64 3.7.0-0.2+b1 amd64 library
for dealing with netlink sockets
ii libnl-genl-3-200:amd64 3.7.0-0.2+b1 amd64 library for dealing
with netlink sockets - generic netlink
ii libnl-route-3-200:amd64 3.7.0-0.2+b1 amd64 library for
dealing with netl
$ ip route
default via 10.0.0.138 dev enp6s0 proto dhcp src 10.0.0.96 metric 100
10.0.0.0/24 dev enp6s0 proto kernel scope link src 10.0.0.96 metric 100
$ ip -6 route
::1 dev lo proto kernel metric 256 pref medium
2001:8003:234d:a600::/64 via fe80::dad7:75ff:fe4d:2452 dev enp6s0 proto
ra metric
^^^
This is an IPv6 address
> inet6 2001:8003:234d:a600:692:26ff:fed1:fa77/64 scope global dynamic
^^
This is an IPv6 address
What do "ip route" and "ip -6 route" give for output?
--
Marxist Law of Dis
brary
ii libnl-3-200:amd64 3.7.0-0.2+b1 amd64
library for dealing with netlink sockets
ii libnl-genl-3-200:amd64 3.7.0-0.2+b1
amd64 library for dealing with netlink sockets - generic netlink
ii libnl-route-3-200:amd64 3.7.0-0.2+b1
those routes
"the default gateway before the VPN was up".
Is there a way to do this ?
It may be through a dispatcher script at vpn-preup time, but I'm not sure by
reading the doc if the routes have been changed at that time or not.
The original route must still be there or the
Hi,
I use a vpn with network manager which routes everything through it.
I'd like to add some exceptions for local or not so local ressources
that cannot be reached through the VPN.
The ideal situation would be to be able to give as gateway for those
routes "the default gateway before the VPN w
ient lines in the logs, but didn't see
> anything suspect.
ie, dhclient is running …
> But when I issued the above grep¹ I found lots of
> lines like this:
> Apr 29 09:19:20 dhcpcd[982]: eno1: adding route to 169.254.0.0/16
> Apr 29 09:19:20 dhcpcd[982]: eno1: adding default route
On Sat, Apr 30, 2022 at 03:29:34PM +0800, Jeremy Ardley wrote:
> One other thing to check is if dhclient is running.
Or dhcpcd. We get a *lot* of that from people who think or claim
they're running Debian, when they're actually running "some variant
of Raspbian that's been customized even more".
On 29/4/22 5:30 pm, nim...@paralog.it wrote:
On gio, 2022-04-28 at 05:26 +0800, Jeremy Ardley wrote:
I can definitely esclude that. I turned off my machine and nobody
answer to ping to its address.
One other thing to check is if dhclient is running.
It can be started by NetworkManager
; > navigate on the web. But I could ping the gateway, I could resolve
> > names... just cannot reach the network (most commands just issued
> > the
> > classic "network is unreachable" message).
> >
> > thinking it was a route problem, I issued "ip r
On 29/4/22 5:30 pm, nim...@paralog.it wrote:
Here are only the syslog lines containing NetworkManager and the time
of the reboot. I also removed hostname to shorten the text a bit.
NetworkManager may not be the only agent involved. Perhaps extracting
syslog entries around the NetworkMana
tric 100
192.168.0.0/23 via 192.168.1.113 dev eno1 proto static metric 100
I just have to delete the wrong default route and add the good one as I
wrote in the original message. Here the "ip r" currently working (I can access
the internet without problems):
default via 192.168.1.113
st cannot reach the network (most commands just issued the
> classic "network is unreachable" message).
>
> thinking it was a route problem, I issued "ip route" on the terminal
> and got this default route:
>
> default dev eno1 scope link src 169.254.30.62 metri
ck that NM didn't somehow acquire a spurious route. Edit Connections
-> Your connection, little gear wheel in the lower left. IPv4 Settings
-> Routes.
Are you sure you aren't getting that spurious route from the DHCP
server? To check on that, add a short script to
/etc/Network
On 28/4/22 4:49 am, nimrod wrote:
default dev eno1 scope link src 169.254.30.62 metric 202
the 169.254 address is Used for link-local addresses between two hosts
on a single link when no IP address is otherwise specified, such as
would have normally been retrieved from a DHCP server.
So so
rk is unreachable" message).
thinking it was a route problem, I issued "ip route" on the terminal
and got this default route:
default dev eno1 scope link src 169.254.30.62 metric 202
I deleted it and add the good one:
ip route add default via 192.168.1.113 dev eno1
and I
On Fri, Oct 04, 2019 at 08:47:57AM +0200, Johann Spies wrote:
How do I remove the first default route in this list?
$ sudo ip route list
default dev enp0s25 scope link
default via 192.168.1.1 dev wlo1 proto dhcp metric 600
…
sudo ip route del default dev enp0s25 scope link
Basically write
On 10/4/19, Johann Spies wrote:
> This problem arised recently after an upgrade (running sid)
>
> How do I remove the first default route in this list?
I'd leave both in - that way things should Just Work if either of the
interfaces goes down.
The question then becomes which inter
Johann Spies wrote:
> $ sudo ip route list
> default dev enp0s25 scope link
> default via 192.168.1.1 dev wlo1 proto dhcp metric 600
> 169.254.0.0/16 dev wlo1 scope link metric 1000
Have you tried specifying the device and/or the GW address, to narrow
down which route you want to
This problem arised recently after an upgrade (running sid)
How do I remove the first default route in this list?
ip route del default
does not do it. When I disable enp0s25 the second line (via 192.168.1.1)
will be the only and correct default route. In that case "ip route del
default&
y helpful. What does it mean that "internet goes down" ? This is
a user experience, not a technical fact. We need technical facts.
routing table is ok
Can you show it with ip route ? Also the output of ip addr.
Can you still reach (ping) the modem from the router ?
sure
So it is
What manages the wan interface ? /etc/network/interfaces,
statically with /etc/network/interfaces
NetworkManager, other ?
I don't have X
Which server ?
debian 9.x
my server has 2 network interfaces
What does it mean exactly ?
that, suddently internet goes down... routing table is ok
addr" and "ip
route" on the router.
Can you still reach (ping) the modem from the router ?
What is the output of "traceroute 8.8.8.8" from the router ?
If the above works, did you check DNS resolution (with host or dig) ?
You can compare these results with the results w
sorry for the mistake :-/
network /30 on both
Pol
On 11/03/2017 11:57 AM, Pascal Hambourg wrote:
Le 03/11/2017 à 10:32, Debian EN a écrit :
Hello to all :-) I've fastweb italian adsl
2 networks interfaces:
wan 192.168.0.2/31 --> modem 192.168.0.1/31
eth0 192.168.1.0/24
everything works but
Le 03/11/2017 à 10:32, Debian EN a écrit :
Hello to all :-) I've fastweb italian adsl
2 networks interfaces:
wan 192.168.0.2/31 --> modem 192.168.0.1/31
eth0 192.168.1.0/24
everything works but:
Really ? It shouldn't.
192.168.0.1/31 and 192.168.0.2/31 are not in the same subnet.
$ ipcalc 19
SL
sometimes removing route and re-add routing works
route del default gw 192.168.0.1
route add default gw 192.168.0.1
sometimes no
which kind of problem can be?
thanks!
Pol
test/devel routers I have different ethernet configurations.
I wanted to configure NetworkManger to handle wlan0 as my primary
interface for having the the default route.
The behaviour of NetworkManger is that it will always use eth0.
So if I plugin and plugout an ethernet cable NetworkManger
Matt Ventura wrote:
> On 01/23/2015 04:05 AM, Sven Hartge wrote:
>> Matt Ventura wrote:
> Well, that confirms my original suspicion. The F5 VPN is throwing its
> default route over the original one, and that's causing traffic to the
> OpenVPN server to try to route ove
On 01/23/2015 04:05 AM, Sven Hartge wrote:
Matt Ventura wrote:
me@client:~$ date ; sudo route -n
Thu Jan 22 11:48:48 EST 2015
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
0.0.0.0 10.144.15.100 128.0.0.0 UG1 0
Matt Ventura wrote:
>> me@client:~$ date ; sudo route -n
>> Thu Jan 22 11:48:48 EST 2015
>> Kernel IP routing table
>> Destination Gateway Genmask Flags Metric RefUse Iface
>> 0.0.0.0 10.144.15.100 128.0.0.0 UG1
On 1/22/2015 3:55 PM, Tom Roche wrote:
summary:
me@client:~$ sudo route del default ppp0
SIOCDELRT: No such process
me@client:~$ sudo route del default dev ppp0
SIOCDELRT: No such process
me@client:~$ sudo route del -net default dev ppp0
SIOCDELRT: No such process
me@client:~$ sudo route del
summary:
me@client:~$ sudo route del default ppp0
SIOCDELRT: No such process
me@client:~$ sudo route del default dev ppp0
SIOCDELRT: No such process
me@client:~$ sudo route del -net default dev ppp0
SIOCDELRT: No such process
me@client:~$ sudo route del -net default gw 10.144.15.234 dev ppp0
Onur Aslan wrote:
> Btw I tried to send this to debian-firewall but I got quota exceed error.
Your message was successfully posted to the maliing list just fine.
There is even a follow-up message posted there.
http://lists.debian.org/debian-firewall/2012/07/msg0.html
That quota exceeded er
Hi.
I want to use my vpn for outgoing port 80 connections in my Debian router.
My current route table:
# ip route
default dev ppp0 scope link
95.9.x.x dev ppp0 proto kernel scope link src 95.9.x.x
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1
nding)
> different network cards together something which I often need to do is
> to set up a route between them. (Windows calls this Internet
> Sharing.) If you were trying different configurations for the
> purposes of learning then I would definitely queue up a router
> configur
tive of gaining experience with
>
different configurations.
>
> In this case a configuration which might be more generally useful
>
would be a router configuration. Instead of bridging (or bonding)
>
different network cards together something which I often need to do is
>
to set up a route b
case a configuration which might be more generally useful
would be a router configuration. Instead of bridging (or bonding)
different network cards together something which I often need to do is
to set up a route between them. (Windows calls this Internet
Sharing.) If you were trying different configurat
Seyyed Mohtadin Hashemi wrote:
> I have a question though: The server is connected to the internet via eth0
> (it gets IP from external DHCP server), will i be able to connect to the
> br0 from the eth0?
Yes. You didn't show that part of your configuration. I expect it
will have a default gatewa
To clarify what i want: I want to setup the connection so that server is
able to "speak" to both desktops (and vice versa) AND the desktops should
be able to "speak" with each other.
You may be right that it is a bridge i need, i'm not that experienced in
setting up networks. I will try the bridg
1 - 100 of 538 matches
Mail list logo
