This brings up a long standing sore point of our routing code
which this patch makes more pronounced. When an interface link
state is down I don't want the route to it to persist but to
become inactive so another path can be chosen. This the very
point of running a routing daemon. So on
On Thu, Mar 07, 2013 at 01:14:03PM +0600, Eugene M. Zheganin wrote:
Hi.
On 07.03.2013 12:23, YongHyeon PYUN wrote:
On Thu, Mar 07, 2013 at 11:08:50AM +0600, Eugene M. Zheganin wrote:
It was definitely older than months. It was running something similar
to FreeBSD 8.2-STABLE #0: Mon Sep
The following reply was made to PR kern/176446; it has been noted by GNATS.
From: Charbon, Julien jchar...@verisign.com
To: John Baldwin j...@freebsd.org
Cc: bug-follo...@freebsd.org,
De La Gueronniere, Marc mdelagueronni...@verisign.com
Subject: Re: kern/176446: [netinet] [patch]
On 07.03.2013 11:39, Andre Oppermann wrote:
On 07.03.2013 07:34, Alexander V. Chernikov wrote:
Hello list!
There is a known long-lived issue with interface routes
addition/deletion:
ifconfig iface inet 1.2.3.4/24 can fail if given prefix is already in
kernel route table (for
example,
On 07.03.2013 12:43, Alexander V. Chernikov wrote:
On 07.03.2013 11:39, Andre Oppermann wrote:
On 07.03.2013 07:34, Alexander V. Chernikov wrote:
Hello list!
There is a known long-lived issue with interface routes
addition/deletion:
ifconfig iface inet 1.2.3.4/24 can fail if given prefix is
Hello Guys,
I've faced out some problem with dhclient during this week on 9.1-RELEASE!
Below there is the log:
[root@home ~]# uname -a
FreeBSD HOME 9.1-RELEASE FreeBSD 9.1-RELEASE #10: Tue Mar 5 18:57:14 CST
2013 root@home:/usr/src/sys/HOME.amd64 amd64
[root@home ~]# dhclient ix0
PID =
On Thu, Mar 7, 2013 at 12:55 PM, Andre Oppermann an...@freebsd.org wrote:
On 07.03.2013 12:43, Alexander V. Chernikov wrote:
On 07.03.2013 11:39, Andre Oppermann wrote:
On 07.03.2013 07:34, Alexander V. Chernikov wrote:
Hello list!
There is a known long-lived issue with interface routes
On 07.03.2013 14:38, Ermal Luçi wrote:
On Thu, Mar 7, 2013 at 12:55 PM, Andre Oppermann an...@freebsd.org
mailto:an...@freebsd.org wrote:
On 07.03.2013 12:43, Alexander V. Chernikov wrote:
On 07.03.2013 11:39, Andre Oppermann wrote:
On 07.03.2013 07:34, Alexander V.
On 07.03.2013 15:55, Andre Oppermann wrote:
On 07.03.2013 12:43, Alexander V. Chernikov wrote:
On 07.03.2013 11:39, Andre Oppermann wrote:
On 07.03.2013 07:34, Alexander V. Chernikov wrote:
Hello list!
There is a known long-lived issue with interface routes
addition/deletion:
ifconfig
On 07.03.2013 14:54, Alexander V. Chernikov wrote:
On 07.03.2013 15:55, Andre Oppermann wrote:
On 07.03.2013 12:43, Alexander V. Chernikov wrote:
On 07.03.2013 11:39, Andre Oppermann wrote:
This brings up a long standing sore point of our routing code
which this patch makes more pronounced.
It seems I have no choice :)
WBR, Alexander
On 07.03.2013, at 18:03, Andre Oppermann an...@freebsd.org wrote:
On 07.03.2013 14:54, Alexander V. Chernikov wrote:
On 07.03.2013 15:55, Andre Oppermann wrote:
On 07.03.2013 12:43, Alexander V. Chernikov wrote:
On 07.03.2013 11:39, Andre
On 06.03.2013 22:02, freebsd-net wrote:
Greetings,
I'm evaluating an ISP for the sake of building BSD operating systems on
hardware
that they use (DSL modems, in this case). When I had my old NEC server, I had a
MIPS environment to develop in. I managed a 28k kernel. In any case, I'm back at
On 07.03.2013 17:51, Andre Oppermann wrote:
On 07.03.2013 14:38, Ermal Luçi wrote:
On Thu, Mar 7, 2013 at 12:55 PM, Andre Oppermann an...@freebsd.org
mailto:an...@freebsd.org wrote:
On 07.03.2013 12:43, Alexander V. Chernikov wrote:
On 07.03.2013 11:39, Andre Oppermann wrote:
The following reply was made to PR kern/176667; it has been noted by GNATS.
From: Gleb Smirnoff gleb...@freebsd.org
To: Lutz Donnerhacke l...@iks-service.de
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: kern/176667: libalias locks on uninitalized data
Date: Thu, 7 Mar 2013 20:30:26 +0400
On
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 | grep flow
kern.sigqueue.overflow: 0
net.inet.tcp.reass.overflows: 0
Greetings Maciej Milewski, and thank you for your thoughtful reply.
On 06.03.2013 22:02, freebsd-net wrote:
Greetings,
I'm evaluating an ISP for the sake of building BSD operating systems on
hardware
that they use (DSL modems, in this case). When I had my old NEC server, I
had a
MIPS
On Wed, Mar 6, 2013 at 12:25 AM, Andre Oppermann an...@freebsd.org wrote:
On 05.03.2013 18:39, Nick Rogers wrote:
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
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 | grep flow
kern.sigqueue.overflow: 0
Hello Guys,
I've faced out some problem with dhclient during this week on 9.1-RELEASE!
Below there is the log:
[root@home ~]# uname -a
FreeBSD HOME 9.1-RELEASE FreeBSD 9.1-RELEASE #10: Tue Mar 5 18:57:14 CST
2013 root@home:/usr/src/sys/HOME.amd64 amd64
[root@home ~]# dhclient ix0
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 |
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:
On 07.03.2013 16:34, Alexander V. Chernikov wrote:
On 07.03.2013 17:51, Andre Oppermann wrote:
On 07.03.2013 14:38, Ermal Luçi wrote:
Isn't it better to teach the routing code about metrics.
Routing daemons cope better this way and they can handle this.
So the policy of this behaviour can be
Hi,
I can confirm I get these messages as well:
Mar 7 19:40:25 opole kernel: arpresolve: can't allocate llinfo for
86.58.122.125
Mar 7 19:40:25 opole kernel: arpresolve: can't allocate llinfo for
86.58.122.125
IP 86.58.122.125 is not from IP pool used by me.
This kernel message
On 08.03.2013 00:53, Andre Oppermann wrote:
On 07.03.2013 16:34, Alexander V. Chernikov wrote:
On 07.03.2013 17:51, Andre Oppermann wrote:
On 07.03.2013 14:38, Ermal Luçi wrote:
Isn't it better to teach the routing code about metrics.
Routing daemons cope better this way and they can handle
Andre Oppermann wrote this message on Thu, Mar 07, 2013 at 08:39 +0100:
Adding interface address is handled via atomically deleting old prefix and
adding interface one.
This brings up a long standing sore point of our routing code
which this patch makes more pronounced. When an interface
Greetings,
I'm evaluating an ISP for the sake of building BSD operating systems on
hardware
that they use (DSL modems, in this case). When I had my old NEC server, I had
a
MIPS environment to develop in. I managed a 28k kernel. In any case, I'm back
at
it for use in alot of hardware I
On Thu, Mar 7, 2013 at 12:51 PM, Li, Qing qing...@bluecoat.com wrote:
Hi,
I can confirm I get these messages as well:
Mar 7 19:40:25 opole kernel: arpresolve: can't allocate llinfo for
86.58.122.125
Mar 7 19:40:25 opole kernel: arpresolve: can't allocate llinfo for
86.58.122.125
IP
I have a machine (actually six of them) with an Intel dual-10G NIC on
the motherboard. Two of them (so far) are connected to a network
using jumbo frames, with an MTU a little under 9k, so the ixgbe driver
allocates 32,000 9k clusters for its receive rings. I have noticed,
on the machine that is
On 08.03.2013 08:10, Garrett Wollman wrote:
I have a machine (actually six of them) with an Intel dual-10G NIC on
the motherboard. Two of them (so far) are connected to a network
using jumbo frames, with an MTU a little under 9k, so the ixgbe driver
allocates 32,000 9k clusters for its receive
On Fri, Mar 08, 2013 at 02:10:41AM -0500, Garrett Wollman wrote:
I have a machine (actually six of them) with an Intel dual-10G NIC on
the motherboard. Two of them (so far) are connected to a network
using jumbo frames, with an MTU a little under 9k, so the ixgbe driver
allocates 32,000 9k
30 matches
Mail list logo
