https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261129
Patrick M. Hausen changed:
What|Removed |Added
CC||p...@hausen.com
--- Comment #2
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261129
--- Comment #19 from Tatsuki Makino ---
If something like the one shown below was about to be built, /etc/rc.conf
needed to define a value like:
ipv6_cpe_wanif="em0"
Also, it is mandatory to send RA from the bridge interface.
If it is sent
On Mon, 08 Apr 2024 04:16:47 +0100 Anton Yudin wrote ---
> I'm running a FreeBSD 14 with two interfaces that use DHCP. I would like
> to make one of the interfaces to never set the default route. Right now the
> first interface to be fully up sets the default rou
On 2024-04-07 20:16, Anton Yudin wrote:
I'm running a FreeBSD 14 with two interfaces that use DHCP.
I would like to make one of the interfaces to never set the default
route.
Right now the first interface to be fully up sets the default route.
I tried to set the following in
Hello.
I'm running a FreeBSD 14 with two interfaces that use DHCP.
I would like to make one of the interfaces to never set the default route.
Right now the first interface to be fully up sets the default route.
I tried to set the following in /etc/dhclient.conf
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261129
FiLiS changed:
What|Removed |Added
CC||freebsdb...@filis.org
--- Comment #18 from
Hi,
I am not able to use route(8) on an i386 jail to set the default route, maybe
someone can reproduce this problem. I have opened a Bug with detailed
information:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271895
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255264
Neal Nelson changed:
What|Removed |Added
Status|Open|Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255264
d...@sunsaturn.com changed:
What|Removed |Added
CC||d...@sunsaturn.com
--- Comment
pf_enable="YES"
>
> dhclient_flags="-b"
> dhcp6c_enable="YES"
> dhcp6c_interfaces="igb2"
> dhcp6c_fib=1
>
> I think this should be sufficient to receive both an IPv4 and IPv6 address
> and a default route, however, neither one is ad
gb2"
dhcp6c_fib=1
I think this should be sufficient to receive both an IPv4 and IPv6 address and
a default route, however, neither one is added. When I manually add them, they
are removed after a while.
$ ifconfig igb2
igb2: flags=8863 metric 0 mtu 1500
description: Cable Modem
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261129
Alexander V. Chernikov changed:
What|Removed |Added
Assignee|b...@freebsd.org|melif...@freebsd.org
if0 inet6 to ($gif_if) rtable 1"
which led to the corruption of the default route in FIBs 0 and 1 within a few
hours. Maybe this happens due to incorrectly recognised protocol 41?
Final conclusions:
1. FreeBSD routing stack is capable of using two different IPv6 GUA subnets on
the same inte
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261129
--- Comment #16 from Marek Zarychta ---
After taking some measures and test, so far I came to following conclusions:
1. The default route gets _silently_ corrupted irregardless of deployed
route.algo, with no traces observable neither
with settings:
ifconfig gif0 inet6 no_radr
ifconfig awg0 inet6 no_radr
and sysctls:
net.inet6.ip6.accept_rtadv=0
net.inet6.ip6.no_radr=1
the default route still gets overwritten with 2001:470:1:c84::16,
2001:470:1:c84::28 or 2001:470:1:c84::29.
I will check if filtering icmp6 on gif(4) helps and
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261129
Tatsuki Makino changed:
What|Removed |Added
CC||tatsuki_mak...@hotmail.com
--- Co
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261129
--- Comment #13 from Marek Zarychta ---
(In reply to Marek Zarychta from comment #12)
>Default gateways:
>1. fib 0:
># netstat -rn6 | grep default
>default 2001:470:x:y::1UGSawg0
>2. fib 1:
># netstat -rn6 -F 1 | grep defaul
different subnets:
1) 2a02:a:b:c::x:y/64 - the subnet with default route.
2) 2001:470:x:y::v:z/64 - fib 1 subnet assigned from still working IPv6 tunnel
to HE.
First of the machines is an endpoint for HE tunnel and acts as a router for
this 2001:470:x:y::v:z/64 tunneled subnet, but main NIC address
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255264
--- Comment #12 from Mitja Horvat ---
(In reply to Pat Maddox from comment #9)
Pat, thanks for the suggestion. If I didn't find a satisfactory workaround
(which it seems I did), vnets were definitely first on the list.
--
You are receivi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255264
--- Comment #11 from Mitja Horvat ---
(In reply to Marek Zarychta from comment #10)
Marek, that worked splendidly. I could even leave net.add_addr_allfibs=0.
rc.conf:
static_routes="fib1_lan fib1_default"
route_fib1_lan="-fib 1 -net 192.1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255264
--- Comment #10 from Marek Zarychta ---
(In reply to Mitja Horvat from comment #8)
If changing the default fib of re0 is inconvenient, then please try this:
"route add default 192.168.1.1 -ifa 192.168.1.2 -fib 1"
You can eventually add sta
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255264
Pat Maddox changed:
What|Removed |Added
CC||p...@patmaddox.com
--- Comment #9 fro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255264
--- Comment #8 from Mitja Horvat ---
(In reply to Marek Zarychta from comment #7)
Thank you very much for the prompt response. Indeed, setting the fib of the re0
interface 1 makes the route work. However this causes all the traffic routed
t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255264
--- Comment #7 from Marek Zarychta ---
(In reply to Mitja Horvat from comment #6)
To succeed early (before the link goes up) you need to assign re0 to the
correct fib:
ifconfig_re0="inet 192.168.1.2 netmask 255.255.255.0 fib 1"
I don't kno
from Mitja Horvat ---
I'm running 13.1-RC3 and it looks like I'm experiencing exactly the same
problem, except that the "net.add_addr_allfibs=1" did not fix my issue. My
problem seems to be somehow related to the interface carrier.
What I'm experiencing is that adding
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255264
--- Comment #5 from Neal Nelson ---
The entry in /usr/src/UPDATING that has been pointed out to me explains the
situation a little better than the current message. I'm sure the current
message makes sense to those that know the ins and outs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255264
Kubilay Kocak changed:
What|Removed |Added
Flags||maintainer-feedback?(ports@
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255264
--- Comment #3 from Alexander V. Chernikov ---
(In reply to Neal Nelson from comment #2)
Hi Neal, you mentioned that the message wasn't helpful.
Do you by any chance have any suggestions/comments on how can the message be
improved to provi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255264
Neal Nelson changed:
What|Removed |Added
Status|New |Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255264
Marek Zarychta changed:
What|Removed |Added
CC||zarych...@plan-b.pwste.edu.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255264
Li-Wen Hsu changed:
What|Removed |Added
CC||lw...@freebsd.org,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253469
--- Comment #15 from courtney.hic...@icloud.com ---
I can confirm this is an issue with the driver. Popped in my PCIe NIC and my
problem is gone:
igb3@pci0:3:0:3:class=0x02 rev=0x01 hdr=0x00 vendor=0x8086
device=0x150e subvendor
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253469
--- Comment #14 from courtney.hic...@icloud.com ---
Poo, that sucks. I could probably take the extra card out of my server tonight.
It's an Intel 82580.
Here is the ifmcstat for now
re0:
inet 192.168.10.201
igmpv3 rv 2 qi 1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253469
--- Comment #13 from Alexander V. Chernikov ---
It looks like Bjoern's diagnostics was right.
So far it looks like a potential problem w.r.t programming multicast groups in
the driver.
Could you consider sharing `ifmcstat` output?
Is ther
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253469
--- Comment #12 from courtney.hic...@icloud.com ---
Just updated to the latest updates in releng/13.0, I did see nd6 updates but no
dice on fixing the issue:
FreeBSD towerDefense 13.0-BETA2 FreeBSD 13.0-BETA2 #9 1e76911d6: Mon Feb 15
20:52:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253469
--- Comment #11 from courtney.hic...@icloud.com ---
For the nd6_options message, I only see it twice. Looking at it, it looks to
come around the completion of DAD for my re0 link local and autoconf IPv6
address. Sorry if some of my terminolo
ulticast is not properly received.
If you do see the unsolicited RAs from your router in
tcpdump -ln -s0 -i re0 -vvv icmp6
then can you do the following:
(0) confirm no firewall active on your local system?
(a) wait for the default route to go away
(b) do not restart anything!
(c) start tcpdump
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253469
--- Comment #9 from Alexander V. Chernikov ---
Good.
So from ICMP6 input histogram, it can be seen we received these RA messages.
Do you see multiple messages "nd6_options: unsupported option 24 - option
ignored
"?
As far as I understand,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253469
--- Comment #8 from courtney.hic...@icloud.com ---
netstat -sp icmp6
icmp6:
2 calls to icmp6_error
0 errors not generated in response to an icmp6 message
0 errors not generated because of rate limitation
Outp
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253469
--- Comment #7 from Alexander V. Chernikov ---
Okay, so we're receiving RAs but for some reason they are ignored.
Could you consider:
1) sharing netstat -sp icmp6 output?
2) turn on sysctl net.inet6.icmp6.nd6_debug=1 & check dmesg if there
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253469
--- Comment #6 from courtney.hic...@icloud.com ---
I watched my systems more. My one that is having issues will let my...I can't
think of the words, information(?) expire. Watching my 12.2 machine with ndp -r
I see the expiration time refres
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253469
--- Comment #5 from courtney.hic...@icloud.com ---
I believe my router will send out RA messages periodically. I have just been
using rtsol to see what changes. I have these in my rc.conf. Let me verify some
of these things on my other 12.2
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253469
--- Comment #4 from Alexander V. Chernikov ---
Okay, so it's actually not the userland who adds/removes the route, as the
"PID" valued of the rtsock messages is 0.
what is the output of "ndp -r" closer to the route expiration? How does "nd
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253469
--- Comment #3 from courtney.hic...@icloud.com ---
I forgot to note, I found out that if I manually add the route, it does not go
away
sudo route -6 add default fe80::1:1%re0
So rtsol is removing the routes? Or something upstream is tellin
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253469
--- Comment #2 from courtney.hic...@icloud.com ---
Here is what I got. I did service rtsold restart and then waited until I lost
my route. Here is the output of ping6 as the route got deleted
16 bytes from 2607:f8b0:400a:805::200e, icmp_seq
--- Comment #1 from Alexander V. Chernikov ---
Is there any chance you could run `route -n monitor > log.txt` in the
background, stopping it when the default route disappears?
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253469
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
13.08.2018 6:15, Yuri wrote:
> When ethernet is unplugged, the interface keeps its IP, and the default route
> stays,
This is intentional.
> so WiFi fails to become functional.
> It is necessary to run 'ifconfig {iface} inet remove' before connecting to
> WiFi.
When ethernet is unplugged, the interface keeps its IP, and the default
route stays, so WiFi fails to become functional.
It is necessary to run 'ifconfig {iface} inet remove' before connecting
to WiFi.
How is this supposed to function, because regular user shouldn't be
It was reported to pfSense [1] and I already opened a bugzilla ticket [2].
It’s reproducible on all versions >= 11.0.
I was not sure about who could be assigned on ticket then I decided to send it
here on the list. Looks like a regression that would be nice to see fixed.
[1] https://redmine.pfs
Xin Li wrote
in <521ba31c.5000...@delphij.net>:
de> > That has always been specifically not supported. default route
de> > needs to be directly attached. in fact the routing tables only ever
de> > deliver the 'next hop'
de>
de> Well, depends on whether
Hello, Xin.
You wrote 23 августа 2013 г., 0:13:51:
XL> I've noticed that we do not install default route last (after other
XL> static routes). I think we should probably install it last, since the
XL> administrator may legitimately configure a static route (e.g. this
XL> IPv
m: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
> n...@freebsd.org] On Behalf Of Xin Li
> Sent: 26 August 2013 19:49
> To: Julian Elischer
> Cc: Kimmo Paasiala; Hiroki Sato; freebsd...@freebsd.org; d...@delphij.net;
> FreeBSD Net
> Subject: Re: Why default route is not install
;>>
>>> de> -BEGIN PGP SIGNED MESSAGE- de> Hash: SHA512 de> de>
>>> Hi, de> de> I've noticed that we do not install default route
>>> last (after other de> static routes). I think we should
>>> probably install it last, sin
On 8/26/13 7:56 PM, Kimmo Paasiala wrote:
On Mon, Aug 26, 2013 at 2:37 PM, Hiroki Sato wrote:
Xin Li wrote
in <521670ff.6080...@delphij.net>:
de> -BEGIN PGP SIGNED MESSAGE-
de> Hash: SHA512
de>
de> Hi,
de>
de> I've noticed that we do not install defau
On Mon, Aug 26, 2013 at 2:37 PM, Hiroki Sato wrote:
> Xin Li wrote
> in <521670ff.6080...@delphij.net>:
>
> de> -BEGIN PGP SIGNED MESSAGE-
> de> Hash: SHA512
> de>
> de> Hi,
> de>
> de> I've noticed that we do not install defaul
Xin Li wrote
in <521670ff.6080...@delphij.net>:
de> -BEGIN PGP SIGNED MESSAGE-
de> Hash: SHA512
de>
de> Hi,
de>
de> I've noticed that we do not install default route last (after other
de> static routes). I think we should probably install it last,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
I've noticed that we do not install default route last (after other
static routes). I think we should probably install it last, since the
administrator may legitimately configure a static route (e.g. this
IPv6 address goes to this inte
On Wed, Apr 24, 2013 at 11:50 AM, Randall Stewart wrote:
> All
>
> Ok I fixed it ;-)
>
> Its in SVN r249848.
>
> I will see about getting it to 9 stable, 8 stable and maybe even
> 8.4 if RE will let me ;-)
>
Great work. Thanks so much. I was afraid this would linger forever!
> R
> On Apr 23, 201
On 24 April 2013 12:11, Ed Maste wrote:
> On 24 April 2013 14:57, Adrian Chadd wrote:
>> Is this an issue on -7 and -6?
>
> I believe so, and it should get merged there as well.
rrs - prty please? :)
adrian
___
freebsd-net@freebsd.org maili
On 24 April 2013 14:57, Adrian Chadd wrote:
> Is this an issue on -7 and -6?
I believe so, and it should get merged there as well.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any ma
Is this an issue on -7 and -6?
(Since people do still run it, and it seems a simple enough fix?)
adrian
On 24 April 2013 11:50, Randall Stewart wrote:
> All
>
> Ok I fixed it ;-)
>
> Its in SVN r249848.
>
> I will see about getting it to 9 stable, 8 stable and maybe even
> 8.4 if RE will let
All
Ok I fixed it ;-)
Its in SVN r249848.
I will see about getting it to 9 stable, 8 stable and maybe even
8.4 if RE will let me ;-)
R
On Apr 23, 2013, at 9:40 AM, Tom Evans wrote:
> On Tue, Apr 23, 2013 at 1:08 PM, Randall Stewart wrote:
>> Ok
>>
>> I too have been struck by this *multiple*
On Tue, Apr 23, 2013 at 1:08 PM, Randall Stewart wrote:
> Ok
>
> I too have been struck by this *multiple* times on my base home router.
>
I hate "me too" style posts, since often they conflate unrelated
issues - however, "me too"!
In my scenario, I have a simple home router with a wan if connec
Ok
I too have been struck by this *multiple* times on my base home router.
I am not sure how its happening, but I have placed in my kernel a special
catch that if the default route is set via the normal route.c path and it
is *not* the default route to my ISP, I will crash the kernel.
My
#x27;t allocate llinfo for
>> 86.58.122.125
>>
>> IP 86.58.122.125 is not from IP pool used by me.
>>
>
> This kernel message is a merely a side effect of a bad route (with
> off-net IP address) being injected as a default route replacement.
I would normally agree
m IP pool used by me.
>
This kernel message is a merely a side effect of a bad route (with
off-net IP address) being injected as a default route replacement.
--Qing
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listi
On 07.03.2013 20:27, Krzysztof Barcikowski wrote:
W dniu 2013-03-07 18:09, Andre Oppermann pisze:
On 07.03.2013 17:54, Nick Rogers wrote:
I'm not sure. I have not explicitly enabled/disabled it. I am using
the GENERIC kernel from 9.1 plus PF+ALTQ.
# sysctl net.inet.flowtable.enable
sysctl: unk
W dniu 2013-03-07 18:09, Andre Oppermann pisze:
On 07.03.2013 17:54, Nick Rogers wrote:
I'm not sure. I have not explicitly enabled/disabled it. I am using
the GENERIC kernel from 9.1 plus PF+ALTQ.
# sysctl net.inet.flowtable.enable
sysctl: unknown oid 'net.inet.flowtable.enable'
# sysctl -a |
work load.
The last time this happened I had a stream of arpresolve messages in the
kernel for the IP that the default route was changed to.
Mar 5 19:12:53 kernel: arpresolve: can't allocate llinfo for
50.142.201.101
The default route was changed to 50.142.201.101 after these messages.
--
kernel's routing table to be corrupted by traffic routing through the
>> system. Under heavy traffic load, the default route can seemingly
>> randomly change to an IP address that is not directly connected to the
>> network (i.e., is not configured anywhere). Dhclient
m under FreeBSD 9.1-RELEASE. I use PF
>>> for
>>> NAT, ALTQ, and RDR/filter rules. I'm not using PPPoE or dhclient. The
>>> default gateway changes to an IP that is not on my network when under
>>> heavy
>>> network load.
>>>
>>> Th
last time this happened I had a stream of arpresolve messages in the
kernel for the IP that the default route was changed to.
Mar 5 19:12:53 kernel: arpresolve: can't allocate llinfo for
50.142.201.101
The default route was changed to 50.142.201.101 after these messages.
--
View this
NAT, ALTQ, and RDR/filter rules. I'm not using PPPoE or dhclient. The
> default gateway changes to an IP that is not on my network when under heavy
> network load.
>
> The last time this happened I had a stream of arpresolve messages in the
> kernel for the IP that the default r
c 13 04:39:59 CET 2012
Thu Dec 13 04:40:11 CET 2012
Fri Jan 4 07:47:00 CET 2013
Mon Jan 28 18:35:43 CET 2013
Sat Feb 2 22:43:01 CET 2013
I do only monitor default route change, but this bug also affects static
routes (i.e. I have one static route and it changes more frequently that
default route).
; Frequency:
> Wed Oct 3 14:19:15 CEST 2012
> Thu Dec 13 04:39:43 CET 2012
> Thu Dec 13 04:39:46 CET 2012
> Thu Dec 13 04:39:47 CET 2012
> Thu Dec 13 04:39:50 CET 2012
> Thu Dec 13 04:39:53 CET 2012
> Thu Dec 13 04:39:59 CET 2012
> Thu Dec 13 04:40:11 CET 2012
> Fri Jan 4 0
On Wed, Mar 06, 2013 at 09:25:21AM +0100, Andre Oppermann wrote:
> I'm trying to create a stack graph to see which parts of the network
> stack are involved in handling your packet.
Ask people if they're using multiple pfil hooks (even just having
ipfilter loaded counts, for instance).
If that's
T 2012
Fri Jan 4 07:47:00 CET 2013
Mon Jan 28 18:35:43 CET 2013
Sat Feb 2 22:43:01 CET 2013
I do only monitor default route change, but this bug also affects static
routes (i.e. I have one static route and it changes more frequently that
default route).
Please let me know if I can provide any
, the default route can seemingly
randomly change to an IP address that is not directly connected to the
network (i.e., is not configured anywhere). Dhclient is not in the
mix, nor is routed, bgpd, etc. Running `route monitor` shows no
evidence of the change in the default route. The one commonality
be
by traffic routing through the
> system. Under heavy traffic load, the default route can seemingly
> randomly change to an IP address that is not directly connected to the
> network (i.e., is not configured anywhere). Dhclient is not in the
> mix, nor is routed, bgpd, etc. Running `route
affecting users
> of FreeBSD 9.x and PF. There appears to be a bug that allows the
> kernel's routing table to be corrupted by traffic routing through the
> system. Under heavy traffic load, the default route can seemingly
> randomly change to an IP address that is not dir
Hello,
I am attempting to create awareness of a serious issue affecting users
of FreeBSD 9.x and PF. There appears to be a bug that allows the
kernel's routing table to be corrupted by traffic routing through the
system. Under heavy traffic load, the default route can seemingly
randomly chan
Do some body know how can we debug kernel memory corruption on live system?
We need to find out which function/subsystem is cause of this mess.
Or maybe is there some way to lock particular memory area, where default
gateway lies and watch which subsystem will cause system crash?
__
Synopsis: Unexpected change of default route
Responsible-Changed-From-To: freebsd-net->freebsd-ipfw
Responsible-Changed-By: qingli
Responsible-Changed-When: Thu Dec 27 23:36:00 UTC 2012
Responsible-Changed-Why:
similar to kern/157796
http://www.freebsd.org/cgi/query-pr.cgi?pr=174
Synopsis: Unexpected change of default route
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Thu Dec 27 20:12:29 UTC 2012
Responsible-Changed-Why:
reclassify.
http://www.freebsd.org/cgi/query-pr.cgi?pr=174
I was reported this behaviour before.
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/157796
On Fri, Oct 5, 2012 at 5:27 PM, Krzysztof Barcikowski
wrote:
> W dniu 2012-10-05 16:22, Dominic Blais pisze:
>
>> Hi,
>>
>> I'm using GENERIC. Everything else is added as loaded module.
>>
>> Here's my
W dniu 2012-10-10 13:57, Dominic Blais pisze:
Hi (sorry, I clicked send too fast ;) ),
I had to change the server of my customer who have this bug because we wanted to put 2
redundant servers with carp... I removed the old server and replaced it with 2 brand new
ones. The old one was an HP ML
Hi,
On Wed, 10 Oct 2012 07:57:05 -0400
Dominic Blais wrote:
> Hi (sorry, I clicked send too fast ;) ),
oh yeah, the fast index finger.
>
> replace the gateway. I often see, but not only, Microsoft owned IP as
> my default gateway when it happens.
do you have traffic to these addresses too? Wh
Hi (sorry, I clicked send too fast ;) ),
I had to change the server of my customer who have this bug because we wanted
to put 2 redundant servers with carp... I removed the old server and replaced
it with 2 brand new ones. The old one was an HP ML115 and the new ones
are Lenovo TS120. The new
Hi,
I had to change the server of my customer who have this bug because we wanted
to put 2 redundant servers with carp... I removed the old server and replaced
it with 2 brand new ones. The old one was an HP ML115 and the new ones are
Lenovo TS120
--
[cid:image001.gif@01CDA6BB.DA8AD840]
W dniu 2012-10-05 16:22, Dominic Blais pisze:
Hi,
I'm using GENERIC. Everything else is added as loaded module.
Here's my kldstat:
I forgot about modules, here they are:
Id Refs AddressSize Name
1 13 0x8020 12200c8 kernel
21 0x81421000 215f8g
...@freebsd.org [mailto:owner-freebsd-...@freebsd.org] De la
part de Krzysztof Barcikowski
Envoyé : 5 octobre 2012 08:30
À : freebsd-net@freebsd.org
Objet : Re: Default route destination changing without warning follow-up
W dniu 2012-10-05 14:23, Vadim Urazaev pisze:
> I don`t know if it`s import
W dniu 2012-10-05 14:23, Vadim Urazaev pisze:
I don`t know if it`s important, anyway I have only one routing table on
server where this issue happens.
Maybe we should check our kernel configuration to find something similar in
it.
For example I have
options ZERO_COPY_SOCKETS
_
I don`t know if it`s important, anyway I have only one routing table on
server where this issue happens.
Maybe we should check our kernel configuration to find something similar in
it.
For example I have
options ZERO_COPY_SOCKETS
___
freebsd-net@freeb
The reason I ask is that if a new wrong one appears, it could be memory
corruption, but if a new one replaces the old one, for some reason when
allocating a new route, it could accidentatlly be replacing the default
route...
Just some thoughts...
Hi,
I don't see a second new route appearing
Blais; freebsd-net@freebsd.org
Objet : Re: Default route destination changing without warning follow-up
On Thu, Oct 04, 2012 at 07:36:51PM +0200, Krzysztof Barcikowski wrote:
> W dniu 2012-10-04 18:02, John-Mark Gurney pisze:
> > Alexander V. Chernikov wrote this message on Mon, Oct 01,
ve the same issue...
> >
> > quick question for you Dominic, do you see the correct number of routes,
> > but a new wrong one appear? or does the route just simply disapear? or
> > does a new one seem to replace the old one?
> >
> > The reason I ask is that
Dominic Blais wrote this message on Thu, Oct 04, 2012 at 12:12 -0400:
> There's never 2 default route... it's always a single default route. Since
> route monitor shows nothing, I guess it's the same route that gets its
> gateway changed for some reason... I guess the
d one, for some reason when
allocating a new route, it could accidentatlly be replacing the default
route...
Just some thoughts...
Hi,
I don't see a second new route appearing in my case, just the default or
static route is replaced.
I'm not conviced of memory corruption, as it happens
There's never 2 default route... it's always a single default route. Since
route monitor shows nothing, I guess it's the same route that gets its gateway
changed for some reason... I guess the effective and appearing change could be
due to a pointer changing somewhere or the mem
1 - 100 of 159 matches
Mail list logo