Re: Obtaining client host IP before accept()

[Bodo Rueskamp]

> >   Will the IP address of the client host ever enter buf[] if the
> >   accept() is _not_ uncommented?
> >  I don't need portability, since this is for use within the FreeBSD inetd
> >  exclusively.
>
> Well if you CAN'T do it in FreeBSD, is there an OS we can copy the API from
> that DOES do it? (Providing it isn't too braindamaged of course.. :)

There is an API that can do it: 
System V Release 4 Streams and TLI (Transport Layer Interface).

TLI is not based on systems calls doing the job.
It is based on message transfer between the user and some kernel entity.
  
Incoming calls are indicated by sending a T_CONN_IND message (connect
indication) to the user process. Then the user process opens a
second TLI stream (like using the socket() system call) and sends a
T_CONN_CON message (connect confirmation) to the kernel entity.

The TLI API is based on OSI. It doesn't provide much more functionality
than BSD sockets. Two APIs for the same task isn't very useful.
So you should better hack the BSD sockets to fit your needs.

A similar functionality in BSD-world would be:

(1) use recvfrom() instead of accept() on the socket
TLI: use getmsg() to receive the T_CONN_IND
(2) create a new socket using socket()
TLI: use open() to open a new stream
(3) accept the connection using an ioctl()
TLI: send T_CONN_CON to accept the connection
or
(2) reject the connection using an ioctl()
TLI: send T_DISCON_REQ to reject the connection

Here's an overview of the TLI messages:

TLI (user)  TLI (kernel)BSD socket

T_INFO_REQ  T_INFO_ACK  -
T_BIND_REQ  T_BIND_ACK  bind()
T_UNBIND_REQ-   -
T_OPTMGMT_REQ   T_OPTMGMT_ACK   setsockopt()
-   T_ERROR_ACK errno
T_CONN_REQ  T_CONN_RES  connect()
T_CONN_CON  T_CONN_IND  accept()
T_DISCON_REQ-   shutdown()
-   T_DISCON_INDerrno
T_ORDREL_REQ-   shutdown()
T_DATA_REQ  -   send() / sendto() / write()
-   T_DATA_IND  recv() / recvfrom() / read()
T_EXDATA_REQ-   send() / sendto()
-   T_EXDATA_INDrecv() / recvfrom()
T_UNITDATA_REQ  -   send() / sendto() / write()
-   T_UNITDATA_IND  recv() / recvfrom() / read()
-   T_UDERROR_IND   recv() / recvfrom() / read() & errno

; Bodo

-- 
Bodo Rüskamp, b...@rueskamp.com, 51°55' N 7°41' E
(1) Elvis is alive.
(2) Dinosaurs too. 
(3) The next millenium starts on January 1st 2000.


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

Re: Introduction

[Dag-Erling Smorgrav]

Ruslan Ermilov  writes:
> * Clean the existing code (both userland and kernel) (10-20% done)
> * Re-design the ipfw's API
> * Port the existing functionality to the new API
> * Proceed with new features

Pretty please with sugar on top, design an API that can be extended
without breaking binary compatibility. We've had too much of that for
no good reason (at least once between 2.2.7 and 2.2.8, and once
between 3.1 and 3.2).

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


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

Re: Introduction

[Doug Rabson]

On 19 Jun 1999, Dag-Erling Smorgrav wrote:

> Ruslan Ermilov  writes:
> > * Clean the existing code (both userland and kernel) (10-20% done)
> > * Re-design the ipfw's API
> > * Port the existing functionality to the new API
> > * Proceed with new features
> 
> Pretty please with sugar on top, design an API that can be extended
> without breaking binary compatibility. We've had too much of that for
> no good reason (at least once between 2.2.7 and 2.2.8, and once
> between 3.1 and 3.2).

As far as possible, all new apis in the kernel should be designed with a
stable ABI. Its pretty simple if you follow a few simple rules:

1. Hide implementation data structures. Access all information
   outside the core implementation using function calls.
2. Try to avoid using complex structures in the api. Each
   structure in an api defines part of its ABI. Changing that
   structure later breaks the ABI.
3. Keep the external api as simple as possible. As a rule of
   thumb, try to write manpages for each function. If you can't
   describe the function accurately and concisely in a manpage
   then its too complex.

--
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-hackers" in the body of the message

Re: SMP and Celerons...

[Pat Lynch]

Actually I have a "patch" that will get sound working on this board (its
working in mine right now...) but it disables support for all the other
ad1848 sound cards ;) I'm actually going through to make it work for all
of them now (at worst its just a couple case statements *shrug*)

If you are only using sound in this on mboard, then I'll give you the
diffs I have.

I *can* however grab the pII's from my mboard (an exact duplicate) and
swap CPU's temporarily, but I'll do it later, as I have not the
inclination to do it right now. If the Thunder2 has a problem with celery,
I'll know by tonight.

anyway, heres the diffs I made to /usr/src/sys/i386/isa/snd/ad1848.c

--- ad1848.cSat Jun 19 05:13:13 1999
+++ ad1848.c.TYAN   Sat Jun 19 05:13:32 1999
@@ -1443,7 +1443,7 @@
 cs423x_probe(u_long csn, u_long vend_id)
 {
 char *s = NULL ;
-u_long id = vend_id & 0xff00;
+u_long id = vend_id & 0x;
 if ( id == 0x3700630e )
s = "CS4237" ;
 else if ( id == 0x2500630e )
@@ -1458,6 +1458,10 @@
s = "Yamaha SA2";
 else if ( id == 0x3000a865)
s = "Yamaha SA3";
+else if ( id == 0x2100a865)
+   s = "Yamaha SA3";
+else if ( id == 0x0208a865)
+   s = "Yamaha SA3";
 else if ( id == 0xa865)
s = "Yamaha YMF719 OPL-SA3";
 else if (vend_id == 0x8140d315)
@@ -1517,7 +1521,8 @@
dev->id_alive = 16 ; /* number of io ports ? */
tmp_d = sb_op_desc ;
if (vend_id==0x2000a865 || vend_id==0x3000a865 ||
-   vend_id==0x0008a865 || vend_id==0x8140d315) {
+   vend_id==0x0008a865 || vend_id==0x8140d315 ||
+   vend_id==0x2100a865 || vend_id==0x0208a865) {
/* Yamaha SA2/SA3 or ENSONIQ SoundscapeVIVO ENS4081 */
dev->id_iobase = d.port[0] ;
tmp_d.alt_base = d.port[1] ;
@@ -1532,10 +1537,12 @@
tmp_d = mss_op_desc ;
dev->id_iobase = d.port[0] -4 ; /* XXX old mss have 4 bytes
before... */
tmp_d.alt_base = d.port[2];
-   switch (vend_id & 0xff00) {
+   switch (vend_id & 0x) {
 
case 0x2000a865:/* Yamaha SA2 */
case 0x3000a865:/* Yamaha SA3 */
+   case 0x2100a865:/* Yamaha SA3 */
+case 0x0208a865:   /* Yamaha SA3 */
case 0xa865:/* Yamaha TMF719 SA3 */
dev->id_iobase = d.port[1];
tmp_d.alt_base = d.port[0];


notice the switch from the vendor id numbers, the TYAN board has
0x instead of 0xff00
(this is based on the patch someone posted to -current earlier this week)

like I said, to make it work on all ad1848 boards is trivial, but then,
I'm not
really a coder, so it takes me more time to work out how I want to do it
;) and chances are, compared to others, it'll be sloppy.

-Pat

___

Pat Lynch   ly...@rush.net
ly...@bsdunix.net
Systems Administrator   Rush Networking
___

On Fri, 18 Jun 1999, Jim Bryant wrote:

> In reply:
> > Heya, sorry I tried this one on -stable and -questions and noone seems to
> > know, and they actually go so far as to ask me how I got two celerons in a
> > motherboard...
> > 
> > so I ask here.
> > 
> > I have two PPGA(Socket 370) Celeron 333A's that are on MSI6905 Dual Socket
> > 1 adaptors...
> > 
> > a Tyan Thunder 2 motherboard (onboard scsi, sound, etc.)
> 
> there is a problem with the freebsd sound support for this board, but
> i am told it is being worked on [?].
> 
> > I boot an SMP kernel, it gets right past autoboot... then panics
> > 
> > the message was that it "could not find local apic"...
> > 
> > its kinda strange because essentially with these adaptors, the celerons
> > should be 1) SMP capable, and 2) the same as a PII, except no L2 cache
> > 
> > I know others that ran FreeBSD SMP with celerons... anyone know if theres
> > some kind of patch I need or modification I have to make to get either
> > -CURRENT or -STABLE working on this machine? Right now it is running a UP
> > kernel instead of the SMP one and runs fine.
> 
> strangeness.
> 
> i run the same board with dual pII-333's, Tyan Thunder2, S1696DLUA.
> 
> when i boot, i show two cpus and an apic.  i have two theories:
> 
> 1). these boards have a problem with celery.
> 
> 2). you have a flaky mb.  granted, i haven't heard about too many of
> them being flaky, but that they have an above average reliability
> level.  but then, there is always someone that get s flake sooner or
> later.
> 
> My experience [of about 12 days so far] is that this is a quality
> midrange system, as configured here, and is maybe even a tad more
> reliable than my workhorse p133 [which has had three spontaneous
> reboots in the same period, but running an older -current by a f

Re: Introduction

[Brian F. Feldman]

On Sat, 19 Jun 1999, Doug Rabson wrote:

> On 19 Jun 1999, Dag-Erling Smorgrav wrote:
> 
> > Ruslan Ermilov  writes:
> > > * Clean the existing code (both userland and kernel) (10-20% done)
> > > * Re-design the ipfw's API
> > > * Port the existing functionality to the new API
> > > * Proceed with new features
> > 
> > Pretty please with sugar on top, design an API that can be extended
> > without breaking binary compatibility. We've had too much of that for
> > no good reason (at least once between 2.2.7 and 2.2.8, and once
> > between 3.1 and 3.2).
> 
> As far as possible, all new apis in the kernel should be designed with a
> stable ABI. Its pretty simple if you follow a few simple rules:
> 
>   1. Hide implementation data structures. Access all information
>  outside the core implementation using function calls.
>   2. Try to avoid using complex structures in the api. Each
>  structure in an api defines part of its ABI. Changing that
>  structure later breaks the ABI.
>   3. Keep the external api as simple as possible. As a rule of
>  thumb, try to write manpages for each function. If you can't
>  describe the function accurately and concisely in a manpage
>  then its too complex.
> 

It might be worth (discussion of) making ipfilter the firewall of choice for 
4.0.
There would of course be rule conversion scripts/programs (ipfw->ipf(5)), and
ipfilter would be converted to a KLD, cruft removed (I'm going to work on 
these), and
ipfilter KLD support (currently options IPFILTER_LKM) made a non-option. It 
seems
that our pretty proprietary ipfw is no longer a good idea.
   And if Luigi ported all of his stuff to ipfilter from ipfw, and I did 
per-[ug]id
support for ipfilter (which I will), we'll definitely be ahead. Ipfilter is a 
win for
compatibilty/ubiquity, and seems to be faster than ipfw anyway. Are there any 
technical
arguments against ipfilter or for ipfw? Note that: political arguments do not 
count,
a conversion method will be available for ipfw users, and we should have 
anything special
(DummyNet, uid/gid-based filtering) ported over to ipfilter.

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

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: Introduction

[Doug Rabson]

On Sat, 19 Jun 1999, Brian F. Feldman wrote:

> On Sat, 19 Jun 1999, Doug Rabson wrote:
> 
> > On 19 Jun 1999, Dag-Erling Smorgrav wrote:
> > 
> > > Ruslan Ermilov  writes:
> > > > * Clean the existing code (both userland and kernel) (10-20% done)
> > > > * Re-design the ipfw's API
> > > > * Port the existing functionality to the new API
> > > > * Proceed with new features
> > > 
> > > Pretty please with sugar on top, design an API that can be extended
> > > without breaking binary compatibility. We've had too much of that for
> > > no good reason (at least once between 2.2.7 and 2.2.8, and once
> > > between 3.1 and 3.2).
> > 
> > As far as possible, all new apis in the kernel should be designed with a
> > stable ABI. Its pretty simple if you follow a few simple rules:
> > 
> > 1. Hide implementation data structures. Access all information
> >outside the core implementation using function calls.
> > 2. Try to avoid using complex structures in the api. Each
> >structure in an api defines part of its ABI. Changing that
> >structure later breaks the ABI.
> > 3. Keep the external api as simple as possible. As a rule of
> >thumb, try to write manpages for each function. If you can't
> >describe the function accurately and concisely in a manpage
> >then its too complex.
> > 
> 
> It might be worth (discussion of) making ipfilter the firewall of
> choice for 4.0. There would of course be rule conversion
> scripts/programs (ipfw->ipf(5)), and ipfilter would be converted to a
> KLD, cruft removed (I'm going to work on these), and ipfilter KLD
> support (currently options IPFILTER_LKM) made a non-option. It seems
> that our pretty proprietary ipfw is no longer a good idea.
>And if Luigi ported all of his stuff to ipfilter from ipfw, and I
> did per-[ug]id support for ipfilter (which I will), we'll definitely
> be ahead. Ipfilter is a win for compatibilty/ubiquity, and seems to be
> faster than ipfw anyway. Are there any technical arguments against
> ipfilter or for ipfw? Note that: political arguments do not count, a
> conversion method will be available for ipfw users, and we should have
> anything special (DummyNet, uid/gid-based filtering) ported over to
> ipfilter.

I don't have a position on ipfw vs. ipfilter. As long as no functionality
is lost, I don't see any problems changing.

--
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-hackers" in the body of the message

What does VOP_FREEBLKS() do?

[Zhihui Zhang]

I find in the routine ffs_blkfree() there is a new statement saying:

VOP_FREEBLKS(ip->i_devvp, fsbtodb(fs, bno), size);
  
which calls spec_freeblks() in file spec_vnops.c.  The routine 
spec_freeblks() looks simple.  When D_CANFREE is set, it gets an empty
buffer and call strategy routine for the buffer.  Since B_READ is not set,
we must call the strategy routine to write some data.  But where is the
data for the buffer?  Why we call VOP_FREEBLKS() at the time we are going
to free the blocks?  BTW, this vnode operation is not listed in the man
pages.

Any help is appreciated.

--
Zhihui Zhang.  Please visit http://www.freebsd.org
--



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

Re: Introduction

[Dag-Erling Smorgrav]

"Brian F. Feldman"  writes:
> It might be worth (discussion of) making ipfilter the firewall of
> choice for 4.0. There would of course be rule conversion
> scripts/programs (ipfw->ipf(5)), and ipfilter would be converted to
> a KLD, cruft removed (I'm going to work on these), and ipfilter KLD
> support (currently options IPFILTER_LKM) made a non-option. It seems
> that our pretty proprietary ipfw is no longer a good idea.

If ipfilter can to everything ipfw can (judging from ipf(5), it can)
and you even manage to keep an ipfw(8) command around so those who
want kan keep using the old syntax still can, then I for one have no
objections.

Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a
simple Perl script should be sufficient.

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


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

Re: Introduction

[Doug Rabson]

On 19 Jun 1999, Dag-Erling Smorgrav wrote:

> "Brian F. Feldman"  writes:
> > It might be worth (discussion of) making ipfilter the firewall of
> > choice for 4.0. There would of course be rule conversion
> > scripts/programs (ipfw->ipf(5)), and ipfilter would be converted to
> > a KLD, cruft removed (I'm going to work on these), and ipfilter KLD
> > support (currently options IPFILTER_LKM) made a non-option. It seems
> > that our pretty proprietary ipfw is no longer a good idea.
> 
> If ipfilter can to everything ipfw can (judging from ipf(5), it can)
> and you even manage to keep an ipfw(8) command around so those who
> want kan keep using the old syntax still can, then I for one have no
> objections.
> 
> Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a
> simple Perl script should be sufficient.

Does ipfilter support divert sockets?

--
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-hackers" in the body of the message

Firewalls (was Re: Introduction)

[Brian F. Feldman]

On 19 Jun 1999, Dag-Erling Smorgrav wrote:

> "Brian F. Feldman"  writes:
> > It might be worth (discussion of) making ipfilter the firewall of
> > choice for 4.0. There would of course be rule conversion
> > scripts/programs (ipfw->ipf(5)), and ipfilter would be converted to
> > a KLD, cruft removed (I'm going to work on these), and ipfilter KLD
> > support (currently options IPFILTER_LKM) made a non-option. It seems
> > that our pretty proprietary ipfw is no longer a good idea.
> 
> If ipfilter can to everything ipfw can (judging from ipf(5), it can)
> and you even manage to keep an ipfw(8) command around so those who
> want kan keep using the old syntax still can, then I for one have no
> objections.
> 
> Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a
> simple Perl script should be sufficient.

Not quite as trivial as you think. ipfw and ipf are completely backwards when 
it comes
to rule order: in ipfw, the first rule matched takes effect; in ipf, the last 
rule matched
takes effect. Plus, ipf doesn't have rule numbers (but there's similar 
functionailty.)
If you think you can get used to them both enough to tackle this, I'll handle 
other
things, and we can have a working replacement for crufty old ipfw. Note that 
Luigi's
extra ipfw functionality and my extra ipfw functionality _will_ be wanted in ipf
before everyone is necessarily willing to switch. I have a feeling there will 
be some
holdouts that, even if ipfw is removed, they'll MFS (merge from stable) ipfw 
back just
because they want to keep the old way. Ipfw could be dead for 4.0-RELEASE, as I 
see it
now. More discussion is, however, necessary.

> 
> DES
> -- 
> Dag-Erling Smorgrav - d...@flood.ping.uio.no
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

ipfilter (was: RE: Introduction)

[Constantine Shkolny]

Hi All,

I'm now analyzing ipfilter in 3.2 and our goal is to port our
IPSec/firewall. I'm still in the beginning of reading the code
so, at this time, I can't yet tell how nice it fits our needs.
I just have some concerns which I'd like the people who are
going to re-design the ipfilter to hear. I wouldn't be surprised
to learn that you are already thinking about this, however, it's
nice to know it for certain :-)

The things in the IPSec field are seemingly moving to using
hardware accelerators for doing compression/encryption/authentication.
This means that IP filters need to grab some of IP packets, process
them on a specialized prosessor and then re-inject them into the IP
packet stream. That is, the filter may decide to convert the packet,
but it doesn't have it ready-to-go when it has to return. However,
it may have it ready at some later time, possibly when it processes
a hardware interrupt and sees that the co-processor has finished its
work on the packet. Can ipfilter handle this?

Thank you,
Stan



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

Re: Firewalls (was Re: Introduction)

[Ian West]

On Sat, Jun 19, 1999 at 11:12:07AM -0400, Brian F. Feldman wrote:
> On 19 Jun 1999, Dag-Erling Smorgrav wrote:
> 
> > "Brian F. Feldman"  writes:
> > > It might be worth (discussion of) making ipfilter the firewall of
> > > choice for 4.0. There would of course be rule conversion
> > > scripts/programs (ipfw->ipf(5)), and ipfilter would be converted to
> > > a KLD, cruft removed (I'm going to work on these), and ipfilter KLD
> > > support (currently options IPFILTER_LKM) made a non-option. It seems
> > > that our pretty proprietary ipfw is no longer a good idea.
> > 
> > If ipfilter can to everything ipfw can (judging from ipf(5), it can)
> > and you even manage to keep an ipfw(8) command around so those who
> > want kan keep using the old syntax still can, then I for one have no
> > objections.
> > 
> > Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a
> > simple Perl script should be sufficient.
> 
> Not quite as trivial as you think. ipfw and ipf are completely backwards when 
> it comes
> to rule order: in ipfw, the first rule matched takes effect; in ipf, the last 
> rule matched
> takes effect. Plus, ipf doesn't have rule numbers (but there's similar 
> functionailty.)
> If you think you can get used to them both enough to tackle this, I'll handle 
> other
> things, and we can have a working replacement for crufty old ipfw. Note that 
> Luigi's
> extra ipfw functionality and my extra ipfw functionality _will_ be wanted in 
> ipf
> before everyone is necessarily willing to switch. I have a feeling there will 
> be some
> holdouts that, even if ipfw is removed, they'll MFS (merge from stable) ipfw 
> back just
> because they want to keep the old way. Ipfw could be dead for 4.0-RELEASE, as 
> I see it
> now. More discussion is, however, necessary.
> 
> > 
> > DES
> > -- 
> > Dag-Erling Smorgrav - d...@flood.ping.uio.no
> > 
> 
>  Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
>  gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
>  FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
>http://www.FreeBSD.org/  _ |___/___/___/ 
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message

Does ip filter now support per interface filtering based on an ip
address, not an interface name ? This was the limitation I encountered
last time I looked at it. Ran up against a few problems getting it to
run nicely with user-ppp. (Can't remember how long ago that was exactly
though, it may be fixed now, if so please ignore this :-)


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

Re: Introduction

[Brian F. Feldman]

On Sat, 19 Jun 1999, Doug Rabson wrote:

> On 19 Jun 1999, Dag-Erling Smorgrav wrote:
> 
> > "Brian F. Feldman"  writes:
> > > It might be worth (discussion of) making ipfilter the firewall of
> > > choice for 4.0. There would of course be rule conversion
> > > scripts/programs (ipfw->ipf(5)), and ipfilter would be converted to
> > > a KLD, cruft removed (I'm going to work on these), and ipfilter KLD
> > > support (currently options IPFILTER_LKM) made a non-option. It seems
> > > that our pretty proprietary ipfw is no longer a good idea.
> > 
> > If ipfilter can to everything ipfw can (judging from ipf(5), it can)
> > and you even manage to keep an ipfw(8) command around so those who
> > want kan keep using the old syntax still can, then I for one have no
> > objections.
> > 
> > Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a
> > simple Perl script should be sufficient.
> 
> Does ipfilter support divert sockets?

It still needs:
divert sockets
Luigi's stuff (dummynet and bridging)
my stuff

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

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: Firewalls (was Re: Introduction)

[Dag-Erling Smorgrav]

"Brian F. Feldman"  writes:
> On 19 Jun 1999, Dag-Erling Smorgrav wrote:
> > Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a
> > simple Perl script should be sufficient.
> Not quite as trivial as you think. ipfw and ipf are completely backwards when 
> it comes
> to rule order: in ipfw, the first rule matched takes effect; in ipf, the last 
> rule matched
> takes effect.

Just throw in 'quick' and ipfilter behaves just like ipfw.

>Note that 
> Luigi's
> extra ipfw functionality and my extra ipfw functionality _will_ be wanted in 
> ipf
> before everyone is necessarily willing to switch.

Divert sockets, dummynet and credential-based filtering would be
sorely missed if they weren't ported to ipfilter.

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


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

Changing Bootmgr display

[Dennis]

 

I've bog

F1: FreeBSD
F2: LINUX
F3: FreeBSD

F3 is a non-bootable file system...is there a way to get the boot manager
to only display F1 and F2?

Dennis


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

Re: Inetd and wrapping.

[David Malone]

> The support (after the patches Sheldon brought in) now is 
> pretty good; is there any reason why the existing functionality should be
> extended ?

We should support atleast as much as tcpd did. I think the only
thing we're missing now is wrapping the first connection of a
udp/wait service and then inetd can do as much as tcpd could.
(Wrapping of internal services is a bonus over what tcpd can do
already).

I'd be happy with just adding support for wrapping udp stuff and
adding a command line flag which turns off wrapping to keep purists
happy. I just wanted to see what the general opinion was.

David.


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

Re: SMP and Celerons...

[Marc Nicholas]

Hmmm...I always thought there was something "broke" inside Celerons to
prevent SMP...maybe I'm wrong? Sure would be neat if you could run them
SMP...


-marc


Marc Nicholas netSTOR Technologies, Inc. http://www.netstor.com
"Fast, Expandable and Affordable Internet Caching Products"
1.877.464.4776 416.979.9000 fax: 416.979.8223 cell: 416.346.9255

On Fri, 18 Jun 1999, Pat Lynch wrote:

> Heya, sorry I tried this one on -stable and -questions and noone seems to
> know, and they actually go so far as to ask me how I got two celerons in a
> motherboard...
> 
> so I ask here.
> 
> I have two PPGA(Socket 370) Celeron 333A's that are on MSI6905 Dual Socket
> 1 adaptors...
> 
> a Tyan Thunder 2 motherboard (onboard scsi, sound, etc.)
> 
> I boot an SMP kernel, it gets right past autoboot... then panics
> 
> the message was that it "could not find local apic"...
> 
> its kinda strange because essentially with these adaptors, the celerons
> should be 1) SMP capable, and 2) the same as a PII, except no L2 cache
> 
> I know others that ran FreeBSD SMP with celerons... anyone know if theres
> some kind of patch I need or modification I have to make to get either
> -CURRENT or -STABLE working on this machine? Right now it is running a UP
> kernel instead of the SMP one and runs fine.
> 
> -Pat
> 
> ___
> 
> Pat Lynch ly...@rush.net
>   ly...@bsdunix.net
> Systems Administrator Rush Networking
> ___
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 



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

Re: Changing Bootmgr display

[Robert Nordier]

Dennis wrote:
 
> F1: FreeBSD
> F2: LINUX
> F3: FreeBSD
> 
> F3 is a non-bootable file system...is there a way to get the boot manager
> to only display F1 and F2?

At the moment, no.  Though you could use the following patch, which
allows the slices to be individually disabled.  (The B0FLAGS setting in
Makefile enables slices 1 and 2; use B0FLAGS=0xf to enable all four
slices.)

If worthwhile, boot0cfg(8) can later be modified to set/unset the
flags, rather than using a build option.

Note that the patch is against boot0.s rev 1.9 committed yesterday.

--
Robert Nordier


--- Makefile.orig   Sat Jun 19 18:48:42 1999
+++ MakefileSat Jun 19 18:43:07 1999
@@ -8,7 +8,7 @@
 
 M4?=   m4
 
-B0FLAGS=0x0
+B0FLAGS=0x3
 B0TICKS=0xb6
 
 ORG=   0x600
--- boot0.s.origSat Jun 19 18:51:10 1999
+++ boot0.s Sat Jun 19 18:51:21 1999
@@ -71,6 +71,8 @@
movwir(partbl+0x4,_bx)  # Partition table
xorl %edx,%edx  # Item number
 main.3:movbr1(_ch,-0x4,_bx_)   # Zero active flag
+   btwr1(_dx,_FLAGS,_bp_)  # Entry enabled?
+   jnc main.5  # No
movb0r(_bx_,_al)# Load type
movwir(tables,_di)  # Lookup tables
movb $TBL0SZ,%cl# Number of entries


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

Re: Changing Bootmgr display

[Warner Losh]

In message <199906191602.maa10...@etinc.com> Dennis writes:
: F3 is a non-bootable file system...is there a way to get the boot manager
: to only display F1 and F2?

More generally, I'd like my Win98 partition to be identified as Win98, 
not .  Also, is there a list of partition types to ignore
somehwere?  My suspend partition also shows up as .

Warner


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

Re: SMP and Celerons...

[Warner Losh]

In message  
Marc Nicholas writes:
: Hmmm...I always thought there was something "broke" inside Celerons to
: prevent SMP...maybe I'm wrong? Sure would be neat if you could run them
: SMP...

What is "broke" about the Celerons is their cache.  Without a good
cache sharing, you can't get good SMP performance.  While you can run
a SMP Celeron machine, it won't scale as well as the PII version of
the chip.

Warner


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

Re: KNE40BT in freebsd only getting 45KB/sec ftp transfer to win98 machine

[Jim Bryant]

duplex should work fine in a 2 machine point to point without a
switch.

In reply:
> Hi,
> 
> Speed in what protocol? FTP? SMB? Appletalk?
> 
> Have you checked the duplexing of cards on both
> machines? Use the DOS program that came with the
> ethernet cards to check. Unless your card is
> connected directly to a switch, it should be
> half duplex (I'm not sure on this, but that
> is my understanding).
> 
> 
> Jim Bryant wrote:
> > 
> > In reply:
> > > I am running FreeBSD-current and for some reason I am only
> > > getting~45KB/sec
> > > transfer to a computer running Windows 98.  I have a Kingston
> > > KNE40BTcard and I
> > > can find no hardware error as to why I am only reaching those speeds.
> > > Could you suggest what may be the error?
> > >
> > > Andrew Tamm
> > 
> > ummm..  winblowz-98.

jim
-- 
All opinions expressed are mine, if you|  "I will not be pushed, stamped,
think otherwise, then go jump into turbid  |  briefed, debriefed, indexed, or
radioactive waters and yell WAHOO !!!  |  numbered!" - #1, "The Prisoner"
--
Inet: jbry...@tfs.netAX.25: kc5...@wv0t.#neks.ks.usa.noam grid: EM28pw
voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM.   http://www.tfs.net/~jbryant
--
HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+


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

Re: Changing Bootmgr display

[Robert Nordier]

Warner Losh wrote:
> In message <199906191602.maa10...@etinc.com> Dennis writes:
> : F3 is a non-bootable file system...is there a way to get the boot manager
> : to only display F1 and F2?
> 
> More generally, I'd like my Win98 partition to be identified as Win98, 
> not .  Also, is there a list of partition types to ignore
> somehwere?  My suspend partition also shows up as .

The present boot manager is limited in size to 446 bytes, so
there's just not space to provide an adequate list of known partitions.

The best solution is probably to customise the sources or use a
"proper" boot manager.  (I see that at the FreeBSD Mall, they're
offering Partition Magic and System Commander with FreeBSD.)

To ignore a partition by type, see the following patch as an example
(we ignore type 0x42).

--
Robert Nordier


--- boot0.s.origSat Jun 19 19:50:23 1999
+++ boot0.s Sat Jun 19 19:50:44 1999
@@ -24,7 +24,7 @@
 
.set PRT_OFF,0x1be  # Partition table
 
-   .set TBL0SZ,0x3 # Table 0 size
+   .set TBL0SZ,0x4 # Table 0 size
.set TBL1SZ,0xa # Table 1 size
 
.set MAGIC,0xaa55   # Magic: bootable
@@ -231,7 +231,7 @@
 # Partition type tables
 
 tables:
-   .byte 0x0, 0x5, 0xf
+   .byte 0x0, 0x5, 0xf, 0x42
 
.byte 0x1, 0x4, 0x6, 0xb, 0xc, 0xe, 0x63, 0x83
.byte 0xa5, 0xa6


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

Re: Firewalls (was Re: Introduction)

[Brian F. Feldman]

On 19 Jun 1999, Dag-Erling Smorgrav wrote:

> "Brian F. Feldman"  writes:
> > On 19 Jun 1999, Dag-Erling Smorgrav wrote:
> > > Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a
> > > simple Perl script should be sufficient.
> > Not quite as trivial as you think. ipfw and ipf are completely backwards 
> > when it comes
> > to rule order: in ipfw, the first rule matched takes effect; in ipf, the 
> > last rule matched
> > takes effect.
> 
> Just throw in 'quick' and ipfilter behaves just like ipfw.

I figured that out. Come to think of it, I rather like "quick" much better
than ipf's default way.

> 
> >Note 
> > that Luigi's
> > extra ipfw functionality and my extra ipfw functionality _will_ be wanted 
> > in ipf
> > before everyone is necessarily willing to switch.
> 
> Divert sockets, dummynet and credential-based filtering would be
> sorely missed if they weren't ported to ipfilter.

Definitely. Working on ipfilter is probably better than reinventing the wheel
again.

> 
> DES
> -- 
> Dag-Erling Smorgrav - d...@flood.ping.uio.no
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: Changing Bootmgr display

[John Baldwin]

On 19-Jun-99 Warner Losh wrote:
> In message <199906191602.maa10...@etinc.com> Dennis writes:
>: F3 is a non-bootable file system...is there a way to get the boot manager
>: to only display F1 and F2?
> 
> More generally, I'd like my Win98 partition to be identified as Win98, 
> not .  Also, is there a list of partition types to ignore
> somehwere?  My suspend partition also shows up as .
> 
> Warner

Then don't use BootEasy.  The OS-BS boot manager is quite nice, and the beta
version (which seems very stable in my experience) even provides a nice
colorful menu on boot up as well as a nice installation utility.

And with that you can name each partition whatever you want, put them in any
order, and optionally have a default partition to boot to. 

---

John Baldwin  -- http://members.freedomnet.com/~jbaldwin/
PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.freebsd.org


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

Re: Changing Bootmgr display

[Aaron Smith]

On Sat, 19 Jun 1999 14:26:52 EDT, John Baldwin writes:
>Then don't use BootEasy.  The OS-BS boot manager is quite nice, and the beta
>version (which seems very stable in my experience) even provides a nice
>colorful menu on boot up as well as a nice installation utility.
>
>And with that you can name each partition whatever you want, put them in any
>order, and optionally have a default partition to boot to. 

LILO's an option too, right? Is no one mentioning it for some
incompatibility I don't know about (I haven't used it with FreeBSD), or is
the reason political?

Aaron


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

Re: Changing Bootmgr display

[John Baldwin]

On 19-Jun-99 Aaron Smith wrote:
> On Sat, 19 Jun 1999 14:26:52 EDT, John Baldwin writes:
>>Then don't use BootEasy.  The OS-BS boot manager is quite nice, and the beta
>>version (which seems very stable in my experience) even provides a nice
>>colorful menu on boot up as well as a nice installation utility.
>>
>>And with that you can name each partition whatever you want, put them in any
>>order, and optionally have a default partition to boot to. 
> 
> LILO's an option too, right? Is no one mentioning it for some
> incompatibility I don't know about (I haven't used it with FreeBSD), or is
> the reason political?
> 
> Aaron

No, I just happen to use OS-BS in an environment of machines that dual boot NT
and FreeBSD.  (And my machine which dual boots '95 and FreeBSD).  I don't
happen to use Linux, so I don't happen to use LILO.  No politics there.

Also, both BootEasy and OS-BS (stable and beta versions) come on the FreeBSD
CD's, so I'd reccommend those to a FreeBSD user just because they are easy to
get to (no 'net surfin' required) if they have the CD's.

FWIW, OS-BS is a completely OS-independent project with no affiliation with
FreeBSD, it just happens to be on the CD.  (AFAIK)

---

John Baldwin  -- http://members.freedomnet.com/~jbaldwin/
PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.freebsd.org


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

Re: SMP and Celerons...

[Shaun Rowland]

Marc Nicholas  writes:

> Hmmm...I always thought there was something "broke" inside Celerons to
> prevent SMP...maybe I'm wrong? Sure would be neat if you could run them
> SMP...
> 
> 
> -marc

Well there is kind of.  If you have a socket 370 adapter you can
un-break it.  I am currently running dual Celeron 400's, and they
truly fly on this box!  I can assure you it works without problems.
-- 
Shaun Rowland   rowl...@cis.ohio-state.edu
http://www.cis.ohio-state.edu/~rowland/


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

Re: SMP and Celerons...

[Shaun Rowland]

Warner Losh  writes:

> In message  
> Marc Nicholas writes:
> : Hmmm...I always thought there was something "broke" inside Celerons to
> : prevent SMP...maybe I'm wrong? Sure would be neat if you could run them
> : SMP...
> 
> What is "broke" about the Celerons is their cache.  Without a good
> cache sharing, you can't get good SMP performance.  While you can run
> a SMP Celeron machine, it won't scale as well as the PII version of
> the chip.
> 
> Warner

Do you mean the ones that don't have cache or the ones that have 128Kb
cache on the chip?  Is there that big of a hit of the cache is on the
chip?  I have seen some benchmarks and the system I have seemed to
keep up well with a dual PII 400.  I don't know how well it would
scale though.
-- 
Shaun Rowland   rowl...@cis.ohio-state.edu
http://www.cis.ohio-state.edu/~rowland/


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

Re: Changing Bootmgr display

[Dennis]

At 11:52 AM 6/19/99 -0700, you wrote:
>On Sat, 19 Jun 1999 14:26:52 EDT, John Baldwin writes:
>>Then don't use BootEasy.  The OS-BS boot manager is quite nice, and the beta
>>version (which seems very stable in my experience) even provides a nice
>>colorful menu on boot up as well as a nice installation utility.
>>
>>And with that you can name each partition whatever you want, put them in any
>>order, and optionally have a default partition to boot to. 
>
>LILO's an option too, right? Is no one mentioning it for some
>incompatibility I don't know about (I haven't used it with FreeBSD), or is
>the reason political?

The only objection I have to lilo is that is doesnt display a menu by
default and you have to specify a default (unlike the "last-used" method of
freebsd), which is a pain for systems that generally have no keyboard or
monitor. 

DB
>
>Aaron
> 


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

Re: Firewalls (was Re: Introduction)

[Jason Thorpe]

On 19 Jun 1999 17:30:13 +0200 
 Dag-Erling Smorgrav  wrote:

 > Divert sockets, dummynet and credential-based filtering would be
 > sorely missed if they weren't ported to ipfilter.

...but if they were ported to IP Filter, then lots of other systems could
use them, too.

-- Jason R. Thorpe 



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

Joystick support for Koules...

[John Baldwin]

In an effort to make FreeBSD even more (un)productive, I added in support for
FreeBSD's joystick driver to Koules, a game which can be found in the ports
collection at /usr/ports/games/koules.  To compile the game with this patch
follow this sequence:

# cd /usr/ports/games/koules
# make patch
# cd work/koules-1.4
# fetch http://www.cslab.vt.edu/~jobaldwi/koules-bsdjoy.tgz
# mkdir temp
# tar xvfzC koules-bsdjoy.tgz temp/
# patch client.c < temp/client.c.patch
# patch koules.c < temp/koules.c.patch
# patch koules.h < temp/koules.h.patch
# patch menu.c < temp/menu.c.patch
# patch xlib/init.c < temp/xlib_init.c.patch
# cp temp/freebsd_joystick.h .

Edit Iconfig and uncomment the '#define JOYSTICK' line, then cd back to
/usr/ports/games/koules, and 'make install' as usual.  One problem so far: it
doesn't detect to make sure a joystick is at a port.  Please send any
suggestions, comments, etc. as I'd like to get this tested on more than just my
box before I send it to the author as the authoritative FreeBSD joystick
support. :)

---

John Baldwin  -- http://members.freedomnet.com/~jbaldwin/
PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.freebsd.org


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

Re: SMP and Celerons...

[Pat Lynch]

Wish that was the case for me, might just be my momboard

___

Pat Lynch   ly...@rush.net
ly...@bsdunix.net
Systems Administrator   Rush Networking
___

On 19 Jun 1999, Shaun Rowland wrote:

> Marc Nicholas  writes:
> 
> > Hmmm...I always thought there was something "broke" inside Celerons to
> > prevent SMP...maybe I'm wrong? Sure would be neat if you could run them
> > SMP...
> > 
> > 
> > -marc
> 
> Well there is kind of.  If you have a socket 370 adapter you can
> un-break it.  I am currently running dual Celeron 400's, and they
> truly fly on this box!  I can assure you it works without problems.
> -- 
> Shaun Rowland   rowl...@cis.ohio-state.edu
> http://www.cis.ohio-state.edu/~rowland/
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 



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

Re: Changing Bootmgr display

[Dennis]

Will it allow you to

1) specify which partitions appear on the menu (ie, eliminate
non-bootables) and
2) set the partition last selected to the default/active partition?

Dennis

At 06:05 PM 6/19/99 -0400, you wrote:
>
>On 19-Jun-99 Dennis wrote:
>> At 03:14 PM 6/19/99 -0400, you wrote:
>>>
>>>On 19-Jun-99 Aaron Smith wrote:
 On Sat, 19 Jun 1999 14:26:52 EDT, John Baldwin writes:
>Then don't use BootEasy.  The OS-BS boot manager is quite nice, and the
>> beta
>version (which seems very stable in my experience) even provides a nice
>colorful menu on boot up as well as a nice installation utility.
>
>And with that you can name each partition whatever you want, put them in
>> any
>order, and optionally have a default partition to boot to. 
 
 LILO's an option too, right? Is no one mentioning it for some
 incompatibility I don't know about (I haven't used it with FreeBSD),
or is
 the reason political?
 
 Aaron
>>>
>>>No, I just happen to use OS-BS in an environment of machines that dual
>> boot NT
>>>and FreeBSD.  (And my machine which dual boots '95 and FreeBSD).  I don't
>>>happen to use Linux, so I don't happen to use LILO.  No politics there.
>>>
>>>Also, both BootEasy and OS-BS (stable and beta versions) come on the
FreeBSD
>>>CD's, so I'd reccommend those to a FreeBSD user just because they are
easy to
>>>get to (no 'net surfin' required) if they have the CD's.
>>>
>>>FWIW, OS-BS is a completely OS-independent project with no affiliation with
>>>FreeBSD, it just happens to be on the CD.  (AFAIK)
>> 
>> And for those of use who dont use the CD method, where might we find it?
>> Does it boot the "last used" OS or is there a specific default?
>
>ftp://ftp.freebsd.org/pub/FreeBSD/tools/{osbs135.exe|osbsbeta.exe}
>
>The osbsbeta.exe is the beta version.  The stable version allows you to set
>custom names for partitions, but I prefer the nice look of the beta version
>myself.  I'm not sure about the stable version, but the beta version
allows you
>to choose between having a set default or having the default be the 'last
used'
>OS.
>
>HTH.
>
>> Dennis
>
>---
>
>John Baldwin  -- http://members.freedomnet.com/~jbaldwin/
>PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc
>"Power Users Use the Power to Serve!"  -  http://www.freebsd.org
> 


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

Re: Changing Bootmgr display

[John Baldwin]

On 19-Jun-99 Dennis wrote:
> Will it allow you to
> 
> 1) specify which partitions appear on the menu (ie, eliminate
> non-bootables) and

Yes.

> 2) set the partition last selected to the default/active partition?

Yes.

> Dennis

Sorry if I wasn't clear enough earlier.

---

John Baldwin  -- http://members.freedomnet.com/~jbaldwin/
PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.freebsd.org


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

Re: SMP and Celerons...

[Warner Losh]

In message <87k8t0c6tp@dhcp9545042.columbus.rr.com> Shaun Rowland writes:
: Well there is kind of.  If you have a socket 370 adapter you can
: un-break it.  I am currently running dual Celeron 400's, and they
: truly fly on this box!  I can assure you it works without problems.

By "broke" people mean that the celerons do not have a cache
architecture that can efficiently handle SMP.  So rather than getting
close to a 2x (1.75) performance increase for 2 CPU, you get more like
1.5 or so due to cache coherency effects.  In the MP world, this is
really bad performance.  It will work, but it scales poorly.

I don't recall if this is due to reduce coherency functionality, or is 
just an artifact of cache sizes.  You really want to have 1M or so of
cache for CPUs in this class.

Warner


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

Re: SMP and Celerons...

[Warner Losh]

In message <87hfo4c6dj@dhcp9545042.columbus.rr.com> Shaun Rowland writes:
: Do you mean the ones that don't have cache or the ones that have 128Kb
: cache on the chip?  Is there that big of a hit of the cache is on the
: chip?  I have seen some benchmarks and the system I have seemed to
: keep up well with a dual PII 400.  I don't know how well it would
: scale though.

By broke, I mean that they don't scale well due to cache effects.  I
think it may just be a size thing, but it might also be a cache
coherency protocol ineffeciencies as well.  The articles I've seen
show that for typical workloads, people with two celerons were getting 
in the 1.5x range, while people with PIIs were getting 1.8x or so.

Warnr


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

Re: firewalling (Was Re: Introduction)

[Julian Elischer]

We use IPFW to great effect in the interjet

whatever we end up with had better have the same features or we can't use
it..

1/ simple to use programatic API
2/ Divert sockets are a MUST. We do a lot of our filtering in userland.
3/ The ability to branch the rules using 'skipto' (goto?) is used heavily
and the goto optimisations are very important to our performance.
4/ The 'fwd' facility is also very important.
5/ Line numbers are crucial to the way we control rules in the product.
6/ the ability to log but not halt processing of a packet is also crucial.
If you change the semantics of how rules interact, you could screw us.

Maybe you should look at what BSDI have..


A bpf based filter for link layer, and a separate IP layer filter..


Also look at the DPF code from MIT (in the exokernel).
If we are going to do a replacement we shouldn't junk ipfw for something 
of equivalent technology (ipf), but consider doing something like DPF
which is truely revolutionary. DPF generates att addition time,
Dynamically generated machine instructions for an optimal packet
classifier. When you add a rule, it re-writes the machine code..
there are ports for several architectures and it's very portable.
Making a tree of indivdually created DPF filters would lead to incredibly
high processing rates of very complicated rules.

If you are not going to go the whole hog, then better to leave things the
way they are (but with some cleaning). Security mechanisms are not the
things you want to futz with too much. WHile I agree that ipf
is "standard in NetBSD and OpenBSD, ipfw is closer to the Linux ipfw
and as such, it would be a better maketting plan to ether leave it as is
or move more towards what they do or leave it much as it is.. the others
are pretty irrelevant when it comes to market  and especially when
it comes to our share of it. After 23 years in this industry I've learned 
(it took a long time) that a working but not perfect feature is better
than a perfect one if the perfect one has marketting drawbacks.

The present system is real easy to understand and many people use it.
Think REAL HARD before removing it.
IPF can already beadded by those that want it.
Don't screw over the project in your eagerness to do good.

Having said that I know IPFW's weaknesses. Most of it comes from 
the fact that we are working "out of the correct layer" sometimes.
I'd LOVE to see a good DPF implementation

julian



On Fri, 18 Jun 1999, Brian Fundakowski Feldman wrote:

> On Sat, 19 Jun 1999, Darren Reed wrote:
> 
> > In some email I received from Brian Fundakowski Feldman, sie wrote:
> > > How do you feel about (after getting it fixed in -CURRENT) helping with
> > > converting ipfw(8) to just a front-end to ipf? I think it's worth 
> > > discussing
> > > whether it's actually worth it to rewrite IPFW or just work on improving
> > > ipfilter. (discussion moved to -hackers)
> > 
> > I imagine they might be fighting words to some ;)  As I see it, if you
> > added hooks for divert to ipfilter in FreeBSD and maybe added the rule
> > number bits (I *know* there are going to be people who'd just die without
> > it) then I can't see why you'd need ipfw.  I imagine that would be a hell
> > of a lot less work than bringing the features of ipfilter into ipfw.
> > 
> > It'd also be one of those steps forward in compatibility between the various
> > BSDs...
> 
>   Yes, and I know it might take some work. I'd like to have something good be
> the default in FreeBSD, and I feel that maybe if ipfilter can be brought
> to the foreground well and made backward compatible (i.e. ipfw(8) to translate
> (perl? /bin/sh? idunno)), it will be a winning thing. I'd of course like to
> add UID/GID support to ipfilter like I did to IPFW (but didn't commit).
>   IPFW is nearing the end of its maintainable life. It needs a pretty large
> rewrite or full replacement pretty soon. If we can get ipfilter in src/contrib
> kept up-to-date and working, supplying a replacement for ipfw(8) as a 
> front-end,
> I don't see why ipfilter can't be the "FreeBSD firewall."
> 
> 
> > 
> > Darren
> > 
> > 
> > To Unsubscribe: send mail to majord...@freebsd.org
> > with "unsubscribe freebsd-hackers" in the body of the message
> > 
> 
>  Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
>  gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
>  FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
>http://www.FreeBSD.org/  _ |___/___/___/ 
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 



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

Re: Introduction

[Julian Elischer]

On Sat, 19 Jun 1999, Brian F. Feldman wrote:

> On Sat, 19 Jun 1999, Doug Rabson wrote:
> 
> > On 19 Jun 1999, Dag-Erling Smorgrav wrote:
> > 
> > > "Brian F. Feldman"  writes:
> > > > It might be worth (discussion of) making ipfilter the firewall of
> > > > choice for 4.0. There would of course be rule conversion
> > > > scripts/programs (ipfw->ipf(5)), and ipfilter would be converted to
> > > > a KLD, cruft removed (I'm going to work on these), and ipfilter KLD
> > > > support (currently options IPFILTER_LKM) made a non-option. It seems
> > > > that our pretty proprietary ipfw is no longer a good idea.
> > > 
> > > If ipfilter can to everything ipfw can (judging from ipf(5), it can)
> > > and you even manage to keep an ipfw(8) command around so those who
> > > want kan keep using the old syntax still can, then I for one have no
> > > objections.
> > > 
> > > Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a
> > > simple Perl script should be sufficient.
> > 
> > Does ipfilter support divert sockets?
> 
> It still needs:
>   divert sockets
>   Luigi's stuff (dummynet and bridging)
>   my stuff

fwd stuff?

> 
> > 
> > --
> > Doug Rabson Mail:  d...@nlsystems.com
> > Nonlinear Systems Ltd.  Phone: +44 181 442 9037
> > 
> > 
> > 
> 
>  Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
>  gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
>  FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
>http://www.FreeBSD.org/  _ |___/___/___/ 
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 



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

Re: Firewalls (was Re: Introduction)

[Julian Elischer]

As a contributor to ipfw, notice that I will be sticking my oar into the
water when it comes to deleting it unless I'm very sure that the ipf stuff
is better. Unless you're Danish you don't just get to delete bits of the
tree without a lot of agreement, especially from those who are working on
it.. (in this case luigi and I would both be extrememly interested).


On Sat, 19 Jun 1999, Brian F. Feldman wrote:

> On 19 Jun 1999, Dag-Erling Smorgrav wrote:
> 
> > "Brian F. Feldman"  writes:
> > > It might be worth (discussion of) making ipfilter the firewall of
> > > choice for 4.0. There would of course be rule conversion
> > > scripts/programs (ipfw->ipf(5)), and ipfilter would be converted to
> > > a KLD, cruft removed (I'm going to work on these), and ipfilter KLD
> > > support (currently options IPFILTER_LKM) made a non-option. It seems
> > > that our pretty proprietary ipfw is no longer a good idea.
> > 
> > If ipfilter can to everything ipfw can (judging from ipf(5), it can)
> > and you even manage to keep an ipfw(8) command around so those who
> > want kan keep using the old syntax still can, then I for one have no
> > objections.
> > 
> > Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a
> > simple Perl script should be sufficient.
> 
> Not quite as trivial as you think. ipfw and ipf are completely backwards when 
> it comes
> to rule order: in ipfw, the first rule matched takes effect; in ipf, the last 
> rule matched
> takes effect. Plus, ipf doesn't have rule numbers (but there's similar 
> functionailty.)
> If you think you can get used to them both enough to tackle this, I'll handle 
> other
> things, and we can have a working replacement for crufty old ipfw. Note that 
> Luigi's
> extra ipfw functionality and my extra ipfw functionality _will_ be wanted in 
> ipf
> before everyone is necessarily willing to switch. I have a feeling there will 
> be some
> holdouts that, even if ipfw is removed, they'll MFS (merge from stable) ipfw 
> back just
> because they want to keep the old way. Ipfw could be dead for 4.0-RELEASE, as 
> I see it
> now. More discussion is, however, necessary.
> 
> > 
> > DES
> > -- 
> > Dag-Erling Smorgrav - d...@flood.ping.uio.no
> > 
> 
>  Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
>  gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
>  FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
>http://www.FreeBSD.org/  _ |___/___/___/ 
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 



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

Re: Firewalls (was Re: Introduction)

[Jordan K. Hubbard]

> is better. Unless you're Danish you don't just get to delete bits of the

s/Unless/Especially if/ :-)

- Jordan


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

Re: Introduction

[Brian F. Feldman]

It has "fwd stuff" :)

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: Firewalls (was Re: Introduction)

[Brian F. Feldman]

On Sat, 19 Jun 1999, Julian Elischer wrote:

> As a contributor to ipfw, notice that I will be sticking my oar into the
> water when it comes to deleting it unless I'm very sure that the ipf stuff
> is better. Unless you're Danish you don't just get to delete bits of the
> tree without a lot of agreement, especially from those who are working on
> it.. (in this case luigi and I would both be extrememly interested).

Deleting IPFW would be a _long_ time from now, if at all. What it looks
like now is:

1. making ipf and ipfw equivalent in functionality
2. cleaning up both
3. MAYBE starting a brand new firewall project

I wasn't planning on trying to rip something out from under anyone :)

> 
> 
> On Sat, 19 Jun 1999, Brian F. Feldman wrote:
> 
> > On 19 Jun 1999, Dag-Erling Smorgrav wrote:
> > 
> > > "Brian F. Feldman"  writes:
> > > > It might be worth (discussion of) making ipfilter the firewall of
> > > > choice for 4.0. There would of course be rule conversion
> > > > scripts/programs (ipfw->ipf(5)), and ipfilter would be converted to
> > > > a KLD, cruft removed (I'm going to work on these), and ipfilter KLD
> > > > support (currently options IPFILTER_LKM) made a non-option. It seems
> > > > that our pretty proprietary ipfw is no longer a good idea.
> > > 
> > > If ipfilter can to everything ipfw can (judging from ipf(5), it can)
> > > and you even manage to keep an ipfw(8) command around so those who
> > > want kan keep using the old syntax still can, then I for one have no
> > > objections.
> > > 
> > > Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a
> > > simple Perl script should be sufficient.
> > 
> > Not quite as trivial as you think. ipfw and ipf are completely backwards 
> > when it comes
> > to rule order: in ipfw, the first rule matched takes effect; in ipf, the 
> > last rule matched
> > takes effect. Plus, ipf doesn't have rule numbers (but there's similar 
> > functionailty.)
> > If you think you can get used to them both enough to tackle this, I'll 
> > handle other
> > things, and we can have a working replacement for crufty old ipfw. Note 
> > that Luigi's
> > extra ipfw functionality and my extra ipfw functionality _will_ be wanted 
> > in ipf
> > before everyone is necessarily willing to switch. I have a feeling there 
> > will be some
> > holdouts that, even if ipfw is removed, they'll MFS (merge from stable) 
> > ipfw back just
> > because they want to keep the old way. Ipfw could be dead for 4.0-RELEASE, 
> > as I see it
> > now. More discussion is, however, necessary.
> > 
> > > 
> > > DES
> > > -- 
> > > Dag-Erling Smorgrav - d...@flood.ping.uio.no
> > > 
> > 
> >  Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
> >  gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
> >  FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
> >http://www.FreeBSD.org/  _ |___/___/___/ 
> > 
> > 
> > 
> > To Unsubscribe: send mail to majord...@freebsd.org
> > with "unsubscribe freebsd-hackers" in the body of the message
> > 
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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