Re: Help with some makefile hackery

[Brian Somers]

On Fri, 25 Jun 2010 05:57:24 -0700 Patrick Mahan  wrote:
> src-kernel: src-kernel-tools
>   cd src; ./amd64-kernel.sh 2>&1 | tee build_amd64_kernel.log

I've had the same issue teeing make output for coverage measurements.
A better way to write this might be

src-kernel: src-kernel-tools
rm -f src-kernel-done
{ cd src; ./amd64-kernel.sh 2>&1 && touch src-kernel-done; } | tee 
build_amd64_kernel.log
rm src-kernel-done

You really want to catch all failures, including tee failures.

-- 
Brian Somers  
Don't _EVER_ lose your sense of humour !   
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: NFSD lockup running ESXi 4

[Brian Somers]

On Wed,  9 Jun 2010 13:52:40 -0400 (EDT) r...@akira.stdio.com wrote:
> I have an AMD64 FreeBSD 8.0 running 8-Stable from around 2010/04/25 19:13:08.
> 
> ZFS disk, Nfsd flags "-t -n 16", private network exclusive for nfs network,
> not using jumbo frames, HZ=1000, Device_Polling, Zero_Copy_Sockets, and the
> following sysctl options:
> net.inet.tcp.recvspace=232140
> net.inet.tcp.sendspace=232140
> net.inet.tcp.slowstart_flightsize=159
> net.inet.tcp.mssdflt=1460
> 
> FreeBSD 6 TB zpool, nfs from Three ESXi 4 (newest patch level 193498)
> working reliably for months.
> 
> Added a new ESXi, patched to the newest (Post Update 1) patch level 256968.
> Added a bunch of VM's, booted them all into the 2008 R2 Server install DVD.
> Then when attempting to do the installs (in parallel/simultaneously) I started
> getting the NFS server locking up.  NFSD would wedge at 100% CPU in "rc_lo"
> which I presume is rc_lock?  Once wedged, /etc/rc.d/nfsd restart can't kill
> nfsd.  So a reboot is required.  A Reboot causes all my active VM's with
> pending disk writes to have disk errors in the VM (10 second default timeout
> for disk writes in the VM.)  This was very reproducable.
> 
> Has anyone noticed this problem?  Is this an ESXi problem with the newest
> updates?  Is this a problem with NFS on FreeBSD 8?

I don't know if it's relevant, but I've been having nfs issues on -current.
I believe they were caused by gam_server, a gnome program running on an
NFS client machine that had /usr/ports nfs mounted and was doing a portupgrade.
Nothing gnomeish should have been anywhere near /usr/ports, but analysis
showed huge numbers of NFS stats against /usr/ports/distfiles/*, restat'ing
the same files over and over.  nfsd was going crazy on the server and
gam_server was clocking up wads of CPU time on the client.

FreeBSD-9 kernels prior to around June 6 were freezing on me.  It may have
been because of the nfsd activity, but I didn't investigate the freeze...

Perhaps looking for changes that might might affect nfsd stability in the week
prior to June 6 might discover a fix?

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


signature.asc
Description: PGP signature

Re: head behaviour

[Brian Somers]

On Mon, 07 Jun 2010 13:05:48 +0200, Dag-Erling Smørgrav  wrote:
> Bakul Shah  writes:
> > Except read doesn't do it quite right:
> >
> > $ ps | (read a; echo $a ; grep zsh)
> > PID  TT  STAT  TIME COMMAND
> 
> yeah, I forgot that it drops leading whitespace...

Well, leading $IFS

$ ps | (IFS= read a; echo "$a"; grep zsh)

works a lot better.

-- 
Brian Somers   
Don't _EVER_ lose your sense of humour !
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Deprecating ps(1)s -w switch

[Brian Somers]

On Tue, 25 Aug 2009 03:40:54 -0700 Brian Somers  wrote:
> I recently closed bin/137647 and had second thoughts after Ivan (the
> originator) challenged my reason for closing it.
> 
> The suggestion is that ps's -w switch is a strange artifact that can
> be safely deprecated.  ps goes to great lengths to implement width
> limitations, and any time I've seen people not using -ww has either
> been a mistake or doesn't matter.  Using 'cut -c1-N' is also a great
> way of limiting widths if people really want that...
> 
> I'd like to propose changing ps so that width limits are removed and
> '-w' is deprecated - ignored for now with a note in the man page
> saying that it will be removed in a future release.
> 
> Does anyone have any objections to doing this?  I don't propose
> merging this back into stable/8.

To clarify, my proposal is to silently ignore the -w switch (any/all of them)
and to remove the code that reads the terminal width and truncates some
columns based on the result (or based on "132").

The pros:

- ps's code becomes simpler.  It was mentioned that the ps code is
  a minefield.  This would remove a few mines.
- ps IMHO has no business knowing about terminal widths (and where
  did the 132 column -w idea come from again?).  Some programs such
  as iostat have similar (but way more broken) behaviour however whilst
  others such as ls do not.
- We remove the sizing bugs (only some columns are truncation victims).

The cons:

- people with visual expectations would have to learn to use less -S or some
  similar tool.  This breaks POLA.
- Scripts may exist that depend on the behaviour without -w.  Furthermore
  having to handle ps from both before and after such a change in one
  script can be painful.

It was also suggested that rather than changing the behaviour of one
flavour of ps it would be better to adopt an approach more like linux's
or even implementing POSIXs suggestions.  AFAIK the linux suggestion
has been on the table for more time than I care to remember (wasn't
Brett Glass going to provide a patch soon?).  Although I haven't read
the linux code, I'm pretty sure it's a scary place - perhaps this is the
reason that we don't have those patches yet.


Unless others have more to say on the subject, I think it's clear that
the most popular vote is to do nothing.  I think this is a shame as I
find the pros more compelling than the cons, and I'm sure there are
more than a few supporters out there on hackers@ that will stay
silent.

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


signature.asc
Description: PGP signature

Deprecating ps(1)s -w switch

[Brian Somers]

I recently closed bin/137647 and had second thoughts after Ivan (the
originator) challenged my reason for closing it.

The suggestion is that ps's -w switch is a strange artifact that can
be safely deprecated.  ps goes to great lengths to implement width
limitations, and any time I've seen people not using -ww has either
been a mistake or doesn't matter.  Using 'cut -c1-N' is also a great
way of limiting widths if people really want that...

I'd like to propose changing ps so that width limits are removed and
'-w' is deprecated - ignored for now with a note in the man page
saying that it will be removed in a future release.

Does anyone have any objections to doing this?  I don't propose
merging this back into stable/8.

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


signature.asc
Description: PGP signature

Re: kernel panics in in_lltable_lookup (with INVARIANTS)

[Brian Somers]

On Fri, 21 Aug 2009 21:55:03 -0700 Brian Somers  wrote:
> On Fri, 21 Aug 2009 17:13:45 -0700 Kip Macy  wrote:
> > Try this:
> > 
> > Index: sys/net/flowtable.c
> > ===
> > --- sys/net/flowtable.c (revision 196382)
> > +++ sys/net/flowtable.c (working copy)
> > @@ -688,6 +688,12 @@
> > struct rtentry *rt = ro->ro_rt;
> > struct ifnet *ifp = rt->rt_ifp;
> > 
> > +   if (ifp->if_flags & IFF_POINTOPOINT) {
> > +   RTFREE(rt);
> > +   ro->ro_rt = NULL;
> > +   return (ENOENT);
> > +   }
> > +
> > if (rt->rt_flags & RTF_GATEWAY)
> > l3addr = rt->rt_gateway;
> > else
> > 
> > You'll need to apply this by hand as gmail munges the formatting.
> > 
> > -Kip
> 
> Hi,
> 
> That certainly stops the panic, however data routed to the tun
> interface doesn't come out the back end and data written
> to the back end doesn't come out the tun interface.
[.]
> Maybe this problem isn't a routing problem.  I'll
> look into it further and figure out if the packet is getting to the tun
> driver and if so, what it thinks it's doing with it.

I wasn't correct - the data *IS* being read out of the back of
the tunnel device.  When I send the ICMP, it goes into the tun
device and comes out the back end as an AF_LINK packet.  ppp
silently discards this (ironically I have a comment noting
that I should really track unidentified packet counts).

I'll try to figure out what in if_tun.c is corrupting the family next...

Cheers.

> > On Fri, Aug 21, 2009 at 16:43, Brian Somers wrote:
> > > Hi,
> > >
> > > I've been working on a fix to address an issue that came up with
> > > our update of openssh-5.  The issue is that openssh-5 now uses
> > > pipe() to create stdin/stdout channels between sshd and the server
> > > side program where it used to use socketpair().  Because it uses
> > > pipe(), stdin is no longer bi-directional and cannot be used for both
> > > input and output by a child process.  This breaks the use of ssh
> > > as a tunnel with ppp on either end (set device "!ssh -e none host
> > > ppp -direct label")
> > >
> > > I talked with des@ for a while and then with the openssh folks and
> > > have not been able to resolve the issues in openssh that made them
> > > choose to enforce the use of pipe() over socketpair().  I now have a
> > > patch to ppp that makes ppp detect that it's connected via pipe() and
> > > causes it to use stdin for input and stdout for output (usually it expects
> > > just one descriptor).  Although I'm happy with the patch and planned on
> > > requesting permission to commit, I've bumped into a show-stopper
> > > that seems unrelated, so I thought I'd ask here if anyone has seen
> > > this or has any suggestions as to what the problem might be.
> > >
> > > The issue
> > >
> > > I'm seeing a panic when I send traffic through a ppp link:
> > >
> > > panic string is: sin_family 18
> > > Stack trace starts:
> > >    in_lltable_lookup()
> > >    llentry_update()
> > >    flowtable_lookup()
> > >    ip_output()
> > >    
> > >
> > > The panic is due to a KASSERT in in_lltable_lookup() that expects the
> > > sockaddr to be AF_INET.  Number 18 is AF_LINK.
> > >
> > > AFAICT this is happening while setting up a temporary route for the
> > > first outbound packet.  I haven't been able to do much investigation
> > > yet due to other patches in my tree that seem to have broken all my
> > > kernel symbols, but once I get a clean rebuild I should be back in
> > > business.
> > >
> > > If anyone has any suggestions, I'm all ears!
> > >
> > > Cheers.

-- 
Brian Somers  
Don't _EVER_ lose your sense of humour !   
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: kernel panics in in_lltable_lookup (with INVARIANTS)

[Brian Somers]

On Fri, 21 Aug 2009 23:23:13 -0700 Brian Somers  wrote:
> On Fri, 21 Aug 2009 22:41:34 -0700 Brian Somers  wrote:
> > On Fri, 21 Aug 2009 21:55:03 -0700 Brian Somers  wrote:
> > > On Fri, 21 Aug 2009 17:13:45 -0700 Kip Macy  wrote:
> > > > Try this:
> > > > 
> > > > Index: sys/net/flowtable.c
> > > > ===
> > > > --- sys/net/flowtable.c (revision 196382)
> > > > +++ sys/net/flowtable.c (working copy)
> > > > @@ -688,6 +688,12 @@
> > > > struct rtentry *rt = ro->ro_rt;
> > > > struct ifnet *ifp = rt->rt_ifp;
> > > > 
> > > > +   if (ifp->if_flags & IFF_POINTOPOINT) {
> > > > +   RTFREE(rt);
> > > > +   ro->ro_rt = NULL;
> > > > +   return (ENOENT);
> > > > +   }
> > > > +
> > > > if (rt->rt_flags & RTF_GATEWAY)
> > > > l3addr = rt->rt_gateway;
> > > > else
> > > > 
> > > > You'll need to apply this by hand as gmail munges the formatting.
> > > > 
> > > > -Kip
> > > 
> > > Hi,
> > > 
> > > That certainly stops the panic, however data routed to the tun
> > > interface doesn't come out the back end and data written
> > > to the back end doesn't come out the tun interface.
> > [.]
> > > Maybe this problem isn't a routing problem.  I'll
> > > look into it further and figure out if the packet is getting to the tun
> > > driver and if so, what it thinks it's doing with it.
> > 
> > I wasn't correct - the data *IS* being read out of the back of
> > the tunnel device.  When I send the ICMP, it goes into the tun
> > device and comes out the back end as an AF_LINK packet.  ppp
> > silently discards this (ironically I have a comment noting
> > that I should really track unidentified packet counts).
> > 
> > I'll try to figure out what in if_tun.c is corrupting the family next...
> 
> if_tun.c is fine.  The data passed from if_output() has family
> AF_LINK - hence the original panic from flowtable_lookup().
> 
> So the question is "why is ip_output() sending AF_LINK traffic
> instead of AF_INET traffic?".
> 
> Still looking

From what I can tell, this is what is happening:

ip_output() is called with ro == NULL.
ip_output() calls flowtable_lookup() with a zeroed 'ro'.
flowtable_lookup() calls ft->ft_rtalloc() (really rtalloc1_fib()) to
initialise 'ro' and ends up with ro->ro_rt->rt_gateway->sa_family
set to AF_LINK.

Your original patch frees ro->ro_rt and fails before calling
llentry_update() with ro->ro_rt->rt_gateway->sa_family !=
AF_INET.

Now, when flowtable_lookup() fails, ro->ro_rt is NULL and
ip_output()s 'dst' gets set up with family AF_INET.  Unfortunately,
right after this, after checking for IP_SENDONES, IP_ROUTETOIF
and IN_MULTICAST, the ip_output() code decides to call
in_rtalloc_ign() (which eventually just calls rtalloc1_fib()) to
initialise ro->ro_rt and then sets dst to be ro->ro_rt->rt_gateway
-- which is *still* an AF_LINK address!

Finally ip_output() calls ifp->if_output() (really tunoutput()) with
dst's family set to AF_LINK, tunoutput() queues it to the tun
character device, ppp reads it and drops it on the floor 'cos it
doesn't know what to do with AF_LINK.

The tun driver is more or less the same as the -stable version,
so it seems that ip_output() is to blame.  The only relevant part
that seems substantially different is rtalloc1_fib(), so right now
I'm guessing that the RTF_CLONING code in -stable always
clones the route with a gw family of AF_INET and expectations
are met after that.

I'll look some more on the weekend...

> > > > On Fri, Aug 21, 2009 at 16:43, Brian Somers wrote:
> > > > > Hi,
> > > > >
> > > > > I've been working on a fix to address an issue that came up with
> > > > > our update of openssh-5.  The issue is that openssh-5 now uses
> > > > > pipe() to create stdin/stdout channels between sshd and the server
> > > > > side program where it used to use socketpair().  Because it uses
> > > > > pipe(), stdin is no longer bi-directional and cannot be used for both
> > > > > input and output by a child process.  This breaks the use of ssh
> > > > > as a tunnel with ppp on eith

Re: kernel panics in in_lltable_lookup (with INVARIANTS)

[Brian Somers]

On Fri, 21 Aug 2009 22:41:34 -0700 Brian Somers  wrote:
> On Fri, 21 Aug 2009 21:55:03 -0700 Brian Somers  wrote:
> > On Fri, 21 Aug 2009 17:13:45 -0700 Kip Macy  wrote:
> > > Try this:
> > > 
> > > Index: sys/net/flowtable.c
> > > ===
> > > --- sys/net/flowtable.c (revision 196382)
> > > +++ sys/net/flowtable.c (working copy)
> > > @@ -688,6 +688,12 @@
> > > struct rtentry *rt = ro->ro_rt;
> > > struct ifnet *ifp = rt->rt_ifp;
> > > 
> > > +   if (ifp->if_flags & IFF_POINTOPOINT) {
> > > +   RTFREE(rt);
> > > +   ro->ro_rt = NULL;
> > > +   return (ENOENT);
> > > +   }
> > > +
> > > if (rt->rt_flags & RTF_GATEWAY)
> > > l3addr = rt->rt_gateway;
> > > else
> > > 
> > > You'll need to apply this by hand as gmail munges the formatting.
> > > 
> > > -Kip
> > 
> > Hi,
> > 
> > That certainly stops the panic, however data routed to the tun
> > interface doesn't come out the back end and data written
> > to the back end doesn't come out the tun interface.
> [.]
> > Maybe this problem isn't a routing problem.  I'll
> > look into it further and figure out if the packet is getting to the tun
> > driver and if so, what it thinks it's doing with it.
> 
> I wasn't correct - the data *IS* being read out of the back of
> the tunnel device.  When I send the ICMP, it goes into the tun
> device and comes out the back end as an AF_LINK packet.  ppp
> silently discards this (ironically I have a comment noting
> that I should really track unidentified packet counts).
> 
> I'll try to figure out what in if_tun.c is corrupting the family next...

if_tun.c is fine.  The data passed from if_output() has family
AF_LINK - hence the original panic from flowtable_lookup().

So the question is "why is ip_output() sending AF_LINK traffic
instead of AF_INET traffic?".

Still looking

> > > On Fri, Aug 21, 2009 at 16:43, Brian Somers wrote:
> > > > Hi,
> > > >
> > > > I've been working on a fix to address an issue that came up with
> > > > our update of openssh-5.  The issue is that openssh-5 now uses
> > > > pipe() to create stdin/stdout channels between sshd and the server
> > > > side program where it used to use socketpair().  Because it uses
> > > > pipe(), stdin is no longer bi-directional and cannot be used for both
> > > > input and output by a child process.  This breaks the use of ssh
> > > > as a tunnel with ppp on either end (set device "!ssh -e none host
> > > > ppp -direct label")
> > > >
> > > > I talked with des@ for a while and then with the openssh folks and
> > > > have not been able to resolve the issues in openssh that made them
> > > > choose to enforce the use of pipe() over socketpair().  I now have a
> > > > patch to ppp that makes ppp detect that it's connected via pipe() and
> > > > causes it to use stdin for input and stdout for output (usually it 
> > > > expects
> > > > just one descriptor).  Although I'm happy with the patch and planned on
> > > > requesting permission to commit, I've bumped into a show-stopper
> > > > that seems unrelated, so I thought I'd ask here if anyone has seen
> > > > this or has any suggestions as to what the problem might be.
> > > >
> > > > The issue
> > > >
> > > > I'm seeing a panic when I send traffic through a ppp link:
> > > >
> > > > panic string is: sin_family 18
> > > > Stack trace starts:
> > > >    in_lltable_lookup()
> > > >    llentry_update()
> > > >    flowtable_lookup()
> > > >    ip_output()
> > > >    
> > > >
> > > > The panic is due to a KASSERT in in_lltable_lookup() that expects the
> > > > sockaddr to be AF_INET.  Number 18 is AF_LINK.
> > > >
> > > > AFAICT this is happening while setting up a temporary route for the
> > > > first outbound packet.  I haven't been able to do much investigation
> > > > yet due to other patches in my tree that seem to have broken all my
> > > > kernel symbols, but once I get a clean rebuild I should be back in
> > > > business.
> > > >
> > > > If anyone has any suggestions, I'm all ears!
> > > >
> > > > Cheers.

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


signature.asc
Description: PGP signature

Re: kernel panics in in_lltable_lookup (with INVARIANTS)

[Brian Somers]

On Fri, 21 Aug 2009 17:13:45 -0700 Kip Macy  wrote:
> Try this:
> 
> Index: sys/net/flowtable.c
> ===
> --- sys/net/flowtable.c (revision 196382)
> +++ sys/net/flowtable.c (working copy)
> @@ -688,6 +688,12 @@
> struct rtentry *rt = ro->ro_rt;
> struct ifnet *ifp = rt->rt_ifp;
> 
> +   if (ifp->if_flags & IFF_POINTOPOINT) {
> +   RTFREE(rt);
> +   ro->ro_rt = NULL;
> +   return (ENOENT);
> +   }
> +
> if (rt->rt_flags & RTF_GATEWAY)
> l3addr = rt->rt_gateway;
> else
> 
> You'll need to apply this by hand as gmail munges the formatting.
> 
> -Kip

Hi,

That certainly stops the panic, however data routed to the tun
interface doesn't come out the back end and data written
to the back end doesn't come out the tun interface.

After connecting a 7-stable and a -current box, I get this sending
a ping packet from the stable box:

-stable:
TCP/IP: OUT ICMP: 172.16.1.22:8 ---> 172.16.1.20 (36/84)
Physical: write
Physical:  7e 3d c0 1c fd 00 12 02 1b 3a c1 1c 64 e8 04 75  ~=...:..d..u
Physical:  84 a1 93 62 d5 e2 c1 86 1e 63 60 9a f4 82 54 43  ...b.c`...TC
Physical:  01 00 70 7c 7e   ..p|~

meaning that ppp sees the ICMP when it reads the back of the
tun interface, and writes the encapsulated data to its physical
link (the "other end").

-current:
Physical: read
Physical:  7e 3d c0 1c fd 00 12 02 1b 3a c1 1c 64 e8 04 75  ~=...:..d..u
Physical:  84 a1 93 62 d5 e2 c1 86 1e 63 60 9a f4 82 54 43  ...b.c`...TC
Physical:  01 00 70 7c 7e   ..p|~
TCP/IP: IN ICMP: 172.16.1.22:8 ---> 172.16.1.20 (36/84)

meaning that ppp reads data from the physical link, decapsulates
it and writes an ICMP to the back of the tun interface.

Then nothing (no ICMP reply).  Sending an icmp from the -current
box doesn't wake ppp at all.

On the -stable box:
br...@gw ~ $ ifconfig tun0
tun0: flags=8051 metric 0 mtu 1540
inet6 fe80::240:f4ff:feb1:1c85%tun0 prefixlen 64 scopeid 0x6 
inet 172.16.1.22 --> 172.16.1.20 netmask 0x 
Opened by PID 89468
br...@gw ~ $ route get 172.16.1.20
   route to: 172.16.1.20
destination: 172.16.1.20
gateway: 172.16.1.22
  interface: tun0
  flags: 
 recvpipe  sendpipe  ssthresh  rtt,msecrttvar  hopcount  mtu expire
   0 0 0 0 0 01540 
0 

and on the -current box:
br...@dev ~ $ ifconfig tun0
tun0: flags=8051 metric 0 mtu 1540
inet 172.16.1.20 --> 172.16.1.22 netmask 0x 
inet6 fe80::240:f4ff:feb1:10da%tun0 prefixlen 64 scopeid 0x7 
Opened by PID 1647
br...@dev ~ $ route get 172.16.1.22
   route to: 172.16.1.22
destination: 172.16.1.22
gateway: 
  interface: tun0
  flags: 
 recvpipe  sendpipe  ssthresh  rtt,msecmtuweightexpire
   0 0 0 0  1540 1 0 

According to ``netstat -I tun0'', Opkts is increasing when I send from
the -current box, although netstat -s doesn't seem to see any more
icmps.  Maybe this problem isn't a routing problem.  I'll
look into it further and figure out if the packet is getting to the tun
driver and if so, what it thinks it's doing with it.

Thanks.

> On Fri, Aug 21, 2009 at 16:43, Brian Somers wrote:
> > Hi,
> >
> > I've been working on a fix to address an issue that came up with
> > our update of openssh-5.  The issue is that openssh-5 now uses
> > pipe() to create stdin/stdout channels between sshd and the server
> > side program where it used to use socketpair().  Because it uses
> > pipe(), stdin is no longer bi-directional and cannot be used for both
> > input and output by a child process.  This breaks the use of ssh
> > as a tunnel with ppp on either end (set device "!ssh -e none host
> > ppp -direct label")
> >
> > I talked with des@ for a while and then with the openssh folks and
> > have not been able to resolve the issues in openssh that made them
> > choose to enforce the use of pipe() over socketpair().  I now have a
> > patch to ppp that makes ppp detect that it's connected via pipe() and
> > causes it to use stdin for input and stdout for output (usually it expects
> > just one descriptor).  Although I'm happy with the patch and planned on
> > requesting permission to commit, I've bumped into a show-stopper
> > that seems unrelated, so I thought I'd ask here if anyone has seen
> > this or has any suggestions as to what the problem might be.

kernel panics in in_lltable_lookup (with INVARIANTS)

[Brian Somers]

Hi,

I've been working on a fix to address an issue that came up with
our update of openssh-5.  The issue is that openssh-5 now uses
pipe() to create stdin/stdout channels between sshd and the server
side program where it used to use socketpair().  Because it uses
pipe(), stdin is no longer bi-directional and cannot be used for both
input and output by a child process.  This breaks the use of ssh
as a tunnel with ppp on either end (set device "!ssh -e none host
ppp -direct label")

I talked with des@ for a while and then with the openssh folks and
have not been able to resolve the issues in openssh that made them
choose to enforce the use of pipe() over socketpair().  I now have a
patch to ppp that makes ppp detect that it's connected via pipe() and
causes it to use stdin for input and stdout for output (usually it expects
just one descriptor).  Although I'm happy with the patch and planned on
requesting permission to commit, I've bumped into a show-stopper
that seems unrelated, so I thought I'd ask here if anyone has seen
this or has any suggestions as to what the problem might be.

The issue

I'm seeing a panic when I send traffic through a ppp link:

panic string is: sin_family 18
Stack trace starts:
in_lltable_lookup()
llentry_update()
flowtable_lookup()
ip_output()


The panic is due to a KASSERT in in_lltable_lookup() that expects the
sockaddr to be AF_INET.  Number 18 is AF_LINK.

AFAICT this is happening while setting up a temporary route for the
first outbound packet.  I haven't been able to do much investigation
yet due to other patches in my tree that seem to have broken all my
kernel symbols, but once I get a clean rebuild I should be back in
business.

If anyone has any suggestions, I'm all ears!

Cheers.

-- 
Brian Somers  
Don't _EVER_ lose your sense of humour !   
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: How to signal a time zone change?

[Brian Somers]

On Fri, 7 Aug 2009 15:08:16 -0700 "Peter Steele" 
 wrote:
> >What's the value of the TZ environment variable for the C apps? You may
> need to have them read the new value from somewhere, and then rerun
> tzset().
> 
> The default value of the TZ environment variable is null. I just tried
> passing the explicitly time zone value to the C app and setting TZ to
> that value and that seemed to work. I would think that that I should be
> able to retrieve that value from /etc/localtime as the docs imply. Guess
> not. If I have to pass the time zone to the C app, then I guess that's
> what I'll do...

This doesn't work because of two bugs in localtime.c.  The first is what
you're hitting where tzset() calls tzset_basic() which calls tzsetwall_basic()
which says:

if (lcl_is_set < 0) {
if (!rdlocked)
_RWLOCK_UNLOCK(&lcl_rwlock);
return;
}

If you were to have your own TZ setting and wanted to modify the
file referred to by that, you'd bump into this bug in tzset_basic():

if (lcl_is_set > 0 && strcmp(lcl_TZname, name) == 0) {
if (!rdlocked)
_RWLOCK_UNLOCK(&lcl_rwlock);
return;
}

Roughly translated, localtime.c goes out of its way to never re-read the
same zone file twice in a row.  This is just a mistake.

As you discovered, altering TZ before calling tzset() is the best way to
make it work right now.  If you really want to ensure that you're reading
/etc/localtime, this bit of hackery works too:

putenv("TZ=/dev/null");
tzset();
unsetenv("TZ");
tzset();

If you raise a PR and let me know the number, I'd be happy to fix this.


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


signature.asc
Description: PGP signature

Re: can we afford an extra column in iostat?

[Brian Somers]

On Tue, 14 Jul 2009 07:23:12 +0300, Giorgos Keramidas  
wrote:
> While converting my laptop's main disk to zfs, I noticed iostat output
> like this (bits copied from here and there):
> 
> | keram...@kobe:/home/keramida$ iostat -w3 ad0 da0
> |   tty ad0  da0 cpu
> |  tin tout  KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
> |5 2119 36.29  56  2.00  54.95   7  0.35   3  0  8  0 89
> |0 9478 10.90 290  3.09  57.22  12  0.67  42  0 43  0 15
> |012595  1.72 213  0.36  21.36  80  1.66  48  0 48  0  4
> |050042  4.56 715  3.19  11.44 164  1.83  29  0 50  1 20
> |  11529568  7.34 443  3.17  16.97 165  2.74  31  0 53  0 16
>[.]
> | $ ./iostat -w2
> |   tty ad0  md0  da0 cpu
> |  tin  tout  KB/t tps  MB/s   KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
> |7  2570 32.92  62  1.98   6.46   0  0.00  43.44  10  0.41   4  0  9  0 87
> |0 36506  0.99 507  0.49   0.00   0  0.00  20.13 155  3.04  34  0 56  1  9
> |0 16695  0.83 226  0.18   0.00   0  0.00  26.16  97  2.48  35  0 56  0  9
> |0 24158 10.63 428  4.45   0.00   0  0.00  14.44 137  1.93  32  0 51  0 17
> | ^C
> 
> The patch that changes this is quite small:

This should be fixed.  Ironically, the only people that usually
have problems with fixes like this are people that have seen
the fields merge and have adjusted some script to understand
column widths!

-- 
Brian Somers   
Don't _EVER_ lose your sense of humour !
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

make {,re}installkernel{,.debug}

[Brian Somers]

 target install, the targets
@@ -269,10 +273,6 @@ realinstall: _kmodinstall
 _kmodinstall:
${INSTALL} -o ${KMODOWN} -g ${KMODGRP} -m ${KMODMODE} \
${_INSTALLFLAGS} ${PROG} ${DESTDIR}${KMODDIR}
-.if defined(DEBUG_FLAGS) && !defined(INSTALL_NODEBUG)
-   ${INSTALL} -o ${KMODOWN} -g ${KMODGRP} -m ${KMODMODE} \
-   ${_INSTALLFLAGS} ${PROG}.symbols ${DESTDIR}${KMODDIR}
-.endif
 
 .include 
 
@@ -290,6 +290,16 @@ _kldxref:
 
 .endif # !target(install)
 
+.if !target(install.debug)
+install.debug:
+.if defined(DEBUG_FLAGS)
+   ${INSTALL} -o ${KMODOWN} -g ${KMODGRP} -m ${KMODMODE} \
+   ${_INSTALLFLAGS} ${PROG}.symbols ${DESTDIR}${KMODDIR}
+.endif
+.endif # !target(install.debug)
+
+install.debug: install
+
 .if !target(load)
 load: ${PROG}
${KMODLOAD} -v ${.OBJDIR}/${PROG}
Index: UPDATING
===
--- UPDATING(revision 195527)
+++ UPDATING(working copy)
@@ -22,6 +22,11 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 8.x IS SLOW:
to maximize performance.  (To disable malloc debugging, run
ln -s aj /etc/malloc.conf.)
 
+20090709:
+   The use of INSTALL_NODEBUG has been deprecated and symbol files
+   are no longer installed by default.  To install kernel and
+   module symbol files, use the {,re}installkernel.debug target.
+
 20090630:
The NFS_LEGACYRPC option has been removed along with the old
kernel RPC implementation that this option selected. Kernel
Index: Makefile
===
--- Makefile(revision 195527)
+++ Makefile(working copy)
@@ -11,9 +11,9 @@
 # world   - buildworld + installworld, no kernel.
 # buildkernel - Rebuild the kernel and the kernel-modules.
 # installkernel   - Install the kernel and the kernel-modules.
-# installkernel.debug
+# installkernel.debug - Also install kernel and module symbols.
 # reinstallkernel - Reinstall the kernel and the kernel-modules.
-# reinstallkernel.debug
+# reinstallkernel.debug - Also reinstall kernel and module symbols.
 # kernel  - buildkernel + installkernel.
 # doxygen - Build API documentation of the kernel, needs doxygen.
 # update  - Convenient way to update your source tree (cvs).
Index: Makefile.inc1
===
--- Makefile.inc1   (revision 195527)
+++ Makefile.inc1   (working copy)
@@ -682,6 +682,9 @@ distrib-dirs distribution:
 # for building kernels and only the first of these is designated
 # as the one being installed.
 #
+# If your kernel is built with DEBUG set, installkernel.debug
+# will additionally install kernel and module symbols.
+#
 # Note that we have to use TARGET instead of TARGET_ARCH when
 # we're in kernel-land. Since only TARGET_ARCH is (expected) to
 # be set to cross-build, we have to make sure TARGET is set
Index: share/mk/bsd.subdir.mk
===
--- share/mk/bsd.subdir.mk  (revision 195516)
+++ share/mk/bsd.subdir.mk  (working copy)
@@ -67,7 +67,7 @@ ${SUBDIR}: .PHONY
 
 .for __target in all all-man checkdpadd clean cleandepend cleandir \
     depend distribute lint maninstall manlint \
-obj objlink realinstall regress tags \
+obj objlink realinstall install.debug regress tags \
 ${SUBDIR_TARGETS}
 ${__target}: _SUBDIR
 .endfor


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


signature.asc
Description: PGP signature

Re: My PPP timer PR [nag]

[Brian Somers]

On Fri, 11 May 2007 17:14:16 +0100 (BST)
Robert Watson <[EMAIL PROTECTED]> wrote:

> 
> On Thu, 10 May 2007, Sergey Zaharchenko wrote:
> 
> > bin/102747 has been sitting there for about 8 months, with no activity 
> > since 
> > it was assigned to brian@, all my mail to whom bounces [CC'd just in case].
> >
> > The patch attached in the PR has been working for me since, so it not being 
> > fixed in the main tree isn't a problem with me. I just thought someone 
> > would 
> > benefit from it being committed...
> 
> In general, I would suggest sending this sort of thing to current@ and/or 
> net@, but not [EMAIL PROTECTED]

I'll have a look at it RSN - or at BSDCan next week at the
latest.

-- 
Brian Somers   <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !<[EMAIL PROTECTED]>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH2] PPP in -direct mode does not execute any chat scripts

[Brian Somers]

Hi,

Yes, this looks fine, although I think this shows that the -direct
description is wrong.  Perhaps this is more appropriate:

-direct
   This is used for communicating over an already established connection,
   usually when receiving incoming connections accepted by getty(8).  ppp
   ignores the ``set device'' line and uses descriptor 0 as the link.  ppp
   will ignore any configured chat scripts unless the ``force-scripts''
   option has been enabled.

   If callback

Do you agree with this description ?  If so, I'll go ahead and commit the
changes.  Just to be picky, I'll re-sort the OPT_ variables too :*P

And thanks for the patches.

On Mon, 03 Feb 2003 14:45:37 -0800, Maksim Yevmenkin wrote:
> Dear Brian and Hackers,
> 
> Please find updated proposed version of the patch. As suggested by
> Warner option has been renamed to 'force-sripts' and now works for
> both 'direct' and 'dedicated' modes. Also as suggested by Terry the
> man page has been updated to document side effect of 'direct'.
> 
> -direct
>This is used for receiving incoming connections.  ppp ignores the
>``set device'' line and uses descriptor 0 as the link.  ppp will
>never use any configured chat scripts unless ``force-scripts''
>option has been enabled.
> 
>If callback is configured, ppp will use the ``set device'' infor-
>mation when dialing back.
> 
> -dedicated
>This option is designed for machines connected with a dedicated
>wire.  ppp will always keep the device open and will never use
>any configured chat scripts unless ``force-scripts'' option has
>been enabled.
> 
> force-scripts
>Default: Disabled. Forces execution of the configured chat
>scripts in direct and dedicated modes.
> 
> >>Please find attached patch that adds new option to the PPP.
> >>
> >>run-scripts-in-direct-mode
> >>Default: Disabled. This allows to run chat scripts in
> >>direct mode.
> >>
> >>did i miss anything? objections? comments? reviews?
> > 
> > 
> > First comment: run it past Brian Somers <[EMAIL PROTECTED]>; it's
> > his baby, and he's the active maintainer.
> 
> I have sent him e-mail.
> 
> > Rest of comments:
> > 
> > Actually, why doesn't "-direct" allow a chat script by default?
> > The man page doesn't document that as a side-effect of "-direct",
> > only of "-dedicated", but it's been there since the import.
> > 
> > Should this really be a "negotiate" section command, rather than
> > just a command or a "set" command?
> > 
> > Also, there are only two other commands even have a "-" in them,
> > and both of them only have one (just seems a little long, compared
> > to, say, "rsid" or "direct-with-script", or even "force-script").
> > 
> > Personal preference: don't make it conditional on "-direct", let
> > it also work with "-dedicated", and call it "force-script" or
> > something, instead.
> 
> done
> 
> > The man page should be updated -- including the undocumented
> > side-effect of "-direct" disabling scripts).
> 
> done
> 
> thanks
> max
> 


-- 
Brian <[EMAIL PROTECTED]>   <[EMAIL PROTECTED]>
  <http://www.Awfulhak.org><[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !   <[EMAIL PROTECTED]>

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: read a file from a driver

[Brian Somers]

There's an example of how to do this in the ``digi'' driver.  It 
loads it's firmware module on-the-fly (if it can) and dumps it 
afterwards.

As you can see, this saves a bunch of runtime space (digi is the base 
driver, digi_* are the firmware modules):

$ ls -l /boot/kernel/digi*
-r-xr-xr-x  1 root  wheel  36911 Mar 29 00:48 /boot/kernel/digi.ko
-r-xr-xr-x  1 root  wheel  17800 Mar 29 00:48 /boot/kernel/digi_CX.ko
-r-xr-xr-x  1 root  wheel  69548 Mar 29 00:48 /boot/kernel/digi_CX_PCI.ko
-r-xr-xr-x  1 root  wheel  68764 Mar 29 00:48 /boot/kernel/digi_EPCX.ko
-r-xr-xr-x  1 root  wheel  70336 Mar 29 00:48 /boot/kernel/digi_EPCX_PCI.ko
-r-xr-xr-x  1 root  wheel  11400 Mar 29 00:48 /boot/kernel/digi_Xe.ko
-r-xr-xr-x  1 root  wheel  72852 Mar 29 00:48 /boot/kernel/digi_Xem.ko
-r-xr-xr-x  1 root  wheel  73608 Mar 29 00:48 /boot/kernel/digi_Xr.ko

Unfortunately, if you want to load digi from loader.conf, you have to 
explicitly load the firmware module(s) too as the module load function 
is called before the filesystem is available.

FWIW, Solaris has a crude interface that will allow you to open and 
getc/putc a file.  It's smart enough to know that it should talk to 
the boot prom if roodev isn't yet set.  I believe it was required for 
Solaris' drivers to be able to read their .conf files at boot time, 
and was sufficient to allow access to other files in the software I 
was writing.

> generally the answer is "You can't do that"
> 
> BUT
> 
> you could make a loadable module with the firmware,
> and load both the module and the driver before booting from 
> the boot blocks..
> then you can unload the firmware module after booting
> (or whenever)
> 
> 
> 
> On Wed, 3 Apr 2002, Kreider, Carl wrote:
> 
> > 
> > I am working on an embedded project running FreeBSD, and my driver
> > for our custom card needs to load an FPGA with code. I know I can
> > compile the code in as data, but for ease of development, I would
> > rather fetch the FPGA code from a file. With a driver in kernel
> > space. Really.
> > 
> > Can it be done? If so, how? open() and read() are obviously in libc
> > which rules them out. Do I have to write my own in assembler?
> > 
> > -- 
> > Carl Kreider
> > Wind River Doctor Design Services
> > 700 E Beardsley  Suite 14A 
> > Elkhart Indiana 46514
> > 219-206-8050  x104
> >  [EMAIL PROTECTED]  [EMAIL PROTECTED]
> >[EMAIL PROTECTED]  [EMAIL PROTECTED]
> > =
> > On two occasions I have been asked [by members of Parliament], 'Pray, Mr.
> > Babbage, if you put into the machine wrong figures, will the right answers
> > come out?' I am not able rightly to apprehend the kind of confusion of
> > ideas that could provoke such a question.
> > -- Charles Babbage 
> > =

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 'rm' incompatibility with Posix.2

[Brian Somers]

> Bogdan TARU <[EMAIL PROTECTED]> writes:
> > On 10 Apr 2002, Dag-Erling Smorgrav wrote:
> > > In my humble opinion, Solaris (and every other *nix) is broken in this
> > > respect, and *BSD is correct.
> > Except for OpenBDS. No NetBDS machine available, maybe some of you could
> > try it on one as well?
> 
> I don't know of any "OpenBDS" or "NetBDS", but NetBSD has the same
> semantics as FreeBSD:
> 
> des@rc4 ~% mkdir foo
> des@rc4 ~% touch foo/bar
> des@rc4 ~% ln -s foo baz
> des@rc4 ~% ls -l baz
> lrwxr-xr-x  1 des  des  3 Apr 10 16:41 baz@ -> foo
> des@rc4 ~% ls -l baz/
> total 0
> -rw-r--r--  1 des  des  0 Apr 10 16:41 bar

OpenBSD is the same.

> DES
> -- 
> Dag-Erling Smorgrav - [EMAIL PROTECTED]

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [Fwd: Jul 30 changes to ppp break my Telstra ADSL PPPoE connection]

[Brian Somers]

> Brian Somers wrote:
> > 
> > Hi,
> > 
> > Thanks for your report.  Would you be able to grab me logs of the
> > connection that doesn't work (the latest ppp) and the one that works
> > (the pre-July 30 one) with the following set:
> > 
> >   set log tun chat lcp ipcp
> > 
> > It may be possible to fix the problem by changing your ``set mru''
> > and ``set mtu'' lines to
> > 
> >   set mru max 1454
> >   set mtu max 1454
> > 
> > but, even if this is successful, I'd be interested in the logs.
> > 
> > It may also be worth trying the latest version of ppp from my web
> > site (http://www.Awfulak.org/~brian) - just in case it's something
> > that I've already fixed but have forgotten to MFC.  If that's the
> > case, then I should be able to find the bogus code more easily.
> > 
> 
> I am having great difficulty getting logs.  I noticed the last time I had ppp log 
>data was November 20th.  But this is what I have.
> 
> /etc/syslog.conf:
> !ppp
> *.* /var/log/ppp.log
> 
> /var/log/ppp.log:
> Dec  5 08:02:26 server ppp[198]: tun0: LCP: deflink: RecvEchoRequest(2) state = 
>Opened 
> Dec  5 08:02:26 server ppp[198]: tun0: LCP: deflink: SendEchoReply(2) state = Opened 

This looks ok.  Can you show me the logs from when the connection is 
established in each case ?

Cheers.

> jhousley@server:~ {13} pppctl -p xx 3000 show log
> Log:   Chat IPCP LCP Tun Warning Error Alert
> Local: Warning Error Alert
> 
> I am getting this with both RELENG_4_3 ppp and RELENG_4 ppp.  Yes syslogd is running 
>as "syslogd -s -s"  If I turn on tcp/ip or debug I get lots of information in the log
> files.  Is it possible that some of the log levels were broken.  I will try the 
>latest verson from (http://www.Awfulak.org/~brian) is see if that logs properly
> 
> Jim
> -- 
> /"\   ASCII Ribbon Campaign  .
> \ / - NO HTML/RTF in e-mail  .
>  X  - NO Word docs in e-mail .
> / \ -
> [EMAIL PROTECTED]  http://www.FreeBSD.org The Power to Serve
> [EMAIL PROTECTED]  http://www.TheHousleys.net
> [EMAIL PROTECTED]  http://www.SimTel.Net
> -
> Your mouse has moved.
> Windows NT must be restarted for the change to take effect!
> 
> Reboot now?  [OK]

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [Fwd: Jul 30 changes to ppp break my Telstra ADSL PPPoE connection]

[Brian Somers]

Hi,

Thanks for your report.  Would you be able to grab me logs of the 
connection that doesn't work (the latest ppp) and the one that works 
(the pre-July 30 one) with the following set:

  set log tun chat lcp ipcp

It may be possible to fix the problem by changing your ``set mru'' 
and ``set mtu'' lines to

  set mru max 1454
  set mtu max 1454

but, even if this is successful, I'd be interested in the logs.

It may also be worth trying the latest version of ppp from my web 
site (http://www.Awfulak.org/~brian) - just in case it's something 
that I've already fixed but have forgotten to MFC.  If that's the 
case, then I should be able to find the bogus code more easily.

Thanks.

>  Original Message 
> From: Greg Lane <[EMAIL PROTECTED]>
> Subject: Jul 30 changes to ppp break my Telstra ADSL PPPoE connection
> To: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
> 
> G'day all,
> 
> I have a problem with PPPoE over Telstra ADSL (Australia). A full
> description of the problem can be found in freebsd-questions 
> (see [EMAIL PROTECTED] dated Nov 30) 
> with the subject:
> 
> ADSL PPPoE (Telstra Aust.) began to hang between 4.3- and 4.4-RELEASE
> 
> The short of it is that at some point during my cvsup history certain
> types of traffic would hang, specifically most web traffic and certain
> types of ssh (e.g. ls -l of a long directory). This was reminiscent of
> the MTU/MRU problems at the beginning of the year. I backdated to
> 4.3-RELEASE which worked and I forgot about it until recently when I
> decided to change my gateway machine.
> 
> I have now chased it up in earnest by going back through 
> various dated "cvsup's" and making the world. On
> July 30th there were some changes to src/usr.sbin/ppp that break ppp
> and cause this problem. Strangely enough the changes were related to 
> MRU's :-> !!
> 
> I can reliably make my DSL connection work on three different machines
> using four different network cards (ed, de, vr, rl) with source dated 
> Jul 30 12:01am, and reliably break it with anything after 
> Jul 31 12:01am. 
> 
> The changes made to ppp on that day were to:
> 
> src/usr.sbin/ppp/command.c
> src/usr.sbin/ppp/lpc.c
> src/usr.sbin/ppp/nat_cmd.c
> src/usr.sbin/ppp/nat_cmd.h
> src/usr.sbin/ppp/ppp.8
> 
> The most likely problem is lpc.c because 1) it looks the most 
> complicated(!!) and 2) it is supposed to:
> 
> MFC: Handle peer REQ/NAKs of >1500 byte MRUs when we have no preference
> 
> The other diffs were small and were to implement two issues:
> 
> MFC: If the peer REJects our MRU REQ, stop REQing it -- *EVEN* if we're
>  doing PPPoE and the default MRU is therefore too big.
> 
> MFC: Actually add the ``nat proto'' command
> 
> I'm afraid my lack of knowledge stops me going on from here. My
> ppp.conf is below and I start ppp with "ppp -ddial -nat -quiet bigpond" 
> Can anyone see the problem and suggest further detective work I can 
> perform or even better, a fix or workaround?
> 
> Cheers,
> Greg
> 
> P.S. I have cross-posted to questions since the thread started there 
> and hackers since I believe I have narrowed down the problem and it is
> technical. I hope this is OK. Please confine your reply to whatever
> list you feel is appropriate, I am subscribed to both.
> 
> ---
> default:
>  #Only enable logging for troubleshooting
>  #set log CBCP CCP Chat Connect Command IPCP tun Phase Warning Debug LCP sync
> 
>  set device PPPoE:rl0:bigpond
>  set speed sync
>  set mru 1454
>  set mtu 1454
>  set ctsrts off
>  enable lqr
>  add default HISADDR
>  set timeout 0
>  set redial 7 0
>  set socket /var/run/pppsocket  *
> 
>  #Network Address Translation (NAT)
>  nat enable yes
>  nat log yes
>  #nat same_ports yes
>  nat unregistered_only yes
> 
>  #enable dns   # this disabled since the box now runs its own dns
> 
> bigpond:
>  set authname ***
>  set authkey ***
> ---

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Checking changes to listening ports in /etc/security

[Brian Somers]

> From: Brian Somers <[EMAIL PROTECTED]>
> Subject: Re: Checking changes to listening ports in /etc/security
> Date: Fri, Sep 14, 2001 at 12:18:43PM +0100
> 
> > I think the attached patch makes things slightly better.  We only run 
> > sockstat once, and remove the trailing whitespace that sockstat emits 
> > (making the diff lines look better when viewed on an 80 column 
> > screen).
> 
> Ahem, that's what happens when one works in 132 column modes.
> Yes, trailing spaces are better removed.
> 
> > Could you look these over ?  If you're happy with this I can commit 
> > it.
> 
> Looks great to me.  I tested it with the usual four runs of
> periodic/daily/450.status-security that I used for my versions.
> It works great :)

I found a problem... if you reboot a machine, lots of diffs come up 
because of the PID column.  I've got a version running locally that 
dykes out the PID stuff from the report.  It also displays the header 
line above the diff output for a bit of context.  If it works ok over 
the next few days I'll commit it.

I've attached the patch FYI.

> -giorgos

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  

Index: security
===
RCS file: /home/ncvs/src/etc/security,v
retrieving revision 1.55
diff -u -r1.55 security
--- security4 Jul 2001 12:49:17 -   1.55
+++ security17 Sep 2001 00:37:01 -
@@ -128,6 +128,31 @@
 tee /dev/stderr | wc -l)
 [ $n -gt 0 -a $rc -lt 1 ] && rc=1
 
+# Show changes in listening tcp and udp ports:
+#
+sockstat -l46 | {
+   read line
+   echo "${line}"
+   sed -e /^USER/d -e /comsat/d -e '/^[ ]*$/d' | sort +5
+} | sed -e 's/[ ][  ]*$//' -e 's/\(..\)./\1/' >${TMP}
+
+if [ ! -f ${LOG}/sockstat.today ]; then
+   [ ${rc} -lt 1 ] && rc=1
+   separator
+   echo "${host} changes in listening ports:"
+   diff -b /dev/null ${TMP}
+   touch ${LOG}/sockstat.yesterday || rc=3
+   mv ${TMP} ${LOG}/sockstat.today || rc=3
+elif ! cmp ${LOG}/sockstat.today ${TMP} >/dev/null 2>&1; then
+   [ ${rc} -lt 1 ] && rc=1
+   separator
+   echo "${host} changes in listening ports:"
+   sed '1{ s/^/  /; q; }' ${TMP}
+   diff -b ${LOG}/sockstat.today ${TMP}
+   mv ${LOG}/sockstat.today ${LOG}/sockstat.yesterday || rc=3
+   mv ${TMP} ${LOG}/sockstat.today || rc=3
+fi
+
 # Show denied packets
 #
 if ipfw -a l 2>/dev/null | egrep "deny|reset|unreach" > ${TMP}; then



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Checking changes to listening ports in /etc/security

[Brian Somers]

> From: Brian Somers <[EMAIL PROTECTED]>
> Subject: Re: Checking changes to listening ports in /etc/security
> Date: Thu, Sep 13, 2001 at 10:25:02PM +0100
> 
> > I like this idea.  I think It would be worth making it diff against 
> > /dev/null when netstat.today doesn't exist, so that the first time 
> > this is run on a given machine, you get to see all the ports that are 
> > open.
> 
> Done.  I duplicated the code of the second if[] since I could not easily come
> up with a version that does not use some kind of shell variable weirdness
> and still work the same way.  I prefer to keep this clean and easy to
> understand.  The attached patch makes /dev/null the first argument of diff
> when sockstat.today does not exist.
[.]

Hi,

I think the attached patch makes things slightly better.  We only run 
sockstat once, and remove the trailing whitespace that sockstat emits 
(making the diff lines look better when viewed on an 80 column 
screen).

Could you look these over ?  If you're happy with this I can commit 
it.

Cheers.
-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  

Index: security
===
RCS file: /home/ncvs/src/etc/security,v
retrieving revision 1.55
diff -u -r1.55 security
--- security4 Jul 2001 12:49:17 -   1.55
+++ security14 Sep 2001 11:12:09 -
@@ -128,6 +128,30 @@
 tee /dev/stderr | wc -l)
 [ $n -gt 0 -a $rc -lt 1 ] && rc=1
 
+# Show changes in listening tcp and udp ports:
+#
+sockstat -l46 | {
+   read line
+   echo "$line"
+   sed -e /^USER/d -e /comsat/d -e '/^[ ]*$/d' | sort +5
+} | sed 's/[][  ]*$//' >${TMP}
+
+if [ ! -f $LOG/sockstat.today ]; then
+   [ $rc -lt 1 ] && rc=1
+   separator
+   echo "$host changes in listening ports:"
+   diff -b /dev/null $TMP
+   touch $LOG/sockstat.yesterday || rc=3
+   mv $TMP $LOG/sockstat.today || rc=3
+elif ! cmp $LOG/sockstat.today $TMP >/dev/null 2>&1; then
+   [ $rc -lt 1 ] && rc=1
+   separator
+   echo "$host changes in listening ports:"
+   diff -b $LOG/sockstat.today $TMP
+   mv $LOG/sockstat.today $LOG/sockstat.yesterday || rc=3
+   mv $TMP $LOG/sockstat.today || rc=3
+fi
+
 # Show denied packets
 #
 if ipfw -a l 2>/dev/null | egrep "deny|reset|unreach" > ${TMP}; then




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Driver structures & alignment

[Brian Somers]

> Hi there,
> 
> Is there a single blessed way to define packed structures
> for use in drivers?  I suspect that using "#pragma pack(1)"
> will lead to alignment errors in non-Intel architectures.

gcc deals with it, certainly on alpha anyway.  However, I don't think 
anyone would ever bless using packed structures as it hurts memory 
transfers.

I prefer the fix-it-up-when-I-need-it-packed approach :*)

> -- 
> Yar

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Checking changes to listening ports in /etc/security

[Brian Somers]

> I've been adding an extra check in my local version of /etc/security for quite
> some time now.  All it does is use 'netstat' to grab a list of the listening
> tcp and udp ports of my machine and save it to /var/log/netstat.today
> (and /var/log/netstat.yesterday).  This way, when some service starts
> and listens on a new port the next run of /etc/security will log the
> fact in the usual stuff sent to root by mail.  I tested this running
> /etc/periodic/daily/450.security twice, and running a local IRC daemon between
> the two runs.  The output that is added to the message root receives looks
> like the following:
[.]

I like this idea.  I think It would be worth making it diff against 
/dev/null when netstat.today doesn't exist, so that the first time 
this is run on a given machine, you get to see all the ports that are 
open.

[.]
+[ -n "$ignore" ] && cmd="egrep -v ${ignore#|}" || cmd=cat
[.]

I think this like is bogus.  In fact, it looks like the 
$daily_status_security_noamd periodic.conf tunable is broken.

Oops !  I'll fix it after your changes go in.
-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: IPv6 DAD avoidance

[Brian Somers]

> 
> brian> Can anybody tell me if it's possbile to tell a given interface
> brian> not to do DAD ?
> 
> There is a kernel MIB, 'net.inet6.ip6.dad_count'.  See inet6(4)
> manpage for more detail.
> 
> However, there is no way to stop DAD for any given interfaces; only
> we have two choices, 'do DAD to any interfaces' or 'do not DAD to all
> interfaces'.

Would it be worth bringing up the subject of adding an IFF_ flag that 
can be SIOCSIFFLAGS'd into the interface with the kame team ?

Currently, ppp manages to control the link-local address every second 
time it's run on a given interface... which just looks weird :*I  It 
seems more sane to allow a program to say ``I do my own address 
discovery''.

If you think it's worth bringing up with the kame guys, can you tell 
me where I should send the mail (which list address) ?  Thanks.

> -- -
> Makoto `MAR' MATSUSHITA

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

IPv6 DAD avoidance

[Brian Somers]

Hi,

Can anybody tell me if it's possbile to tell a given interface not to 
do DAD ?  Specifically, when using the tun device for PPP, PPP 
negotiates it's own endpoint (link-local) addresses with the peer.  
However, it doesn't look possible to stop the kernel from doing DAD 
unless we already have a link-local address assigned to the interface 
when we IFF_UP it

Perhaps we could have a new IFF_ flag (say, IFF_NODAD) that could be 
ioctl()d into the interface's if_flags field and checked in 
in6_ifattach() ?

Thanks for any help
-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: For review: Patch to ps(1) old-style option parsing.

[Brian Somers]

>This is pretty low-priority and I don't think it needs to be
> MFC'd for the 4.4 release, but there is a small error in ps's
> old-style option handling.  An outstanding example of this is
> when one runs `ps Uroot':

This has irritated me in the past too :*)  I've applied your patch to 
-current.  Thanks.
-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

freebsd-hackers@freebsd.org

[Brian Somers]

> ,[ On Thu, Aug 02, at 05:57PM, Julian Elischer wrote: ]--
> | anyone had success watching a dvd?
> `[ End Quote ]---
> 
> ok, first and foremost, please, anyone else replying, reply to the list
> and not to me and please dont cc me, i am on the list. (i have to, i got
> a LOT of replies far after my answer was achieved last time) anyway, vlc
> is what you want, it works decently if you have a good video card, it
> simply reboots my -current laptop, so your milleage may vary, but there
> are numerous reports of successful usage. good luck. --gabe

This program doesn't seem to work very well at all.  It seems to 
create a thread and set p_vout to NULL on line 95 of 
vlc-0.2.81/src/video_decoder/vpar_synchro.c, then goes and 
dereferences it on line 228 of 
vlc-0.2.81/src/video_decoder/vpar_synchro.c.

If anyone's interested in committing it as a port, you can find the 
necessary files at ftp://ftp.Awfulhak.org/pub/vlc-port.

> -- 
> 
> "It's not brave if you're not scared."

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: portmap_enable vs. rpcbind_enable

[Brian Somers]

> In message <[EMAIL PROTECTED]> Brian Somers writes:
> : > In message <[EMAIL PROTECTED]> Dima Dorfman writes:
> : > : Does anybody know (remember?) why portmap_enable (the rc.conf knob)
> : > : wasn't renamed to rpcbind_enable when portmap became rpcbind?  It
> : > : seems odd to have a knob called portmap_enable that actually starts
> : > : something called rpcbind (not to mention violating POLA).
> : > 
> : > Because we didn't want to break old people's config files.  Also, the
  ^^
> : > rpcbind rename was stupid and there were people at the time that had
> : > hoped it be renamed portmap since that was a bigger pola :-)
> : 
> : Are you referring to grog & bde only ?
> 
> There were a fair number of people that wanted the name to remain the
> same...  I want it to remaint he same, but I don't care enough to
> fight.

I was actually making a smart arse comment about your wording :*)

> Warner

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: portmap_enable vs. rpcbind_enable

[Brian Somers]

> In message <[EMAIL PROTECTED]> Dima Dorfman writes:
> : Does anybody know (remember?) why portmap_enable (the rc.conf knob)
> : wasn't renamed to rpcbind_enable when portmap became rpcbind?  It
> : seems odd to have a knob called portmap_enable that actually starts
> : something called rpcbind (not to mention violating POLA).
> 
> Because we didn't want to break old people's config files.  Also, the
> rpcbind rename was stupid and there were people at the time that had
> hoped it be renamed portmap since that was a bigger pola :-)

Are you referring to grog & bde only ?

> Warner

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Why install -C include files?

[Brian Somers]

> 
> 
> On Wed, 25 Jul 2001 08:58:02 CST, Warner Losh wrote:
> 
> > The reason I'd like to see it isn't so that make world kills things
> > automatically, but so that I could kill them (or at least find out
> > what should be killed) on systems that had FreeBSD 1.0 installed on
> > them, then upgraded, disk cloned, etc.
> 
> That's exactly what I'm talking about. :-)

Every now and then, rather than doing ``make installworld'', do:

# cd /usr
# mv share share.not
# mv include include.not
# mv libdata libdata.not
# cd src
# make -m /usr/src/share/mk installworld
# cd ..
# rm -fr share.not include.not libdata.not

This keeps things reasonably clean.

> Ciao,
> Sheldon.

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: A full source-tour somewhere?

[Brian Somers]

> On Mon, Jul 23, 2001 at 12:56:04AM -0700, Julian Elischer wrote:
> > Julian Elischer wrote:
> > > 
> > > Dima Dorfman wrote:
> > [...]
> > > >  * A cross reference of the FreeBSD kernel
> > > 
> > > well I have the source code of course, but the second is what I'm
> > > looking for except that it stopped being updated October 2000.
> > > 
> > > I'm looking for a current one.
> > 
> > oh yeah, and that one doesn't work..
> > try clicking on something you want to cross reference..
> 
> I'm not shure what you exactly need.
> With global you can simply gtags && htags in a dir and enjoy the html.
> You have do do it for every application & kernel on their own because
> they share identic named functions like main() and so on.
> The result is nice but I wouldn't call it "cross reference"

I think devel/cscope is reasonably good.

> -- 
> B.Walter  COSMO-Project http://www.cosmo-project.de
> [EMAIL PROTECTED] Usergroup   [EMAIL PROTECTED]

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: interface cloning MFC

[Brian Somers]

> I plan to MFC the network interface cloning support and the gif
> modularization early next week unless someone has objections.  I'd like
> to get it in before the code slush and since I'll be leaving for a week
> on the 31st, that means sometime early to mid next week to allow for any
> bug reports.  I don't really expect any problems.
> 
> A diff is available at:
> 
> http://people.freebsd.org/~brooks/patches/gif-stable.diff
> 
> apply with:
> 
> cd /usr/src
> mkdir sys/modules/if_gif sys/modules/if_stf
> patch < gif-stable.diff
> 
> -- Brooks

This works nicely on my -stale box.  Thanks.

One niggle though :)  It's probably worth changing 
``$FreeBSD: $'' to ``$FreeBSD$'' in your patched version.  
Without this, mergemaster assumes that the new version in /usr/src/etc 
is the same as the /etc version (same Ids).  This caused a problem 
here, I fixed the problem and went to prepare a patch for you the 
patch file came up empty -- you already had the missing ``create'' in 
your patches (of course) :*D

Cheers.
-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: interface cloning MFC

[Brian Somers]

> I plan to MFC the network interface cloning support and the gif
> modularization early next week unless someone has objections.  I'd like
> to get it in before the code slush and since I'll be leaving for a week
> on the 31st, that means sometime early to mid next week to allow for any
> bug reports.  I don't really expect any problems.

Good stuff.

> A diff is available at:
> 
> http://people.freebsd.org/~brooks/patches/gif-stable.diff

You forgot:

Index: LINT
===
RCS file: /home/ncvs/src/sys/i386/conf/Attic/LINT,v
retrieving revision 1.749.2.64
diff -u -r1.749.2.64 LINT
--- LINT2001/06/29 21:14:24 1.749.2.64
+++ LINT2001/07/20 19:35:42
@@ -509,7 +509,7 @@
 optionsETHER_SNAP  # enable Ethernet_802.2/SNAP frame
 
 # for IPv6
-pseudo-device  gif 4   #IPv6 and IPv4 tunneling
+pseudo-device  gif #IPv6 and IPv4 tunneling
 pseudo-device  faith   1   #for IPv6 and IPv4 translation
 pseudo-device  stf #6to4 IPv6 over IPv4 encapsulation
 

I'm just rebuilding the world now :)  I'll let you know how I get on. 
Thanks for your work.

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Some questions about kernel programming

[Brian Somers]

> Have a look at the digi driver in -current where I did this.  The 
> caveat is that the kernel code looks ugly.  From the driver's ioctl 
> routine:
> 
> case DIGIIO_IDENT:
> return (copyout(sc->name, *(char **)data,
> strlen(sc->name) + 1));
> 
> and from digiio.h:
> 
> #define DIGIIO_IDENT_IOW('e', 'E', char *)
> 
> and from userland (digictl.c):
> 
> char namedata[256], *name = namedata;
> 
> } else if (ioctl(fd, DIGIIO_IDENT, &name) != 0) {
> 

Oops, we weren't talking about copyout() :*D

There's a copyinstr() function available.  Would that solve the 
problem ?

> > -- 
> > -Alfred Perlstein [[EMAIL PROTECTED]]
> > Ok, who wrote this damn function called '??'?
> > And why do my programs keep crashing in it?
[.]
-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Some questions about kernel programming

[Brian Somers]

> > write() doesn't exist in the kernel.  The simple answer is "you're
> > going to have to read what the send() syscall does and emulate it".
> > First, though, you need to answer the question "why do I want to do
> > this in the kernel?"
> 
> it actually exists, however the problem is that copyin and friends 
> assume a seperate address space, I wonder if one could do some trick
> to alias the seperate address space on top of the kernel, that should
> allow copyin and friends to work on pointers into the kernel's address
> space.

Solaris does this by passing a tag into it's driver calls.  The tag 
is given to ddi_copy{in,out}() which DTRT.  When a kernel wants to 
open a file, it does a layered open (lyr_open() or some such) which 
results in an opaque handle with which you can do other lyr_* calls 
such as lyr_ioctl().  The driver has to declare itself as being 
capable of doing layered opens (via the d_flag bit of it's devsw), 
meaning that it uses ddi_copy{in,out} rather than copy{in,out}.

> > > 3. How I can copy a pointer string ( character array ) from user space to
> > >kernel space using copyin() without the following problem (I can't
> > >pass the length the explicitly from user land):
> > >
> > > structMySystemCall_args {
> > >   char *  address;
> > > };
> > >
> > > int MySystemCall( p,uap)
> > >   struct proc *p;
> > >   register struct  MySystemCall_args *uap;
> > > {
> > >   char *the_address;
> > >
> > >   printf(" ---> uap->address : %s\n", uap->address );
> > >   printf(" ---> (strlen (uap->address) * sizeof(char)) : %d \n",
> > >   (strlen (uap->address) * sizeof(char)) );
> > >   copyin(uap->address, the_address, (strlen (uap->address) * sizeof(char))
> > > );
> > >   printf("the_address: %s \n", the_address );
> > >   printf("strlen (the_address): %d \n", strlen (the_address) );
> > >
> > > When this code run in mode kernel:
> > >   ---> uap->address : 127.0.0.1
> > >   ---> (strlen (uap->address) * sizeof(char)) : 9
> > >   the_address : 127.0.0.1\M-"\M-Y\M-GX\M-p+\M-@@\M-_\M-*\M-@
> > >   strlen (the_address): 20
> > >
> > > This crash the kernel later...
> > 
> > You've forgotten the terminating \0.  Add one to the length.
> 
> You can't call kernel strlen on a userland address, you must do
> something like this:
> 
> /*
>  * return number of characters in a userland address string
>  * or -1 if an illegal access occurs.
>  */
> int
> user_strlen(uaddr)
>   char *uaddr;
> {
>   int ret;
> 
>   ret = -1;
>   do {
>   ch = fubyte(uaddr);
>   ret++;
>   } while (ch != 0 && ch != -1);
> 
>   return (ch == -1 ? -1 : ret);
> }

Have a look at the digi driver in -current where I did this.  The 
caveat is that the kernel code looks ugly.  From the driver's ioctl 
routine:

case DIGIIO_IDENT:
return (copyout(sc->name, *(char **)data,
strlen(sc->name) + 1));

and from digiio.h:

#define DIGIIO_IDENT_IOW('e', 'E', char *)

and from userland (digictl.c):

char namedata[256], *name = namedata;

} else if (ioctl(fd, DIGIIO_IDENT, &name) != 0) {


> -- 
> -Alfred Perlstein [[EMAIL PROTECTED]]
> Ok, who wrote this damn function called '??'?
> And why do my programs keep crashing in it?

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: mgetty+AutoPPP pointers?

[Brian Somers]

There's stuff in the ppp(8) man page about this -- although I've 
deprecated the mgetty stuff in favour of getty which is capable of 
doing the same thing.

> Hello all,
> 
> I want to configure a server machine I have at home to answer a phone line via
> internal modem and setup a PPP connection to the "outside world" (the machine
> is connected via broadband) for a Win98 machine being the remote caller.
> 
> I've read up a little on mgetty and its use of AutoPPP to fire off pppd via
> various google searches. Many of the links I've brought up are reasonably
> decent explanations, but based around Linux setups.
> 
> Does anybody have any bookmarked pointers to setting up mgetty+AutoPPP under
> FreeBSD -STABLE?
> 
> I've dug through a few bits and I know our in-tree compilation of pppd is
> compiled with -DCHAPMS (which the Linux-related pointers said to make sure you
> used when compiling pppd) and our port of mgetty+sendfax does define
> -DAUTO_PPP during compilation (which was another "must"). Is there anything
> else that is needed to enable the code to DTRT?
> 
> If anybody has done this sort of thing and wishes to share config files, or
> "gotchas" I would much appreciate it! Please 'cc:' me.
> 
> After grepping the archives, it looks like this topic has come up a lot with
> varied answers but no real "pointers." If somebody has pointers or sample
> config files, I would be happy to try and mark them up and submit them to the
> -doc project!
> 
> -Jr
> 
> -- 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> | John Reynolds   WCCG, CCE,  (space for rent, cheap!)  |
> | Intel Corporation   MS: CH6-210   Phone: 480-554-9092   pgr: 602-868-6512 |
> | [EMAIL PROTECTED]  http://www-aec.ch.intel.com/~jreynold/  |
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: FreeBSD Mall now BSDCentral

[Brian Somers]

> Poul-Henning Kamp wrote:
> 
> | In message <[EMAIL PROTECTED]>, Brian Somers writes:
> | 
> | >I'm not having a go at Cheapbytes.  I'm just saying that their CDs 
> | >should be labeled official or unofficial based on their content.  If 
> | >they want to drop the base ISO image onto a CD and sell it, then 
> | >they're as official as anybody else.
> | 
> | Right, and what are you going to do about some random company
> | in Elbonia who labels and "unapproved" cd as "Official" ?
> | 
> | One should never makes rules one can't enforce...
> 
> Perhaps this labelling can be in the form of information on the
> FreeBSD.ORG web site that lists distributions that merit the
> "official" label.

That seems to make a lot of sense.  In this context, ``official'' 
really means ``sanctioned by the FreeBSD project''.
-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: FreeBSD Mall now BSDCentral

[Brian Somers]

> On Sat, 7 Jul 2001, Brian Somers wrote:
> 
> > Richard Hodges <[EMAIL PROTECTED]> wrote:
> > > And as far as distribution goes, if my vote counts, I would suggest
> > > that anyone should have the right to sell (or give away) copies for
> > > whatever price they want.  The more copies, the better!  I fail to
> > > see why FreeBSD distribution should be "guided" to certain entities
> > > based on their political contributions.
>  
> > FSL have thought quite a bit about this -- what's acceptable as a 
> > FreeBSD release.  We need some sort of balance.  On one hand, we (the 
> > FreeBSD project) want to encourage distributors to produce copies of 
> > FreeBSD with added-value.  On the other hand, we don't want to end up 
> > with the linux-effect.
> 
> Really?  I was hoping to see a new disto with the FreeBSD userland
> wrapped around a Linux kernel :-)  Or was it the other way around...
> 
> But as far as "added-value" goes, why wouldn't minimum cost be an 
> added value to a potential customer?  I think that the companies
> like Cheapbytes serve a social purpose in this regard.

I'm not having a go at Cheapbytes.  I'm just saying that their CDs 
should be labeled official or unofficial based on their content.  If 
they want to drop the base ISO image onto a CD and sell it, then 
they're as official as anybody else.

> > So I think the idea of an ``official'' distribution is good, but only 
> > insofar as that implies that the distribution contains a specific 
> > base system.  Anyone who mucks about with that official base system 
> > in a way that's not controlled by the user should not be allowed to 
> > call their distribution ``official''.
> 
> Sure, no argument there.  Taking Wes' suggestion, maybe there is an
> opportunity in the "official" distribution distinction.  How about a
> "certificate of authenticity" which costs the vendors $1 or $2 (or
> whatever), and shows the customer that their choice of vendors helped
> FreeBSD financially.  Incidentally, this certificate might also be a
> selling point for those twisted individuals that just don't understand
> free software :-)

Companies that sell CDs shouldn't necessarily be limited in the ways 
that they can give back to the project.  If a company (WRS for 
example) are forking out lots of money to the FreeBSD project 
already, why should they have to now send money to the foundation ?

Besides, our software is free, it's not shareware.

> Thanks for the info,
> 
> -Richard
> 
> ---
>Richard Hodges   | Matriplex, inc.
>Product Manager  | 769 Basque Way
>   [EMAIL PROTECTED]  | Carson City, NV 89706
> 775-886-6477| www.matriplex.com 

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: FreeBSD Mall now BSDCentral

[Brian Somers]

Josef Karthauser <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 06, 2001 at 02:28:18PM -0700, Kris Kennaway wrote:
> >=20
> > In the past, the officially blessed CD distributor was kicking back
> > money directly to FreeBSD; whatever happens in the future with respect
> > to CD distribution, I think we should make sure this continues to
> > happen in an economically sustainable way.
> >=20
> 
> FSL, I believe, are keen to keep up this tradition also (although I
> can't speak for what projects they will be supporting).

To qualify this (a little), we (FSL == FreeBSD Services Ltd) will be 
distributing a FreeBSD-4.4 DVD set.  The profits will be used to fund 
developers (Paul Richards, Mark Murray and I to start with) initially 
in the form of our wages, but eventually in more diverse ways that 
are beneficial to the project at large.  We also plan to adopt the 
give-free-DVDs-to-all-developers approach subject to our financial 
success.

To give people confidence in our abilities, we gave away about 350 
FreeBSD-4.3 DVDs at Usenix last week -- samples of what's to come 
(and proof that we can produce).  http://www.FreeBSD-services.com/ 
has more details (please feel free to register for further updates).

Richard Hodges <[EMAIL PROTECTED]> wrote:
> And as far as distribution goes, if my vote counts, I would suggest
> that anyone should have the right to sell (or give away) copies for
> whatever price they want.  The more copies, the better!  I fail to
> see why FreeBSD distribution should be "guided" to certain entities
> based on their political contributions.

FSL have thought quite a bit about this -- what's acceptable as a 
FreeBSD release.  We need some sort of balance.  On one hand, we (the 
FreeBSD project) want to encourage distributors to produce copies of 
FreeBSD with added-value.  On the other hand, we don't want to end up 
with the linux-effect.  The idea of producing standard distributions 
on which vendors can base their projects means that we can keep 
control of the base system - ensuring that the evolution of different 
flavours of FreeBSD are based on what *we* want, not on what someone's 
marketing department wants.

For example, a good way for a vendor to build their own flavour of 
FreeBSD might be to provide a ``Vendor-Desktop'' port/package that 
people can select from sysinstall to give them everything that the 
vendor wants to provide as standard, maybe even including proprietary 
stuff.

So I think the idea of an ``official'' distribution is good, but only 
insofar as that implies that the distribution contains a specific 
base system.  Anyone who mucks about with that official base system 
in a way that's not controlled by the user should not be allowed to 
call their distribution ``official''.

Kris Kennaway <[EMAIL PROTECTED]> wrote:
> What's likely to happen if we let it is that a number of entities will
> publish verbatim copies of the "officially produced" ISO images, and
> do so at production cost + some profit margin which only feeds back
> into their own pockets.  This means that if the larger CD distribution
> facilities like, say, CheapBytes could do this more cheaply than
> someone like, say, DaemonNews, the latter will find it very hard to
> compete without losing money unless they can feed off of some kind of
> "preferred vendor" status.  Entities which are more friendly to the
> FreeBSD project (like DaemonNews) and who may want to donate a portion
> of the proceeds to the Foundation will have to take it out of their
> profit margins and will lose money relative to those that don't.
> 
> In the past, the officially blessed CD distributor was kicking back
> money directly to FreeBSD; whatever happens in the future with respect
> to CD distribution, I think we should make sure this continues to
> happen in an economically sustainable way.

I don't think we'll get away with ``favouring'' certain distributors. 
It's not really with the spirit of things.  As Jordan has said, the 
kick-back contributions have always been very much appreciated, but 
not based on any official agreements.

I personally believe that the distributors who contribute stuff back 
will continue to be favoured - but maybe I'm being idealistic.

Ted Mittelstaedt <[EMAIL PROTECTED]> wrote:
> So, are you ready for $100-per-box FreeBSD distros?  Do you think the
> FreeBSD userbase is?  Boy, now THAT's sure an advance for the customer!

I think you're over-reacting Ted.  FSL are planning on selling the 
two-DVD set for around $40.00.  We may even be putting a CD on the 
other side of the initial disc (that may put costs up by a few $$, 
but will benefit more people), but the FreeBSD community will 
continue to get reasonable value.  The $100 vendors will just simply 
sink.

Jordan Hubbard <[EMAIL PROTECTED]> wrote:
> Also, when Wes said the following:
> 
> > Specifically, we need a Product Manager who can shepherd FreeBSD through
> > the release process, and coordinate with CD-ROM distributor(s) who are
> 
>

Re: C++ to C translator

[Brian Somers]

I requested the bug list for that ``compiler'' at one point and was 
given hundreds of sheets of ``known bugs'' (several bugs per sheet).  
At the time, I was looking for alternatives to g++ because of a bug 
I'd come across.  Needless to say, the bug in question appeared in 
the cfront known-bugs documentation :)

In short, avoid cfront :o{}

> The original Stroustrop AT&T C++ complier called cfront was a front-end C
> compiler.  They may have it available at research.att.com.  It's missing some
> things, though, like generic container classes.
> 
> -Original Message-
> From: Rayson Ho [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 03, 2001 9:45 PM
> To: [EMAIL PROTECTED]
> Subject: C++ to C translator
> 
> 
> Hi,
> 
> I have written some code in C++. However, I want to run it on an old
> mainframe machine, which a C++ compiler is not available.
> 
> I know that the old g++ is a C++ to C compiler. Does anyone know which
> version it is? Also, anyone knows other C++ to C compilers?
> 
> Thanks,
> Rayson
> 
> 
> __
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail
> http://personal.mail.yahoo.com/

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Linux Applications Over PPP

[Brian Somers]

> Brian Somers wrote:
> 
>  > The only strange occurrence I've seen that sounds even vaguely
>  > similar is that if you leave out a nameserver line in
>  > /compat/linux/etc/hosts, it *doesn't* default to 127.1.
>  >
>  > Try adding a nameserver line (if you haven't already got one).
> 
> Thanks for the suggestion, but it has still not solved the problem.
> 
> In fact there wasn't even a /compat/linux/etc/hosts file, so I created
> one, containing the line:

Oops, I meant /etc/resolv.conf... sorry.

[.]
> John.

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Linux Applications Over PPP

[Brian Somers]

The only strange occurrence I've seen that sounds even vaguely 
similar is that if you leave out a nameserver line in 
/compat/linux/etc/hosts, it *doesn't* default to 127.1.

Try adding a nameserver line (if you haven't already got one).

> Hi,
> 
> Six million *.rpm files later, I've finally got the Linux version of
> Mozilla working properly. However, neither the Linux versions of Mozilla
> or Opera seem to be able use my PPP connection - they simply can't
> connect to anything, even when I'm fully connected and browsing using
> the FreeBSD version of Mozilla.
> 
> Why is this? What setting do I need to alter to enable Linux apps to use
> my PPP connection?
> 
> Regards,
> 
> John.
> 
> ppp.conf (username/password hashed out!):
> 
> #
> # PPP  Sample Configuration File
> # Originally written by Toshiharu OHNO
> # Simplified 5/14/1999 by [EMAIL PROTECTED]
> #
> # $FreeBSD: src/etc/ppp/ppp.conf,v 1.2 1999/08/27 23:24:08 peter Exp $
> #
> 
> default:
> 
> 
>  #
>  # Make sure that "device" references the correct serial port
>  # for your modem. (cuaa0 = COM1, cuaa1 = COM2)
>  #
> 
>  set device /dev/cuaa0
> 
>  set log Phase Chat LCP IPCP CCP tun command
>  set speed 57600
>  set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT OK-AT-OK
> ATE1Q0M0 OK \\dATDT\\T TIMEOUT 40 CONNECT"
> 
>  set timeout 120
>  set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
>  add default HISADDR
>  enable dns
> 
> 
> anytime:
> 
>  set phone 08089933001
>  set authname 
>  set authkey 

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: rman wildcard question

[Brian Somers]

> In the gif interface cloning code I used the resource management code
> like Brian did in the tun cloning code to manage unit numbers.  When the
> user requests an arbitrary unit, they get the first one available, but
> I'm not convinced that's what we want because that has the potential to
> interfere with static configurations with temporary holes in them.  It
> seems that a more logical policy would be to allocate the largest
> available unit, but rman_reserve_resource doesn't seem to allow that.
> Is there a way to do this that I'm just not seeing?

Not with rman AFAIK.

Bear in mind though, starting with 0x7fff as an interface unit number 
will look pretty ugly when you ifconfig -a

> -- Brooks

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: cloning network interfaces

[Brian Somers]

> I went ahead and nuked the auto-creation and -D flag in favor of plumb
> and unplumb in the patch at:
> 
> http://www.one-eyed-alien.net/~brooks/FreeBSD/gif.diff
> 
> This version includes a change to rc.network to plumb gif interfaces
> before calling gifcreate.  This will still trip up users who build
> static gif tunnels from hosts with dynamic addresses since they can't
> run gifconfig yet, but we don't really have any means of supporting that
> in the rc files yet anyway.
> 
> -- Brooks

This looks good to me.  I've cc'd freebsd-arch to see if anyone else 
wants to comment.  If there are no objections, I'll test & commit it 
in about a week.
-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: cloning network interfaces

[Brian Somers]

> Ok, I've got the quick and dirty way working for testing (a nine line
> clone handler works great for that), but I think Brian's suggestion is
> probably best for a real solution especialy since it's rather easier to
> check for permissions before allowing creation this way.  My current
> patch lets joe user create 2^15 gif devices by doing "ls /dev/gif###"
> 2^15 times because I didn't have a proc structure handy.  The other
> advantage is that it should be fairly easy to backport to -stable which
> is where the project I'm working on this for is currently being developed.
> 
> I think I'll add a to ifconfig function styled after ifmaybeload() that
> trys to create interfaces if the user trys to do something with them.
> I'm still thinking about the right way to handle creation of new, free
> devices, perhaps a syntax like:
> 
> ifconfig gif#
> 
> where ifconfig returns the interface name the way mdconfig does when you
> don't specify a unit.  If we decied that interfaces that want to grow
> this way will have a /dev/if_ device that accepts the appropriate
> ioctl(s), that should be fairly easy to implement so it works in all
> cases without further hacks to ifconfig.

I think it'd be better to use the solaris ``plumb'' keyword.  I can't 
recall how it works (something like ``ifconfig gif0 plumb'' - I 
haven't got a Solaris machine handy here), but it seemed cleaner, 
making it more obvious what's being done.  An ``unplumb'' keyword may 
be appropriate for doing the removal.

> -- Brooks

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: cloning network interfaces

[Brian Somers]

> In message <[EMAIL PROTECTED]>, Brooks Davis writes:
> 
> >With network devices that are also normal devices the way tun is,
> >you do this by just implementing a dev_clone event handler so when the
> >user attempts to open a non-existent instance it's created.  The problem
> >with gif is that there's no device in /dev to open.  Since most network
> >devices at attached to hardware this usually doesn't matter, but in this
> >case it does.
> >
> >[...]
> >
> >How would this work anyway?
> >
> >Comments, thoughts, ideas?
> 
> The quick and dirty way:
> 
>   Make a clone handler despite the fact that there is no /dev
>   entry needed.  You don't actually have to create a dev entry
>   in the clone handler, you could just create the gif_interface.
> 
>   Applications would then:
> 
>   stat("/dev/gif345") /* Ignore error */
>   system("ifconfig gif345 bla bla bla");
> 
> The slower but less dirty:
> 
>   Make a sysctl which returns an integer which is the next
>   free gif device.
> 
> The really slow and very dirty:
> 
>   Implement cloning in ifconfig.

Maybe a reasonable alternative would be to have a /dev/if_gif device 
with ioctls for creating and destroying interfaces.  ifconfig(8) 
could be taught to create (and maybe even to delete) them.

> -- 
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> [EMAIL PROTECTED] | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: speeding up /etc/security

[Brian Somers]

As you suspect, mounting nosuid makes /etc/security skip the 
suid checks... good for giving the security-unconscious a reason 
to fix their system :)

I was alway quite impressed with this :)

> On Mon, Jun 04, 2001 at 12:07:19PM -0700, Matthew Jacob wrote:
> 
> Does /etc/security take filesystem mounted with:
> 
>  nosuid  Do not allow set-user-identifier or set-group-identifier
>  bits to take effect.  Note: this option is worthless if a
>  public available suid or sgid wrapper like suidperl(1)
>  is installed on your system.
> 
> into account? If so, and the filesystems have nothing on them that
> needs suid you could mount 'm this way
> 
> Just a thought,
> 
> Wilko
> 
> > That's an interesting question.
> > 
> > A couple of ideas:
> > 
> > a) I wonder of RWatson's ACL stuff could help here?
> > 
> > b) This problem cries for a DMAPI type solution- you could have a daemon that
> > monitors all creats/chmods and retains knowledge of the filenames for all
> > SUID/SGID creats/chmods- this way /etc/security would simply summarize the
> > current list and could be run any time.
> > 
> > > /etc/security takes a number of hours to run on my system.  The problem
> > > is that I have some very large mounted file systems and the code to look
> > > for setuid files wants to walk through them all.  I recoded the check in
> > > Perl, but it ran at about the same speed.  I have considered reworking
> > > the code to do the file systems in parallel, but I thought I should ask
> > > here first.  Comments?  Suggestions?
> > > 
> > > -r
> > > 
> > 
> > 
> > 
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-hackers" in the body of the message
> ---end of quoted text---
> 
> -- 
> |   / o / /  _ Arnhem, The Netherlandsemail: [EMAIL PROTECTED]
> |/|/ / / /( (_) Bulte  Powered by FreeBSD/[alpha,x86] http://www.freebsd.org  

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: telnet to AF_UNIX sockets [PATCH]

[Brian Somers]

> 
> :
> :On Wed, 23 May 2001, Matt Dillon wrote:
> :
> :> Nice one!  I'm going to be using this all over the place myself.
> :
> :I am missing something here.  Is there a practical use for this? :)
> :
> :Jamie
> 
> Many programs these days use unix-domain sockets as a rendezvous
> for IPC between processes.  Being able to connect to such sockets
> for monitoring, debugging, development, etc...  can be very useful.

pppctl(8) does this too.

>   -Matt

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ppp problems on 4.3-RELEASE and PPPoE

[Brian Somers]

> According to Brian Somers:
> > Brett Glass (cc'd) has complained about a similar problem where it 
> > seems that the ng_pppoe node is locked up.  I can't reproduce the 
> > problem here though :(
> 
> Does the following help you :
[.]

Not really - I think we need ``physical'' logs so that we can see if 
stuff is actually being written to the netgraph node.  The ``timer'' 
diagnostics are too verbose to be of use here.

The idea is to do the ``ping -c1'', and if everything were working, 
see the physical log show the packet being written to netgraph and 
then netgraph putting it on the wire.

> Nothing really interesting from 'tcpdump -n -i ed0 not ip'...

As in nothing at all ?  I wonder what the last ``not ip'' traffic to be 
written was - perhaps the netgraph node thinks it's closed.

> -- 
> Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED]
> FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun  4 22:44:19 CEST 2000

-- 
Brian <[EMAIL PROTECTED]>
  <http://www.Awfulhak.org>   
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ppp problems on 4.3-RELEASE and PPPoE

[Brian Somers]

Hmm,

I wonder if you can catch it again and do a ``set log local 
physical'' and run ``tcpdump -i XXX -e not ip'' on the interface at 
the same time ?

A ``ping -c 1'' should then show if ppp's sending the data out, and 
if it is, if ng_ether is forwarding it.

I'm a little concerned about the MRU of 1500 too.  The peer seems 
broken.  I have patches to fix this, but they've been paid for as 
part of another project so will have to wait 'till the source is 
released.  If the ping packet goes out but nothing comes back it may 
indicate that the peer is hung up trying to send a 1500+8 byte packet 
across an Ethernet that can only handle 1500

> According to Brian Somers:
> > If pppctl is still working (ppp will talk to it), then it may be 
> > worth seeing what ``show physical'' and ``show timer'' say (is the 
> > link open, or is ppp waiting for something to happen via a timeout?).
> 
> Locked again with a pppctl attached.
> 
> show timer
> -=-=-
> IPCP throughput timer[0x80a37d8]: freq = 1.00s, next = 0.00s, state = running
> physical throughput timer[0x80af068]: freq = 1.00s, next = 0.90s, state = running
> hdlc timer[0x80b1d84]: freq = 60.00s, next = 22.90s, state = running
> -=-=-
> 
> show physical
> -=-=-
> Name: deflink
>  State:   open (established)
>  Device:  PPPoE:ed0:
>  Link Type:   background
>  Connect Count:   1
>  Queued Packets:  0
>  Phone Number:N/A
> 
> Defaults:
>  Device List: "PPPoE:ed0:"
>  Characteristics: sync, cs8, no parity, CTS/RTS on
>  CD check delay:  device specific
> 
> Connect time: 24:08:11
> 14864337 octets in, 8655370 octets out
> 56740 packets in, 56238 packets out
>   overall  270 bytes/sec
>   currently  0 bytes/sec in,  0 bytes/sec out (over the last 5 secs)
>   peak   70148 bytes/sec on Mon May 21 20:02:16 2001
> -=-=-
> 
> show lcp
> -=-=-
> PPP ON keltia> show lcp
> deflink: LCP [Opened]
>  his side: MRU 1492, ACCMAP , PROTOCOMP off, ACFCOMP off,
>MAGIC 6317ffaa, MRRU 0, SHORTSEQ off, REJECT 
>  my  side: MRU 1500, ACCMAP , PROTOCOMP off, ACFCOMP off,
>MAGIC 0c7a6a1f, MRRU 0, SHORTSEQ on, REJECT 
> 
>  Defaults: MRU = 1492, ACCMAP = 
>LQR period = 30s, Open Mode = active (delay 1s)
>FSM retry = 3s, max 5 Config REQs, 5 Term REQs
> Ident: 
> 
>  Negotiation:
>ACFCOMP =   disabled & denied
>CHAP =  disabled & accepted
>CHAP80 =disabled & accepted
>LANMan =disabled & accepted
>CHAP81 =disabled & accepted
>LQR =   disabled & denied
>PAP =   disabled & accepted
>PROTOCOMP = disabled & accepted
> -=-=-
> 
> -- 
> Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED]
> FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun  4 22:44:19 CEST 2000

-- 
Brian <[EMAIL PROTECTED]>
  <http://www.Awfulhak.org>   
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: sysctl to disable reboot

[Brian Somers]

> > That's a good point.  A more sophisticated sysctl again would be one that 
> > would prevent the loading of a new keymap which enabled rebooting where 
> > the previous one did not.
> 
> > cons.keymap.protected perhaps?
> 
> I could impliment a cons.keymap.securelevel which did:
> 
>   0: Anyone can change the keymap.
>   1: Only root can change keys with effects like reboot, panic, ...
>   2: Only root can make any change to the keymap.
> 
> Or would that be overkill? (The name is certainly a bit silly ;-)

I would have guessed that suser()ing keymap changes would be most 
appropriate.  After all, a keymap change survives a logout and should 
really only be changed with care.

Having said that, a malicious user with access to the keyboard can 
install some quite hideous root traps (a program that says login: etc 
etc).

>   David.

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ppp problems on 4.3-RELEASE and PPPoE

[Brian Somers]

Hi,

I think it's important to quantify what a lockup is here.

If pppctl is still working (ppp will talk to it), then it may be 
worth seeing what ``show physical'' and ``show timer'' say (is the 
link open, or is ppp waiting for something to happen via a timeout?).

If pppctl isn't working it's worth building with -g and trying a kill 
-11 (or attaching with gdb) to get a stack trace.

Brett Glass (cc'd) has complained about a similar problem where it 
seems that the ng_pppoe node is locked up.  I can't reproduce the 
problem here though :(

> According to James Housley:
> > and I am not in Canada.  I am using natd and ipfw for NAT and the
> > firewall.  The link has a static IP if it matters.  Below I am attaching
> > ppp.conf.  I have watched some of the data with tcpdump on both tun0 and
> 
> I'm also using ppp + ng_pppoe on a 4.3-STABLE system. My MTU is
> 1492. Configuration below. I'm experiencing lockups from ppp (average is one
> time a day). ppp stops recieving anything from the modem (Alcatel Speed Touch
> Home with ethernet).
> 
> Any idea where it could come from?
> 
> -=-=-
> default:
>  set device /dev/cuaa0
>  set speed 115200
>  disable lqr
>  deny lqr
>  set redial 15 0
>  set reconnect 15 1
>  set accmap 0
>  set server +3000 
> 
> adsl:
>  set device PPPoE:ed0:
>  set authname *
>  set authkey *
>  set timeout 0
>  set mtu 1492
>  set mru 1492
>  set speed sync
>  disable acfcomp protocomp
>  deny acfcomp
>  set log Phase Chat LQM hdlc LCP IPCP CCP tun
>  set ifaddr 0/0 0/0
>  add 0 0 HISADDR
>  dial
> -=-=-
> 
> Nothing interesting from the ppp log :-(
> -- 
> Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED]
> FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun  4 22:44:19 CEST 2000

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ppp problems on 4.3-RELEASE and PPPoE

[Brian Somers]

Try reducing the interface MTU further.  It's possible that there's a 
misconfigured router between you and the sites *and* a part of the 
route has an mtu of less than 1492.

``set mtu 1480'' or ``set mtu 1460'' may work.

> I have been having problems with the the newer Windows machines, 2000 &
> Me, not being able to access some websites.  I have had to manually edit
> the registry to change the MTU.  This should not be needed, because I am
> running 4.3-RELEASE which has had the tcpmssfixup feature for a while. 
> It is enabled.  Unfortunately this maching is in an office in Canada,
> and I am not in Canada.  I am using natd and ipfw for NAT and the
> firewall.  The link has a static IP if it matters.  Below I am attaching
> ppp.conf.  I have watched some of the data with tcpdump on both tun0 and
> ed0, but I am not sure what to look for.
> 
> Suggestion on how to proceed.
> 
> Jim
> 
>  ppp.conf 
> default:
>  ident user-ppp VERSION (built COMPILATIONDATE)
> 
>  # Ensure that "device" references the correct serial port
>  # for your modem. (cuaa0 = COM1, cuaa1 = COM2)
>  #
>  set device /dev/cuaa1
> 
>  set log Phase Chat LCP IPCP CCP tun command
>  set speed 115200
>  set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \
>\"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT"
>  set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
>  set timeout 180# 3 minute idle timer (the
> default)
>  add default HISADDR# Add a (sticky) default route
>  enable dns # request DNS info (for
> resolv.conf)
> 
> magma:
>  ident
>  set device PPPoE:ed0
>  set MRU 1492
>  set MTU 1492
>  set authname **
>  set authkey ***
>  set log Phase Chat Connect
>  set dial
>  set login
>  set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0/0 0.0.0.0/0
>  set timeout 0
>  set server +3000 ***
>  enable tcpmssfixup
>  disable dns
>  set cd 5
>  set crtscts off
>  enable pap
>  disable pred1
> 
> --
> -- 
> /"\   ASCII Ribbon Campaign  .
> \ / - NO HTML/RTF in e-mail  .
>  X  - NO Word docs in e-mail .
> / \ -
> [EMAIL PROTECTED]  http://www.FreeBSD.org The Power to Serve
> [EMAIL PROTECTED]  http://www.TheHousleys.net
> -
> The wise man built his network upon Un*x.
> The foolish man built his network upon Windows.

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

How to auto-boot from an alternate disk

[Brian Somers]

Hi,

I have a machine with 3 IDE disks and 2 SCSI disks and I want to boot 
from the first SCSI disk *but* my BIOS won't boot it.

How are you supposed to do this ?

I've currently done

# boot0cfg -v -t 10 -B -s 5 ad0
# boot0cfg -v -t 1 -B -s 5 -m 0 ad1
# boot0cfg -v -t 1 -B -s 5 -m 0 ad2

Which causes things to merrily skip across my IDE disks 'till it 
finds the first SCSI disk, loads /boot/loader from there, finds my 
kernel and then drops into a dumb ``manual mount'' prompt that makes 
me say ``ufs:/dev/da0s1a''.

What I'd *REALLY* like is some way to just say ``default to 
3:da(0,a)/boot/loader''.

Any suggestions ?

Ta.
-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: xargs(1) "replstr" patch

[Brian Somers]

I'd suggest going ahead and committing it ASAP - before people start 
``discussing'' it again :oI

Feel free to blame me for reviewing it !!!

> Folks,
> 
> The attached patch adds a "replacement string" feature to xargs(1).
> There's a full description in the man page update (also attached), but
> the following should demonstrate the new functionality:
> 
>   dima@spike% ./xargs -J [] echo CMD LINE [] ARGS < test
>   CMD LINE this is the contents of the test file ARGS
>   dima@spike% ./xargs -J [] echo CMD [] LINE ARGS < test
>   CMD this is the contents of the test file LINE ARGS
>   dima@spike% ./xargs -J [] echo [] CMD LINE ARGS < test
>   this is the contents of the test file CMD LINE ARGS
> 
> This is similar to, but not identical to, the -I option described in
> SUSv2.  The latter allows the replstr ("[]" above) to be attached to
> other arguments, and appear multiple times.  Furthermore, it implies
> '-n 1'.  Although the features are similar, they can solve different
> problems; even if -I is implemented later, this (-J) would still be
> useful.  -J also doesn't have the performance implications attached
> with -I.
> 
> There was a nice, long thread about this on current a few weeks ago
> (topic: "Re: cp -d dir patch for review (or 'xargs'?)").  It was
> rather inconclusive, but nobody managed to come up with a way to
> *properly* and *easily* imitate this functionality.  Writing a script
> to do this *properly* (i.e., handle environment growth) isn't as easy
> as it sounds (although it's possible, of course).
> 
> The patch is a joint effort between myself and Garance Dorsihn (gad).
> 
> Comments?  Suggestions?
> 
> Thanks in advance,
> 
>   Dima Dorfman
>   [EMAIL PROTECTED]
[.]
-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Writing device drivers (was: help me please)

[Brian Somers]

> hi,
> Thanx Julian for pointing me to the tunnel pseudo-driver.
> But my major concern was regarding linking the driver to the kernel( i 
> am trying to use static linking stuff). I am presently doing
> a major grep on "tun" 8-)
>  It would be great if i could get some docs regding which files
> have to be modified so that the kernel realises my driver. So far
> i could figure out that the below files have to be modified( did i leave 
> anything )
> 
> /usr/src/sys/i386/conf/*
> /usr/src/sys/conf/majors
> /usr/src/sys/conf/files

That's about it.

>  Do i really have to modify the /usr/src/sys/modules/* files???

Only if you want a module (and have a MODULE_DECLARE in your source). 
I would suggest that it's worthwhile spending the time making your 
code modular - it makes development easier and leads to better 
practices of ensuring that your detach cleans up all resources etc.

> jayesh

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Writing device drivers (was: help me please)

[Brian Somers]

> On Wednesday,  9 May 2001 at 10:40:50 +0530, Jayesh Krishna wrote:
> > Hi guys...
> > I am comfortable with Linux Device Drivers. Presently I am trying
> > to write some pseudo-drivers in FreeBSD(4.2-Release). I tried out
> > make_pseudo_driver.sh
> > in the /usr/share/examples/drivers but it does not work :-( I also
> > went through the "FreeBSD Device Driver Writer's Guide" by Eric L.
> > Hernes but it seems to be outdated :-(
> > Please someone point me out to some docs regarding writing device
> > drivers in FreeBSD
> 
> "UTSL".  Take a look at a similar driver and get to understand it.
> I'm afraid that this is an area which is woefully undocumented.
> 
> You'll also get more replies if you put a useful text on the Subject:
> line.

You should probably tell julian@ about the problems you have with 
make_pseudo_driver.sh.

> Greg
> --
> Finger [EMAIL PROTECTED] for PGP public key
> See complete headers for address and phone numbers

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: pax(1) gzip functionality

[Brian Somers]

> On Thu, Apr 26, 2001 at 04:42:44PM +0100, Brian Somers wrote:
> > > On Thu, Apr 26, 2001 at 02:54:25AM -0700, Kris Kennaway wrote:
> > > > Please review the following code from OpenBSD; it adds -z and -Z
> > > > options to pax(1) to gzip(1) the archives created.
> > > 
> > > Sigh.  They could have generalized this just a little and supported Bzip2
> > > at the same time.  Please let me know after you commit this so I can do
> > > this.
> > 
> > Is this necessary ?  What's the problem with using a pipe ?  Isn't 
> > this the same argument as the xargs one we've just gotten through ?
> 
> What's wrong with:
> tar cf - foo | gzip >foo.tar.gz
> gzip -dc foo.tar.gz | tar xf -
> 
> Someone deemed them too inconvient for the number of times they are
> invoked.  I'm not going to enter that discussion, but _if_ gzip support
> is added, I feel bzip2 support should be added to be orthogonal with
> today's uses.

Agreed.

> -- 
> -- David  ([EMAIL PROTECTED])

-- 
Brian <[EMAIL PROTECTED]>
  <http://www.Awfulhak.org>   
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: pax(1) gzip functionality

[Brian Somers]

> On Thu, Apr 26, 2001 at 02:54:25AM -0700, Kris Kennaway wrote:
> > Please review the following code from OpenBSD; it adds -z and -Z
> > options to pax(1) to gzip(1) the archives created.
> 
> Sigh.  They could have generalized this just a little and supported Bzip2
> at the same time.  Please let me know after you commit this so I can do
> this.

Is this necessary ?  What's the problem with using a pipe ?  Isn't 
this the same argument as the xargs one we've just gotten through ?

Maybe I'm missing something...

> -- 
> -- David  ([EMAIL PROTECTED])

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: VPN

[Brian Somers]

> no vpn or sloop labels in my 4.1 system ... when were they introduced ??

They were MFC'd on December 18 '00, 4.1 was released the August 
before.
-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: VPN

[Brian Somers]

>  
> > Actually ppp shouldn't be that hard to set up as a vpn server.
> 
> exactly where to find  config information suitable for a non-expert ??

/usr/share/examples/ppp - have a look at the vpn* and sloop* labels.

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: vm fun

[Brian Somers]

> Hi,
>   
> If inside a syscall, what is the proper way to find the physical address of
> an arbitrary userland address of the current process ?

Probably something like VM_PAGE_TO_PHYS - but you'll need a vm_page_t 
to use that.  vm_page_list_find() looks promising, but I've never 
used it :-/

> Thanks,
> David Rufino

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Modules with INVARIANTS

[Brian Somers]

Hi,

Does anyone know of a clean way to have module builds detect that 
INVARIANTS is defined in opt_global.h ?
-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Patch to make snp(4) devfs-friendly

[Brian Somers]

This looks good.  I'd say you should commit the change yourself - 
feel free to say it's reviewed by me.

As an aside, when I did this to if_tun, I chose to do all the 
destroy_dev()s at module unload time (I guess the snp device could do 
with a MODULE_DECLARE).  This allows the administrator to relax the 
driver-chosen permissions on tun devices with something like

  kldload if_tun
  >/dev/tun0
  chmod blah /dev/tun0

The destroy_dev() added to snpclose() prevents this.

Having said all that, it's unlikely that anyone would want to relax 
the permissions a snoop device that wasn't already opened, so the 
destroy_dev() looks ok here in practice.

> Brian Somers <[EMAIL PROTECTED]> writes:
> > I haven't actually tested the code, but looking at the patch, I think 
> > there's a problem with it...
> > 
> > Specifically, on a non-devfs system - where the device nodes are 
> > created with mknod(1), snp_clone() isn't going to be called before 
> > snpopen().
> > 
> > I've (ab)used drv2 as a flag to say whether make_dev() has been 
> > called in net/if_tun.c, but I'm not sure if this is the right answer 
> > either :*]
> 
> I think the correct approach is to check for !(si_flags & SI_NAMED) as
> done in rev. 1.68 of sys/net/bpf.c (that rev. has a precedence bug,
> which has since been fixed).  That was written by phk, who I take to
> be pretty authoritative on the subject; looking at the places SI_NAMED
> is used also supports this conclusion.
> 
> A corrected patch is attached (although I didn't test it in the
> non-devfs case).
> 
> Thanks!
> 
>   Dima Dorfman
>   [EMAIL PROTECTED]
> 
> 
> Index: tty_snoop.c
> ===
> RCS file: /st/src/FreeBSD/src/sys/kern/tty_snoop.c,v
> retrieving revision 1.52
> diff -u -r1.52 tty_snoop.c
> --- tty_snoop.c   2001/03/26 12:41:01 1.52
> +++ tty_snoop.c   2001/04/17 09:16:52
> @@ -287,10 +287,10 @@
>   return (error);
>  
>   if (dev->si_drv1 == NULL) {
> - int mynor = minor(dev);
> -
> + if (!(dev->si_flags & SI_NAMED))
> + make_dev(&snp_cdevsw, minor(dev), UID_ROOT, GID_WHEEL,
> + 0600, "snp%d", dev2unit(dev));
>   dev->si_drv1 = snp = malloc(sizeof(*snp), M_SNP, M_WAITOK|M_ZERO);
> - make_dev(&snp_cdevsw, mynor, 0, 0, 0600, "snp%d", mynor);
>   } else
>   return (EBUSY);
>  
> @@ -365,6 +365,7 @@
>   free(snp->snp_buf, M_SNP);
>   snp->snp_flags &= ~SNOOP_OPEN;
>   dev->si_drv1 = NULL;
> + destroy_dev(dev);
>  
>   return (snp_detach(snp));
>  }
> @@ -505,10 +506,25 @@
>  static void snp_drvinit __P((void *unused));
>  
>  static void
> +snp_clone(void *arg, char *name, int namelen, dev_t *dev)
> +{
> + int u;
> +
> + if (*dev != NODEV)
> + return;
> + if (dev_stdclone(name, NULL, "snp", &u) != 1)
> + return;
> + *dev = make_dev(&snp_cdevsw, unit2minor(u), UID_ROOT, GID_WHEEL, 0600,
> + "snp%d", u);
> + return;
> +}
> +
> +static void
>  snp_drvinit(unused)
>   void *unused;
>  {
>  
> + EVENTHANDLER_REGISTER(dev_clone, snp_clone, 0, 1000);
>   cdevsw_add(&snp_cdevsw);
>  }
>  

-- 
Brian <[EMAIL PROTECTED]>
  <http://www.Awfulhak.org>   
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Patch to make snp(4) devfs-friendly

[Brian Somers]

I haven't actually tested the code, but looking at the patch, I think 
there's a problem with it...

Specifically, on a non-devfs system - where the device nodes are 
created with mknod(1), snp_clone() isn't going to be called before 
snpopen().

I've (ab)used drv2 as a flag to say whether make_dev() has been 
called in net/if_tun.c, but I'm not sure if this is the right answer 
either :*]

> Attached is a patch to make the snp(4) driver play ball with DEVFS.
> For better or for worse, I used the bpf(4) driver as a guide on how to
> do this.
> 
> If someone could review this, and, if nothing is wrong with it, commit
> it, I'd appreciate it.
> 
> Thanks in advance,
> 
>   Dima Dorfman
>   [EMAIL PROTECTED]
> 
> Index: tty_snoop.c
> ===
> RCS file: /st/src/FreeBSD/src/sys/kern/tty_snoop.c,v
> retrieving revision 1.52
> diff -u -r1.52 tty_snoop.c
> --- tty_snoop.c   2001/03/26 12:41:01 1.52
> +++ tty_snoop.c   2001/04/17 08:17:23
> @@ -286,12 +286,9 @@
>   if ((error = suser(p)) != 0)
>   return (error);
>  
> - if (dev->si_drv1 == NULL) {
> - int mynor = minor(dev);
> -
> + if (dev->si_drv1 == NULL)
>   dev->si_drv1 = snp = malloc(sizeof(*snp), M_SNP, M_WAITOK|M_ZERO);
> - make_dev(&snp_cdevsw, mynor, 0, 0, 0600, "snp%d", mynor);
> - } else
> + else
>   return (EBUSY);
>  
>   /*
> @@ -365,6 +362,7 @@
>   free(snp->snp_buf, M_SNP);
>   snp->snp_flags &= ~SNOOP_OPEN;
>   dev->si_drv1 = NULL;
> + destroy_dev(dev);
>  
>   return (snp_detach(snp));
>  }
> @@ -505,10 +503,25 @@
>  static void snp_drvinit __P((void *unused));
>  
>  static void
> +snp_clone(void *arg, char *name, int namelen, dev_t *dev)
> +{
> + int u;
> +
> + if (*dev != NODEV)
> + return;
> + if (dev_stdclone(name, NULL, "snp", &u) != 1)
> + return;
> + *dev = make_dev(&snp_cdevsw, unit2minor(u), UID_ROOT, GID_WHEEL, 0600,
> + "snp%d", u);
> + return;
> +}
> +
> +static void
>  snp_drvinit(unused)
>   void *unused;
>  {
>  
> + EVENTHANDLER_REGISTER(dev_clone, snp_clone, 0, 1000);
>   cdevsw_add(&snp_cdevsw);
>  }
>  

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ffs dirpref speedup

[Brian Somers]

There's a (maybe overly simple) avoidance algorithm for this.  
It attempts to ensure that it doesn't end up filling up cgs with 
directories and no files.  

There are also two tunables

int32_t  fs_avgfilesize;   /* expected average file size */
int32_t  fs_avgfpdir;  /* expected # of files per directory */

aimed at being able to tune things such as squid caches (and I would 
guess the ports tree).

> We discussed this a while back; it has some interesting (and in some 
> cases) undesirable side-effects.  FFS tries to balance directories across 
> CGs in order to balance the use of CGs for file allocation.  The approach 
> being advocated here will tend to use CGs one at a time, resulting in 
> poor distribution of files and corresponding fragmentation problems.
> 
> > I wonder whether FreeBSD has this improvement or not.
> > 
> > With softupdates or async mounted filesystems it seems that the speedup is
> > very big...
> > 
> > Thanks,
> > --
> > Attila Nagye-mail:  [EMAIL PROTECTED]
> > Budapest Polytechnic (BMF.HU)   @work: +361 210 1415 (194)
> > H-1084 Budapest, Tavaszmezo u. 15-17.   cell.: +3630 306 6758
> > -- Forwarded message --
> > Date: Sat, 7 Apr 2001 02:02:21 +0400
> > From: Grigoriy Orlov <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: Re: CVS: cvs.openbsd.org: src
> > 
> > On Fri, Apr 06, 2001 at 10:27:55PM +0100, Brian Somers wrote:
> > > > CVSROOT:/cvs
> > > > Module name:src
> > > > Changes by: [EMAIL PROTECTED]2001/04/06 14:43:31
> > > >
> > > > Modified files:
> > > > sys/ufs/ffs: fs.h ffs_alloc.c ffs_vfsops.c
> > > > sbin/fsck_ffs  : setup.c
> > > > sbin/tunefs: tunefs.c
> > > >
> > > > Log message:
> > > > Replace FFS directory preference algorithm(dirpref) by new one.
> > > > It allocates directory inode in the same cylinder group as a parent
> > > > directory in. This speedup file/directory intensive operations on
> > > > a big file systems in times.
> > > >
> > > > Don't forget to recompile fsck_ffs with updated fs.h or you will get
> > > > "VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE" at
> > > > the next boot. In any case you can ignore this error safely.
> > > >
> > > > Requested by deraadt@
> > >
> > > Do you have any numbers or statistics ?  Just curious as to how
> > > big/small the gain is
> > 
> >   These results is old and I improve algorithm after these tests was done.
> > Nevertheless they show how big may be perfomance speedup. I have done two
> > file/directory intensive tests on a two OpenBSD systems with old and new
> > dirpref algorithm. The first test is "tar -xzf ports.tar.gz", the second
> > is "rm -rf ports". There ports.tar.gz - port collection from OpenBSD 2.8
> > release, it contains 6596 dirs and 13868 files. The test systems are:
> > 
> > 1. Celeron-450, 128Mb, two IDE drives, the system at wd0, file system for
> >test is at wd1. Size of test file system is 8 Gb, number of cg=991,
> >size of cg is 8m, block size = 8k, fragment size = 1k OpenBSD-current
> >from Dec 2000 with BUFCACHEPERCENT=35
> > 
> > 2. PIII-600, 128Mb, two IBM DTLA-307045 IDE drives at i815e, the system
> >at wd0, file system for test is at wd1. Size of test file system is 40 Gb,
> >number of cg=5324, size of cg is 8m, block size = 8k, fragment size = 1k
> >OpenBSD-current from Dec 2000 with BUFCACHEPERCENT=50
> > 
> >   Test Results
> > 
> >  tar -xzf ports.tar.gz rm -rf ports
> >   mode  old dirpref new dirpref speedup old dirpref new dirpref speedup
> >  First system
> >  normal 667 472  1.41   477331   1.44
> >  async  285 144  1.98   130 14   9.29
> >  sync   768 616  1.25   477334   1.43
> >  softdep413 252  1.64   241 38   6.34
> >  Second system
> >  normal 329 81   4.06   263.5   93.5 2.81
> >  async  302 25.711.75   112  2.26   49.56
> >  sync   281 

Re: Vinum stripe size (was: tuning a VERY heavily (30.0) loaded server)

[Brian Somers]

> On Tuesday, 27 March 2001 at  9:39:36 +0100, Brian Somers wrote:
> >> On Tuesday, 20 March 2001 at 11:11:44 -0600, Michael C . Wu wrote:
> >>> [Lengthy email, bear with me please, it is quite interesting.
> >>> This box averages 30.0 load with no problems.]
> >>>
> >>> 
> >>>
> >>> Average file size is about 4K.  /home/bbsusers* is on a vinum
> >>> stripe'd volume with 3 Ultra160 9G 1RPM drives on sym0 at stripe
> >>> size 256K,  Greg: I know this should be a prime number,
> >>
> >> No, there's no requirement for it to be a prime number.  The only
> >> problem is that with 32 MB cylinder groups and a power of two stripe
> >> size and subdisk count, you end up with all the superblocks on one
> >> subdisk, which is a performance issue.  Choose the stripe size so that
> >> the superblocks are roughly evenly distributed.
> >
> > A performance issue ?  Surely you've misspelt ``reliability'' ?
> 
> I don't see a reliability issue here.

I believe the only issue with having all your superblocks on one disk 
is a reliability thing - if you lose the disk you lose your 
superblock(s).  Surely the only performance problem would be that of 
locality - if you use the partition a bit, that ``problem'' should go 
away though.

> Greg
> --
> Finger [EMAIL PROTECTED] for PGP public key
> See complete headers for address and phone numbers

-- 
Brian <[EMAIL PROTECTED]>
  <http://www.Awfulhak.org>   
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Control messages.

[Brian Somers]

I can't see where in the kernel we're *not* using CMSG_DATA().  This 
was fixed a while ago and tested ok on beast (for 3 descriptors 
AFAIR).  Are we looking at the same code (I'm looking in /sys/kern) ?

The only dodgy thing I see in there is the COMPAT_OLDSOCK stuff in 
uipc_syscalls.c, and that has a very nice disclaimer:

/*
 * We assume that old recvmsg calls won't receive access
 * rights and other control info, esp. as control info
 * is always optional and those options didn't exist in 4.3.
 * If we receive rights, trim the cmsghdr; anything else
 * is tossed.
 */

> I was looking at our implimention of passing descriptors and
> credentials over unix domain sockets (I want to add the ability to
> pass more than one message at a time). According to Steven's book
> you should use the CMSG_DATA macro to find the data in associated
> with a struct cmsghdr. We define this macro as:
> 
> #define CMSG_DATA(cmsg) ((u_char *)(cmsg) + \
>  _ALIGN(sizeof(struct cmsghdr)))
> 
> However, the kernel seems to get the address of the data by looking
> at (void *)(&cmsg[1]). Some applications either find the data either
> using the kernel's method or by using:
> 
>   struct blah {
>   struct cmsghdr header;
>   sturct wibble data;
>   };
> 
> and taking the address of "data". Fortunately all these methods are
> the same on the i386 'cos the sizeof(sizeof(struct cmsghdr)) is a
> multiple of the alighment size. However on the alpha the alignment
> requirement is 8 bytes and so:
> 
>   CMSG_DATA(cmsg) != (&cmsg[1])
> 
> If you use the struct method then offset of "data" will line up
> with one or the other of these depending on the alignment requirements
> of data.
> 
> I'd like to change the code to always use the CMSG_DATA method,
> which will change the ABI on the alpha. This shouldn't cause too
> much disruption as descriptor and credential passing is rarely
> used. (I think ppp and maybe some rpc stuff use it - not much
> else does).
> 
> (As far as I can tell descriptor passing for a large number of
> descriptors will panic an alpha running FreeBSD too. If anyone can
> give access to an alpha that it's OK for me to crash I can test
> this).
> 
>   David.

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Vinum stripe size (was: tuning a VERY heavily (30.0) loaded server)

[Brian Somers]

> On Tuesday, 20 March 2001 at 11:11:44 -0600, Michael C . Wu wrote:
> > [Lengthy email, bear with me please, it is quite interesting.
> > This box averages 30.0 load with no problems.]
> >
> > 
> >
> > Average file size is about 4K.  /home/bbsusers* is on a vinum
> > stripe'd volume with 3 Ultra160 9G 1RPM drives on sym0 at stripe
> > size 256K,  Greg: I know this should be a prime number,
> 
> No, there's no requirement for it to be a prime number.  The only
> problem is that with 32 MB cylinder groups and a power of two stripe
> size and subdisk count, you end up with all the superblocks on one
> subdisk, which is a performance issue.  Choose the stripe size so that
> the superblocks are roughly evenly distributed.

A performance issue ?  Surely you've misspelt ``reliability'' ?

> Greg
> --
> Finger [EMAIL PROTECTED] for PGP public key
> See complete headers for address and phone numbers

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: PPPD!

[Brian Somers]

> Hi!
> Does anybody know about support pppunit in the ppp conf files, or may be
> can advice me where I can read about pppunit.
> Thank you very much.

I'm afraid I can't really help, but I believe ppp(8) can do the same 
thing with the -unit command line switch.
-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Inheriting the nodump flag

[Brian Somers]

> Attached below is a port of NetBSD's patch to FreeBSD's dump(8).
> dump's tree walker is a little weird, so the patch is a little more
> complicated than calling fts_set with FTS_SKIP.  For the technical
> details of what it does, see:
> http://lists.openresources.com/NetBSD/tech-kern/msg00453.html.
[.]
> Comments?

Just that I noticed a typo in a comment where ``inherited'' is misspelt 
``herited'' going via your URL but it's fixed in the attached 
patch :-)  It's probably worth updating the web page.

I'd certainly like to see this committed - I'm sick of backing up 
release directories, cvs repositories and /usr/obj :-)

> Thanks in advance
> 
>   Dima Dorfman
>   [EMAIL PROTECTED]

Cheers.
-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: character device driver

[Brian Somers]

[.]
> In my mind, it is important that (in the general case) we provide a struct
> file state hook rather than having per-process state, to allow things like
> threads, process teams, aio, file descriptor passing, etc, to work
> properly.  One advantage to tying VFS statefulness to device statefulness
> is you get some nice benefits like guarantees about open/close pairs on
> devices.  I think there aren't too many VFS complications -- the only
> complications might be if vnodes are ever used for relevant calls
> (ioctl, read, write, ...) without a VOP_OPEN first -- a few used to exist
> but I think those have been cleaned up.

IMHO phk's recent suggestion on -arch was excellent.

The idea is that a driver calls make_dev() with some sort of CLONE 
flag.  When a lookup() happens and devfs sees that the path points to 
such a device, it asks the driver for a udev_t.  The driver may (if 
it wants to) call make_dev(), and then returns the udev_t.  devfs 
creates the vnode and returns it to the caller.  The VOP_OPEN then 
happens as usual.  (I'm not sure what magic devfs needs to do with 
the nameidata at this point).

The good thing about this is that the driver gets to declare a minor 
as being a CLONE device and gets to choose whether it'll return a new 
minor or not for the imminent open().  fork(), exec() and dup*() will 
make new references to the same vnode, as will open()s of the device 
if the driver did a make_dev().  Some sort of locking will be 
required so that the driver can handle udev_t requests while others 
are outstanding...

I'd like to implement something (if I ever get the time) and post 
patches to -arch & phk, as this seems to solve all the problems I 
know of :-)

> Robert N M Watson FreeBSD Core Team, TrustedBSD Project
> [EMAIL PROTECTED]  NAI Labs, Safeport Network Services

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ADSL and PPPoE question

[Brian Somers]

[.]
> I thought something like this:
> 
> 
>[ISP]
>  |
>  |
> -
> Office [ADSL]
>  |
>  |
> [FreeBSD Box]
>   |  |  |  |
>   |  |  |  |
>  [A][B][C][D]
> 
> where A, B, C, D all have their own routable IPs.   So according to what you
> said, FreeBSD would need to establish a separate PPPoE session for each of
> the computers A, B, C and D, provided the ISP supports multiple PPPoE
> sessions over the single ADSL line?

The FreeBSD box should run a single PPPoE session to your provider 
over the ADSL link.  If your provider will route more than one IP to 
you then you can simply run ppp(oE) without the NAT switch and it'll 
just work.  Use the same IP on the FreeBSD box's internal network 
interface as you're using on the local end of the ADSL PPPoE session.

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: What's changed recently with vmware/linuxemu/file I/O

[Brian Somers]

> On Thu, Feb 08, 2001 at 04:58:17AM -0800, Julian Elischer wrote:
> >=20
> > Looks like some way of clustering this might achieve a lot.
> >=20
> > what does systat -vmstat or vmstat 1
> > show?
> > Better still, I guess we could do a linux-truss
> > and see what it's doing...
> 
> I believe that it's strace under linux.  If someone can provide me
> with a binary of this tool I'll happily run it here and see what
> vmware's doing.
> 
> Joe

The problem seems to have gone away after this (kindly pointed out to 
me by Maxim after my other post about xsane dropping cores):

: Subject: cvs commit: src/lib/libc/stdio findfp.c
: Date: Wed, 7 Feb 2001 09:34:50 -0800 (PST)
: From: Maxim Sobolev <[EMAIL PROTECTED]>
: To: [EMAIL PROTECTED], [EMAIL PROTECTED]
: 
: sobomax 2001/02/07 09:34:49 PST
: 
:   Modified files:
: lib/libc/stdio   findfp.c 
:   Log:
:   Fix a f^Hdamn typo, which prevented to fopen() more that 17 files at once.
:   
:   Tested by:  knu, sobomax and other #bsdcode'rs
:   
:   Revision  ChangesPath
:   1.9   +2 -2  src/lib/libc/stdio/findfp.c

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: What's changed recently with vmware/linuxemu/file I/O

[Brian Somers]

> Bruce Evans wrote:
> > 
> > On Tue, 6 Feb 2001, Josef Karthauser wrote:
> > 
> > > I'm wondering what's changed recently to cause vmware2 running on
> > > the linuxemu to lose a lot of performance with disk I/O.
> > 
> > Use of cmpxchg and possibly other SMP pessimizations.
> > 
> > > A couple of weeks ago I could boot win2000 under vmware2 in a matter
> > > of minutes;  on today's kernel it takes 5 or 10 minutes to boot,
> > > and disk I/O is through the roof.
> > >
> > > Could someone please hit me with a clue-bat :)
> > 
> > Read your freebsd-emulation mail :-).
> 
> You are wrong Bruce, the cmpxchg discussion was regarding why
> running FreeBSD as a GUEST OS was slow, because the virtual machine was
> very slow at emulating them. That does not explain why Windows2000 and the Boot
> loader
> both slowed down by a factor or 3->6 over teh last 2 weeks.
> 
> It's even slower to start up, before it has even started any emulation..
> 
> This feels like the system is massively slowing down page activations or
> some other sort of exceptions that are standard for vmware.
> 
> The same vmware with the same guest OS (not been updated) is now much slower.

Indeed.  I've been doing a ``make build'' on an OpenBSD-current vm 
for three days (probably about 36 hours excluding suspends) on a 
366MHz laptop with a ATA33 disk.

This is on a Feb 4 kernel.  NetBSD next

> -- 
>   __--_|\  Julian Elischer
>  /   \ [EMAIL PROTECTED]
> (   OZ) World tour 2000-2001
> ---> X_.---._/  
> v

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: PPPoE

[Brian Somers]

I think the best way to implement this is some sort of config message 
to the pppoe node (before the connect/listen).  The NETGRAPH version 
of ppp(8) is capable of doing ``chat scripts'' with netgraph nodes, 
so it's fairly easy to configure the node configuration conversation...

Hopefully now that Christmas is over I'll be able to get back to 
netgraph'ifying ppp :-)

> Felix-Antoine Paradis wrote:
> > 
> > To get pppoe to work, just set the options in the kernel and use a good
> > config (ppp.conf) and use pppd.
> > 
> > On Mon, 22 Jan 2001, Daniel C. Sobral wrote:
> > 
> > > It seems I need the following parameters to get my PPPoE to work. Could
> > > we have these options, please?
> > >
> > > >> -f disc:sess
> > > >>The  -f  option  sets  the Ethernet frame types for
> > > >>PPPoE discovery and session frames.  The types  are
> > > >>specified  as  hexadecimal  numbers  separated by a
> > > >>colon.  Standard PPPoE uses frame types  8863:8864.
> > > >>You should not use this option unless you are abso¡
> > > >>lutely sure the peer you are dealing with uses non-
> > > >>standard  frame  types.  If your ISP uses non-stan¡
> > > >>dard frame types, complain!
> 
> Definitly complain! This is equivalent to calling a protocol tcp/ip
> but using a first byte in the packet.
> I will look at a configuration message for the netgraph node
> but Brian will hav eto work out how to send it, and where the
> configuration parameter should be set to do this..
> 
> The other possibility is a sysctl.
> 
> 
> > > >>  -S service_name
> > > >> Specifies the desired  service  name.   pppoe  will
> > > >> only  initiate  sessions  with access concentrators
> > > >> which can provide the specified service.   In  most
> > > >> cases,  you should not specify this option.  Use it
> > > >> only if you know that  there  are  multiple  access
> > > >> concentrators or know that you need a specific ser¡
> > > >> vice name.
> 
> 
> If you are talking about the netgraph based pppoe, then -xxx type 
> flags are not how you configure it.  I think you are talking about
> the (rather inefficient) userland ppp daemon.
> 
> the service name requested is already an argument in the pppoe 
> configuration.
> 
> "If a PPPoE:iface[:provider] specification is given, ppp will at-
> tempt to create a PPP over Ethernet connection using the given
> iface interface by using netgraph(4). "
> 
> In this case the "provider" is the service name.
> 
> 
> -- 
>   __--_|\  Julian Elischer
>  /   \ [EMAIL PROTECTED]
> (   OZ) World tour 2000
> ---> X_.---._/  from Perth, presently in:  Budapest
> v

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: PPP failures in 4.2-STABLE

[Brian Somers]

Hi,

The only thing that comes to mind here is that perhaps you've got 
something like hylafax or mgetty running against the same port and 
something's gone wrong with the port locking code.

It *looks* like something's writing fax commands to your modem at the 
same time as you're trying to dial

> Hi all,
> 
>   After updating to 4.2-STABLE (previous version was 4.1.1-RELEASE) I'm
>   having some strange problem with ppp. When I try to connect for the
>   first time to an ISP the following occurs:
> 
>   ppp[177]: tun0: Chat: Send: ATDT22334455^M
>   ppp[177]: tun0: Chat: Expect(120): CONNECT
>   ppp[177]: tun0: Chat: Received: ATDT22334455^M^M
>   ppp[177]: tun0: Chat: Received: +FHS:11^M
>   ppp[177]: tun0: Chat: Received: ^M
>   ppp[177]: tun0: Chat: Received: OK^M
>   ppp[177]: tun0: Chat: Parent notified of failure
>   (I press ^c here because nothing happens)
> 
>   Then, I try again and it works fine, but If the time between the first
>   and the second connection is too long I receive the same error again,
>   so I can't wait too much to do the second try.
> 
>   Another error that I got these days is the following (a bit like the
>   previous one but with something more):
> 
>   ppp[315]: tun0: Chat: Send: ATDT22335040^M
>   ppp[315]: tun0: Chat: Expect(120): CONNECT
>   ppp[315]: tun0: Chat: Received: ATDT22335040^M^M
>   ppp[315]: tun0: Chat: Received: +FCO^M
>   ppp[315]: tun0: Chat: Received: ^M
>   ppp[315]: tun0: Chat: Received: +FHS:11^M
>   ppp[315]: tun0: Chat: Received: ^M
>   ppp[315]: tun0: Chat: Received: OK^M
>   ppp[315]: tun0: Chat: Parent notified of failure
>   (I press ^C here because nothing happens)
> 
>   When dialing to this particular ISP other strange thing happens, cause
>   even if I try for the second time (without spending too much time bet-
>   ween the two tries) ppp aborts the operation:
> 
>   ppp[325]: tun0: Chat: Send: ATDT22335040^M
>   ppp[325]: tun0: Chat: Expect(120): CONNECT
>   ppp[325]: tun0: Chat: Received: ATDT22335040^M^M
>   ppp[325]: tun0: Chat: Received: CONNECT 50666/ARQ/V90/LAPM/V42BIS^M
>   ppp[325]: tun0: Chat: Parent notified of failure
>   (I didn't press ^C this time)
> 
>   The relevant parts of my ppp.conf follows:
> 
>   # ppp.conf
> 
>   default:
>   set log command chat tun connect
>   set device /dev/cuaa1
>   set speed 115200
>   set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 15 \"\" AT OK-AT-OK
> ATE1Q0 OK
> 
>   isp1:
>set redial 1 50
>set phone 22334455
>set authname isp1-user
>set authkey isp1-pass
>set timeout 80
>set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
>add default HISADDR
> 
>  isp2:
>set phone 22335040
>set authname isp2-user
>set authkey isp2-pass
>set timeout 100
>set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
>add default HISADDR
> 
>   # EOF
> 
>   My modem is a internal USRobotics 56k (x2/v90) and as additional
>   information this doesn't happen in Linux (2.2.17).
> 
>   If this isn't the correct mailing list forgive me please (perhaps
>   -stable would be the one, but anyway).
> 
>   Thanks in advance,
> 
> 
> Giovanni P. Tirloni
> 
> mail: [EMAIL PROTECTED]
> mail: [EMAIL PROTECTED]
> fone: +55 44 225 6267

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: PPPoE w/ nat auto fragmentation hack? (use tcpmssd port)

[Brian Somers]

> > ppp will run programs as the user id that invoked ppp rather than
> > using the effective user id (ie, it runs things as *you*, not *root*).
> 
> Mmm-mmh. In my case, since ppp is started at boot time, the only user that
> ever invokes it is root, hence the tcpmssd thingy is run as root. As
> confirmed by the multiple "ps" I ran: euid == ruid == svguid == 0.
> 
> 
> > A good ``first step'' is to run
> >   ! sh -c "/usr/local/bin/tcpmssd -p 12345 -i INTERFACE >/tmp/log 2>&1"
> > so that you can get to see any error messages - ppp redirects I/O to
> 
> Yup, tried that, here's what I get:
> 
>  start ***
> Wed Nov 15 13:30:12 PST 2000
> id says: uid=0(root) gid=0(wheel) groups=0(wheel)
> HOME=/
> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin
> 01001 divert 1234 tcp from any to any out xmit tun0 setup
> 
> The rule gets inserted, tcpmssd runs as root, and I feel like a dummy. Any
> other ideas?
> 
> Thanks for the help Brian,

I'm not sure what the problem could be - can you confirm that 
everything's seen if you divert everything ?

> --Renaud
> 
> 
> 
> - Original Message -
> From: Brian Somers <[EMAIL PROTECTED]>
> To: Renaud Waldura <[EMAIL PROTECTED]>
> Cc: Brian Somers <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>
> Sent: Wednesday, November 15, 2000 4:32 PM
> Subject: Re: PPPoE w/ nat auto fragmentation hack? (use tcpmssd port)
> 
> 
> > > Maybe I'm just being boneheaded, but...
> > >
> > > >   ! sudo ipfw add 4 divert 12345 all from any to any via INTERFACE
> > > >   ! sudo /usr/local/bin/tcpmssd -p 12345 -i INTERFACE
> > >
> > > I was under the (tested & confirmed) impression that programs executed
> by
> > > ppp are run under uid 0. Eg. I don't use "sudo" but the ipfw rule is
> added
> > > anyway, and tcpmssd is run as root.
> > >
> > > But maybe a sudo environment brings something else? That could explain a
> lot
> > > right there.
> > >
> > > --Renaud
> >
> > ppp will run programs as the user id that invoked ppp rather than
> > using the effective user id (ie, it runs things as *you*, not *root*).
> >
> > AFAIK, sudo will not muck about with your environment
> >
> > A good ``first step'' is to run
> >
> >   ! sh -c "/usr/local/bin/tcpmssd -p 12345 -i INTERFACE >/tmp/log 2>&1"
> >
> > so that you can get to see any error messages - ppp redirects I/O to
> > /dev/null by default.

-- 
Brian <[EMAIL PROTECTED]>
  <http://www.Awfulhak.org>   
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: PPPoE w/ nat auto fragmentation hack? (use tcpmssd port)

[Brian Somers]

> Maybe I'm just being boneheaded, but...
> 
> >   ! sudo ipfw add 4 divert 12345 all from any to any via INTERFACE
> >   ! sudo /usr/local/bin/tcpmssd -p 12345 -i INTERFACE
> 
> I was under the (tested & confirmed) impression that programs executed by
> ppp are run under uid 0. Eg. I don't use "sudo" but the ipfw rule is added
> anyway, and tcpmssd is run as root.
> 
> But maybe a sudo environment brings something else? That could explain a lot
> right there.
> 
> --Renaud

ppp will run programs as the user id that invoked ppp rather than 
using the effective user id (ie, it runs things as *you*, not *root*).

AFAIK, sudo will not muck about with your environment

A good ``first step'' is to run

  ! sh -c "/usr/local/bin/tcpmssd -p 12345 -i INTERFACE >/tmp/log 2>&1"

so that you can get to see any error messages - ppp redirects I/O to 
/dev/null by default.

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: PPPoE w/ nat auto fragmentation hack? (use tcpmssd port)

[Brian Somers]

> 
> On Tue, 14 Nov 2000, Renaud Waldura wrote:
> 
> ->Dear hackers,
> ->
> ->> What exactly does not work?
> ->> What does the option -l do?
> ->
> ->When launched automatically by ppp, tcpmssd doesn't get any of the packets
> ->and is useless. When I start it manually from the command line, it works
> ->fine.
> ->
> ->I realize this isn't much in the way of helpful debugging information, and
> ->was hoping to further define this: I implemented that "-l" option to log all
> ->the packets processed by tcpmssd. I'm not even sure this bug applies to
> ->anybody else, which is why I did not seek help or publicize it until now.
> ->
> ->Anyway, I haven't been able to figure out what the problem is (and am
> ->lacking time now). The best I have is this: when launched by ppp, tcpmssd
> ->never seems to return from the main select() call. Ruslan, if you feel like
> ->an account on the machine where I'm using this could help, just let me know
> ->and I will gladly give you one.
> 
> It does not work for me either.  Start the script in rc.local rather than
> ppp.linkup works fine.  

What are you doing in ppp.linkup ?

When I add this:

  ! sudo ipfw add 4 divert 12345 all from any to any via INTERFACE
  ! sudo /usr/local/bin/tcpmssd -p 12345 -i INTERFACE

everything seems to work ok

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: PPPoE w/ nat auto fragmentation hack?

[Brian Somers]

> 
> Hi, Any of you happened to hack the PPPoE support on Fbsd 4.x to
> automatically fragment the IP datagram if whatever device behind the
> NAT refuses to adjust its MTU?

There's a ``tcpmssd'' port.

> Thanks

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: PPP patch (CHAP81 + MPPE)

[Brian Somers]

Hi,

Thanks for the patches.  I've committed the changes although I'm 
having problems with MPPE.  I suspect the problems are actually in 
the CCP stuff though - and I've suspected this for some time, 
something to do with running ppp back-to-back (and not over a tty).

I'll look into this soon.

Anyway, thanks again for your work.  It's really appreciated.

> Hi!
> 
> Here is a patch attached (made from current from 2813).
> 
> Patch makes ppp able to respond and initiate MS-CHAP-v2 authentication and
> supports MPPE encryption protocol. With all these ppp can participate in
> MS VPN. Please look at this, and tell me what you think?
> 
> Bye!
[.]

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Making /etc/defaults/rc.conf a configuration file.

[Brian Somers]

> Hi,
> 
> With these patches, and the new tiny util 'sourceconf', we can make
> /etc/defaults/rc.conf and /etc/defaults/periodic.conf configuration
> files again, such that they can be parsed by things other than 'sh'.
[.]

Looks good to me !
-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: mergemaster RFC (long)

[Brian Somers]

> 
> Another thing that would be very useful is that during a
> merge of two files that it's possible to specify both
> the left hand side and the right hand side.  That would
> fix cases like:
> 
> Orig:
> 
> # $FreeBSD: src/etc/shells,v 1.4 SOMEDATE$
> #
> # List of acceptable shells for chpass(1).
> # Ftpd will not allow users to connect who are not using
> # one of these shells.
> 
> /bin/sh
> /bin/csh
> /usr/local/bin/zsh
> 
> 
> The new 1.5 version has: /bin/tcsh in it.  Mergemaster won't let
> me have both my /usr/local/bin/zsh and the /bin/tcsh.  During merge
> I can have either but not both :(
> 
> Joe

You can ``e b'' (edit both) from the sdiff prompt.
-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: mergemaster RFC (long)

[Brian Somers]

> Brian Somers <[EMAIL PROTECTED]> wrote:
> 
> > >   First, the things I am definitely going to do. Christian "naddy"
> > > Weisgerber has taken on the task of porting mm to openbsd.
> > 
> > I think it would be nice to aim to keep the two scripts exactly the 
> > same, using `uname` when it's really necessary.
> 
> If I have interpreted the noises Theo has made correctly, he wants
> mergemaster in the base tree.  I don't think he'll keep a "case
> `uname` ..." in there.

Of course if we didn't need it... that'd be far better :-)

> Most of the diff deals with two simple differences:
> - mergemaster uses "read -p " throughout.  That fails for
>   OpenBSD's /bin/sh (pdksh), where "read -p" means something entirely
>   different.

That's not too bad as the read -p can be changed to echo/read.

> - On OpenBSD, "install" is synonymous to "install -c".  FreeBSD still
>   has the old behavior where plain "install" deletes the source file.

Maybe the best bet here is to have ``INSTALL=install'' at the top of 
the script (``INSTALL="install -c" for FreeBSD).  It's a difference, 
but managable.

> If we can get rid of those, the actual differences become more
> visible.
> 
> Oh, and changing every instance of "FreeBSD" into "${OPSYS}" or
> some such would remove another few diff lines.

Aye.  Looks like we're thinking along the same lines.

I'll have to talk to Wes at BSDCon about trying to get the NetBSD 
guys to introduce it there too - maybe some of the NetBSD developers 
will be there too.

> -- 
> Christian "naddy" Weisgerber  [EMAIL PROTECTED]

-- 
Brian <[EMAIL PROTECTED]>
  <http://www.Awfulhak.org>   
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: mergemaster RFC (long)

[Brian Somers]

[.]
>   First, the things I am definitely going to do. Christian "naddy"
> Weisgerber has taken on the task of porting mm to openbsd. He has made
> some very reasonable requests that will make his life easier and reduce
> gratuitous differences between versions. Also, several people have asked
> for
> the ability to specify DESTDIR, which is an easy fix and definitely an
> understandable request. 

I think it would be nice to aim to keep the two scripts exactly the 
same, using `uname` when it's really necessary.  IMHO this really 
helps when maintaining code - if there are different versions, the 
tendency is to update the one you use most, and ``mean to get around 
to'' updating the other(s) later.  Of course the ``later'' tends to 
stop happening after a while...

[.]
> script. I'm going to add variables to the .mergemasterrc file for
> mergemaster-start and mergemaster-end scripts (names may change). These
> scripts will run after the temproot environment is built, and after mm
> is done with it's run. These scripts would be source'd from within mm so
> all the variables will be available to them.  This should allow people
> to add in their own "options" that I don't want to add to the program. 

I like this idea.  Perhaps the man page should have a HOWTO section 
that describes how to ``not compare files'' by deleting them in the 
start script etc.

> This is cobbled together from various people's suggestions.
> We need a list of files somewhere (probably in .mergemasterrc) that
> people don't ever want to have to deal with via the "normal" mm process.
> If a file on that list has been updated (according to the cvs tag) then
> instead of presenting that file to the user, it will be ignored the
> first time through. Then, at the end of the script there will be a
> printout similar to what happens when the user leaves a file to do by
> hand later. Something like:

I think having

  IGNOREFILES="a b c"

isn't necessary when it's as easy to have

  rm a b c

in your start script.  It seems like overkill to handle ignored files 
specifically.

>   Next on the list of things I'm open to suggestions on is a small script
> I wrote that compares the variables in /etc/rc.conf[.local] to the ones
> in /etc/defaults/rc.conf, and does the same for make.conf.
[.]

I don't really think it matters where this happens in mergemaster, 
but it would be nice to include periodic.conf too.  Of course you 
can't generically include everything in defaults/ as pccard.conf is 
probably something to avoid.

>   This also brings up the question of which files in /etc are good to
> examine before a world build.
[.]

Yes, too much handholding I think.

>   There was a PR filed in regards to the current situation with the new
> sendmail moving the aliases file to /etc/mail, and mergemaster's
[.]

Yep, this is definitely an SEP !

>   I have an idea related to getting users to actually READ the man page
[.]

Yeuch ! :-)

>   And the last of the ideas I want feedback on is related to the problem
> of determining permissions on the files to be installed. To my knowledge
[.]

Perhaps the best thing here is to make mtree capable of understanding 
rwxrwxrwx type modes, and then generate an mtree spec file based on 
the stuff in temproot and apply it to destdir ?

> Doug
> -- 
> "The dead cannot be seduced."
>   - Kai, "Lexx"
> 
>   Do YOU Yahoo!?

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Getting all the IP address for a machine from code...

[Brian Somers]

> I am looking for a way to get all the IP addresses that are configured a
> machine.  I need to do this in c source code, and without using DNS services
> (ie: gethostname/gethostbyname won't work).  I am hoping there are some
> system calls I can use to get this information.  Thanks in advance for any
> help.

This is a bit late

I'd favour copying src/usr.sbin/portmap/from_local.c (a reasonably 
recent version of the code).  It can be built as a main program that 
literally just outputs a list of local IP numbers.

>   - Chris

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Fdescfs updates--coming to a devfs near you!

[Brian Somers]

> The majority of these programs could be handled by adding knowledge
> of "-" as a magic filename to fopen(3).
[.]
> I would argue that the programs and the scripts that call them are
> already broken, but hey...

So (just to add fuel to the mass opposition), do this without 
temporary files:

  count=$(program | tee /dev/stderr | wc -l)
  exit $count

But then, you also said:

> At the same time I would really love if we implemented "|.*" to mean
> "do an popen(3)" instead.

so I guess this could result in

  count=$(program |. cat | wc -l)
  exit $count

(substitute correct "|.*" syntax - whatever that is).

> --
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> [EMAIL PROTECTED] | TCP/IP since RFC 956
> FreeBSD coreteam member | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Redirect stdout/stderr to syslog [OFF-TOPIC]

[Brian Somers]

> Hi,
> 
> I wonder if it is possible to redirect stdout/stderr to syslog.
> 
> Background:
> I'm writing a program which starts (fork=>execvp) and observes
> another program. I would like to redirect all output of the "execvped"
> program to syslog.
> 
> I know this is not really FBSD related but I hope you can help
> me anyway. Please don't tell me that I should redirect the output
> to a file and not to syslog. I know how to redirect the output to
> a file (that's my prog doing at present state).

I guess you could do something like:

  int fd;

  fd = open(_PATH_DEVNULL, O_RDONLY);
  dup2(fd, STDIN_FILENO);
  close(STDOUT_FILENO);
  openlog();
  dup2(STDOUT_FILENO, STDERR_FILENO);

> Bye,
> Alex

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Critical (or equivalent) section in Userland?

[Brian Somers]

> In message <[EMAIL PROTECTED]> Karl Pielorz writes:
> : I'm writing a program under FreeBSD 3.X that has been forced into having to
> : make a number of rename() calls that must be completed atomically (i.e. all
> : together) without the process being interrupted, or any other process being
> : allowed to run...
> 
> If advisory locks won't work (and they almost always will for things
> like this), then you could walk the process tree.  For all processes
> that aren't suspended or yourself, send a SIGSTOP, keep a list.  Keep
> going through the tree while you keep finding processes.  SIGSTOP
> can't be caught or blocked, so you know you've stopped them).  Do your
> operation, then send SIGCONT to all the processes that you sent a
> SIGSTOP to.  Of course, this will likely be much harder than doing
> advisory locking, but might be a way that you might be able to exactly
> what you want.

Wow, forgive me for saying this, but it must take a warped mind to 
think of that !!! :-)

Now if the original poster could arrange that all the files are 
either in the same directory or symlinked to the same directory, a 
quick directory rename (or symlink move) may do the job.  If that's 
not atomic enough, you could always replace that chunk of filesystem 
with a mount().

> Warner
> 
> P.S.  Can you tell I'm partial to advisory locks?

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Does sio have a maintainer?

[Brian Somers]

> 
> Hi folks,
> 
> Does the sio driver have a maintainer?  There are two PR's open that
> contain patches to provide support for new devices, but I can't find
> anyone to pin them on. :-)

I thought bde looked after sio.c...  Dunno if he reads this list.
-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Writing device drivers (ioctl issue)

[Brian Somers]

> I ran into this same problem when modifying the vmmon VMWare driver for
> FreeBSD to support mulitple emulator instances.  FreeBSD's VFS does not
> have a concept of stateful file access: there are open's and close's, but
> the VOP_READ/WRITE operations are not associated with sessions.  This
[.]
> There are a number of possible solutions to this problem, including the
[.]
> My preferred solution, and I actually hacked around with a kernel a bit to
> do this, is to make the VFS provide (optional) stateful vnode sessions.
> vop_open() would gain an additional call-by-reference argument, probably a
> void**.  When NULL, the caller would be requesting a stateless vnode open,
[.]
> My changes are incomplete as I was working on it on the plane, and
> comments on the idea would be welcome.  One thing this would allow is for
[.]

I think this is something that BSD lacks big-time.  It simplifies the 
way userland opens devices and should be fairly easy to implement.

If you haven't got time, I'd be willing to pick this up.  Do you have 
anything worth sending me (patches) ?

Cheers.

>   Robert N M Watson 
> 
> [EMAIL PROTECTED]  http://www.watson.org/~robert/
> PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
> TIS Labs at Network Associates, Safeport Network Services

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: /etc/security -> /etc/periodic/security ?

[Brian Somers]

> > Brian Somers wrote:
> > 
> > >> Well, "periodic security" will work as long as /etc/periodic/security
> > >> exists, so I guess you just mean the docs need updating?  I'll get to
> > >> that if someone is actually planning on committing this stuff.
> > >=20
> > > Perhaps the best option is to do with the inline security option and=20
> > > just run ``periodic security'' from cron ?  I can commit the changes.
> > 
> > I don't think there's really a problem with just running security
> > from daily.  I can add a note that this is normal practice in the
> > manpage, and that security shouldn't be run separately unless you set
> > daily_security_enable=3DNO or whatever the option is.
> 
> Oops, sorry for the reply latency
> 
> I don't think it's appropriate to separate the security script into 
> multiple scripts unless the intention is to run ``periodic 
> security''.  This is just my personal view though.  If you feel 
> strongly about it, you should bring it up on freebsd-arch.  I'll 
> certainly back down if the concensus says it should be split.

Duh!  I didn't realise -arch was already on the cc list :-/

> > --=20
> > Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D
> 
> BTW, congrats on your commit bit !
-- 
Brian <[EMAIL PROTECTED]>
  <http://www.Awfulhak.org>   
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: /etc/security -> /etc/periodic/security ?

[Brian Somers]

> Brian Somers wrote:
> 
> >> Well, "periodic security" will work as long as /etc/periodic/security
> >> exists, so I guess you just mean the docs need updating?  I'll get to
> >> that if someone is actually planning on committing this stuff.
> >=20
> > Perhaps the best option is to do with the inline security option and=20
> > just run ``periodic security'' from cron ?  I can commit the changes.
> 
> I don't think there's really a problem with just running security
> from daily.  I can add a note that this is normal practice in the
> manpage, and that security shouldn't be run separately unless you set
> daily_security_enable=3DNO or whatever the option is.

Oops, sorry for the reply latency

I don't think it's appropriate to separate the security script into 
multiple scripts unless the intention is to run ``periodic 
security''.  This is just my personal view though.  If you feel 
strongly about it, you should bring it up on freebsd-arch.  I'll 
certainly back down if the concensus says it should be split.

> --=20
> Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D

BTW, congrats on your commit bit !
-- 
Brian <[EMAIL PROTECTED]>
  <http://www.Awfulhak.org>   
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: /etc/security -> /etc/periodic/security ?

[Brian Somers]

[ x-posted to -arch to fish for complaints ]

> James Howard wrote:
> 
> > On Thu, 29 Jun 2000, Ben Smithurst wrote:
> >=20
> >> Try the attached.  They haven't been thoroughly tested, but that's what
> >> -CURRENT is for, right? :-) I even remembered to update the manual page
> >> this time...
> >=20
> > This needs to have knobs and stuff located in /etc/defaults/periodic.conf
> 
> Umm, which knobs?  I added the only two options the security stuff currently
> uses, what else does it need?
> 
> > Also, it would be cool if a security option were made to periodic(8).
> 
> Well, "periodic security" will work as long as /etc/periodic/security
> exists, so I guess you just mean the docs need updating?  I'll get to
> that if someone is actually planning on committing this stuff.

Perhaps the best option is to do with the inline security option and 
just run ``periodic security'' from cron ?  I can commit the changes.

If you send me some diffs, I'll commit them and then look at 
introducing {daily,weekly,monthly,security}_silence flags that will 
silence mails that have nothing to say.

Assuming there are no objections that is

> --=20
> Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: /etc/security -> /etc/periodic/security ?

[Brian Somers]

> Will we be seeing a move in this direction towards a more configurable
> security script?  Is anyone planning it?
> 
> I am porting the scripts to Linux and will hold off on security if
> nothing is being planned or make the changes myself.  I just do not want
> to duplicate efforts.
> 
> Also, I found a bug with a patch in conf/19567.  Please apply :)

I've changed /etc/security in -current by adding switches to the 
scripts command line and making those switches configurable in 
/etc/periodic.conf.

If you want to take this further, I would think it best to keep it 
controllable from periodic.conf - but feel free to argue about 
specifics :-)

I wouldn't mind if you wanted to pass any patches by me.

> Jamie

Cheers.
-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: PPPoE help me please!!

[Brian Somers]

> I can run tcpdump on my ethernet device ed1 and it is sending out a 
> PADI packet but it is not getting anything back.

This is either because you have an incorrect :provider setting in 
your ``set device'' line, or because you were using a different NIC 
with your provider at one point, and they've cached its MAC address.

I would think it's just the wrong provider.
-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: .core file reporting in daily report

[Brian Somers]

> I was trying to figureout how the periodic scripts were run when I
> noticed that cron had coredumped back in October and left a core file in
> /var/run/cron.  I got to thinking, it would be nice if the daily scripts
> would report when core files are found so they can be cleaned up.

I'm about to commit a change to the way the periodic scripts are run. 
You'll be able to tune this in /etc/periodic.conf shortly.

> Jamie

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: buildworld summary

[Brian Somers]

> Brian Somers wrote:
> 
> >> A few months ago someone posted a script that summarizes make
> >> buildworld as it progresses. I've searched the ports and the mailing
> >> lists but I can't find it any more :-( so I'd be grateful if someone
> >> would tell me. Thanks.
> >=20
> > It was phk (cc'd), and yes, it seems to have evaporated.
> 
> Hmm, are you sure you're not thinking of 'whereintheworld' by
> fenner, or isn't that what you were thinking of?  Take a look at
> <http://people.freebsd.org/~fenner/whereintheworld> and see if it's what
> you're after.
> 
> And Brian, are you sure you're not mixing it up with phk's proposals to
> post a list of world breakage to -current or something?  Or am I just
> getting terribly confused?  (I'll shut up now.)

I'm fairly sure phk posted about 3 of these reports.  I whinged about 
the first one because it mentioned that something didn't build and 
then went on to report 0 errors...

> --=20
> Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D






To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: buildworld summary

[Brian Somers]

> A few months ago someone posted a script that summarizes make
> buildworld as it progresses. I've searched the ports and the mailing
> lists but I can't find it any more :-( so I'd be grateful if someone
> would tell me. Thanks.

It was phk (cc'd), and yes, it seems to have evaporated.

> Tony.
> -- 
> f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
> 356 pungent unguent for stump-itch

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message