Re: CCD and the new ATA/ATAPI subsystem?

[NAKAGAWA Yoshihisa]

> Without getting into the ccd/vinum comparisons, is there a reason you
> want to use ad? and not wd? ? AFAIK, wd? works fine with Soren's new
> driver (well, it's working for me, at any rate).

Soren's driver is alpha level, and danger with some chipset. For
example, it cause file system crash with Opti Viper-M chipset.

--
NAKAGAWA, Yoshihisa
y-nak...@nwsl.mesh.ad.jp
nakag...@jp.freebsd.org


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: kvm_getswapinfo is broken

[Matthew D. Fuller]

On Tue, May 25, 1999 at 11:38:38PM -0600, a little birdie told me
that Kenneth D. Merry remarked
> 
> {panzer:/usr/home/ken:2:0} pstat -s
> Device  1K-blocks UsedAvail Capacity  Type
> /dev/(null)3275520   327552 0%Interleaved
> /dev/(null)3930880   393088 0%Interleaved
> Total  7206400   720640 0%
> 
> That's with -current as of Friday.


In a -CURRENT as of early last week, I see the same:
[2:28:11] mortis:~
(ttyp6):{106}% pstat -s
Device  1024-blocks UsedAvail Capacity  Type
/dev/(null)  655232  144   655088 0%Interleaved
/dev/(null)  524160  196   523964 0%Interleaved
/dev/(null)  130944   80   130864 0%Interleaved
/dev/(null)  262016   56   261960 0%Interleaved
/dev/(null)  524160   12   524148 0%Interleaved
Total   2096512  488  2096024 0%

It happened also through the buildworld before that one, which was a few
days before, but not the one before that, which was about a week back (or
something like that).  A quick perusal of the code tells me absolutely
nothing; at a guess, the kvm_read() is turning up nothing there, so I'll
make a wild guess that something moved and forget to tell the post office
to forward its references.



-- 

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| Matthew FullerMF4839http://www.over-yonder.net/ |
* fulle...@futuresouth.com   fulle...@over-yonder.net *
| UNIX Systems Administrator  Specializing in FreeBSD |
*   FutureSouth Communications   ISPHelp ISP Consulting   *
|  "The only reason I'm burning my candle at both ends,   |
*is because I haven't figured out how to light the*
| middle yet" |
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: Hacking objcopy

[Doug Rabson]

On Wed, 26 May 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote:

> 
> Would anyone have any objections to me hacking objcopy so that it could do 
> the 
> following -
> 
> a) Change symbol names from one thing to another
> 
> b) Add/remove dependencies on other shared objects.
> 
> If I submit these changes, what chance do I have of getting them made 
> "official"?

If the changes are modular enough so that it won't make life difficult
merging new versions of binutils, then I don't mind committing such a
thing. If you can get the binutils maintainers to take the change, that
would be the best possible situation.

--
Doug Rabson Mail:  d...@nlsystems.com
Nonlinear Systems Ltd.  Phone: +44 181 442 9037





To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: More compiler option comparisons

[Maxim Sobolev]

Garrett Wollman wrote:

> Just for completeness, I did one final run of HINT with just `-O'
> specified (our usual default).? `-O' results in significantly better
> integer performance than `-O4'.? (Floating-point performance is just
> the opposite.)
>
> This suggests that compiling the world with `-O' levels higher than
> one is probably a bad idea.? (The generated assembly is identical from
> `-O2' to `-O4'.)? The `-O2' code appears to be less efficient at
> register allocation; about twice as much stack temporary space is
> required.
>
> For the graph, see .

As my own test shown hint reporded benchmarks depend highly on options
used to
compile libm, so to get more accurate results your must consider to make
libm with
the same options used to compile hint (probably better to make several
static
versions of hint executable linked with the corresponding libm).
Also please report your processor model when reporting benchmarks
result, because non-Intel processors (AMD for the example) can pepform
better with 486 optimisation that with pentium optimisation)

Sincerely,

Maxim


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: More compiler option comparisons

[Maxim Sobolev]

Garrett Wollman wrote:

> Just for completeness, I did one final run of HINT with just `-O'
> specified (our usual default).? `-O' results in significantly better
> integer performance than `-O4'.? (Floating-point performance is just
> the opposite.)
>
> This suggests that compiling the world with `-O' levels higher than
> one is probably a bad idea.? (The generated assembly is identical from
> `-O2' to `-O4'.)? The `-O2' code appears to be less efficient at
> register allocation; about twice as much stack temporary space is
> required.
>
> For the graph, see .

As my own test shown hint reporded benchmarks depend highly on options used to
compile libm, so to get more accurate results your must consider to make libm 
with
the same options used to compile hint (probably better to make several static
versions of hint executable linked with the corresponding libm).

Sincerely,

Maxim




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

FTP passive mode - a new default?

[Jordan K. Hubbard]

Unless I hear unanimous fierce outcry against it, I'm strongly
considering making FTP_PASSIVE_MODE obsolete by virtue of being the
default for all tools/libraries which currently examine it.
FTP_ACTIVE_MODE will be the new flag for toggling the previous
behavior.

Given the state of the Internet today, I think this is purely a
sensible change in defaults.  Comments?

- Jordan


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: FTP passive mode - a new default?

[Dom Mitchell]

On 26 May 1999, "Jordan K. Hubbard" proclaimed:
> Unless I hear unanimous fierce outcry against it, I'm strongly
> considering making FTP_PASSIVE_MODE obsolete by virtue of being the
> default for all tools/libraries which currently examine it.
> FTP_ACTIVE_MODE will be the new flag for toggling the previous
> behavior.
> 
> Given the state of the Internet today, I think this is purely a
> sensible change in defaults.  Comments?

Please do.  However, a suitable notice must be plastered somewhere
suitable (RELNOTES?).  It might also be worth noting in ipfw(8).
-- 
Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator

"Value of 2 may go down as well as up"
-- FORTRAN programmers manual 
-- 
**
This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they   
are addressed. If you have received this email in error please notify 
the system manager.

This footnote also confirms that this email message has been swept by 
MIMEsweeper for the presence of computer viruses.
**


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: FTP passive mode - a new default?

[Nick Hibma]

Is there a list of pro-/cons- available?

- it is slower, but by how much and on which types of lines (low/high
latency, low/high bandwidth)?

- any (windows) tools not supporting it?

Nick

 > Unless I hear unanimous fierce outcry against it, I'm strongly
 > considering making FTP_PASSIVE_MODE obsolete by virtue of being the
 > default for all tools/libraries which currently examine it.
 > FTP_ACTIVE_MODE will be the new flag for toggling the previous
 > behavior.
 > 
 > Given the state of the Internet today, I think this is purely a
 > sensible change in defaults.  Comments?
 > 
 > - Jordan
 > 
 > 
 > To Unsubscribe: send mail to majord...@freebsd.org
 > with "unsubscribe freebsd-current" in the body of the message
 > 
 > 

-- 
ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: FTP passive mode - a new default?

[Daniel J. O'Connor]

On 26-May-99 Nick Hibma wrote:
>  Is there a list of pro-/cons- available?
>  
>  - it is slower, but by how much and on which types of lines (low/high
>  latency, low/high bandwidth)?
>  
>  - any (windows) tools not supporting it?

Well funnily enough some servers won't allow passive mode, and I have seen a
broken server/firewall combo which meant that passive ftp wouldn't work because
the firewall denied the clients connection for passive mode (very duh).

FTP passive mode works by getting the server to bind to a port and telling the
client to connect to that to get/send the data, whereas normal ftp mode the
client binds the port and the server connects to it.


FreeBSD's ftpd allows you to specify a port range for passive ftp so you don't
have to have your system wide open.

---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

RE: FTP passive mode - a new default?

[Ladavac Marino]

> -Original Message-
> From: Nick Hibma [SMTP:nick.hi...@jrc.it]
> Sent: Wednesday, May 26, 1999 1:38 PM
> To:   Jordan K. Hubbard
> Cc:   curr...@freebsd.org
> Subject:  Re: FTP passive mode - a new default?
> 
> 
> Is there a list of pro-/cons- available?
> 
> - it is slower, but by how much and on which types of lines (low/high
> latency, low/high bandwidth)?
[ML]  same speed.  passive means that the client (and not the
server) opens the data connection.  advantageous for people sitting
behind packet or nat firewalls.

> - any (windows) tools not supporting it?
[ML]  this is an ftp client request.  some ancient ftp servers
may not support passive data connections, but I haven't seen one of
those in a long while.  I don't know whether the windows ftpd is
incapable of passive mode.  actually, if the passive mode default is
implemented correctly, the client should send PASV and if the server
accepts it proceed, otherwise remain in active mode (and if you are
behind a nat or a firewall you are no worse off than you already were).

/Marino

> Nick
> 
>  > Unless I hear unanimous fierce outcry against it, I'm strongly
>  > considering making FTP_PASSIVE_MODE obsolete by virtue of being the
>  > default for all tools/libraries which currently examine it.
>  > FTP_ACTIVE_MODE will be the new flag for toggling the previous
>  > behavior.
>  > 
>  > Given the state of the Internet today, I think this is purely a
>  > sensible change in defaults.  Comments?
>  > 
>  > - Jordan
>  > 
>  > 
>  > To Unsubscribe: send mail to majord...@freebsd.org
>  > with "unsubscribe freebsd-current" in the body of the message
>  > 
>  > 
> 
> -- 
> ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

process did not exit properly after kill signal

[Eric Haug]

Hi,
I have a pr440fx dual PPro system with 132Mb.
I replaced memory and was testing memory with a short program
(included below) and decided to try to kill it
keyboard signals did change what the system was doing
in that the swapping that was occurring stopped.
kill -9 PID did not have the usual effect.
But the process has not exited, the shell prompt has not returned.
The system now is strangely sluggish.
ps indicates that the pagedaemon is accumulating a lot of run time.
the program is in DE+ state. top says it's STATE is objtrm.
this is with FreeBSD 4.0-CURRENT of about Wed May  5 06:20 CDT
I suppose this is some VM problem with cleaning up on program exit.
Fixed since May 5 ???
eric haug
Saint Louis Univ

#define L 32

long j[L][1024][1024];
main()
{
int l,m,n,o;
for(o=0; o<16;o++)
for(l=0; l

PPP problem + mailing list archive problem

[Richard J Kuhns]

Well, I'd hoped I'd be able to do a little more before bothering the list,
but...

I'd last built world around the end of April, with no problems.  I then
grew a fairly heavy workload, and so didn't get a chance to build world
again until 2 days ago (May 24).  During that time, something changed with
ppp so it no longer works correctly for me (details shortly).

**
I decided to check the -commit archives in case I missed an alert
somewhere, and the database seems to be corrupted.  Using netscape 4.5, I
checked cvs-committers only, asked for articles on ppp sorted by date, and
got a nice list.  However, when I click on, say,

4.Brian Some cvs commit: src/usr.sbin/ppp arp.c defs.c iface.c ipcp.c tun.c 
   Score: 711; Lines: 35; 26-Apr-1999; Archive: cvs-committers

I get an article commenting on a commit to src/secure/usr.bin/bdes bdes.c.
**

I normally start ppp with -auto XXX-pppd, with the following ppp.conf (I
have a static IP address).

#
# Default setup. Executed always when PPP is invoked.
#
default:
 set log Phase Chat Connect LCP IPCP CCP TUN command
 set device /dev/cuaa0
 set speed 57600
 set ctsrts on
 set stopped 5
 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATZ OK-AT-OK \\dATDT\\T 
TIMEOUT 40 CONNECT"
#
#
XXX-pppd:
 allow user me
 set openmode passive
 set phone 123456
 set login "TIMEOUT 5 login:-\\r-login: ppp word: xx
 set timeout 1200
 set socket /var/tmp/internet ""
 deny lqr
 disable lqr
 delete all
 set ifaddr *myaddr* *hisaddr*
 add default HISADDR
 enable dns

test-pppd:
 allow user me
 set openmode passive
 set phone 123456
 set login "TIMEOUT 5 login:-\\r-login: ppp word: xx

#

I dial and login ok, but then nothing happens.  the ppp.log says

(normal successful login...)
May 25 11:02:48 moran ppp[3577]: tun0: Phase: deflink: login -> lcp 
May 25 11:02:48 moran ppp[3577]: tun0: LCP: FSM: Using "deflink" as a transport 
May 25 11:02:48 moran ppp[3577]: tun0: LCP: deflink: State change Initial --> 
Closed 
May 25 11:02:48 moran ppp[3577]: tun0: LCP: deflink: State change Closed --> 
Stopped 
May 25 11:02:53 moran ppp[3577]: tun0: LCP: deflink: Stopped timer expired 
May 25 11:02:53 moran ppp[3577]: tun0: LCP: deflink: State change Stopped --> 
Closed 
May 25 11:02:53 moran ppp[3577]: tun0: LCP: deflink: State change Closed --> 
Initial 
May 25 11:03:01 moran ppp[3577]: tun0: Command: /dev/tty: down 
May 25 11:03:01 moran ppp[3577]: tun0: Phase: deflink: Disconnected! 

It sits at the "State change Closed --> Initial" until I tell it to
disconnect or the idle time goes off.  ps shows it waiting on "select".
All the `p's in the pppctl/ppp prompt are lower case.

Curiously enough, if I do everything manually, it works!  Ie, I start ppp,
set device, set speed, use "term" to talk directly to the modem, and
ATDT123456 to dial and then login, I get the prompt almost immediately with
all upper-case Ps, and I can then enter the commands to set address/routes
and it works just fine.

At this moment, I'm running a 3.1 binary from the CD; it works perfectly
also.  Did I miss something, or is this a genuine bug?  I'll be happy to
try other things/supply more info on request.

Thanks...

-- 
Richard Kuhns   r...@grauel.com
PO Box 6249 Tel: (765)477-6000 \
100 Sawmill Roadx319
Lafayette, IN  47903 (800)489-4891 /


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: FTP passive mode - a new default?

[Jonathan M. Bresler]

> 
> Unless I hear unanimous fierce outcry against it, I'm strongly
> considering making FTP_PASSIVE_MODE obsolete by virtue of being the
> default for all tools/libraries which currently examine it.
> FTP_ACTIVE_MODE will be the new flag for toggling the previous
> behavior.
> 
> Given the state of the Internet today, I think this is purely a
> sensible change in defaults.  Comments?
> 

so the difference between the current and proposed is:

FTP_PASSIVE_MODE=YESvs  FTP_ACTIVE_MODE=NO
FTP_PASSIVE_MODE=NO vs  FTP_ACTIVE_MODE=YES

do any apps check for FTP_ACTIVE_MODE?
are we going to apply patches to each app to check for this
and maintains those patches over the course of time?

seems to be a change without commensurate benefit.it will
confuse some, suprise others and doesnt seem to offer
substantial benefit.

recommend against the change.

jmb


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: FTP passive mode - a new default?

[Matthew N. Dodd]

On Wed, 26 May 1999, Jordan K. Hubbard wrote:
> Unless I hear unanimous fierce outcry against it, I'm strongly
> considering making FTP_PASSIVE_MODE obsolete by virtue of being the
> default for all tools/libraries which currently examine it.
> FTP_ACTIVE_MODE will be the new flag for toggling the previous
> behavior.
> 
> Given the state of the Internet today, I think this is purely a
> sensible change in defaults.  Comments?

Yay!

-- 
| Matthew N. Dodd  | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS |
| win...@jurai.net |  This Space For Rent | ix86,sparc,m68k,pmax,vax  |
| http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage?   |



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: PPP problem + mailing list archive problem

[Brian Somers]

> Well, I'd hoped I'd be able to do a little more before bothering the list,
> but...
> 
> I'd last built world around the end of April, with no problems.  I then
> grew a fairly heavy workload, and so didn't get a chance to build world
> again until 2 days ago (May 24).  During that time, something changed with
> ppp so it no longer works correctly for me (details shortly).
> 
[.]
> May 25 11:02:53 moran ppp[3577]: tun0: LCP: deflink: Stopped timer expired 
> May 25 11:02:53 moran ppp[3577]: tun0: LCP: deflink: State change Stopped --> 
> Closed 

This happens because the peer hasn't said anything in the five 
seconds you've been connected (``set openmode passive'' says to wait 
for the peer to start talking and ``set stopped 5'' says to bring the 
layer down if we find ourselves in the STOPPED state for 5 seconds).

Your login script looks suspect - it's always dangerous to have a 
login script that sends your password and waits for no confirmation 
of success (or failure).  Isn't there something you can ``expect'' ?

Try increasing your ``set stopped'' value to (say) 20 and see if that 
helps.

[.]
> Thanks...
> 
> -- 
> Richard Kuhns r...@grauel.com
> PO Box 6249   Tel: (765)477-6000 \
> 100 Sawmill Road  x319
> Lafayette, IN  47903   (800)489-4891 /

-- 
Brian 
     
Don't _EVER_ lose your sense of humour !  




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: FTP passive mode - a new default?

[Nate Williams]

> Unless I hear unanimous fierce outcry against it, I'm strongly
> considering making FTP_PASSIVE_MODE obsolete by virtue of being the
> default for all tools/libraries which currently examine it.
> FTP_ACTIVE_MODE will be the new flag for toggling the previous
> behavior.
> 
> Given the state of the Internet today, I think this is purely a
> sensible change in defaults.  Comments?

Gofer it!


Nate


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: FTP passive mode - a new default?

[Dan Langille]

On 26 May 99, at 3:50, Jordan K. Hubbard wrote:

> Unless I hear unanimous fierce outcry against it, I'm strongly
> considering making FTP_PASSIVE_MODE obsolete by virtue of being the
> default for all tools/libraries which currently examine it.
> FTP_ACTIVE_MODE will be the new flag for toggling the previous
> behavior.
> 
> Given the state of the Internet today, I think this is purely a
> sensible change in defaults.  Comments?

It would surely simplify some things.  If you are using a firewall, you'll 
need passive mode.  If you're not using a firewall, passive mode won't 
bother you one bit.

For the argument that some ftp servers don't accept passive mode, I say 
it's a question of numbers: which default setting will satisfy the 
greatest number of people?  which setting will reduce the number of 
questions "how do I do X"?
--
Dan Langille - DVL Software Limited
The FreeBSD Diary - http://www.FreeBSDDiary.org/freebsd/
NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/
The Racing System - http://www.racingsystem.com/racingsystem.htm


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

moused broken?

[David Scheidt]

My -CURRENT box is having problems with the mouse pointer freezing.  Killing
moused and restarting it seems to solve the problem, until it happens again,
of course.  It seems to happen after about 8 or nine hours of use.  This
hadn't been a problem with the previous -CURRENT, which was a month or so
old.  I am now running -CURRENT as of cvs-cur-5352, which is from sunday 23
May.  I haven't seen anything in the commit logs that would indicate
anything has changed that would break this.  If it happens again, I shall
see if I can get a better look at what happens.

David Scheidt



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: kvm_getswapinfo is broken

[Dmitrij Tejblum]

"Andrey A. Chernov" wrote:
> Just check 'swapinfo' in recent -current, it shows "/dev/(null)" as swap
> device, it means that devinfo() call in kvm_getswapinfo() returns NULL,
> i.e. called with wrong argument which is swinfo.sw_dev

This is a known problem. It is because dev_t in kernel and dev_t and 
userland are now different things. This is worse on the alpha, where 
they also have different sizes. So, on the alpha, the numbers are broken 
too, not just device names.

Supposedly, it will be fixed by a junior kernel hacker.

Dima




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: More compiler option comparisons

[Scott Michel]

I don't recall that the FreeBSD version of egcs is built with Haifa
turned on, which is supposed to improve optimizations as the level
is increased (more aggressive instruction scheduling.)

>   With egcs, the '-O' flag doesn't specify the optimization level like it
> does in GCC. It specifies the desired stability of the generated code. Lower
> numbers (0,1,2) request higher stability. ;)
> 
>   DS
> 
> > Dan Nelson wrote:
> > > -O4 doesn't exist in egcs (or it didn't a month or so ago).  According
> > > to the source, -O2 enables all optimizations except -funroll-all-loops,
> > > and all -O3 does is enable -funroll-all-loops.
> >
> > I think I recall reading somewhere that EGCS uses -O numbers > 3 to test
> > experimental optimizations.



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: PPP problem + mailing list archive problem

[Richard J Kuhns]

Brian Somers writes:
 > > Well, I'd hoped I'd be able to do a little more before bothering the list,
 > > but...
 > > 
 > > I'd last built world around the end of April, with no problems.  I then
 > > grew a fairly heavy workload, and so didn't get a chance to build world
 > > again until 2 days ago (May 24).  During that time, something changed with
 > > ppp so it no longer works correctly for me (details shortly).
 > > 
 > [.]
 > > May 25 11:02:53 moran ppp[3577]: tun0: LCP: deflink: Stopped timer expired 
 > > May 25 11:02:53 moran ppp[3577]: tun0: LCP: deflink: State change Stopped 
 > > --> Closed 
 > 
 > This happens because the peer hasn't said anything in the five 
 > seconds you've been connected (``set openmode passive'' says to wait 
 > for the peer to start talking and ``set stopped 5'' says to bring the 
 > layer down if we find ourselves in the STOPPED state for 5 seconds).
 > 
 > Your login script looks suspect - it's always dangerous to have a 
 > login script that sends your password and waits for no confirmation 
 > of success (or failure).  Isn't there something you can ``expect'' ?
 > 
 > Try increasing your ``set stopped'' value to (say) 20 and see if that 
 > helps.
 > 
 > [.]

I raised my `set stopped' to 20; that just made it wait 20 seconds before
it said `stopped timer expired' :-(.

I removed the `set openmode passive' and got


May 26 17:49:59 moran ppp-4[28641]: tun0: LCP: FSM: Using "deflink" as a transpo
rt 
May 26 17:49:59 moran ppp-4[28641]: tun0: LCP: deflink: State change Initial -->
 Closed 
May 26 17:49:59 moran ppp-4[28641]: tun0: LCP: deflink: State change Closed --> 
Stopped 
May 26 17:50:00 moran ppp-4[28641]: tun0: LCP: deflink: LayerStart 
May 26 17:50:00 moran ppp-4[28641]: tun0: LCP: deflink: SendConfigReq(1) state =
 Stopped 
May 26 17:50:00 moran ppp-4[28641]: tun0: LCP:  ACFCOMP[2] 
May 26 17:50:00 moran ppp-4[28641]: tun0: LCP:  PROTOCOMP[2] 
May 26 17:50:00 moran ppp-4[28641]: tun0: LCP:  ACCMAP[6] 0x 
May 26 17:50:00 moran ppp-4[28641]: tun0: LCP:  MRU[4] 1500 
May 26 17:50:00 moran ppp-4[28641]: tun0: LCP:  MAGICNUM[6] 0x1f0d216b 
May 26 17:50:00 moran ppp-4[28641]: tun0: LCP: deflink: State change Stopped -->
 Req-Sent 
May 26 17:50:00 moran ppp-4[28641]: tun0: LCP: deflink: RecvConfigReq(1) state =
 Req-Sent 
May 26 17:50:00 moran ppp-4[28641]: tun0: LCP:  ACFCOMP[2] 
May 26 17:50:00 moran ppp-4[28641]: tun0: LCP:  PROTOCOMP[2] 
May 26 17:50:00 moran ppp-4[28641]: tun0: LCP:  ACCMAP[6] 0x 
May 26 17:50:00 moran ppp-4[28641]: tun0: LCP:  MRU[4] 1500 
May 26 17:50:00 moran ppp-4[28641]: tun0: LCP:  MAGICNUM[6] 0x1f0d216b 
May 26 17:50:00 moran ppp-4[28641]: tun0: LCP: Magic is same (1f0d216b) - 1 time
s 
May 26 17:50:01 moran ppp-4[28641]: tun0: LCP: deflink: SendConfigNak(1) state =
 Req-Sent 
May 26 17:50:01 moran ppp-4[28641]: tun0: LCP:  MAGICNUM[6] 0x1f0d216b 
May 26 17:50:01 moran ppp-4[28641]: tun0: LCP: deflink: RecvConfigNak(1) state =
 Req-Sent 
May 26 17:50:01 moran ppp-4[28641]: tun0: LCP:  MAGICNUM[6] 0x1f0d216b 
May 26 17:50:01 moran ppp-4[28641]: tun0: LCP:  Magic 0x1f0d216b is NAKed! 
May 26 17:50:01 moran ppp-4[28641]: tun0: LCP: deflink: SendConfigReq(2) state =
 Req-Sent 
May 26 17:50:01 moran ppp-4[28641]: tun0: LCP:  ACFCOMP[2] 
May 26 17:50:01 moran ppp-4[28641]: tun0: LCP:  PROTOCOMP[2] 
May 26 17:50:01 moran ppp-4[28641]: tun0: LCP:  ACCMAP[6] 0x 
May 26 17:50:01 moran ppp-4[28641]: tun0: LCP:  MRU[4] 1500 
May 26 17:50:01 moran ppp-4[28641]: tun0: LCP:  MAGICNUM[6] 0x38e4a5bd 
May 26 17:50:01 moran ppp-4[28641]: tun0: LCP: deflink: RecvConfigReq(2) state =
 Req-Sent 
May 26 17:50:01 moran ppp-4[28641]: tun0: LCP:  ACFCOMP[2] 
May 26 17:50:01 moran ppp-4[28641]: tun0: LCP:  PROTOCOMP[2] 
May 26 17:50:01 moran ppp-4[28641]: tun0: LCP:  ACCMAP[6] 0x 
May 26 17:50:01 moran ppp-4[28641]: tun0: LCP:  MRU[4] 1500 
May 26 17:50:01 moran ppp-4[28641]: tun0: LCP:  MAGICNUM[6] 0x38e4a5bd 
May 26 17:50:01 moran ppp-4[28641]: tun0: LCP: Magic is same (38e4a5bd) - 2 time
s 
May 26 17:50:02 moran ppp-4[28641]: tun0: LCP: deflink: SendConfigNak(2) state =
 Req-Sent 

[...]

May 26 17:50:50 moran ppp-4[28641]: tun0: LCP:  ACFCOMP[2] 
May 26 17:50:50 moran ppp-4[28641]: tun0: LCP:  PROTOCOMP[2] 
May 26 17:50:50 moran ppp-4[28641]: tun0: LCP:  ACCMAP[6] 0x 
May 26 17:50:50 moran ppp-4[28641]: tun0: LCP:  MRU[4] 1500 
May 26 17:50:50 moran ppp-4[28641]: tun0: LCP:  MAGICNUM[6] 0x534d1784 
May 26 17:50:53 moran ppp-4[28641]: tun0: Phase: deflink: Too many LCP REQs sent
 - abandoning negotiation 
May 26 17:50:53 moran ppp-4[28641]: tun0: LCP: deflink: SendTerminateReq(13) sta
te = Req-Sent 
May 26 17:50:53 moran ppp-4[28641]: tun0: LCP: deflink: State change Req-Sent --
> Closing 
May 26 17:50:56 moran ppp-4[28641]: tun0: LCP: deflink: SendTerminateReq(13) sta
te = Closing 



which didn't do much good.  Finally, I told it to expect `Welcome' after
logging in, and received the 

Re: FTP passive mode - a new default?

[Chris Dillon]

On Wed, 26 May 1999, Jordan K. Hubbard wrote:

> Unless I hear unanimous fierce outcry against it, I'm strongly
> considering making FTP_PASSIVE_MODE obsolete by virtue of being the
> default for all tools/libraries which currently examine it.
> FTP_ACTIVE_MODE will be the new flag for toggling the previous
> behavior.
> 
> Given the state of the Internet today, I think this is purely a
> sensible change in defaults.  Comments?

Wouldn't bother me a bit.  I just set up a firewall and now need
passive mode to do any FTPing to outside hosts.  Passive shouldn't
hurt people who don't have firewalls anyway, so go for it.


-- Chris Dillon - cdil...@wolves.k12.mo.us - cdil...@inter-linc.net
   FreeBSD: The fastest and most stable server OS on the planet.
   For Intel x86 and Alpha architectures (SPARC under development).
   ( http://www.freebsd.org )

   "One should admire Windows users.  It takes a great deal of
courage to trust Windows with your data."



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: FTP passive mode - a new default?

[Eivind Eklund]

On Wed, May 26, 1999 at 07:54:03AM -0700, Jonathan M. Bresler wrote:
> > 
> > Unless I hear unanimous fierce outcry against it, I'm strongly
> > considering making FTP_PASSIVE_MODE obsolete by virtue of being the
> > default for all tools/libraries which currently examine it.
> > FTP_ACTIVE_MODE will be the new flag for toggling the previous
> > behavior.
> > 
> > Given the state of the Internet today, I think this is purely a
> > sensible change in defaults.  Comments?
> > 
>   do any apps check for FTP_ACTIVE_MODE?
>   are we going to apply patches to each app to check for this
>   and maintains those patches over the course of time?
> 
>   seems to be a change without commensurate benefit.it will
>   confuse some, suprise others and doesnt seem to offer
>   substantial benefit.

It has the (large!) benefit of NATed[1] and firewalled users getting a
working setup at once.  I'm in favour.

[1] Those using natd/ppp -alias will get this already, due to a
protocol translator in libalias.  Alas, this does not combine with
firewalls on the NAT machine unless somebody choose to activate the
code I added to libalias to punch 'holes' in ipfw.

Eivind.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: FTP passive mode - a new default?

[Jonathan M. Bresler]

> > > 
> > do any apps check for FTP_ACTIVE_MODE?
> > are we going to apply patches to each app to check for this
> > and maintains those patches over the course of time?
> > 
> > seems to be a change without commensurate benefit.it will
> > confuse some, suprise others and doesnt seem to offer
> > substantial benefit.
> 
> It has the (large!) benefit of NATed[1] and firewalled users getting a
> working setup at once.  I'm in favour.

changing the default to FTP_PASSIVE_MODE=YES would accomplish
the same thing, no?   i agree that this is good.  i disgree about
changin the name of the knob to FTP_ACTIVE_MODE.

jmb

> 
> [1] Those using natd/ppp -alias will get this already, due to a
> protocol translator in libalias.  Alas, this does not combine with
> firewalls on the NAT machine unless somebody choose to activate the
> code I added to libalias to punch 'holes' in ipfw.
> 
> Eivind.
> 


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: cvs commit: src/sys/i386/isa ida.c

[John W. DeBoskey]

Hi,

   I'm moving this to -current from -cvs which I beleive is more
appropriate...

>> Is this a driver for a RAID controller or something else?  I'm just
>> curious because on the Compaq servers I have there are some disk
>> status lights (disk OK/online/failure, etc) on each individual
>> hot-swap disk that operate under NT, but not under FreeBSD.  Does this
>> driver control that hardware monitoring feature on these servers
>> (S.M.A.R.T. I would assume)?
>
>There is a standard for ``SCSI-Attached Fault-Tolerant Enclosures''
>(SAF-TE) which is implemented by some vendors.  If an unknown
>processor target shows up in your SCSI probe list, that's probably
>what you have.  I have several machines with two of them:
>
>pt0 at ahc0 bus 0 target 6 lun 0
>pt0:  Fixed Processor SCSI-2 device 
>pt0: 3.300MB/s transfers
>pt1 at ahc1 bus 0 target 6 lun 0
>pt1:  Fixed Processor SCSI-2 device 
>pt1: 3.300MB/s transfers
>
>The way you recognize and talk to them is defined in a Microslop Word
>document which you can find floating about under the name
>`saftespec.zip'.


   I have/use Dell enclosures. These show-up at boot-time as:

pass6 at ahc0 bus 0 target 6 lun 0
pass6:  Fixed Processor SCSI-2 device 
pass6: 3.300MB/s transfers

   I was thinking about how I could talk to this unit so I 
could write a daemon to monitor all the drives for failures.
If a drive fails, I'd like to automatically (somehow) swap to
the spare drive and reconstruct. This sounds like a vinum
subject (which I have not looked into at all yet).

   Has anyone actually worked on something like this?

Thanks!
John


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: FTP passive mode - a new default?

[Adam]

> > Unless I hear unanimous fierce outcry against it, I'm strongly
> > considering making FTP_PASSIVE_MODE obsolete by virtue of being the
> > default for all tools/libraries which currently examine it.

If they already examine FTP_PASSIVE_MODE, why not just set it to YES by
default somewhere? 


> > FTP_ACTIVE_MODE will be the new flag for toggling the previous
> > behavior.
> > 
> > Given the state of the Internet today, I think this is purely a
> > sensible change in defaults.  Comments?
> 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: FTP passive mode - a new default?

[Mark Murray]

On Wed, 26 May 1999, Jordan K. Hubbard wrote:

> Unless I hear unanimous fierce outcry against it, I'm strongly
> considering making FTP_PASSIVE_MODE obsolete by virtue of being the
> default for all tools/libraries which currently examine it.
> FTP_ACTIVE_MODE will be the new flag for toggling the previous
> behavior.
> 
> Given the state of the Internet today, I think this is purely a
> sensible change in defaults.  Comments?

Very sensible. You have my vote.

M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: FTP passive mode - a new default?

[Dan Langille]

On 26 May 99, at 23:50, Adam wrote:

> > > Unless I hear unanimous fierce outcry against it, I'm strongly
> > > considering making FTP_PASSIVE_MODE obsolete by virtue of being the
> > > default for all tools/libraries which currently examine it.
> 
> If they already examine FTP_PASSIVE_MODE, why not just set it to YES by
> default somewhere? 

That makes more sense to me than introducing a new flag.
--
Dan Langille - DVL Software Limited
The FreeBSD Diary - http://www.FreeBSDDiary.org/freebsd/
NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/
The Racing System - http://www.racingsystem.com/racingsystem.htm


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: FTP passive mode - a new default?

[Jordan K. Hubbard]

I could accept this as an alternative implementation, no problem.  All
I care about is the functionality, and I'd personally be happier not
to have to document a new flag. :)

I'll see what setting it in login.conf does - that *should* solve the
problem swiftly and easily.

- Jordan

> On 26 May 99, at 23:50, Adam wrote:
> 
> > > > Unless I hear unanimous fierce outcry against it, I'm strongly
> > > > considering making FTP_PASSIVE_MODE obsolete by virtue of being the
> > > > default for all tools/libraries which currently examine it.
> > 
> > If they already examine FTP_PASSIVE_MODE, why not just set it to YES by
> > default somewhere? 
> 
> That makes more sense to me than introducing a new flag.
> --
> Dan Langille - DVL Software Limited
> The FreeBSD Diary - http://www.FreeBSDDiary.org/freebsd/
> NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/
> The Racing System - http://www.racingsystem.com/racingsystem.htm
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message