https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218959
Sprow changed:
What|Removed |Added
Summary|routed closes socket 0 when |routed(8) closes socket 0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218959
Alexander Vereeken changed:
What|Removed |Added
Keywords|patch |
--
You are receiving this m
<>
That's been a very workable system.
p vixie
On May 17, 2024 21:32, "Rodney W. Grimes" wrote:
> Scott writes:
> > Anyway, fun's over. Perhaps this is a greater lesson that the Foundation
> > provide the rules under which code is added or removed from base and then
> > we'd all be
> Scott writes:
> > Anyway, fun's over. Perhaps this is a greater lesson that the Foundation
> > provide the rules under which code is added or removed from base and then
> > we'd all be the wiser.
>
> The FreeBSD Foundation does not set project policy, the FreeBSD Core
> Team does.
Sadly tha
Scott writes:
> Anyway, fun's over. Perhaps this is a greater lesson that the Foundation
> provide the rules under which code is added or removed from base and then
> we'd all be the wiser.
The FreeBSD Foundation does not set project policy, the FreeBSD Core
Team does.
DES
--
Dag-Erling Smør
tails on that.
i apologise if it came across as unnecessarily rhetorical, but i
often find the easiest way to explain my reasoning behind something is
by example. perhaps this is a personal flaw :-)
in any case it sounds like you're content with routed being moved to a
port rather than b
> > Anyway, I'm a user, albeit a small user, of RIP and wouldn't object to its
> > removal from FreeBSD if there were a small footprint alternative. I've
> > used
> > FRR and VyOS a bit and they are overkill as replacements.
>
> Cy has already create
ual oci management :-)
> would people objecting to the removal of routed also advocate for
> putting window(1) back into base? (this is not a rhetorical question,
> 'yes' is a perfectly reasonable answer.)
The subtle difference between "removing RIP/RIPng (routed/route6d)&q
ere a small footprint alternative. I've used
> FRR and VyOS a bit and they are overkill as replacements.
Cy has already created ports for these (although i haven't tested them
yet):
https://cgit.freebsd.org/ports/tree/net/freebsd-routed
https://cgit.freebsd.org/ports/tree/net/free
behalf of Marek Zarychta
*Date: *Wednesday, May 15, 2024 at 11:19 AM
*To: *freebsd-net@freebsd.org
*Subject: *Re: removing RIP/RIPng (routed/route6d)
Today Michael Sierchio wrote:
There is an argument to be made that all such components of the
"base" system should be packages, an
: removing RIP/RIPng (routed/route6d)
Today Michael Sierchio wrote:
There is an argument to be made that all such components of the "base" system
should be packages, and managed that way. That would facilitate removal or
addition of things like MTAs, Route daemons for various protocols,
mons
from src. if
>>> there's some concern that people still want to use the BSD
>>> implementation of routed/route6d, i'm also willing to submit a
port such
>>> as net/freebsd-routed containing the old code, in a similar
way to how
o remove both of these daemons from src.
> if
> >>> there's some concern that people still want to use the BSD
> >>> implementation of routed/route6d, i'm also willing to submit a port
> such
> >>> as net/freebsd-routed containing the old code, in a
tt wrote:
>>> On Mon, Apr 15, 2024 at 09:49:27PM +0100, Lexi Winter wrote:
>>> (..)
>>> i'd like to submit a patch to remove both of these daemons from src. if
>>> there's some concern that people still want to use the BSD
>>> implementation of r
On Wed, May 15, 2024 at 4:20 PM Scott wrote:
> On Mon, Apr 15, 2024 at 09:49:27PM +0100, Lexi Winter wrote:
> > (..)
> > i'd like to submit a patch to remove both of these daemons from src. if
> > there's some concern that people still want to use the BSD
>
On Mon, Apr 15, 2024 at 09:49:27PM +0100, Lexi Winter wrote:
> [note: this is a copy of a mail i sent this to arch@, but someone
> suggested also asking net@ about this.]
>
> hello,
>
> currently FreeBSD ships routed(8) and route6d(8) which implement the RIP
> resp. RI
On Mon, 15 Apr 2024 at 16:49, Lexi Winter wrote:
>
> currently FreeBSD ships routed(8) and route6d(8) which implement the RIP
> resp. RIPng routing protocols.
> ...
> i'd like to submit a patch to remove both of these daemons from src. if
> there's some concern that
[note: this is a copy of a mail i sent this to arch@, but someone
suggested also asking net@ about this.]
hello,
currently FreeBSD ships routed(8) and route6d(8) which implement the RIP
resp. RIPng routing protocols.
many years ago, it was fairly common for hosts to run these protocols to
get
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270644
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
g people from
> "traditional" routing suites/daemons.
> With all that in mind, I see RIP popularity and usage going in only one
> direction.
Btw, I do use RIPv2 in production these days (but with ripd, not routed) and I
have several reasons to do so.
First, RIPv2 is distance-v
On Wed, 24 Jun 2020 10:07:34 +0100 Alexander V. Chernikov melif...@freebsd.org
said
22.06.2020, 14:54, "Hiroki Sato" :
> "Alexander V. Chernikov" wrote
> in <273191592779...@mail.yandex.ru>:
>
> me> Hey,
> me>
> me> I would like t
22.06.2020, 14:54, "Hiroki Sato" :
> "Alexander V. Chernikov" wrote
> in <273191592779...@mail.yandex.ru>:
>
> me> Hey,
> me>
> me> I would like to propose removal of sbin/routed and usr.sbin/route6d.
>
> I am still using both of t
22.06.2020, 13:50, "Rodney W. Grimes" :
>> Hey,
Hi Rodney,
>>
>> I would like to propose removal of sbin/routed and usr.sbin/route6d.
>
> I disagree with removal, as your analysis is flawed.
Thank you for the feedback!
>
>> routed(8) is the
23.06.2020 12:33, Rodney W. Grimes wrote:
> Can you agree with that logic Eugene?
I'm not against keeping routed(8) in the base while it has happy users raising
voice for it.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org
> 23.06.2020 2:26, Rodney W. Grimes wrote:
>
> >> 22.06.2020 19:49, Rodney W. Grimes wrote:
> >>> Whats unmaintained about code that has no need to change cause it just
> >>> pretty much works?
> >> Have you actually tried running routed(8) as bas
23.06.2020 2:26, Rodney W. Grimes wrote:
>> 22.06.2020 19:49, Rodney W. Grimes wrote:
>>> Whats unmaintained about code that has no need to change cause it just
>>> pretty much works?
>> Have you actually tried running routed(8) as base for real network with
>&g
> 22.06.2020 19:49, Rodney W. Grimes wrote:
>
> > Whats unmaintained about code that has no need to change cause it just
> > pretty much works?
>
> Have you actually tried running routed(8) as base for real network with loops,
> mix of p2p and ethernet-like interf
"Alexander V. Chernikov" wrote
in <273191592779...@mail.yandex.ru>:
me> Hey,
me>
me> I would like to propose removal of sbin/routed and usr.sbin/route6d.
I am still using both of them in production environments because they
work well at least for my configurati
22.06.2020 19:49, Rodney W. Grimes wrote:
> Whats unmaintained about code that has no need to change cause it just pretty
> much works?
Have you actually tried running routed(8) as base for real network with loops,
mix of p2p and ethernet-like interfaces, IPv4 aliases, need of offset-lis
> Hey,
>
> I would like to propose removal of sbin/routed and usr.sbin/route6d.
I disagree with removal, as your analysis is flawed.
> routed(8) is the daemon implementing RIPv2 routing protocol.
> route6d(8) is the daemon implementing RIPng routing protocol for IPv6.
>
&g
22.06.2020 6:05, Alexander V. Chernikov wrote:
> To summarise: RIP protocol is obsolete, implementations for newer protocols
> exists in ports, implementation in base is unmaintained.
Too many reasons but one real one: it's broken since FreeBSD 4 at least when I
tried to use it in production
Sounds good to me. We don't need a RIP daemon in base, and if needed,
it is just a pkg install away via one of the myrriad maintained
routing daemons.
Thanks,
Conrad
On Sun, Jun 21, 2020 at 4:06 PM Alexander V. Chernikov
wrote:
>
> Hey,
>
> I would like to propose removal of
Hey,
I would like to propose removal of sbin/routed and usr.sbin/route6d.
routed(8) is the daemon implementing RIPv2 routing protocol.
route6d(8) is the daemon implementing RIPng routing protocol for IPv6.
RIP [1] was one of the first protocols used in the networking. The first
version was
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218959
Mark Linimon changed:
What|Removed |Added
Keywords||patch
Assignee|freebsd-b.
% system, 4.2% interrupt, 90.1% idle
> > CPU 6: 1.4% user, 0.0% nice, 3.8% system, 1.4% interrupt, 93.4% idle
> > CPU 7: 2.8% user, 0.0% nice, 0.0% system, 3.8% interrupt, 93.4% idle
> >
> > 34263 igb0:que 0
> > 32308 igb0:que 1
> > 35022 igb0:que 2
>
le
> CPU 6: 1.4% user, 0.0% nice, 3.8% system, 1.4% interrupt, 93.4% idle
> CPU 7: 2.8% user, 0.0% nice, 0.0% system, 3.8% interrupt, 93.4% idle
>
> 34263 igb0:que 0
> 32308 igb0:que 1
> 35022 igb0:que 2
> 34593 igb0:que 3
> 14931 igb1:que 0
> 13059 igb1:que 1
>
:que 2
34593 igb0:que 3
14931 igb1:que 0
13059 igb1:que 1
12971 igb1:que 2
13032 igb1:que 3
So I guess interrupts are routed correctly after all, but for some reason
driver takes some 5 times less time to process it on cpus 4-7
(per-interrupt). Weird.
On Wed, Oct 21, 2015 at 10:41 AM, John Baldwin
On Tuesday, October 20, 2015 06:31:47 PM Maxim Sobolev wrote:
> Here you go:
>
> $ sudo procstat -S 11
> PIDTID COMM TDNAME CPU CSID CPU MASK
>11 100082 intr irq269: igb1:que 41 4
>11 100084 intr irq270: igb1:que 51 5
>11
ts, so my
> guess
> > that for whatever reason bus_bind_intr() is not doing what's expected to
> do
> > for half of those interrupts.
> >
> > What's interesting is that on a similar box (same chassis/mobo/cpu) but
> > equipped with the quad-port X540-AT2 10
ilar box (same chassis/mobo/cpu) but
> equipped with the quad-port X540-AT2 10Gig card, interrupts are routed
> properly. The latter is running with hw.ix.num_queues="3".
>
> pcib2: port 0xcf8-0xcff on acpi0
> pci0: on pcib2
> pcib3: irq 26 at device 1.0 on pci0
>
ts, so my guess
that for whatever reason bus_bind_intr() is not doing what's expected to do
for half of those interrupts.
What's interesting is that on a similar box (same chassis/mobo/cpu) but
equipped with the quad-port X540-AT2 10Gig card, interrupts are routed
properly. The lat
Hi,
I'm just going off what I saw in the code. Maybe the code changed and
the bug was introduced.
I suggest:
(a) use ipfw to filter them for now; and
(b) file a PR (https://bugs.freebsd.org/submit/) so it's not forgotten.
Thanks!
-a
___
freebsd-net@
On Sun, Oct 5, 2014 at 6:24 PM, Brandon Vincent
wrote:
> On Sun, Oct 5, 2014 at 2:39 PM, Adrian Chadd wrote:
> > All accept_sourceroute does is prevent the stack from forwarding
> > source routed packets. If it's destined locally then it's still
> > accept
On Sun, Oct 5, 2014 at 2:39 PM, Adrian Chadd wrote:
> All accept_sourceroute does is prevent the stack from forwarding
> source routed packets. If it's destined locally then it's still
> accepted.
Out of curiosity, isn't "net.inet.ip.accept_sourceroute" suppose
Hi,
Can you please get a packet capture of what it's sending and what it's
receiving?
All accept_sourceroute does is prevent the stack from forwarding
source routed packets. If it's destined locally then it's still
accepted.
You could try crafting an ipfw rule to filter ou
kalin wrote:
> ok.. this is getting a bit ridiculous…
>
> just did a brand new install of the freebsd 9.3 aim on amazon…
>
> with nothing installed on it and only ssh open i get the same result when
> scanning with openvas:
>
> "Summary:
> The remote host accept
ok.. this is getting a bit ridiculous…
just did a brand new install of the freebsd 9.3 aim on amazon…
with nothing installed on it and only ssh open i get the same result when
scanning with openvas:
"Summary:
The remote host accepts loose source routed IP packets.
The feature was designe
adding "set block-policy return" to pf.conf? OpenVAS
> might be assuming that a lack of response from your system to source
> routed packets is an acknowledgement that it is accepting them.
>
> Brandon Vincent
>
___
freebsd-net
On Sun, Oct 5, 2014 at 8:33 AM, el kalin wrote:
> should is submit this as a bug?
Can you first try adding "set block-policy return" to pf.conf? OpenVAS
might be assuming that a lack of response from your system to source
routed packets is an acknowledgement that it is accepting t
eroute="NO"
> accept_sourceroute="NO"
>
>
> what am i missing? this is pretty important….
>
> thanks…..
>
>
>
> On Sat, Oct 4, 2014 at 11:46 PM, el kalin wrote:
>
>>
>> hi all…
>>
>> i'm setting up a freebsd 10
eebsd 10 on aws (amazon) to be as secure as possible…
> i used openvas to scan it and pretty much everything is fine except this:
>
> "The remote host accepts loose source routed IP packets.
> The feature was designed for testing purpose.
> An attacker may use it to circumvent po
hi all…
i'm setting up a freebsd 10 on aws (amazon) to be as secure as possible…
i used openvas to scan it and pretty much everything is fine except this:
"The remote host accepts loose source routed IP packets.
The feature was designed for testing purpose.
An attacker may use it to
Synopsis: [patch] routed(8): if.c in routed fails to compile if time_t and long
are different sizes
State-Changed-From-To: open->closed
State-Changed-By: kevlo
State-Changed-When: Tue Nov 1 03:25:20 UTC 2011
State-Changed-Why:
Fixed in r204405
http://www.freebsd.org/cgi/query-pr.cgi?pr=155
Charles Sprickman wrote
in :
sp> On Tue, 17 May 2011, Hiroki Sato wrote:
sp>
sp> > Charles Sprickman wrote
sp> > in
sp> > :
sp> >
sp> > sp> First, the easy one. For IPv6 aliases, what is the proper subnet?
sp> >
sp> > Normally it is a /64. See also Section 2.5.4 in RFC 4291.
sp>
sp> My und
ne, which is also probably easy. We're going to move
sp> at some point from a bunch of subnets on the same wire to having our
sp> own router that gets our blocks routed to it. At that point I'd like
sp> to move to routing individual IPs (or small subnets) to each host
sp> be
the same wire to having our
sp> own router that gets our blocks routed to it. At that point I'd like
sp> to move to routing individual IPs (or small subnets) to each host
sp> behind the router.
sp>
sp> For example, say we have the following routed to our router:
sp>
sp>
ome point from a bunch of subnets on the same wire to having our own
router that gets our blocks routed to it. At that point I'd like to move
to routing individual IPs (or small subnets) to each host behind the
router.
For example, say we have the following routed to our router:
10.1.
Old Synopsis: if.c in routed fails to compile if time_t and long are different
sizes
New Synopsis: [routed] [patch] if.c in routed fails to compile if time_t and
long are different sizes
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Chan
On Nov 14, 2010, at 02:23 , Milen Dzhumerov wrote:
> We're investigating some ways to perform symbolic execution of distributed
> systems and we're looking for real-world programs to test. The "routed"
> daemon[1] which is included with FreeBSD seemed like
On 11/13/2010 05:23 PM, Milen Dzhumerov wrote:
Hi all,
We're investigating some ways to perform symbolic execution of distributed systems and
we're looking for real-world programs to test. The "routed" daemon[1] which is
included with FreeBSD seemed like a good candidate
On Sun, 14 Nov 2010, Milen Dzhumerov wrote:
> Hi all,
>
> We're investigating some ways to perform symbolic execution of
> distributed systems and we're looking for real-world programs to
> test. The "routed" daemon[1] which is included with FreeBSD see
Hi all,
We're investigating some ways to perform symbolic execution of distributed
systems and we're looking for real-world programs to test. The "routed"
daemon[1] which is included with FreeBSD seemed like a good candidate and I was
wondering whether anyone can point me t
The following reply was made to PR bin/127192; it has been noted by GNATS.
From: "Jens Kassel"
To: ,
Cc:
Subject: Re: bin/127192: routed(8) removes the secondary alias IP of interface
after 5 minutes - FreeBSD version 7.0
Date: Wed, 12 Aug 2009 12:30:14 +0200
This is a
Synopsis: routed(8) deletes link-level routes in the presence of a /32 alias
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: brucec
Responsible-Changed-When: Fri Jan 30 23:17:06 UTC 2009
Responsible-Changed-Why:
Over to maintainer(s).
http://www.freebsd.org/
Steve Bertrand wrote:
> Hi everyone,
...hrm...never mind.
I was trying too hard to think again...
The traffic was allowed through, obviously because the _destination_ is
allowed to be routed. I have no idea why I had such a lapse of sense ;)
Sorry for the noise. *hangs head*
St
168.100.21:3720
208.70.106.58:25 in via em0
Jan 29 18:59:59 lanx kernel: ipfw: 36 Count TCP 192.168.100.21:3720
208.70.106.58:25 out via em4
I can verify that the space is routed properly (via Quagga):
lanx# sh ip route 192.168.100.21
Routing entry for 192.168.0.0/16
Known via "bgp", d
Thank you.
The option "-iface" works as expected.
Also solved the problem when the squid 3.0.STABLE10 could not connect to
the real ip, which ISP issued on pppoe.
Now squid normally sees routes to these IP.
Li, Qing writes:
Hi,
I have committed a patch for this problem. Please sync-up to
nt: Thursday, December 25, 2008 1:33 AM
> To: Vladislav V. Prodan; Qing Li
> Cc: freebsd-net@freebsd.org; freebsd-curr...@freebsd.org
> Subject: RE: Odd behavior routed
>
> I found the bug and it was indeed introduced by the arp-v2
> changes.
>
> Since adding static ARP/NDP
Thu, Dec 25, 2008 at 01:32:43AM -0800, Li, Qing wrote:
> Please find the patch file in my home directory
> at http://people.freebsd.org/~qingli/arp-v2-patch-122508
The real URL is
http://people.freebsd.org/~qingli/arp-v2-patch-122408
--
Eygene
____ _.--. #
\`.|\...
December 24, 2008 11:33 AM
> To: freebsd-curr...@freebsd.org; freebsd-net@freebsd.org
> Cc: freebsd-hack...@freebsd.org
> Subject: Odd behavior routed
>
> # uname -a
> FreeBSD mary-teresa.X 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Dec
> 24
> 05:06:55 EET 2008
> vla...@m
o: freebsd-curr...@freebsd.org; freebsd-net@freebsd.org
> Cc: freebsd-hack...@freebsd.org
> Subject: Odd behavior routed
>
> # uname -a
> FreeBSD mary-teresa.X 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Dec
> 24
> 05:06:55 EET 2008
> vla...@mary-teresa.x:/usr/obj/usr/src
Vladislav V. Prodan writes:
Before rebuild kernel, it appeared, and now there is no.
It is now adding routes?
That is so not working:
route add -net 79.140.0.0/20 -iface tun2
That's how works:
route add -net 79.140.0.0/20 195.138.80.168
Option "-interface" also does not help.
# uname -a
FreeBSD mary-teresa.X 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Dec 24
05:06:55 EET 2008
vla...@mary-teresa.x:/usr/obj/usr/src/sys/mary-teresa.10 amd64
We have two providers on tun1 and tun2.
>>/etc/rc.conf:
...
gateway_enable="YES"
router="/sbin/route
Synopsis: [bpf] [patch] bpf incorrectly determines outgoing routed packets as
incoming when BIOCSDIRECTION is used
Responsible-Changed-From-To: freebsd-net->jkim
Responsible-Changed-By: jkim
Responsible-Changed-When: Mon Apr 28 19:19:36 UTC 2008
Responsible-Changed-Why:
This is my bug. G
Old Synopsis: bpf incorrectly determines outgoing routed packets as incoming
when BIOCSDIRECTION is used
New Synopsis: [bpf] [patch] bpf incorrectly determines outgoing routed packets
as incoming when BIOCSDIRECTION is used
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsi
On Apr 8, 2008, at 11:10 AM, Martes G Wigglesworth wrote:
When fielding a newer, less resource rich system as access point/
router,
I noticed that after about five minutes of a client securing a good
connection, the ip address of the ath0 device dissappeared from the
routing table, and routed
address of the ath0 device dissappeared from the
routing table, and routed began spitting out errors indicating that it
could not find the route, etc... When this behavior starts/started the
connectivity also becomes unstable; meaning that any client connected to
the AP sees the connection fail, and
Hi Philip,
> Yepps. And adding bridged does not help either.
> I'm beginning to belive that I am the problem since there must be other
> people doing this.
did you resolve your problem ? If yes, what was the solution ?
Regards,
--
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile
Jeremie Le Hen wrote:
Hi Philip,
both counters increase.. and the last one "allow ip from any to any"
But I guess that is because it matches the rules two times.
I have tried only having one rule but the same problem ( ofcourse only
one way. )
I have also experimented with recv and xmit
Hi Philip,
> both counters increase.. and the last one "allow ip from any to any"
>
> But I guess that is because it matches the rules two times.
> I have tried only having one rule but the same problem ( ofcourse only
> one way. )
> I have also experimented with recv and xmit without success..
fooler wrote:
- Original Message -
From: "Philip Olsson" <[EMAIL PROTECTED]>
To:
Sent: Monday, July 11, 2005 2:43 PM
Subject: ipfw+dummynet only getting half bandwidth when using
routedinterfaces.
This is a typo, sorry!
Supposed to be 2048Kbit/s
ok
This is my conf
vladone wrote:
Hello Philip,
Monday, July 11, 2005, 9:43:39 AM, you wrote:
Hello
I have a working setup with ipfw+dummynet+bridge where I get proper
speeds but I want to have routed interfaces instead and skip the bridge.
But when converting to routed interfaces the bandwith
Hello Philip,
Monday, July 11, 2005, 9:43:39 AM, you wrote:
> Hello
> I have a working setup with ipfw+dummynet+bridge where I get proper
> speeds but I want to have routed interfaces instead and skip the bridge.
> But when converting to routed interfaces the bandwith throug
Hello
I have a working setup with ipfw+dummynet+bridge where I get proper
speeds but I want to have routed interfaces instead and skip the bridge.
But when converting to routed interfaces the bandwith through the queues
drops to half.
This is both in 5.4-REL and RELENG_5_4 and is showing on
On Tuesday 22 June 2004 02:27 pm, Bruce M Simpson wrote:
> Hi,
>
> Historically the Rhyolite routed has resided in src/sbin/routed.
>
> However, this code is maintained on a vendor branch, and as such,
> should really reside in src/contrib/routed and be referenced by
> the
Hi,
Historically the Rhyolite routed has resided in src/sbin/routed.
However, this code is maintained on a vendor branch, and as such,
should really reside in src/contrib/routed and be referenced by
the Makefile in src/sbin/routed accordingly.
Would we be able to move it with a repocopy? Or
share the same local IP address with
an ethernet interface (think of pppd and proxyarp).
2) routed, zebra and quagga cannot currently use outgoing RIPv2 multicasts
with IFF_POINTOPOINT interfaces (ppp, gif etc.) at least in 4-STABLE.
There was an attempt to fix this by modifying INADDR_TO
I need to set up a "loosely routed" tunnel between two boxes, one running
STABLE, and other 5.2.1-RELEASE. Under "loosely routed" I mean that tunnel
route won't be allocated once at tunnel creation, but looked up on every
emitting packet.
So, I have got a WAN link, an
Hi,
I've just merged version 2.27 of rhyolite.com's routed into the tree.
If you track -CURRENT and use the MD5 authentication feature, note that
it is no longer compatible with previous versions of FreeBSD; however it
is now compatible with the Sun Solaris and Cisco implementation
Synopsis: Routed does not reflect preference of Internet Router Discovery Protocol.
Responsible-Changed-From-To: freebsd-net->andre
Responsible-Changed-By: andre
Responsible-Changed-When: Tue Dec 30 01:59:14 PST 2003
Responsible-Changed-Why:
Take over.
http://www.freebsd.org/cgi/query-pr.cgi
Synopsis: Routed does not reflect preference of Internet Router Discovery Protocol.
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: bms
Responsible-Changed-When: Tue 25 Nov 2003 09:09:27 PST
Responsible-Changed-Why:
This probably wants wider discussion on -
Hi!
It seems there is a bug in routed(8): it aggregates routes
in its RIPv2 responses even when /etc/gateways contains:
ripv2
no_ag
no_super_ag
rtquery -t dump always shows full RIP2 table so routed(8)
has full information. However, rtquery -n shows only small part
of RIP2 table when there is a
At the other point, I cannot make routed(8) to announce default route
without introducing total mess. I tried to set non-zero hopcount
to the static default route or to run 'routed -s -g'.
In both cases routed starts to announce default route and
stops to keep (and announce) many o
John Polstra wrote:
> I'm trying for the first time to get routed(8) to do something useful,
> and it's got me stumped. The man page says:
>
> Static routes in the kernel table are preserved and included in RIP
> responses if they have a valid RIP metric (see rout
I'm trying for the first time to get routed(8) to do something useful,
and it's got me stumped. The man page says:
Static routes in the kernel table are preserved and included in RIP
responses if they have a valid RIP metric (see route(8)).
>From reading the sources, &quo
Eugene Grosbein wrote:
> I run routed(8) on a multihomed machine (3 NICs up and running).
> In that cases routed will not inject route from its RIP trable
In what cases, I want to ask.
Eugene
___
[EMAIL PROTECTED] mailing list
http://lists.freeb
Hi!
I run routed(8) on a multihomed machine (3 NICs up and running).
In that cases routed will not inject route from its RIP trable
into the kernel (kernel does not have more general route
through the same inteface)?
For example, consider route to 172.20.11.1/32:
# rtquery -n | fgrep 172.20.11
Not sure this is the correct list, as this question is only semi-technical,
but I'm going to try anyway. A quick note though, I don't think there is a
charter for this list on the freebsd site.
Anyway, I have two questions about routed:
1) Is there a way to force certain interfaces (o
Hi,
I've encountered a possible bug in routed code that's interfering
with path mtu discovery mechanism. Routed deletes any cloned route
as soon as it sees one (with exception of arp routes in the local
ethernet), including protocol cloned routes served as holders for
path mtu informat
On Wed, Sep 25, 2002 at 03:15:48PM -0400, Louis A. Mamakos wrote:
> > > I do not permit any ICMP packages...
> Sigh, and this is why Path MTU discovery is broken on the Internet.
'Packages' sounds awfully Checkpoint-ish.
There's a lot of it about these days. :-(
BMS
To Unsubscribe: send mail t
1 - 100 of 120 matches
Mail list logo
