Paul wrote:
Get these with GRE tunnel on
FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT
2008 :/usr/obj/usr/src/sys/ROUTER amd64
But do not get them with 7.0-RELEASE
Any ideas what changed? :) Wish there was some sort of changelog..
# of messages per second seems consis
Robert Watson wrote:
An FYI on the state of things here: in the last month, John has
updated a number of device drivers to be MPSAFE, and the USB work
remains in-flight. I'm holding fire a bit on disabling IFF_NEEDSGIANT
while things settle and I catch up on driver state, and will likely
sen
Robin Sommer wrote:
Hi all,
we're seeing some strange effects with our libpcap-based application
(the Bro network intrusion detection system) on a FreeBSD 7-RELEASE
system. As the application has always been running fine on 6.x,
we're wondering whether this might be triggered by any of the
chang
[EMAIL PROTECTED] wrote:
The only thing i can think of is that it's the UDP checksum,
residing beyond hlen, which is overwritten somewhere in the
call to if_simloop -- in which case perhaps a better fix is
to m_pullup() the udp header as well ?
It is the checksum that gets trashed, yes.
..
[EMAIL PROTECTED] wrote:
I gather you mean that a fast link on which also we're looping back
the packet will be an issue? Since this packet is only going into the
simloop() routine.
We end up calling if_simloop() from a few "interesting" places, in
particular the kernel PIM packet handler.
[EMAIL PROTECTED] wrote:
Somehow the data that the device needs to do the proper checksum
offload is getting trashed here. Now, since it's clear we need a
writable packet structure so that we don't trash the original, I'm
wondering if the m_pullup() will be sufficient.
If it's serious enoug
M. Warner Losh wrote:
I've been shepherding this patch in my p4 tree for a long time. It
removes the obsolete support for other systems in if_spppsubr.c. Is
there a reason I shouldn't commit this?
Looks fine to me.
___
freebsd-net@freebsd.org mai
Bjoern A. Zeeb wrote:
Hi,
I have a patch, that was inspired by work from Y!, to do porper
IPv4 source address selection for unbound sockets (with multi-IP
jails).
Hi,
This kinda overlaps with some other ideas I'd like to see go in. It
looks good and if it's already been tested, it should pro
Debarshi Ray wrote:
I am implementing a library/utility which basically encompasses the
features of the traditional route utilities and those of newer tools
(like ip from iproute2), which are mostly specific to a particular
kernel. The overpowering objective is to make the library/utility work
un
Debarshi Ray wrote:
...
I was going through the FreeBSD and NetBSD documentation and the
FreeBSD sources of netstat and route. I was suprised to see that while
NetBSD's route implementation has a 'show' command, FreeBSD does not
offer any such thing. Moreover it seems that one can not read the
en
Debarshi Ray wrote:
Why don't you just use XORP's FEA code?
It already does all this under a BSD-type license.
I was not aware of it. What does it do? Is it portable across other
OSes or is it *BSD specific?
XORP's FEA process is responsible for talking to the underlying
forwarding p
Luigi Rizzo wrote:
do you know if any of the *BSD kernels implements some good mechanism
to access a dynamic kernel data structure (e.g. the routing tree/trie,
or even a list or hash table) without the flaws of the two approaches
i indicate above ?
Hahaha. I ran into an isomorphic problem wi
Whenever I call this sysctl, I get an errno of EPROGNOTAVAIL from sysctl():
»···name[0] = CTL_NET;
»···name[1] = PF_LINK;
»···name[2] = NETLINK_GENERIC;
»···name[3] = IFMIB_IFDATA;
»···name[4] = ifindex;
»···name[5] = IFDATA_DRIVERNAME;
»···len = IFNAMSIZ;
»···if
Bruce M Simpson wrote:
It looks like the switch..case in that path could be fubar'd by the
compiler as there are not break statements for each distinct case
label, could this be due to gcc friendly fire?
Possibly false alarm or PEBKAC, I wasn't checking return values right in
Debarshi Ray wrote:
...
By the way, would you want someone to implement 'show' support for
FreeBSD's route implementation? I can give it a go now. :-)
For sure, we'd be very happy to see a patch like that.
Many thanks
BMS
___
freebsd-net@freebsd.o
[EMAIL PROTECTED] wrote:
Old Synopsis: icmp socket receives icmp replies not owned by the process.
New Synopsis: [icmp]: icmp socket receives icmp replies not owned by the
process.
This PR is bogus because:
ICMP has no concept of datagrams being "owned" by a process. There is no
field in t
The following reply was made to PR kern/127528; it has been noted by GNATS.
From: "Bruce M. Simpson" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: freebsd-net@FreeBSD.org, [EMAIL PROTECTED]
Subject: Re: kern/127528: [icmp]: icmp socket receives icmp replies not owned
by the pr
Chris Buechler wrote:
This PR is bogus because:
ICMP has no concept of datagrams being "owned" by a process. There is
no field in the ICMP protocol which differentiates ICMP "sessions" on
a per-process basis, and this is because ICMP has no concept of
"sessions" -- ICMP messages are directed
Hi,
I looked at ACE years and years ago (~1997) when Doug Schmidt was first
promoting the ideas behind it. The whole Reactor/Proactor split pretty
much hangs on the event dispatch which your particular OS supports.
The key observation is whether your target OS implements events in an
edge-tr
Hi,
I agree with the intent of the change that IPv4 and IPv6 input queues
should have a tunable queue length. However, the change provided is
going to make the definition of IFQ_MAXLEN global and dependent upon a
variable.
[EMAIL PROTECTED] wrote:
Hi,
It turns out that the last time anyone
[EMAIL PROTECTED] wrote:
...
I found no occurrences of the above in our code base. I used cscope
to search all of src/sys. Are you aware of any occurrences of this?
I have been using IFQ_MAXLEN to size buffer queues internal to some
IGMPv3 stuff.
I don't feel comfortable with a change w
Giulio Ferro wrote:
There are no messages in the logs, and no interface has been
touched. Anyway, since there are a lot of routes and only one
gets deleted I don't think it depends on interface changing
(it would delete them all, wouldn't it?)
Normally static routes only get touched if the st
Hi Ryan,
Did you initialize the .pr_init member of struct protosw for MPLS?
AFAIK, MPLS does not use an outer IP header, so adding a struct
ipprotosw won't work; they are similar structs however.
cheers
BMS
___
freebsd-net@freebsd.org mailing list
h
Yony Yossef wrote:
Hi All,
I'm trying to manually build an mbuf chain with clusters in various sizes.
I'm doing it using the MGETHDR and MEXTADD macros, it works fine.
Now I'm looking for the simplest way to free an mbuf cluster, since I want
to free the clusters seperately. This function will b
Hi,
I have been trying to get FreeBSD onto the Freecom FSG3 Storage Gateway.
It is an xScale based ARM system.
Whilst the npe(4) driver appears to attach, the PHY does not. It is a
Realtel RTL8305SB switch chip in dual miibus mode. Unfortunately the
RTL8305SB does not have ID registers. The RT
Sepherosa Ziehau wrote:
Are you sure you could read from BMSR? Return invalid value from BMSR
is the usual cause of miibus attaching/probing failure. For ID1/ID2
reading, you could just fake some values in npe(4)'s miibus_readreg
implementation.
Thanks for the tip (from you and Pyun). I ha
Julian,
Thank you (and Marko) very much for preparing this document.
The VIMAGE import has had me at something of an impasse re: the IGMPv3
branch and clearly written documentation is a big help indeed.
Julian Elischer wrote:
Well not completely, but I've had a number of questions over the
l
Espartano wrote:
Actually i know how to program with C language in a basic level but i
don't know nothing about hardware or computer organization, what
topics i should study for gain knowledges about net-drivers ? or if
someone can recommend me books about this topic i will be very
thankful.
[Resend to list for everyone]
Espartano wrote:
Actually i know how to program with C language in a basic level but i
don't know nothing about hardware or computer organization, what
topics i should study for gain knowledges about net-drivers ? or if
someone can recommend me books about this topi
Hi,
I am missing context of what Max's suggestion was, do you have a
reference to an old email thread?
Style bugs:
* needs style(9) and whitespace cleanup.
* C typedefs should be suffixed with _t for consistency with other
kernel typedefs.
* Function typedefs usually named like foo_func_t (s
Hi,
Just skimming this I notice it uses the if_afdata[AF_INET] pointer
purely for lltbl purposes; this clashes with the IGMPv3 code drop.
Please look in the bms_netdev branch, where I introduce a 'struct
ip_ifinfo' to make more general use of that slot. IGMPv3 needs to store
per-interface st
Peter Steele wrote:
..
Based on the discussion in the link above, it doesn't seem like the
problem was entirely resolved by the patches mentioned in this thread.
Has anything been done since this discussion took place. Surely there
must be a way to get limited broadcast to work under FreeBSD.
Peter Steele wrote:
...
It's really a matter of time. We didn't anticipate limited broadcast
being broken in FreeBSD and we're scrambling to come up with a solution.
To be quite frank I haven't done anything with IPv6 before so it would
be more research to get up to speed on this option. It seems
Peter Steele wrote:
The folk who point out that link-local addresses could be used, have
an
interesting suggestion which might work for you.
It's definitely interesting, but it is very likely that some of our
customers will want to be able to set their own IP ranges and not be
li
Peter Steele wrote:
...
I personally like this idea, but I'm not sure I can sell it to the
others. Are there any restrictions to these 169.254.x.y addresses?
169.254.0.0/16 must never appear outside a link -- it is strictly scoped
to that link.
Currently the IPv4 BSD stack has no concept
Bruce M. Simpson wrote:
Peter Steele wrote:
...
I personally like this idea, but I'm not sure I can sell it to the
others. Are there any restrictions to these 169.254.x.y addresses?
169.254.0.0/16 must never appear outside a link -- it is strictly
scoped to that link.
P.S. I check
Yony Yossef wrote:
Thanks for the explanation.
So there's no way to determine this in advance..
I must build a script that contains my own mapping between MAC addresses and
the wanted interface names and run it after each driver load, rename the
interfaces if necessary.
It seems quite wrong,
Yony,
Bruce M. Simpson wrote:
And how come the unit number is given an arbitrary value? Is there a
good
reason for that?
...
In your case I'm not sure why your two cards would flip order. Could
it be how your BIOS and hardware set up the PCI IDSEL lines at boot?
If this is the
Eygene Ryabinkin wrote:
...
I wanted to stress only one point: simple 'kldunload ' and
'kldload ' makes devices to flip for Yony's case. This means
that unless some PCI hotplug stuff is here (which I don't believe to be
present, because no physical cards are touched and there is actually a
small
Sam,
Sam Leffler wrote:
This patches avoids the crash. Not sure how ifma_protospec is
supposed to be handled so I'm not committing it.
Thanks for this.
I have a test machine ready to be prepped but it's missing a CF card (I
have none) so need to pick one up from a friend. I have a pci-cardb
Matthias Apitz wrote:
I went today evening with my EeePC and CURRENT on USB key
to that Greek restaurant; DHCP does not get IP in CURRENT either;
this is somehow good news, isn't it :-)
This may be orthogonal, but:
A lab colleague and I have been seeing a sporadic problem where the
ath0
The following reply was made to PR kern/132722; it has been noted by GNATS.
From: Bruce M Simpson
To: Matthias Apitz
Cc: bug-follo...@freebsd.org, Sam Leffler ,
freebsd-net@freebsd.org, "Sean C. Farley"
Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP
[Repost without attachment]
OK. We've managed to reproduce this set of symptoms now in our work area.
[If anyone needs to see a pcap, please Cc: me offlist.]
Timebase: beginning of the pcap is in sync with a bringup from
single-user mode; the tcpdump runs in the background from init whilst
bru...@freebsd.org wrote:
Synopsis: [libc] socket(2): INP_PORTHIGH and INP_ONESBCAST share same value
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: brucec
Responsible-Changed-When: Mon Mar 23 21:45:54 UTC 2009
Responsible-Changed-Why:
Over to maintainer(s).
John Hay wrote:
I found doing a -bgscan before it happens, make it not happen. I now
have -bgscan in my rc.conf.
That's exactly the workaround I needed. Thanks John.
As Sam points out, the root fix is probably already in HEAD; it would be
nice to find time to backport, but this works for u
The following reply was made to PR kern/132722; it has been noted by GNATS.
From: Bruce M Simpson
To: John Hay
Cc: Matthias Apitz , freebsd-net@freebsd.org,
Sam Leffler ,
"Sean C. Farley" , bug-follo...@freebsd.org
Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP
Hi,
Will Andrews wrote:
Hello,
I've written a patch (against 8.0-CURRENT as of r191369) which makes
it possible to build, load, run, & unload CARP as a module, using the
GENERIC kernel. It can be obtained from:
http://firepipe.net/patches/carp-as-module-20090421.diff
There's no need to i
Da Rock wrote:
So I could use some guidance as to what I can do to rectifiy this
problem. I have 2 goals:
1. setup iwi to start on boot, and attach to my ap whenever its in range.
2. make sure iwi stays connected without manually monitoring it.
3. prioritise my routes via the rl0 and iwi if's
I can only speak about IPv4 router alert in detail; we do nothing with
IPv4 RA nor would it appear that it would make any real difference in
performance given how the code is laid out. RSVP packets should be
passed verbatim to userland from ip_input() via rip_input() there.
I think your IPv6 f
I am very close to merging support for RFC 3678 to -CURRENT. I will
make a patch available before I commit.
The only userland consumer in the tree which is likely to be affected by
the removal of ip_multicast_if() from the kernel is routed, which I will
update to use the new setsourcefilter()
I'm all for this in principle. I believe that the case for FAST_IPSEC
over KAME IPSEC is fairly clear for those of us who have read the USENIX
paper. Qualitatively speaking I can say FAST_IPSEC has been more
pleasant to work with when introducing the TCP-MD5 support.
I will try to look at the
Rajkumar S wrote:
Hi,
I have a low cost 128kbps and a high cost 512 kbps link to internet.
Is it possible to do a "spillover" routing so that the high cost link
is used only when the low cost link is, say, used more than 80%.
This feature is almost certainly not going to be present in the base
Hi,
For a while now I have had a patch available to teach olsrd to use
IP_ONESBCAST instead of using libnet/bpf just to send broadcast
datagrams in FreeBSD, which has had IP_ONESBCAST for a few years now.
If anyone is using olsrd on FreeBSD I would greatly appreciate testing
and feedback for
Yar Tikhiy wrote:
Quagga still uses it, too, if its configure script detects FreeBSD
or NetBSD. I'm afraid it was me who submitted the patch to the
Quagga folks when I'd found that Quagga's ospfd couldn't handle
unnumbered P2P interfaces in FreeBSD because their local IPs weren't
unique. Unfort
Hi,
As part of my ongoing work to support Zero-configuration networking in
FreeBSD, please check out the following patches. I have been able to
browse and connect to services from with the KDE environment using these.
At the moment, the basic kernel support for Zeroconf/Bonjour is in place
i
First of all,
Xin: Many thanks for your excellent work on bringing the code up to date.
Mike Silbersack wrote:
No. That is not going into FreeBSD if I can help it.
http://www.ietf.org/ietf/IPR/ERICSSON-EIFEL
On top of that, we don't need yet another complication to the already
too-complex re
Andrew Thompson wrote:
I have come across this panic which appears to be from incorrect
refcounting on the inet6 multicast code.
I'm assuming this is in -CURRENT, as the refcount code has not yet been
MFCed.
...
in6m_refcount is still 1 so the in6_multi is not freed.
I'll try to investi
I can't speak for ALTQ at the moment however I believe dummynet may work
on vlan devices.
I was careful not to break this when rewriting ether_input() in
-CURRENT, as ip_dn_check_rule() is always called any time ether_demux()
is entered (regardless if ether_input() has been re-entered due to t
Andrew Thompson wrote:
I have come across this panic which appears to be from incorrect
refcounting on the inet6 multicast code.
I can reproduce this panic, however I don't entirely understand what's
going on. When the same IPv6 unicast address is configured twice on the
edsc0 interface, t
I speculate that the problem you are seeing in netinet6 is due to it not
freeing referenced in6_multi objects when the interface address changes
or the same address is re-added, as the same bug was present in netinet.
Previous to the introduction of refcounting, FreeBSD would just leak memory.
Bruce M Simpson wrote:
Comments and feedback, particularly more in-depth testing by another
contributor, are very welcome. I have tested this on my local 802.11
wireless segment with ath(4).
Before this can be committed to ports or pushed upstream, it is
missing an rc script.
There has
I am proud to announce the first code drop of SSM support for FreeBSD 7.0.
From the README file:
%%%
Source-Specific Multicast for FreeBSD 7.0 -- Phase I
This change brings FreeBSD closer to the standard of multicast API
support offered by Linux 2.6 and Microsoft Windows "Longhorn". It is
mostl
Gore Jarold wrote:
Comments ? The idea is to bond things into one, single, usable connection that
could provide multiple connections worth of bandwidth for single-threaded
network transactions (like downloading a single file from an ftp server).
Perhaps there is a better tool to do this with
Some ideas:
1. Enable IFF_STATICARP on your interface to stop ARP sending out to
resolve the IP/MAC address tuple.
2. Consider that you can deal with resolution in userland (RTF_RESOLVE)
but this involves changing the net's entry (route) in the FTE. You'd
then process RTM_RESOLVE messages an
Alan Garfield wrote:
Hi all!
One word HOW! :)
I've no clue what this FreeBSD ARP stuff is all about, there is little
or no documentation, there are 14 different sock_addr's which seem to
have a bazillion different fields, and I cannot output a simple debug
statement without getting 'error:
Hi,
Does anyone want to see these changes MFCed, or otherwise object to such
an MFC?
The introduction of M_PROMISC did the following:
* Drop frames immediately if the interface is not marked IFF_UP.
* Always trim off the frame checksum if present.
* Always use M_VLANTAG in preference to
I've had some feedback from Robert Watson which has been factored into
the branch. Thanks, Robert!
If I hear no objections I'll aim to commit this code to -CURRENT within
the next week, subject to approval. No MFC is planned because of the
magnitude of the change.
Regards,
BMS
__
Actually, I thought the change which moved the VLAN tag out of the mbuf
tag pool and into the mbuf packet header had also been MFCed. It has not.
As CURRENT is the branch normally used for feature development it is
probably best I don't MFC this unless the VLAN tag change is MFCed also.
There
Abraham K. Mathen wrote:
Is it possible to successfully sendto() on a UDP socket
with 127.255.255.255 as the destination address? If yes,
how can that be done.
No, because in FreeBSD, lo(4) is not implemented as a broadcast
interface. It is a multicast capable software loopback interface. I
Ozgur Ozdemircili wrote:
Hello,
I have a network of 10.10.10.0 and the gw is at 10.10.10.1. GW is
giving out ip with DHCP. If the client pc is configured with DHCP they
can get the ip from the server and go out to internet easily. But if
the client has* static Ip configured*, for example 192.168
Andre Oppermann wrote:
Synopsis: [ipv6] IPv6-related crash if if_delmulti
Responsible-Changed-From-To: freebsd-net->bms
Responsible-Changed-By: andre
Responsible-Changed-When: Sun May 13 18:36:25 UTC 2007
Responsible-Changed-Why:
Send over to BMS. He's active in that area and may have fixed th
Wilkinson, Alex wrote:
0n Mon, May 21, 2007 at 07:39:06PM +0100, Tom Judge wrote:
> I have also seen 700Mb/s sustained FreeBSD - FreeBSD using the openssh HPN
> patch set and no extra tuning of the network stack. Which makes me
> think that maybe the linux stack needs some tun
Luca Da Col wrote:
Hello,
I would like to know if someone is actively working on MPLS project for
FreeBSD. I would also like to know if James Leu's MPLS implementation for
Linux has been considered as starting point for this project.
No one is actively working on this to the best of my knowled
Jack Vogel wrote:
On 5/31/07, Wilkinson, Alex <[EMAIL PROTECTED]> wrote:
0n Wed, May 30, 2007 at 04:45:05PM -0700, Jack Vogel wrote:
> Does any driver do this now? And if a driver were to coalesce
> packets and send something up the stack that violates mss
> will it barf?
erm,
Eygene Ryabinkin wrote:
NFSD binds to the port nfsd (2049) and for my -CURRENT both lockd
and statd have '-p' options:
-
$ man rpc.lockd rpc.statd | grep -- -p
rpc.lockd [-d debug_level] [-g grace period] [-p port]
-p The -p option allow to force the daemon to bind to the speci
Julian Elischer wrote:
I have some thoughts on this.
firstly, while it is interesting to have an arp table (ok LLA table)
on each interface, I'm not sure that it gains you very much.
Unfortunately maintaining a single ARP table is insufficient for
supporting multiple paths within the IPv4 st
ghozzy wrote:
I've found a way:
# sysctl net.inet6.ip6.auto_linklocal=1
# ifconfig em0 down up
will assign link-local address to interface.
after all required interfaces have link-local addresses,
run /etc/rc.d/network_ipv6 start and all will be set ! :)
Well, this may work now, however, don't
Julian Elischer wrote:
In the future I am hoping to be able to use vimage in our products.
They are based at the moment on 6.1, but I can see in a year they will
be based on 7.x.
Patches for 7.0 and vimage are currently available in perforce.
What I would like to see is if there are any parts
George Michaelson wrote:
its interesting that when I sent-pr'd this, I got tut-tutted back to
freebsd questions. In my books, not being able to do this kind of V6
maintenance work on the interface without taking it down probably
deserves to be kept as an open bug!
I agree. Please mail me the
Synopsis: enabling IPv6 post-boot didn't work: required reboot
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: bms
Responsible-Changed-When: Sun Jun 24 22:37:28 UTC 2007
Responsible-Changed-Why:
Real issue. I may get around to this but am currently allocated
on non
Is your routing table correct? My default route entry for IPv6 just
looks like this:
default fe80::%gif0
UGSgif0
and gif0 just looks like this:
gif0: flags=8051 mtu 1280
tunnel inet a.b.c.d -> x.x.x.x
inet6 fe80::XXX:XXX:%
Eric F Crist wrote:
My problem isn't getting out to 2001:4980:1::5, it's getting to my
LAN, the 2001:4980:1:111::/64 network. My gateway, the machine from
which I posted the routing and ifconfig information, is able to ping
across the tunnel, and to the internet just fine. Nothing is able t
Mike Karels wrote:
I'd be happy to see the change undone as well. I (well, our test
group) found this change in a similar way, and it didn't agree with
our previous usage.
In -CURRENT my changes to the ethernet input path maintain the use of
ETHER_MAX_FRAME() however the check is folded un
Hi,
I may have some commercial work coming up which requires me to make
modifications to the IPv4 multicast forwarding code in Linux. It is
likely I will prototype the work in FreeBSD. It will probably not be
released publicly.
To prepare for this I have started cleaning up the MROUTING code
Please see the following patch which adds a check for the IP Router
Alert option, for use by in-kernel IPv4 protocol domain consumers:
http://people.freebsd.org/~bms/dump/ipoptions-routeralert.patch
Comments/review before commit appreciated.
regards
BMS
_
Christian S.J. Peron wrote:
...
One idea was to duplicate the socket options mbuf and pass in a NULL pointer
for the multi-cast options. Keep in mind that these are multicast options
associated with a divert socket.
So I guess the questions:
(1) Are there any users that are specifying multicas
Christian S.J. Peron wrote:
I can't think of a reason why a user would wish to supply any multicast
socket options to a divert socket, other than the 'small' ones, i.e.
IP_MULTICAST_TTL/IF/LOOP/VIF.
Why would these options ever be set on the divert socket itself though?
To me it would mak
Christian S.J. Peron wrote:
Well, it's still the intent to keep the ability to divert and re-inject
multicast packets. This change would basically say: "You cant specify
multicast options via the divert socket". Which in practice doesn't
happen anyway (where I looked).
I dont think we should be
rajneesh rana wrote:
hello all,
i am opening up two tap interfaces, both connected to bridge, assigning them
IP addresses and want to open up tcp connection b/w them without using
loopback interface, so i bind client socket to first tap using
SO_BINDTODEVICE option and socket server listening on
Tuc at T-B-O-H.NET wrote:
In my case, as always, its a bit "special". I have
2 OPENVPN tunnels, which I sent over different transits to
the same end host. On that host, I do my NAT. SO, without
getting into all sorts of hot/heavy things, is there a simple
program to install to ping someth
Ivo Vachkov wrote:
Does FreeBSD rtalloc*() (or any other) functions implement route
caching and how ? I looked at the code but it's not exactly easiest
thing to read / understand :)
Not really, at least, not in the way one would think. rtalloc() is a
legacy function.
ip_output() will still cal
I second Max. If you are going to introduce a bunch of AF_* constants
into the tree you have to be very careful as AF_MAX is used to size
arrays and figure out how many radix trie heads to allocate.
It could be argued this wastes a bunch of CPU time and memory, though I
speculate 'not much' at
Ivo Vachkov wrote:
Actually there is:
struct route_in6 ip6_forward_rt;
that "caches" the last route used (thanks blue !!!) but i think this
technique is pointless in a multiflow traffic.
Yes, this is why OpenBSD got rid of this form of 'route caching'.
Is it reasonable to believe that r
Claudio Jeker wrote:
Just because you believe that route caches are great doesn't mean it is
true. Show some real code and include benchmarks with various workloads
(e.g. a core router that is hit by many many many sessions).
It is a reasonable approach, for a uniprocessor design, to focus o
Randy Bush wrote:
just did a cvsup build and portupgrade of a six month old -current
i386 system running quagga. quagga cranked to 0.99.8. i got
slammed by bgp tcpmd5 requirement.
bgpd[469]: can't set sockopt TCP_MD5SIG 0 to socket 17
bgpd[469]: can't set sockopt TCP_MD5SIG 0 to socket 18
bgpd
Looks like a netcat bug, if it doesn't tune buffers to the interface MTU.
I'm not sure if nc has a 'de facto' maintainer however I believe it is
something which was recently imported into the freebsd base system.
Still, it is better to try to field patches with the upstream maintainer
before
Christian S.J. Peron wrote:
I am not sure who has their hands in the routing code these days so
I figured I would just forward this message off here. Does the
following look reasonable?
I'm looking, but mostly with long range goggles on.
Yes, this looks like the right change. rtalloc1() alw
Weiguang Shi wrote:
nc might be waiting on all the interfaces; enumerating MTUs and choosing the
largest
sounds complicated, especially when some interfaces can be configured to receive
jumbo frames. Why not just use something like 64KB as the other user
suggested or something even larger?
BTW: Casual inspection with kscope suggests there is a similar
free-while-locked issue in nd6_ns_input() (netient6/nd6_nbr.c) and
in_arpinput() (netinet/if_ether.c).
nd6_ns_input() references rt-»rt_gateway after rtfree(), a potential
race not to mention a use-after-free.
I haven't checked C
Ivan Alexandrovich wrote:
Hi
I'm wondering is anybody using double vlans ("q-in-q",
"vlan stacking", any name you like) on production hosts?
Does it play well with common ethernet device drivers in freebsd
(concerning the frame size) - fxp, em, for example?
Looks like that almost nobody mentio
1 - 100 of 613 matches
Mail list logo
