Hi,
I tried to keep the route messages to be legacy compatible due to reported
breakage at the time. Let me revisit the code and get back to you.
I haven't run the quagga code for years, so please don't mind me request
some information from you offline.
--Qing
The problem you described here seemed familiar so I checked into the svn
history,
and found I have in fact fixed this issue in other parts of the code.
Please see
http://svnweb.freebsd.org/base?view=revisionrevision=186708
So I think similar fix should be applied here as well.
--Qing
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
got message of size 184 on Wed Sep 12 00:15:49 2012
RTM_DELETE: Delete Route: len 184, pid: 0, seq 0, errno 0,
flags:UP,GATEWAY,STATIC
locks: inits:
sockaddrs: DST,GATEWAY,NETMASK
default default default ### - This looks normal, I
usually see it when customers connect to
V
V Could this be
http://svnweb.freebsd.org/base/head/sys/netinet/in.c?r1=226120r2=22622
4pathrev=226331
Why do you suspect this one?
I was hitting a similar issue in 8.2. After down/up on the interface
to the default gateway, I saw this message and arpresolve would never
It is not working properly in one case, of load balancing among physical
interfaces having a single prefix, all are attached to the same physical
link, and reaching a single first-hop router.
The feature itself, of installing (/removing) multiple routing entries of
varying
first-hop to the
The route selection is based on a hash function of source-ip and destination-ip
when
RADIX_MPATH is enabled. You do not need to perform specific actions, other than
perhaps
setting varying weights on each entry as an option. So depends on the traffic
destination
the chosen route may always be
and try to come up with a patch.
--Qing
From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org] on behalf
of David DeSimone [f...@verio.net]
Sent: Tuesday, May 15, 2012 4:14 PM
To: freebsd-net@freebsd.org
Subject: Re: [stable-9]
Li, Qing qing
Okay, this is good information. I will look into it now.
Thanks,
--Qing
-Original Message-
From: Ryan Stone [mailto:ryst...@gmail.com]
Sent: Thursday, April 26, 2012 7:03 AM
To: Li, Qing
Cc: freebsd-net
Subject: Re: Removing an IPv6 address does not remove NDP entries
The patch is located at
http://people.freebsd.org/~qingli/nd6_prefix.diff
Please give it a try. I did only basic testing as of now and
will do more tomorrow.
--Qing
-Original Message-
From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
n...@freebsd.org] On Behalf Of Li
From previous tests, the difference between flowtable and
routing table was small with a single process (about 5% or 50ns
in the total packet processing time, if i remember well),
but there was a large gain with multiple concurrent processes.
Yes, that sounds about right when we did the tests a
Yup, all good points. In fact we have considered all of these while doing
the work. In case you haven't seen it already, we did write about these
issues in our paper and how we tried to address those, flow-table was one
of the solutions.
http://dl.acm.org/citation.cfm?id=1592641
--Qing
I have a patch that has been sitting around for a long time due to
review cycle latency that caches a pointer to the rtentry (and
llentry) in the the inpcb. Before each use the rtentry is checked
against a generation number in the routing tree that is incremented
on
every routing
[rstone@vm-head ~]ndp -a
Neighbor Linklayer Address Netif ExpireS
Flags
1::2 08:00:27:1e:b8:16em0 7sR
fe80::a00:27ff:fefa:8732%em0 08:00:27:fa:87:32em0 permanent R
rstone@vm-head ~]uname -a
FreeBSD
that uncovers the issue ?
--Qing
-Original Message-
From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
n...@freebsd.org] On Behalf Of Li, Qing
Sent: Monday, April 02, 2012 10:54 AM
To: Ryan Stone
Cc: freebsd-net
Subject: RE: Removing an IPv6 address does not remove NDP entries
From: Ryan Stone [ryst...@gmail.com]
Sent: Monday, April 09, 2012 4:50 PM
To: Li, Qing
Cc: freebsd-net
Subject: Re: Removing an IPv6 address does not remove NDP entries on that subnet
On Mon, Apr 9, 2012 at 5:46 PM, Li, Qing qing...@bluecoat.com wrote
On Fri, Mar 30, 2012 at 12:28 AM, Li, Qing qing...@bluecoat.com wrote:
* In a way this is a good thing as in6_lltable_prefix_free() is
guaranteed to crash your kernel in two different ways, and that's
not
counting the race conditions that it's subject to.
Could you please
Currently, if you remove an IPv4 address from an interface, all ARP
cache entries on its subnet are invalidated. However, the same thing
is not done for NDP cache entries when an IPv6 address is removed*.
Is this correct behaviour? It seems weird to have IPv4 and IPv6
behave differently.
Yes, what you are trying to do is allowed and is supported. In fact several
bugs
were fixed to support such configuration properly. For example, see these
commits:
http://svnweb.freebsd.org/base?view=revisionrevision=225947
Hmm... I don't see this problem until multiple FIBs are enabled.
--Qing
-Original Message-
From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
n...@freebsd.org] On Behalf Of Steven Hartland
Sent: Wednesday, February 08, 2012 11:13 AM
To: Gary Palmer
Cc:
So you have RADIX_MPATH option enabled in the kernel configuration, and booting
up OpenBGPD triggers the crash immediately ?
--Qing
From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org] on behalf
of Joe Holden [li...@rewt.org.uk]
Sent:
Could you please apply this patch
http://svnweb.freebsd.org/base?view=revisionrevision=227002
and let me know how it works out for you ?
Thanks,
--Qing
From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org] on behalf
of Slono Slono
The host-id/interface-id can have a specific value and is properly masked out
when
adding a prefix route. As in
route add -net 192.103.54.9/24 10.9.44.1
OR for IPv6
route add -inet6 -net 2001:db8:1::1/48 2001:418:1800::1
The problem is when deleting the route,
First thing comes to mind is to check if rl0 is running in promiscuous mode.
Check ifconfig output, and do a ifconfig rl0 -promisc just for good measure
and
see what happens.
--Qing
From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org] on
You don't have the flowtable component enabled, do you ?
--Qing
From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org] on behalf
of Steven Hartland [kill...@multiplay.co.uk]
Sent: Friday, October 21, 2011 4:44 PM
To: freebsd-net@freebsd.org
: net.inet.flowtable.nmbflows: 197632
net.inet.flowtable.tcp_expire: 86400
net.inet.flowtable.fin_wait_expire: 600
net.inet.flowtable.udp_expire: 300
net.inet.flowtable.syn_expire: 300
net.inet.flowtable.enable: 1
net.inet.flowtable.debug: 0
This mean yes?
- Original Message - From: Li
Yep found that, but it was post 8.2 so don't have it here and tbh if its
that broken that an IP move doesn't work it could also do with some
serious warning if enabled, otherwise some unsuspecting sole is going
to end up in a similar situation to us tonight, scratching their heads
thing
Hi,
I believe I have identified the root cause based on the data provided by Larry
Baird, but I am
still verifying the patch against the mpd5 code. In a nutshell, the host route
installed by mpd5
appears to be missing a flag resulting in the crash.
In the meantime, please try the following
This failure showed up in the IPv6 Ready Logo test suites and I am fixing it.
I already made a checkin recently on this front, and more is coming.
http://svnweb.freebsd.org/base?view=revisionrevision=226451
I will be posting the test results soon so we know where we are.
--Qing
The important thing is if you have questions, just ask me.
You can start from this email thread.
http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026423.html
--Qing
From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org]
Here is one of my specific responses to the PRs.
http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026506.html
-- Qing
From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org] on behalf
of Li, Qing
Sent: Friday, October 07
I believe there is actually another bug needs fixing. Let me confirm and will
provide
another patch later.
--Qing
From: Matt Smith [m...@xtaz.co.uk]
Sent: Tuesday, October 04, 2011 3:33 AM
To: Li, Qing
Cc: freebsd-net@freebsd.org
Subject: Re: gif
Hi,
I saw the thread but I was traveling the whole of last week, did not
have a system to work on.
The problem you encountered on gif was due to a bug in the IPv6 code.
I believe have a patch but I need to do more testing. I will post it shortly.
--Qing
-Original Message-
From:
Just to let you know that I was doing a lot of testing off of the
mailing list with Hiroki Sato and we basically discovered that I was
missing an alias on my lo0 interface. He first advised me to try
testing with adding a /126 to gif0 rather than a /128 which worked
successfully. Then he
Hi,
This address is for IPv6 Node Information Query, called the NI Group Address.
For example, you can issue the command
ping6 -w fe80::250:fcff:feb8:5443%rl0
you can get your hostname back.
--Qing
-Original Message-
From: owner-freebsd-...@freebsd.org
Hi,
Yes, the address alias and its associated prefix installation code changed.
Operationally it makes sense because all addresses of that same prefix go
through one route utilizing that given interface.
The side effect is you can have two separate interfaces on the same prefix,
but only a
Thank you Chris for the verification. I will wait a few days before committing
the patch.
--Qing
From: Chris Miller [mailto:chrismiller@gmail.com]
Sent: Monday, August 29, 2011 7:31 PM
To: Li, Qing
Cc: freebsd-net@freebsd.org
Subject: Re: arpresolve: can't allocate llinfo
Qing
Hi,
Could you please try the patch sitting at
http://people.freebsd.org/~qingli/in.c.diff
and let me know if it works for you?
Thanks,
-- Qing
-Original Message-
From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
n...@freebsd.org] On Behalf Of Chris Miller
Sent:
This issue should have been fixed quite a while ago.
I need to go through my past commits and see if everything has been merged back
into the 8.1 branch.
--Qing
-Original Message-
From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
n...@freebsd.org] On Behalf Of Chris Miller
First of all, are you encountering any issues ?
There is an outstanding issue with the address alias and improper routing
table update that I am actively working on.
--Qing
-Original Message-
From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
n...@freebsd.org] On Behalf Of
AM
To: Li, Qing
Cc: freebsd-net@freebsd.org; Ingo Flaschberger
Subject: Re: interface ip arp
Hi,
On Mon, May 2, 2011 at 4:03 AM, Li, Qing qing...@bluecoat.com wrote:
Please give this patch a try for IPv4 ARP
http://people.freebsd.org/~qingli/arp2.patch
Your patch works; the manually
patch for IPv4, just going over the IPv6 code.
I will post the patch in a few minutes.
-- Qing
From: Arnaud Lacombe [lacom...@gmail.com]
Sent: Monday, May 02, 2011 12:41 AM
To: Li, Qing
Cc: Ingo Flaschberger; freebsd-net@freebsd.org
Subject: Re: interface ip
Please give this patch a try for IPv4 ARP
http://people.freebsd.org/~qingli/arp2.patch
--Qing
From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org] on behalf
of Li, Qing
Sent: Monday, May 02, 2011 12:45 AM
To: Arnaud Lacombe
Cc: freebsd
That's not the expected behavior, probably a bug, I will take a look ...
-- Qing
On May 1, 2011, at 4:51 PM, Ingo Flaschberger i...@xip.at wrote:
is it expected behaviour that the static, permanent arp entry of the
interface ip disappear after ifdown/ifup at 8.x release?
ifconfig em0
jeez, this bug has been around for quite a while ...
Please try patch at http://people.freebsd.org/~qingli/arp.patch
-- Qing
From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org] on behalf
of Li, Qing
Sent: Sunday, May 01, 2011 4:54 PM
kern/155772 can be resolved using RADIX_MPATH.
regarding kern/155772:
at stock 8.2 FreeBSD the system panics after ifconfig down / ifconfig up /
ifconfig down with 1 route and 1 interface route (multipath).
What's the exact step and a specific example that triggers a panic ?
Also
I see,
What you are saying is the rtalloc() call does not have an indicator whether
it should be searching
for an interface route or not.
In the case when RADIX_MPATH is enabled, in_lltable_rtcheck() needs to walk the
ECMP route chain
to find an interface route.
yes ?
-- Qing
The self-pointing route 10.0.5.1 should have multiple references set on
it, and that route won't be deleted from the routing table until the
last reference is removed.
You can verify that by checking the netstat output, the Ref column
after tun1 has been created.
The above has been verified
As I am revising the ECMP code and reviewing the work done
by Ingo Flaschberger, I come to the conclusion that I need
to make one more enhancement to ECMP.
I want to implement the inetCidrRouteProto concept as the
2nd variable that differentiates among the ECMP routes.
I have already started on
Hi,
The indirect route is colliding with the interface route, both have
the same mask.
How do you expect this to work ?
How would the routing code differentiate between on-link nodes and
the those needing to be routed through 10.11.11.1 ?
-- Qing
one of the problems:
sysctl -w
, 2010 11:28 AM
To: Li, Qing
Cc: n...@freebsd.org
Subject: RE: funny ECMP
Dear Li,
The indirect route is colliding with the interface route, both have
the same mask.
How do you expect this to work ?
How would the routing code differentiate between on-link nodes and
the those needing
I am trying to figure out, if the routing table have
10.13.13.0/24 10.11.11.1
10.13.13.0/24 link#1
And if I do ssh 10.13.13.2, which route should be used?
the route with the lower weight.
if they have the same weight, use any of them.
I get the principle, the
Sure, but such a configuration did not make much sense.
Why not?
Use CARP and OSPF and you have such a configuration.
Okay, I will try that.
I hoped, that now, as freebsd has multi-route support (as other unix
really have for a long long time) everything would be easier.
But
Hi,
I have changed the route selection code of ecmp to
balance only between routes of the same weight.
(see attached file)
As Qing Li mentioned months ago, there are problems with static routes
and interfaces.
Do you have the exact link to the email thread?
There were no
As Qing Li mentioned months ago, there are problems with static
routes
and interfaces.
Do you have the exact link to the email thread?
There were no pending ECMP related issues since my last round of
commits
as far as I can remember.
Hi Ruslan,
Doesn't seem to have any effect. Please see
http://lists.freebsd.org/pipermail/freebsd-net/2010-March/024728.html
on how to reproduce.
Could you please try the patch at:
http://people.freebsd.org/~qingli/ng-patch.diff
I was able to reproduce the problem and the patch
Hi Ruslan,
Yes, I can reproduce this issue. The patch is still necessary, however,
it does not resolve the if_ng issue because if_ng is a virtual interface
that is not really associated with any physical nic. The physical NIC is
where all of the entries (including the proxied entries) are kept.
Yes, it's still broken (it's a regression compared to 7.x). A
workaround I've found working after analyzing the newer kernel
code is to ALWAYS use the same IP address for the local end of
the tunnel as of the corresponding ARP capable interface.
Are you using VLANs?
Were you
I have been monitoring the tcpm ML debate about this draft for
the past year. Frankly for the past two months the volume of
tinygrams on the subject is so overwhelming I stopped reading
any email relating to this topic.
I think Mark Allman's email titled TCPM posted on March 2
put things into
This topic has come up quite a few times. Please search into the ML
archive
(as recent as 2 weeks ago) and read about the details.
I get an ugly error message on current, but at least it setups the
address:
[98]chipmunk.cicely.de# arp -an
? (10.1.1.9) at 00:1c:c0:94:2c:d7 on vlan0 expires
Please try this patch
http://people.freebsd.org/~qingli/nd6.c.diff
and let me know if it works out for you.
Thanks,
-- Qing
-Original Message-
From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
n...@freebsd.org] On Behalf Of Li, Qing
Sent: Tuesday, February 23
Okay, I read through your core file and I think I see the problem now.
Let me try to get you a patch later tonight.
-- Qing
-Original Message-
From: owner-freebsd-...@freebsd.org on behalf of Doug Barton
Sent: Tue 2/23/2010 12:38 PM
To: freebsd-net@freebsd.org
Subject: Apparent IPv6
/8/sys/netinet/in.c?view=log
Then please report back the result of your verification.
--Qing
From: Brett Glass [mailto:br...@lariat.net]
Sent: Fri 2/12/2010 2:39 PM
To: David Horn
Cc: Li, Qing; n...@freebsd.org
Subject: Re: Routing problems on VPN servers
, and whatever other pieces of information you are
willing to share.
Thanks,
-- Qing
From: Brett Glass [mailto:br...@lariat.net]
Sent: Fri 2/12/2010 4:04 PM
To: Li, Qing
Cc: n...@freebsd.org
Subject: RE: Routing problems on VPN servers running FreeBSD 8.0
Read the manpage. only just require a host route to be present.
I don't think it will make a difference here.
-- Qing
-Original Message-
From: Brett Glass [mailto:br...@lariat.net]
Sent: Fri 2/12/2010 6:30 PM
To: Li, Qing
Cc: n...@freebsd.org; Li, Qing; Luiz Otavio O Souza
Subject: RE
Okay, well, I need to pack. So will get back to it in a week.
-- Qing
-Original Message-
From: Brett Glass [mailto:br...@lariat.net]
Sent: Fri 2/12/2010 6:22 PM
To: Li, Qing
Cc: n...@freebsd.org; Li, Qing; Luiz Otavio O Souza
Subject: RE: Routing problems on VPN servers running FreeBSD
the ECMP code is probably not the best
piece to start with, but you seem to ignore whatever I have
said completely ...
-- Qing
From: owner-freebsd-curr...@freebsd.org on behalf of Balaji G
Sent: Thu 2/11/2010 12:21 AM
To: Li, Qing
Cc: qin...@freebsd.org; curr
The ECMP (indirect) routes are installed into the FIB just fine, and
load balancing works fine with these routes.
The problem is with interface prefix routes. See my other email for details.
Because only a single prefix route was installed, obviously there is no
load balancing.
-- Qing
I
Can you at least build one 8-stable system and see if the latest
patches resolve your problems before we carry on with the
merge into 8-release or other alternatives discussion ?
-- Qing
Date: Thu, 04 Feb 2010 22:41:38 -0700
From: Brett Glass br...@lariat.net
To:Li, Qing
One of the advantages of enabling ECMP is to allow for connection load
balancing.
Currently the address alias handling method is colliding with the ECMP code.
For example, when two interfaces are configured on the same prefix, only
one prefix route is installed. So connection load balancing is
Sure enough, that fixes this warning. Yea. But, sadly, it causes
other problems. If you look at sbin/atm/atmconfig/natm.c you'll see
code like:
static void
store_route(struct rt_msghdr *rtm)
{
...
char *cp
struct sockaddr *sa;
...
cp = (char *)(rtm + 1);
Not since the ARP table and the routing table have been split.
However, the addresses for which the machine is doing proxy ARP do
need to show up there, and they do not.
You described a bug symptom that should have been fixed.
The proxy ARP entry should be displayed in the ARP table
after
The problems seem to be that (a) proxy ARP doesn't get set
up in either the ARP table or the routing table, and
Proxy ARP entries are not installed into the routing table.
I believe I have fixed this issue in svn r201282 and merged
into 8-STABLE
Few of the symptoms you described here were present in the vanilla
8.0-RELEASE but I have been fixing these in 8-STABLE since the official
announcement.
Could you please try 8-STABLE and report back if these problems
persist there?
-- Qing
-Original Message-
From:
Just an update on this issue and to letting you know your
report is not ignored.
I have been working with Sherin George offline and we have
Been pulling information off Sherin's server box.
The box becomes unresponsive after about 4 days. The routing
table is fine is properly accessed. The ARP
I have been consumed by day job 200% of my time.
I have some free time tonight and can work with you off-line.
Is it possible for you to update to the latest stable-8 kernel
and we start from there ?
-- Qing
-Original Message-
From: owner-freebsd-...@freebsd.org on behalf of Sherin
We only need one 'me' option that matches v4 and v6, because the
other two can be implemented as 'ip4 me' and 'ip6 me' at no extra
cost (the code for 'me' only scans the list corresponding to the
actual address family of the packet). I would actually vote for
removing the 'me6'
Sorry, I didn't even see your original email until today.
Please send problem reports directly to qin...@freebsd.org
instead of my work email to get faster response.
Thanks,
-- Qing
On Sun, Jan 3, 2010 at 12:18 AM, David Horn dhorn2...@gmail.com
wrote:
Qing --
I have been having some
Thanks for reporting back and the detailed description.
- bgpd don't terminate, it's OK
Okay, making progress.
but there appeared some new problems:
Interestingly enough, my patch is to resolve the issue where adding
and removing address aliases are not reported. This issue appears to
16, 2009, at 6:39 PM, Li, Qing wrote:
Hi,
You have reported issues regarding openbgp/bgpd exiting
abnormally. Please apply patch:
http://people.freebsd.org/~qingli/bgpd-patch-121615.diff
and let me know if it fixes your issue. I performed limited
unit testing.
Thanks
Hi,
Could you please tell us what version you are running?
If the tcp_output just have some error, for example: when alloc mbuf,
it returns NULL, and then the snd_nxt number will not be return to
normal.
If just in this time, SYN Ack arrives, freeBSD can't handle this
situdition.
I have
Hi,
You have reported issues regarding openbgp/bgpd exiting
abnormally. Please apply patch:
http://people.freebsd.org/~qingli/bgpd-patch-121615.diff
and let me know if it fixes your issue. I performed limited
unit testing.
Thanks,
-- Qing
Thanks for reporting back. I asked you for a routing table dump
in my previous email, would you mind emailing it to me privately?
-- Qing
-Original Message-
From: Tom Pusateri [mailto:pusat...@bangj.com]
Sent: Tuesday, December 15, 2009 1:28 PM
To: Li, Qing
Cc: freebsd-net
...@freebsd.org] On Behalf Of Li, Qing
Sent: Tuesday, December 15, 2009 1:46 PM
To: Tom Pusateri
Cc: freebsd-net@freebsd.org; freebsd-sta...@freebsd.org
Subject: RE: patch: bad ipv6 neighbor solicitation
Thanks for reporting back. I asked you for a routing table dump
in my previous email, would you mind
Hi,
Recently there have been several reports regarding issues with ppp, mpd5
and proxy-arp configuration over the ppp links. I read through the
various postings and the problems seem to be:
1. Unable to add proxy-arp entries for the remote ppp clients.
2. Log showing ifa_add_loopback_route:
I will take a look at it later today.
-- Qing
-Original Message-
From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
n...@freebsd.org] On Behalf Of Dennis Glatting
Sent: Sunday, December 13, 2009 1:59 PM
To: freebsd-net@freebsd.org
Subject: Understanding multiple IPv6
Please try the temporary patch at:
http://people.freebsd.org/~qingli/nd6-ns.diff
and it should fix your problem.
-- Qing
-Original Message-
From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
n...@freebsd.org] On Behalf Of Li, Qing
Sent: Monday, December 14, 2009 10
Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I was
expecting bce1 rather than lo0, I suppose you were as well :)
This loopback route is necessary for short circuiting traffic to
local address within a node.
-- Qing
If I'm not mistaken, the
You don't need to perform all that route-foo. I believe the root cause of
this issue may be due to a bit of regression in the IPv6 prefix management
code, and I am in the process of putting together a permanent fix.
The issue as it stands today, is due to how the prefix was inserted in
the first
apply the
patch and report back.
Thanks,
-- Qing
-Original Message-
From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
n...@freebsd.org] On Behalf Of Li, Qing
Sent: Monday, December 14, 2009 3:00 PM
To: Dennis Glatting; JASSAL Aman
Cc: freebsd-net@freebsd.org
Subject: RE
I will look into it and get back to you.
-- Qing
-Original Message-
From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
n...@freebsd.org] On Behalf Of Harti Brandt
Sent: Sunday, November 22, 2009 5:09 AM
To: freebsd-net@freebsd.org
Subject: ARP regression in releng-8
Hi
I am not sure if what you are observing is a side effect of
svn-r196714. In particular, the code I added for:
- Routing messages are not generated when adding and removing
interface address aliases.
If my memory serves me right, I put in the above
[mailto:owner-freebsd-
n...@freebsd.org] On Behalf Of Li, Qing
Sent: Sunday, November 22, 2009 10:40 AM
To: Adam Jacob Muller; freebsd-net@freebsd.org
Subject: RE: openbgpd + 8.0
I am not sure if what you are observing is a side effect of
svn-r196714. In particular, the code I added
I remember looking at this bug and tried to reproduce it ...
If my memory serves me right, I believe this bug was fixed by
svn r197364, committed on 9/20. RC1 was built on 9/17.
Another symptom of this bug is the route get command issued
on any lo0 addresses returns destination: default
I have committed the fix into the -current branch, svn r198111.
Please give it a try and I plan to MFC the patch into 8.0 release branch
in 3 days.
Thank you for the report.
-- Qing
-Original Message-
From: owner-freebsd-curr...@freebsd.org on behalf of Li, Qing
Sent: Wed 10/14/2009 6
I know that arp has changed a lot in FreeBSD 8. I am wondering if one
change was by design? In older versions of FreeBSD, if you ping a host
that is on a local network but is down, after a few seconds ping displays:
ping: sendto: Host is down
ping: sendto: Host is down
Might be a regression issue. I will take a look and get back
to you later today.
-- Qing
-Original Message-
From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
n...@freebsd.org] On Behalf Of Larry Baird
Sent: Monday, October 12, 2009 7:42 AM
To: freebsd-net@freebsd.org
Hi, I keep getting these messages whenever I restart OpenVPN. My
configuration indeed has some static routes that's supposed to clean
upon shutdown, but neither of them have a loopback address as a next
hop.
This message is harmless, however, could you please email me
Your ifconfig -a and
I cannot reproduce this problem. I configured my system according to the
bug
description and I get the expected error message:
---
# traceroute6 2a02:898:17:1234::
connect: Network is unreachable
---
-- Qing
Li, Qing wrote:
Me and many other people running net/mpd handling thousands of PtP
interfaces sharing local addresses with each other and with some
Ethernet interface. This change makes such setup inoperable, as mpd
will constantly receive errors while trying to set addresses and
drop
1 - 100 of 166 matches
Mail list logo
