Mohsen Pahlevanzadeh wrote:
> I don't want to use set proxy in firefox and other application, but
> I want to send any packets to 127.0.0.1: and my program itself
> send to eth0.
>
> OK, there is an underlying assumption that you are not telling
> us.
>
> Why do you want to do
hink)
It uses the (must be local) nat rules to work out where the packet was
originally intended for.
Make the squid host the default route for your traffic.
On the squid host, nat everything to the proxy port
Now I'm not posting in my sleep :-) I suspect that squid handles this in
the re
On 4/30/25 11:47 PM, Dan Ritter wrote:
Mohsen Pahlevanzadeh wrote:
On 4/30/25 4:29 PM, Jonathan Dowland wrote:
On Wed Apr 30, 2025 at 10:19 AM BST, Mohsen Pahlevanzadeh wrote:
I want to send any packet to 127.0.0.1: and it se
les to work out where the packet was
originally intended for.
Make the squid host the default route for your traffic.
On the squid host, nat everything to the proxy port
Mohsen Pahlevanzadeh wrote:
>On 4/30/25 4:29 PM, Jonathan Dowland wrote:
>
> On Wed Apr 30, 2025 at 10:19 AM BST, Mohsen Pahlevanzadeh wrote:
>
> I want to send any packet to 127.0.0.1: and it sends my packets
> to internet. my outgoing interface is eth0.
>
> You can
outgoing interface is eth0.
You need to set up a virtual network interface, using /dev/net/tun, and
configure it to be the default route.
Do you know any documentation?
Then you will have to encapsulate all you get from /dev/net/tun into a
packet for your program
On 4/30/25 4:29 PM, Jonathan Dowland
wrote:
On Wed Apr 30,
2025 at 10:19 AM BST, Mohsen Pahlevanzadeh wrote:
I want to send any packet to
127.0.0.1: and it sends my packets to internet. my outgoing
interface is eth0.
On 4/30/25 4:29 PM, Jonathan Dowland wrote:
On Wed Apr 30, 2025 at 10:19 AM BST, Mohsen Pahlevanzadeh wrote:
I want to send any packet to 127.0.0.1: and it sends my packets
to internet. my outgoing interface is eth0.
You can use socat¹ to listen on a port and forward received packets
el
On Wed Apr 30, 2025 at 10:19 AM BST, Mohsen Pahlevanzadeh wrote:
I want to send any packet to 127.0.0.1: and it sends my packets to
internet. my outgoing interface is eth0.
You can use socat¹ to listen on a port and forward received packets
elsewhere. But…
I don't want to use set proxy i
ing /dev/net/tun, and
configure it to be the default route.
Then you will have to encapsulate all you get from /dev/net/tun into a
packet for your program listening on 127.0.0.1: to attach all the
headers that do not fit into UDP or TCP. But at this point you might as
well realize that your ini
Dear all,
I have a debian machine and my program listen to such as: 127.0.0.1
I want to send any packet to 127.0.0.1: and it sends my packets to
internet. my outgoing interface is eth0.
I don't want to use set proxy in firefox and other application, but I
want to send any packets t
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
1 - 100 of 549 matches
Mail list logo
