headers
Brad | 1 Aug 2004 06:04

hme NIC diffs

From NetBSD...

do not reset the chip (and subsequently the phy) when unnecessary; that is,
for address changes, multicast filter changes, or adjusting promiscuous mode.
Fixes resetting the phy for things like start/stopping tcpdump.

Please test.

// Brad

for the bus-independent driver..

Index: hme.c
===================================================================
RCS file: /cvs/src/sys/dev/ic/hme.c,v
retrieving revision 1.31
diff -u -p -r1.31 hme.c
--- hme.c	31 May 2004 01:51:30 -0000	1.31
+++ hme.c	31 Jul 2004 16:01:42 -0000
 <at>  <at>  -239,6 +239,7  <at>  <at>  hme_config(sc)
 	ifp->if_watchdog = hme_watchdog;
 	ifp->if_flags =
 	    IFF_BROADCAST | IFF_SIMPLEX | IFF_NOTRAILERS | IFF_MULTICAST;
+	sc->sc_if_flags = ifp->if_flags;
 	IFQ_SET_READY(&ifp->if_snd);
 	ifp->if_capabilities |= IFCAP_VLAN_MTU;

 <at>  <at>  -621,6 +622,7  <at>  <at>  hme_init(sc)

 	ifp->if_flags |= IFF_RUNNING;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Galbraith | 1 Aug 2004 16:40

DSL connections using ppp/pppoe, and netstart in /etc/rc

I've got my DSL connection to the world configured to start from my
hostname.if file via a "!ppp -background pppoe" command.  Maybe that's not
the Right Way, but it seems clean to me.  

Unfortunately, /etc/rc blows away the PPP pid file (/var/run/tun0.pid) soon
after running netstart.  Is there any chance this could be changed so that
processes started from netstart won't have their pid files trashed?  Or
maybe someone could tell me a Better way to start my DSL connection?
Cheers,

Paul
Permalink | Reply | 2 comments |
headers
Chris Zakelj | 1 Aug 2004 18:22
Picon

Re: DSL connections using ppp/pppoe, and netstart in /etc/rc

This would have been better off in misc <at> , but since it's here, a little 
bit of Googling will show you an easier way.  Hints... hostname.if 
contains a single word, -background isn't the option you want to feed 
ppp, and you'll start it out of rc.local.

Paul Galbraith wrote:

>I've got my DSL connection to the world configured to start from my
>hostname.if file via a "!ppp -background pppoe" command.  Maybe that's not
>the Right Way, but it seems clean to me.  
>
>Unfortunately, /etc/rc blows away the PPP pid file (/var/run/tun0.pid) soon
>after running netstart.  Is there any chance this could be changed so that
>processes started from netstart won't have their pid files trashed?  Or
>maybe someone could tell me a Better way to start my DSL connection?
>Cheers,
Permalink | Reply | 1 comment |
headers
Erblichs | 1 Aug 2004 19:26
Picon
Favicon

Re: hme NIC diffs

Wow,

	The hme driver is a 10/100Mb Eth driver from
	Sun Microsystems...

	This looks like code that was developed at
	Sun..

	Have all the Sun IP restrictions been lifted
	that the code can be used with a OS other than
	Solaris??

	Mitchell Erblich
	Former owner of a few Eth drivers including
	hme while at Sun Microsystems..
	------------------------------------

Brad wrote:
> 
> >From NetBSD...
> 
> do not reset the chip (and subsequently the phy) when unnecessary; that is,
> for address changes, multicast filter changes, or adjusting promiscuous mode.
> Fixes resetting the phy for things like start/stopping tcpdump.
> 
> Please test.
> 
> // Brad
> 
> for the bus-independent driver..
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Shalayeff | 3 Aug 2004 03:18
Gravatar

fxp interrupts coalescing

re
here is a diff that implemets interrupts coalescing
on 82558 and later chips. it loads a microcode
that sets the parameters (a msg printed into dmesg).
the default max delay for an interrupt after first
packet received is 64ms and max number of packets
to accumulate before generating an interrupt is 16.
any packets smaller than 128 bytes will be reported
immidiately w/o any delays (for tcp acks and stuff).

please test before and after and see if any particular
troubles arise (such as slower tcp).
the number of interrupts (on ping -f -s128) shall
decrease and interrupt time (in top) go down as well.
revision 1 chips do not support it.

the code came from freebsd w/ hacking by dmitry bogdan and meself...

10x
cu
--

-- 
    paranoic mickey       (my employers have changed but, the name has remained)

Index: cardbus/if_fxp_cardbus.c
===================================================================
RCS file: /cvs/src/sys/dev/cardbus/if_fxp_cardbus.c,v
retrieving revision 1.7
diff -u -u -b -w -r1.7 if_fxp_cardbus.c
--- cardbus/if_fxp_cardbus.c	27 Jun 2004 02:38:37 -0000	1.7
+++ cardbus/if_fxp_cardbus.c	31 Jul 2004 19:16:12 -0000
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Galbraith | 1 Aug 2004 18:51

Re: DSL connections using ppp/pppoe, and netstart in /etc/rc

That could be, I've seen other methods that start ppp out of rc.local and
delay the startup of pf and start it from rc.local as well...not sure if
that's what you're suggesting, but if it is, I prefer to leave pf to startup
in the normal sequence laid out in /etc/rc.

And if you're suggesting using -ddial instead of -background, I don't like
that either because it has been unreliable in re-establishing dead
connections.  I prefer to use -background and use another method to monitor
the ppp process and restart if necessary.

But, since you're not willing to be more specific about what you think is a
better method, I can't be certain that's what you're talking about at all.

----- Original Message ----- 
From: "Chris Zakelj" <c.zakelj <at> ieee.org>
To: "Paul Galbraith" <paul <at> paulgalbraith.net>
Cc: <tech <at> openbsd.org>
Sent: Sunday, August 01, 2004 12:22 PM
Subject: Re: DSL connections using ppp/pppoe, and netstart in /etc/rc

> This would have been better off in misc <at> , but since it's here, a little
> bit of Googling will show you an easier way.  Hints... hostname.if
> contains a single word, -background isn't the option you want to feed
> ppp, and you'll start it out of rc.local.
>
> Paul Galbraith wrote:
>
> >I've got my DSL connection to the world configured to start from my
> >hostname.if file via a "!ppp -background pppoe" command.  Maybe that's
not
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Eggleston | 3 Aug 2004 07:35

HFSC / PF limit of 62 / scaling questions

I am looking for a way to rate limit thousands (preferably in the low
thousands at least) of customers to the Internet using OpenBSD.  The best
way I have found so far is HFSC, due to its apparent ability (as much as I
can gather) to overcommit bandwidth with a limit (upperlimit) as opposed to
cbq's general "borrow" idea, and guarantee a minimum throughput.

It became apparent that HFSC is limited to 62 queues per interface, at least
at the top level.  Is there any way to change that?

I have included a sample PF file that classifies traffic from customers into
queues, and also a script to generate a config with up to 16K customers.
Unless it's a simple question (for which I'd appreciate a simple answer),
I'd like to have a discussion about it and also offer any coding assistance
if necessary.  Algorithmically, nothing hits me as to how this wouldn't be
possible to do in software.  It just requires someone interested :)

As it stands, the scaling for the PF rules for classifying the traffic could
be improved by grouping by class C and using anchors, similar to a hash
table with existing functionality in pf, but I didn't put that into the
example below.

I'm essentially trying to use OpenBSD as a Packeteer.  I don't subscribe to
tech <at> openbsd.org, so please CC me on any replies.

problem:
# /home/jason/altqtest.py 63 em0 em1 > pf.conf
# pfctl -f pf.conf
pfctl: DIOCADDALTQ: Cannot allocate memory
# /home/jason/altqtest.py 62 em0 em1 > pf.conf 
# pfctl -f pf.conf
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michal Ludvig | 3 Aug 2004 15:36
Picon
Favicon

/dev/crypto

Hi all,

could anyone please explain (or give some links) why the "unusual"
semantics of /dev/crypto usage was chosen?

I don't really understand why it is necessary to first open the device and
obtain a file descriptor and then issue an ioctl(CRIOGET) to get another
one for the actual crypto operations. Why is this approach better that
opening the device everytime it is needed?

Thanks!

Michal Ludvig
--

-- 
* A mouse is a device used to point at the xterm you want to type in.
* Personal homepage - http://www.logix.cz/michal
Permalink | Reply | 3 comments |
headers
Paul Galbraith | 3 Aug 2004 15:56

Re: DSL connections using ppp/pppoe, and netstart in /etc/rc

RZR wrote:
> /etc/rc.local
> ...
> ###ADSL-STARTUP###
> 
> if [ -f /etc/ppp/adsl.sh ]; then
>         ./etc/ppp/adsl.sh; echo ' Starting ADSL...'
> fi
> ...
> 
> $ sudo cat /etc/ppp/adsl.sh
> #!/bin/sh
> ifconfig dc0 up
> ppp -ddial pppoe

That might be fine for someones workstation and a different ISP from 
mine, but -ddial is unreliable for me and I often need to manually kill 
the connection and restart it.  Running PPP with -background and 
restarting the process when the connection goes down has (so far) been 
much more reliable for me, and since this box is an hour drive away for 
me, that's critical.  Maybe things have changed a bit since the last 
time I tried it your way, but aren't you also starting pf from rc.local 
as well?

Regardless, for me, I'd like to see /etc/rc changed to move the /var/run 
cleanup code above the call to netstart, or vice versa.  Since someone's 
gone to some effort to preserve the dhclient.pid file, however, it seems 
that there may be a good reason not to do so, or maybe that's just a 
clue that supports my suggestion?  Having spent some time searching, and 
not finding any answers, I'm asking here if it makes sense to be changed.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Theo de Raadt | 3 Aug 2004 18:21
Picon
Favicon

Re: /dev/crypto

> could anyone please explain (or give some links) why the "unusual"
> semantics of /dev/crypto usage was chosen?
> 
> I don't really understand why it is necessary to first open the device and
> obtain a file descriptor and then issue an ioctl(CRIOGET) to get another
> one for the actual crypto operations.

Lack of cloning device nodes.

> Why is this approach better that
> opening the device everytime it is needed?

Oh, that would be very silly and not work.  Most crypto hardware
devices maintain state.
Permalink | Reply | 2 comments |

Gmane