Date: Mon, 25 Nov 1996 09:54:25 -0500 From: Lotus_Mail_Exchange@CSERVE4.CCMAIL.compuserve.com To: "INTERNET:hackers@freefall.freebsd.org" <hackers@freefall.freebsd.org> Subject: NON-DELIVERY of: hackers-digest V1 #1659 Message-ID: <199611250959_MC1-C33-8F40@compuserve.com>
next in thread | raw e-mail | index | archive | help
Sender: owner-hackers-digest@freefall.freebsd.org
Received: from mail.webspan.net (mail.webspan.net [206.154.70.7]) by dub-img-4.compuserve.com (8.6.10/5.950515)
id JAA13249; Wed, 20 Nov 1996 09:29:39 -0500
From: <owner-hackers-digest@freefall.freebsd.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.18])
by mail.webspan.net (8.7.5/8.7.3) with ESMTP id JAA27555;
Wed, 20 Nov 1996 09:25:08 -0500 (EST)
Received: (from root@localhost)
by freefall.freebsd.org (8.7.5/8.7.3) id GAA05019
for freebsd-hackers-digest-outgoing; Wed, 20 Nov 1996 06:00:08 -0800 (PST)
Date: Wed, 20 Nov 1996 06:00:08 -0800 (PST)
Message-Id: <199611201400.GAA05019@freefall.freebsd.org>
To: freebsd-hackers-digest@FreeBSD.ORG
Subject: hackers-digest V1 #1659
Reply-To: hackers@freefall.freebsd.org
Errors-To: owner-hackers-digest@freefall.freebsd.org
Precedence: bulk
hackers-digest Wednesday, 20 November 1996 Volume 01 : Number 1659
In this issue:
Re: Ipx to ip routing
Re: split speed sio port?
Re: Who needs Perl? We do!
Re: Who needs Perl? We do!
Re: Who needs Perl? We do!
Re: Kernel calls - args in registers
Re: Who needs Perl? We do!
Re: Who needs Perl? We do!
Re: Kernel calls - args in registers
Re: arpresolve errors
Re: Voice Recognition (URGENT)
Re: Kernel calls - args in registers
Re: arpresolve errors
RELENG_2_2 and CVS
Recuperating a DOS partition
DLT4000 bootup problems
gated's weirdness (Was: arpresolve errors)
----------------------------------------------------------------------
From: Joe Greco <jgreco@brasil.moneng.mei.com>
Date: Tue, 19 Nov 1996 17:00:51 -0600 (CST)
Subject: Re: Ipx to ip routing
> And we want to eliminate the need for so many ip addresses so that we
> can get rid of all the ip address conflicts that we can't seem to trace
> down.
>
> Any one have a good method of finding an ip address conflict?
Don't know about the rest, but typically I would suggest that the above
suggests a certain lack of networking discipline. :-(
Usually IP address conflicts arise when someone has created a network that
is too large. I usually become uncomfortable somewhere around 8 or 16
nodes, but then I am a bit paranoid. :-)
Ideally, in a school environment, each networked classroom or lab should
be on its own subnet, or perhaps several subnets. When the machines are
configured, use a labeler to note the machine's IP address on the front
of the machine. Preferably devise some logical mechanism for numbering,
such as sequential numbering, so that when students pull off the labels,
it is still pretty easy to figure it out.
If you do that and keep no more than, maybe, 16 machines on a network,
then you only have 16 machines to check when a problem arises. If they
are all in the same room, this is pretty easy.
As far as your address space concerns, in your scenario I would probably
consider using 10-net addresses, a proxy Web server, and a NAT device to
provide continued access to Internet services.
The 10-net thing works really nice even for a large school, because you
can use the second octet to designate building, third octet to designate
room, and fourth octet to designate machine number.
... JG
------------------------------
From: Adam David <adam@veda.is>
Date: Wed, 20 Nov 1996 04:27:04 +0000 (GMT)
Subject: Re: split speed sio port?
> > This is all very well, but when upstream is not (yet?) willing to implement
> > such measures themselves and will not trust software that is located outside
> > of their direct control, one has to make do with what is available.
>
> Huh? How does this affect anything? Or are you saying that "upstream"
> insists that you use an asymmetrical link?
It is at present the only way we can transmit more than we receive, without
paying through the nose for the ability to receive more. This is because we
are required to pay per-kb rate for 25% of available incoming bandwidth even
if we only actually use 10%. (I don't think anyone else is happy with this
billing arrangement either, except for the biller).
> > Of course, a proven product might catch their interest in terms of
> > suitability.
>
> Hey, go for it 8)
What was the name of that product again, and does it have a URL? :)
Adam
------------------------------
From: davidn@sdev.usn.blaze.net.au (David Nugent)
Date: Wed, 20 Nov 1996 16:25:50 +1100
Subject: Re: Who needs Perl? We do!
Nik Clayton writes:
> Terry Lambert writes:
> > This is the rub. PERL is not stable over the release cycle period for
> > FreeBSD. People are *always* complaining "why don't you upgrade your
> > PERL?", even when it it well known that an upgrade frequently requires
> > updating all of the PERL-dependent scripts to the new syntax, since
> > the syntax is not sufficiently stable.
>
> As someone who spends a reasonable amount of the working day coding in
> Perl, I don't think this is a particularly valid point, particularly in
> comparison to the moving target that is Tcl/Tk. In the past four years
> Perl 4.036 (/usr/bin/perl on 2.1.5 and below) has been the standard,
> rock-solid version on the 4.branch, while 5.0 was the new, OO biased
> version.
Yes. I have to think carefully when trying to come up with something
works under perl4 as well. :) The comment about perl4 being dead *is*
very true it is no longer supported.
Let's see.. excluding things provided for perl development, in the
- -current distribution we have the following scripts:
/usr/bin/catman
/usr/bin/keyinfo
/usr/bin/killall
/usr/bin/makewhatis
/usr/bin/sgmlfmt
/usr/bin/whereis
/usr/bin/which
/usr/sbin/adduser (and presumably add/rmgroup & removeuser?)
/usr/sbin/kbdmap
/usr/sbin/spkrtest
/usr/sbin/vidfont
It is interesting to note that all of these scripts run unchanged
under perl5. So the first paragraph quoted above is bogus in any
case.
> There is an issue moving from 4.036 to 5.x, as the syntax did change
> in a few places between the two -- not counting the option of a new
> OOish syntax, which wouldn't break older scripts anyway. Most obviously
> where '@' in strings suddenly needed to backslash-escaped. This broke
> a lot of things that dealt with e-mail addresses.
Yes. That is perhaps the most pertinent change, and the one that
is most likely to affect anyone who is dependant on perl4. There
are others, but most dependancies are fairly obscure.
> Not much in the way of hard facts there, but this seems to be an opinion
> only thread anyway.
I can only confirm the same experience.
All I will add is that a decision not to upgrade perl (not necessarily
follow the bleeding edge at all!) is just putting off the inevitable
with the probability of creating likely dependancies on perl4 that
apparently don't currently exist.
> Having said that, I don't think Perl should be moved to the base system
> anyway (assuming that base system is whatever you get when you install
> bin.xx for the first time). But this is for the same reason I don't
> particularly want tcl in there either -- they're extensions to the
> system -- I have no objections to seeing a new dist category, something
> like 'cool-things-we-think-you'll-enjoy', but I tend to prefer to
> build these things myself.
I could not agree more.
Personally, i think perl5 is *too big* to include in the base system
anyway, and comes with a large amount of cruft that noone will use
unless they develop applications in perl or run a lot of third-party
perl scripts (mainly web sites). For the few perl scripts in the
system, only the sgml formatter will be the loss (unless something
in the install depends upon it? Can't say I've looked). Almost
everything else can be easily replaced, either with a shell script
or a small C program (which I'll happily volunteer to take care of,
if the removal of perl4 from the base dist is the preferred way to
go).
It appears to me at least that the reluctance to "upgrade" to perl
is due to its size. I agree with that. It's just that as a
developer who uses perl, having perl4 on the system is a pain in
the rear. Yes, sure, I know I won't affect finished scripts that
use #!, but (a) it is a waste of space just for a few scripts,
(b) for a variety of reasons, I'd prefer to have /usr/bin in my
path before /usr/local/bin and while developing scripts, I often
need to call perl from the command line (with -d, for example),
and (c) nothing perl 4 does can't be done by perl 5.
David Nugent, Unique Computing Pty Ltd - Melbourne, Australia
Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet
davidn@blaze.net.au http://www.blaze.net.au/~davidn
------------------------------
From: davidn@sdev.usn.blaze.net.au (David Nugent)
Date: Wed, 20 Nov 1996 16:28:42 +1100
Subject: Re: Who needs Perl? We do!
Terry Lambert writes:
> The problem, again, is that the change cycle on PERL has historically
> been too short to base a FreeBSD release on a PERL release... PERL
> is moving faster than FreeBSD, in other words.
Which then begs the question - why use perl at all?
Yes, I use it quite a bit, but in a base distribution I don't really
see it as an appropriate tool. It is certainly easier that programming
in, say, bourne shell, and probably significantly faster too. But I
still think it is a mistake it being part of the base system.
David Nugent, Unique Computing Pty Ltd - Melbourne, Australia
Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet
davidn@blaze.net.au http://www.blaze.net.au/~davidn
------------------------------
From: roberto@keltia.freenix.fr (Ollivier Robert)
Date: Wed, 20 Nov 1996 00:21:39 +0100
Subject: Re: Who needs Perl? We do!
According to Terry Lambert:
> I realize this. However, it requires going over your existing PERL
> code to make sure it doesn't break from the syntactical changes.
99% of the time, all you need is "perl -cw your.script".
> What was the delay between when people started saying we should upgrade
> to PERL 5.x and the release of MajorDomo 1.93?
I think 1.93 was released before that moment. The first really usable
version was 5.001m (5.000 should have never seen the light and 5.001 was
still very buggy).
> The problem, again, is that the change cycle on PERL has historically
> been too short to base a FreeBSD release on a PERL release... PERL
> is moving faster than FreeBSD, in other words.
Yes, that's why I think it is better to wait for 5.004 and use this one.
- --
Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr
FreeBSD keltia.freenix.fr 3.0-CURRENT #28: Sun Nov 10 13:37:41 MET 1996
------------------------------
From: "John S. Dyson" <toor@dyson.iquest.net>
Date: Wed, 20 Nov 1996 00:32:38 -0500 (EST)
Subject: Re: Kernel calls - args in registers
> Travis Hassloch x231 stands accused of saying:
> >
> > One thing I thought might make a worthwhile gain is to make all
> > intrakernel calls use registers -- and if possible, all kernel calls.
>
> I think Bruce will have opinions here, but IMHO using registers for
> arg passing isn't much of a win, especially on the x86 where there
> are so few of them.
>
I have an opinion also... I have already recompiled much of the FreeBSD kernel
to use the register passing convention. Not really worth it. F.E.
our approx 500-530usec fork perf (on a P5-166) doesn't budge almost
at all with a change in calling convention... The pgcc compiler or
- -fomit-frame-pointer makes much more difference (if it works to compile
your kernel :-) -- sometimes "advanced options" don't work to compile
ours...) (BTW, even that difference is in the 5% or so range.)
I think that algorithmic improvements in the kernel are where "it is."
It is likely that if we use the register passing conventions in the
kernel -- it'll be because there is a worthwhile improvement. I haven't
seen a significant one -- YET. If you see one -- let me know!!!
John
------------------------------
From: Gary Clark II <gclarkii@main.gbdata.com>
Date: Tue, 19 Nov 1996 23:44:45 -0600 (CST)
Subject: Re: Who needs Perl? We do!
Terry Lambert wrote:
> > > FreeBSD. People are *always* complaining "why don't you upgrade your
> > > PERL?", even when it it well known that an upgrade frequently requires
> > > updating all of the PERL-dependent scripts to the new syntax, since
> > > the syntax is not sufficiently stable.
> >
> > Between Perl4 and Perl5, the changes are documented in perltrap. Between
> > 5.x there have been very few syntaxic changes. You won't notice many
> > changes between 5.003 and 5.004 in that respect.
The only major change that hit people was that the @ was no longer
escaped by default.
>
> I realize this. However, it requires going over your existing PERL
> code to make sure it doesn't break from the syntactical changes.
Takes very little time. Just like taking a C program to C++.
>
> The problem is the dependencies for the existing code, and that fact
> that if the maintainers of the code haven't "upgraded", then we become
> promary support for the "upgraded" scripts.
Most programs run fine with NO changes.
>
> This would have been less of a problem in the 5.x changeover if the
> PERL distribution had a tool to upgrade scripts over the syntactic
> changes.
Why don't C++ compliers supply the same thing? I've seen programmers
get bit by the same thing.
>
>
> > > For FreeBSD, the biggest problem is PERL dependent ports and MajorDomo;
> > > PERL upgrades have been delayed for MajorDomo more than once in the
> > > past.
> >
> > Majordomo has been Perl5 compatible as of 1.93. 1.94 runs fine under it.
>
> What was the delay between when people started saying we should upgrade
> to PERL 5.x and the release of MajorDomo 1.93?
>
> The problem, again, is that the change cycle on PERL has historically
> been too short to base a FreeBSD release on a PERL release... PERL
> is moving faster than FreeBSD, in other words.
HuH???!!!???
> Terry Lambert
> terry@lambert.org
Gary
- --
Gary Clark II (N5VMF) | I speak only for myself and "maybe" my company
gclarkii@GBData.COM | Member of the FreeBSD Doc Team
Providing Internet and ISP startups mail info@GBData.COM for information
FreeBSD FAQ at ftp://ftp.FreeBSD.ORG/pub/FreeBSD/docs/freebsd-faq.ascii
------------------------------
From: Gary Clark II <gclarkii@main.gbdata.com>
Date: Tue, 19 Nov 1996 23:58:44 -0600 (CST)
Subject: Re: Who needs Perl? We do!
Michael Smith wrote:
> Ollivier Robert stands accused of saying:
> >
> > Perl 5.004 is rounding the corner. 5.003_08 just came out and 5.003_09 will
> > be 5.004-candidate.
> >
> > Many thinks are broken (even if people don't tumble often on them) and
> > 5.004 should be stable.
>
> Ok. I am still waiting for a hand up from someone who has a
> contrib-ready perl5.
If someone can point me towards the how-to contrib docs I'll do this.
Considering I did the perl4 b-make and the commit, I have no problems
doing this.
> ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[
Garyy
- --
Gary Clark II (N5VMF) | I speak only for myself and "maybe" my company
gclarkii@GBData.COM | Member of the FreeBSD Doc Team
Providing Internet and ISP startups mail info@GBData.COM for information
FreeBSD FAQ at ftp://ftp.FreeBSD.ORG/pub/FreeBSD/docs/freebsd-faq.ascii
------------------------------
From: Bruce Evans <bde@zeta.org.au>
Date: Wed, 20 Nov 1996 17:51:32 +1100
Subject: Re: Kernel calls - args in registers
>I've been looking at this a bit lately, and noticed that, as you
>point out, gcc doesn't use registers on the x86 by default (IMHO it should
>have, at least if you can configure that for free Unixes -- it's not like we
>had a historical baggage commercial compiler to be call-level compatible
>with).
Well, gcc didn't officially support passing args in registers until
2.7, and it still doesn't quite work - function calls through a
pointer sometimes clobber one of the args. Example: FreeBSD qsort().
My version of FreeBSD works when compiled with -mrtd (callee pops),
but I gave up on getting -mregparm=N to work when I hit this problem.
- -mrtd doesn't make much difference. It gives slightly smaller code and
is a few percent faster on 486's (because `ret N' is just as fast as
`ret') and a few percent slower on Pentiums (because `ret N' is one
nonpairable cylce slower than `ret').
- -mregparm=2 gives slightly larger code. I think it won't make much
difference to the speed when it works.
Bruce
------------------------------
From: Bill Fenner <fenner@parc.xerox.com>
Date: Tue, 19 Nov 1996 21:52:13 PST
Subject: Re: arpresolve errors
In message <Pine.BSF.3.91.961120143155.8206K-100000@panda.hilink.com.au> you wr
ite:
>Are messages like the one below indicative of mbuf problems, or something
>else?
Generally they're indicative of routing problems.
>"arpresolve: can't allocate llinfo for 203.x.y.49"
What's the routing table look like for 203.x.y.49?
>A check through the messages file
>shows that it only happens to CSLIP links which are gateways to remote
>nets/subnets.
Are you using gated? gated likes to add bogus host routes which confuse
the routing table. There's code in 2.2 that handles this.
Bill
------------------------------
From: Amancio Hasty <hasty@rah.star-gate.com>
Date: Wed, 20 Nov 1996 00:28:56 -0800
Subject: Re: Voice Recognition (URGENT)
Yeap, what about it . I remember about a year ago approaching the project
to import technology to FreeBSD and the folks over there where not
interested so what is the status nowdays?
Amancio
>From The Desk Of Andrew Y Ng :
> Hmmm.. Chk out the CMU Speech Lab:
> http://www.speech.cs.cmu.edu/speech/
>
> /ayn
>
> --
> Andrew Y Ng <ayn@CMU.EDU> http://andrew.Ngbert.org
> Carnegie Mellon University; ECE major, Music minor
> campus ph: 412/862-2836; voice mail: 412/268-6700 x30027
> talk: finger ayn@andrew.Ngbert.org for online status.
> finger ayn@CMU.EDU for more info,
> such as my public key, geekcode, snail address, etc.
>
> NGBERT! http://www.Ngbert.org
>
------------------------------
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: Wed, 20 Nov 1996 00:32:23 -0800
Subject: Re: Kernel calls - args in registers
>It is likely that if we use the register passing conventions in the
>kernel -- it'll be because there is a worthwhile improvement. I haven't
>seen a significant one -- YET. If you see one -- let me know!!!
The x86 just doesn't have enough registers for this to be worth
much. But for NetBSD, looking in a non-x86-specific direction:
I experimented with this on 68030s running More/BSD (Mt.Xinu's
version of the Utah port of 4.3bsd-Tahoe, or thereabouts) to hp300s.
I measured worthwhile savings from both passing arguments
in registers and using callee-pops for non-variadic functions.
That was with gcc 1.33; I don't know how much saving to expect from
gcc2, if and when the -mregparm works again. I'd definitely encourage
the NetBSD people with access to m68k machines to try it, though.
Are there better alternatives, these days, than rewriting
all the locore routines to use different calling convention?
Like maybe adding attributes to a declaration to disable -mrtd?
And of course, passing _syscall_ args in registers rather
than on the normal stack saves copyin/copyout, and reduces
syscall latency, which is a Good Thing for us time vultures.
------------------------------
From: "Daniel O'Callaghan" <danny@panda.hilink.com.au>
Date: Wed, 20 Nov 1996 19:40:15 +1100 (EST)
Subject: Re: arpresolve errors
On Tue, 19 Nov 1996, Bill Fenner wrote:
I wrote:
> >Are messages like the one below indicative of mbuf problems, or something
> >else?
>
> Generally they're indicative of routing problems.
> >"arpresolve: can't allocate llinfo for 203.x.y.49"
>
> What's the routing table look like for 203.x.y.49?
203.x.y.48/28 203.x.y.49 UGc
203.x.y.49 203.x.y.34 UH
203.s.t 203.x.y.49 UGc
> >A check through the messages file
> >shows that it only happens to CSLIP links which are gateways to remote
> >nets/subnets.
>
> Are you using gated? gated likes to add bogus host routes which confuse
> the routing table. There's code in 2.2 that handles this.
Yes, I am using gated. Yes, there are host routes, but they seem to make
sense (e.g. the one listed above) for the point to point links. And the
PPP-connected networks on this and another 2.1.5R terminal server have
*not* exhibited this [arpresolve] behaviour, although the routing entries
are equivalent.
Thanks,
Danny
------------------------------
From: Michael Hancock <michaelh@cet.co.jp>
Date: Wed, 20 Nov 1996 17:40:58 +0900 (JST)
Subject: RELENG_2_2 and CVS
I discovered that my CVS tree was corrupt after trying the following:
cd /jaz
cvs co -r RELENG_2_2 src # -r implies -P
The checkout failed and later that night my cvsup cron job failed with the
error "Possible reference of NIL".
So I rm -rf /jaz/cvs; cvsup'ed the tree again; rm -rf /jaz/src; checked
out 2.2 release; built a new kernel and things look fine now for testing
2.2.
/jaz/src was current. Which brings me to a question, should I have done a
cvs release src? The man pages say that doing a checkout-only is ok, but
seems to recommend doing a release beforehand. What do most people do in
practice, especially with something as large as the entire FreeBSD src
tree?
Regards,
Mike Hancock
------------------------------
From: Jean-Pierre Morant <jpm@marben.be>
Date: Wed, 20 Nov 1996 13:35:53 +0100
Subject: Recuperating a DOS partition
Hello !
being a bit short on swap space I would like to reuse a DOS
partition on my wd1 (second ESDI) disk.
I've used fdisk to assign that partition to FreeBSD,
then edited the fstab so that /dev/wd1s1f (the next available partition
name) is seen as a swap partition.
Apaprently there is a step inbetween that I'm missing : how to tell
FreeBSD that the second (nr 1) partition on disk wd1 should be used as
/dev/wd1s1f ?
Do anybody know what I'm forgetting ?
Thanks
ADDITIONNAL INFO
=====
Now, if I type swapon -a
I get : swapon: /dev/wd1s1f: Device not configured
fdisk /dev/wd1
tells me that :
******* Working on device /dev/wd1 *******
parameters extracted from in-core disklabel are:
cylinders=244160 heads=1 sectors/track=1 (1 blks/cyl)
Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=244160 heads=1 sectors/track=1 (1 blks/cyl)
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 0 is:
sysid 165,(FreeBSD/NetBSD/386BSD)
start 0, size 244160 (119 Meg), flag 80
beg: cyl 0/ sector 1/ head 0;
end: cyl 1023/ sector 1/ head 0
The data for partition 1 is:
sysid 165,(FreeBSD/NetBSD/386BSD)
start 0, size 244160 (119 Meg), flag 0
beg: cyl 0/ sector 0/ head 0;
end: cyl 447/ sector 1/ head 0
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
where partition 0 is another file system mounted and used as :
/dev/wd1s1e on /tmp (local)
- --
Jean-Pierre Morant
c/o MARBEN S.A./N.V. La vie serait tellement
Boulevard du Souverain,400, Vorstlaan plus facile
1160 Bruxelles Si seulement
Belgium nous avions les sources....
+ 32 2 663 1130 (phone)
+ 32 2 663 1199 (fax)
http://www.marben.be
jpm@marben.be
------------------------------
From: mark@plato.salford.ac.uk (Mark Powell)
Date: 20 Nov 1996 12:48:22 -0000
Subject: DLT4000 bootup problems
I was testing a DLT4000 tape on my system. However, 2.2-960801 hung when
the kernel was probing the scsi devices. Any ideas why? Yes, it was properly
terminated and I'd slotted it in using the same cable, terminator and scsi ID
of the DAT drive that is usually on that machine.
- --
Mark Powell - Unix Information Officer - Clifford Whitworth Building
A.I.S., University of Salford, Salford, Manchester, UK.
Tel: +44 161 745 5936 Fax: +44 161 736 3596
Email: mark@ucsalf.ac.uk finger mark@ucsalf.ac.uk (for PGP key)
<A HREF="http://www.ucsalf.ac.uk/~mark/">Home Page</A>
------------------------------
From: J Wunsch <j@uriah.heep.sax.de>
Date: Wed, 20 Nov 1996 12:08:00 +0100 (MET)
Subject: gated's weirdness (Was: arpresolve errors)
As Bill Fenner wrote:
> Are you using gated? gated likes to add bogus host routes which confuse
> the routing table. There's code in 2.2 that handles this.
Btw., people might remember that i've once asked about some complaints
GateD spits onto the console of our modem server whenever somebody
logs in via PPP. Now that i've finally got 'round yesterday to DTRT
and subnet our IP address space, my PPP peers are no longer inside the
ether address range, and i could throw the d*mn proxyARP hackery
overboards... Needless to say, GateD no longer complains! It works
fine as expected, as soon as a PPP interface comes up, GateD notices
it and offers routing for this peer.
- --
cheers, J"org
joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
------------------------------
End of hackers-digest V1 #1659
******************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611250959_MC1-C33-8F40>