net-snmp-coders — Discussion of internal project coding (Please use this OR -users, NOT both!)

Re: UID GID patch (2)

[Wes H. <wjh...@uc...>]

>>>>> On Tue, 07 Nov 2000 10:07:51 -0800, Harrie Hazewinkel <ha...@co...> said:

Harrie> I have attached a patch that enables the configuration of the
Harrie> uid and gid for the snmpd via the configuration file.

Actually, you didn't attach the patch :-)

I actually applied your earlier patch already and made similar
modifications to the one that you did.

Harrie> I also changed a config_pwarn into config_perror where an
Harrie> unknown token was interpreted as a warning.

This could be a problem, however.  It's possible to dynamically
determine at runtime which mib modules to initialize, and hence tokens 
supported by those modules won't be recognized and really is a warning 
(since it's your own fault for running the agent in that
configuration).

The end result is that it really needs to be a warning.  Maybe I'll go 
back on what I said earlier and say that we should register for the
tokens in question with a config parser that merely calls
config_perror() when the defines in question aren't found.

Harrie> In line with the concerns of Niels; it would be a bad thing if
Harrie> snmpd would run different as expected by the configuration
Harrie> file.

Ehh...  It'd be on a win32 machine probably and I wouldn't care :-)
But, someone else might, I suppose.

Harrie> I also uncommented the 'exit' when a configuration error is
Harrie> found.

That we can't do.  What we can do is propagate the error condition
back up to the agent (somehow) and have it exit instead.

-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: diskio MIB

[<uc...@ra...>]

On Tue, Nov 07, 2000 at 01:44:04PM -0500, Stan Brown wrote:
> >Stan> Now, do I need to add anything to snmpd.conf to enable this? If I do a
> >Stan> snmpwalk of the whole ucd-snmp MIB, will the disk I/O data show
> >Stan> up?
> >
> >It should if you ran configure as mentioned above.
> 
> 	Yes, I am getting something, now if only I can figure out how to decode
> 	it :-( Seems to be some sort of table?


Yes, this is a sample from one of our servers:
diskIOTable.diskIOEntry.diskIOIndex.1 = 1
diskIOTable.diskIOEntry.diskIOIndex.2 = 2
diskIOTable.diskIOEntry.diskIOIndex.3 = 3
diskIOTable.diskIOEntry.diskIODevice.1 = sd21
diskIOTable.diskIOEntry.diskIODevice.2 = sd0
diskIOTable.diskIOEntry.diskIODevice.3 = sd1
diskIOTable.diskIOEntry.diskIONRead.1 = 26296968
diskIOTable.diskIOEntry.diskIONRead.2 = 4254173078
diskIOTable.diskIOEntry.diskIONRead.3 = 2405043606
diskIOTable.diskIOEntry.diskIONWritten.1 = 0
diskIOTable.diskIOEntry.diskIONWritten.2 = 1804509696
diskIOTable.diskIOEntry.diskIONWritten.3 = 3393364480
diskIOTable.diskIOEntry.diskIOReads.1 = 798
diskIOTable.diskIOEntry.diskIOReads.2 = 1430650
diskIOTable.diskIOEntry.diskIOReads.3 = 1465686
diskIOTable.diskIOEntry.diskIOWrites.1 = 20
diskIOTable.diskIOEntry.diskIOWrites.2 = 3579153
diskIOTable.diskIOEntry.diskIOWrites.3 = 3537768

diskIOIndex is just the index
diskIODevice maps each index to a devicename
diskIONRead is the number of bytes read
diskIONWritten is the number of bytes written
diskIOReads is the number of read operations
diskIOWrites is the number of write operations

So to find the number of bytes written to sd1, you look at
.....diskIONWritten.3 (because index 3 is sd1)

See?


-- 
Ragnar Kjørstad

Trouble Loading 4.2pre1 win32.dsw file

[John C. W. <joh...@c-...>]

NET-SNMP-CODERS,

Has anyone had trouble loading the win32.dsw file (project file
needed to do a Win32 build in batch mode)?

When I load it - it does nothing.  MSVC++ 6.0 just seems to ignore
the file.

Regards,
John
********************************************
John C. Westmoreland
Broadband Network Division
C-Cube Microsystems, Inc.
1778 McCarthy Boulevard
Milpitas, California 95035
Phone:  408-490-5111
Fax:    408-490-5508
E-Mail:  joh...@c-...
Pager: (800) 562-0687
Text Page: 800...@mo...
********************************************

"Most of the important things in the world have been
accomplished by people who have kept on trying
when there seemed to be no hope at all."
--Dale Carnegie

Re: about ucd-snmp

[Shiow J. J. <sj...@cl...>]

Wes Hardaker wrote:

> >>>>> On Mon, 06 Nov 2000 11:33:23 -0800, Shiow Jen Jin <sj...@cl...> said:
>
> Shiow> When I did this step, I got the message as follows:
> Shiow> Modification of a read-only value attempted at ./mib2c line 261, <GEN1>
> Shiow> line 59.
>
> You can probably ignore that error message.
>
> --
> Wes Hardaker
> Please mail all replies to net...@li...

Hi:
 If I ignore the error message, please tell me how can I convert EtherLike-MIB.txt to
transmission.c and transmission.h template by mib2c.

SJJ

Re: Pluggable transport domains via register_readfd-like API?

[John N. <jb...@ca...>]

> Well, I've always been primarily interested in the agent, rather
> than the library.  The specific changes I'm thinking of refer to
> the MIB module API - in particular what information is passed in.
> 
>   A couple of examples:
> 
> 	-  Currently, the MIB module code does not have access
> to any of the PDU "administrative" information, such as the
> authenticated user, the community string, or the context.
> This might be useful for particular modules that want to respond
> differently based on this information.
> 
> 	-  Currently, the MIB module works with one object at
> a time.  For GETNEXT requests, it might be more efficient if the
> module was given a valid range, and could return anything within
> that range (rather than being called repeatedly).   This would
> also have simplified the AgentX implementation (though I've worked
> around it now).

  Interesting ideas.  I'm sure they would be very useful for MIB 
implementors.  One possibility might be to have a variant of register_mib 
that lets you specify which callback API you want for your var_ and write_ 
routines -- the Classic or Advanced API.  Then you could migrate code on a 
per-MIB-module (or finer) granularity to the new API.

>   I'm sure we could come up with other possibilities given a bit
> of thought.  There was a short discussion over the summer (triggered
> by Juergen and Frank Strauss), which covered some similar issues.
>
>    As regards the library, I'd like to get rid of some of the
> "special casing" and duplication of effort (such as file descriptor
> handling),  and split some of the more cumbersome files into more
> manageable pieces - 'snmp_api.c' is the obvious contender here.
> This probably wouldn't affect the visible APIs - just the internal
> code structure.

  I've been looking at snmp_api.c more closely today -- I see what you mean when you said it made your head hurt now!  I was thinking of something vaguely like this:

  New header snmp_transport.h defines a struct snmp_transport which provides a transport-independent API via a bunch of function pointers to read, write, close etc. different types of transport socket.  All access from snmp_api.c is via these structures (saved along with sessions à la struct snmp_internal_session).  Bunch of new "transport provider" files (e.g. snmpUDPDomain.c, snmpTCPDomain.c, snmpIPXDomain.c, snmpATMPVCDomain.c, ...) which provide the functions to be pointed at (these hiding all the transport-specific and/or platform-specific grunge) and also provide easy-to-use functions like snmp_udp_transport(192.168.4.4/161) or whatever that return struct snmp_transports.  New snmp_api call snmp_sess_add(struct snmp_session, struct snmp_transport) which links its arguments onto the Sessions list so that the underlying socket becomes visible to snmp_select_info and friends.

  The net (ha) effect ought to be that all of the low-level sockety stuff (like gethostbyname and all that kind of thing) ends up in the transport-specific files, which should slim snmp_api.c a bit.  This has the additional benefit that individual transports can then be ./configured in and out of the library/agent.  This wouldn't affect the visible API (except for the addition of the snmp_sess_add call).

  Thoughts?

John
-- 
// Dr. John Naylon // Senior Software Engineer // Cambridge Broadband Ltd.
// The future of broadband wireless access  // www.cambridgebroadband.com

Re: [mrtg] UCD SNMP diskio MIB?

[Stan B. <st...@aw...>]

On Tue Nov  7 11:11:26 2000 =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= wrote...
>
>On Tue, Nov 07, 2000 at 10:31:51AM -0500, Stan Brown wrote:
>> 	Has anyone figured out how to use mrtg to graph data obtained from the
>> 	new UCD-SNMP disko MIB?
>> 
>> 	I have teh CVS version of UCD-SNMP compiled on a Solaris boxm and can
>> 	do an snmpwalk and get this data, but it appears to be some sort of
>> 	"table', and I am having trouble figuring out how to get mrth to take
>> 	advanyage of this.
>> 
>> 	An example would be great.
>
>There is an example of cricket configuration at:
>http://www.stud.ntnu.no/~ragnarkj/download/
>
>MRTG configuration should not be too different, but of course syntax is
>different. Cricket looks up the table-index using snmp, as far as I know
>MRTG can't do this, so you will have to look them up yourself and
>include them in the OID. This means that if the device order changes
>somehow, you will have to update your configuration (device order can
>change when you e.g. add new devices).
>

	Thanks, I've been wondering about this with mrtg for a while now. I am
	getting the real strong impression I should scrap mrtg, and go with
	cricket.

	Thanks for the pointer.

-- 
Stan Brown     st...@aw...                                    843-745-3154
Charleston SC.
-- 
Windows 98: n.
	useless extension to a minor patch release for 32-bit extensions and
	a graphical shell for a 16-bit patch to an 8-bit operating system
	originally coded for a 4-bit microprocessor, written by a 2-bit 
	company that can't stand for 1 bit of competition.
-
(c) 2000 Stan Brown.  Redistribution via the Microsoft Network is prohibited.

Re: diskio MIB

[Stan B. <st...@aw...>]

On Tue Nov  7 13:23:22 2000 Wes Hardaker wrote...
>
>>>>>> On Tue, 7 Nov 2000 10:04:54 -0500 (EST), "Stan Brown" <st...@aw...> said:
>
>Stan> I have gotten the CVS sources to compile On a Solaris box, with
>Stan> this turned on.
>
>Did you configure with --with-mib-modules="ucd-snmp/diskio"?

	Yes.
>
>Stan> Now, do I need to add anything to snmpd.conf to enable this? If I do a
>Stan> snmpwalk of the whole ucd-snmp MIB, will the disk I/O data show
>Stan> up?
>
>It should if you ran configure as mentioned above.

	Yes, I am getting something, now if only I can figure out how to decode
	it :-( Seems to be some sort of table?

-- 
Stan Brown     st...@aw...                                    843-745-3154
Charleston SC.
-- 
Windows 98: n.
	useless extension to a minor patch release for 32-bit extensions and
	a graphical shell for a 16-bit patch to an 8-bit operating system
	originally coded for a 4-bit microprocessor, written by a 2-bit 
	company that can't stand for 1 bit of competition.
-
(c) 2000 Stan Brown.  Redistribution via the Microsoft Network is prohibited.

Re: diskio MIB

[Wes H. <wjh...@uc...>]

>>>>> On Tue, 7 Nov 2000 10:04:54 -0500 (EST), "Stan Brown" <st...@aw...> said:

Stan> I have gotten the CVS sources to compile On a Solaris box, with
Stan> this turned on.

Did you configure with --with-mib-modules="ucd-snmp/diskio"?

Stan> Now, do I need to add anything to snmpd.conf to enable this? If I do a
Stan> snmpwalk of the whole ucd-snmp MIB, will the disk I/O data show
Stan> up?

It should if you ran configure as mentioned above.

-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: about ucd-snmp

[Wes H. <wjh...@uc...>]

>>>>> On Mon, 06 Nov 2000 11:33:23 -0800, Shiow Jen Jin <sj...@cl...> said:

Shiow> When I did this step, I got the message as follows:
Shiow> Modification of a read-only value attempted at ./mib2c line 261, <GEN1>
Shiow> line 59.

You can probably ignore that error message.

-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: Setting the uid and gid via a configuration file

[Wes H. <wjh...@uc...>]

Harrie> Attached is a patch that allows you to set the agent userid
Harrie> and agent groupid from the configuration files.

I've applied the patch and am applying various configuration changes
to protect it now...

-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: Setting the uid and gid via a configuration file

[Harrie H. <ha...@co...>]

Wes Hardaker wrote:
> 
> >>>>> On Mon, 06 Nov 2000 10:24:49 -0800, Harrie Hazewinkel <ha...@co...> said:
> 
> Harrie> I tend to agree. So we now have the following options:
> Harrie>    1) If a platform does not support this
> Harrie>       ignore 'snmpuser' and 'snmpgroup'.
> Harrie>    2) If a platform does not support this
> Harrie>       print error message and exit (with suggestion to fix it).
> 
> Harrie> Should we go for option 2.
> 
> Or:
>           3) If a platform does not support this
>              don't register the 'snmpuser' and 'snmpgroup' handlers,
>              which will print the default "unknown token" warning.
> 
> I'd vote for 3.

Ah, you just were to early. :-)) I thought of this later
during the change I made ot my patch. The patch just sent
does this.


Harrie 
0- Harrie Hazewinkel ---------------------------------------0
 mailto:ha...@co...            phone:+1-415-536-5221
0-----------------------------------------------------------0

Re: Setting the uid and gid via a configuration file

[Wes H. <wjh...@uc...>]

>>>>> On Mon, 06 Nov 2000 10:24:49 -0800, Harrie Hazewinkel <ha...@co...> said:

Harrie> I tend to agree. So we now have the following options:
Harrie>    1) If a platform does not support this
Harrie>       ignore 'snmpuser' and 'snmpgroup'.
Harrie>    2) If a platform does not support this
Harrie>       print error message and exit (with suggestion to fix it).

Harrie> Should we go for option 2.

Or:
          3) If a platform does not support this
             don't register the 'snmpuser' and 'snmpgroup' handlers,
             which will print the default "unknown token" warning.

I'd vote for 3.

-- 
Wes Hardaker
Please mail all replies to net...@li...

UID GID patch (2)

[Harrie H. <ha...@co...>]

Hi,

I have attached a patch that enables the configuration of
the uid and gid for the snmpd via the configuration file.

After opening the 'root' required ports and kmem
the snmpd can run as anyother user. This will
improve security. If someone hacks the 'snmpd' process
he is not becoming the root user.

What does the attached patch do. Register the tokens and
handling functions to read the uid and gid out of a file.

I also changed a config_pwarn into config_perror
where an unknown token was interpreted as a warning.
In line with the concerns of Niels; it would be a bad
thing if snmpd would run different as expected by the
configuration file.

I also uncommented the 'exit' when a configuration error
is found.


Cheers,

Harrie 
0- Harrie Hazewinkel ---------------------------------------0
 mailto:ha...@co...            phone:+1-415-536-5221
0-----------------------------------------------------------0

Re: diskio MIB

[<uc...@ra...>]

On Tue, Nov 07, 2000 at 10:04:54AM -0500, Stan Brown wrote:
> 	I am experimenting with the ucd-snmp/diski MIB.
> 
> 	I have gotten the CVS sources to compile On a Solaris box, with this
> 	turned on.
> 
> 	Now, do I need to add anything to snmpd.conf to enable this? If I do a
> 	snmpwalk of the whole ucd-snmp MIB, will the disk I/O data show up?

You don't need to modify snmpd.conf - it should show up by itself.
Doesn't it?


-- 
Ragnar Kjørstad

diskio MIB

[Stan B. <st...@aw...>]

	I am experimenting with the ucd-snmp/diski MIB.

	I have gotten the CVS sources to compile On a Solaris box, with this
	turned on.

	Now, do I need to add anything to snmpd.conf to enable this? If I do a
	snmpwalk of the whole ucd-snmp MIB, will the disk I/O data show up?

	Thanks.

-- 
Stan Brown     st...@aw...                                    843-745-3154
Charleston SC.
-- 
Windows 98: n.
	useless extension to a minor patch release for 32-bit extensions and
	a graphical shell for a 16-bit patch to an 8-bit operating system
	originally coded for a 4-bit microprocessor, written by a 2-bit 
	company that can't stand for 1 bit of competition.
-
(c) 2000 Stan Brown.  Redistribution via the Microsoft Network is prohibited.

Re: Pluggable transport domains via register_readfd-like API?

[Dave S. <D.T...@cs...>]

>                                         Are there specific 
> non-backward-compatible changes that you are thinking of?

Well, I've always been primarily interested in the agent, rather
than the library.  The specific changes I'm thinking of refer to
the MIB module API - in particular what information is passed in.

  A couple of examples:

	-  Currently, the MIB module code does not have access
to any of the PDU "administrative" information, such as the
authenticated user, the community string, or the context.
This might be useful for particular modules that want to respond
differently based on this information.

	-  Currently, the MIB module works with one object at
a time.  For GETNEXT requests, it might be more efficient if the
module was given a valid range, and could return anything within
that range (rather than being called repeatedly).   This would
also have simplified the AgentX implementation (though I've worked
around it now).


  I'm sure we could come up with other possibilities given a bit
of thought.  There was a short discussion over the summer (triggered
by Juergen and Frank Strauss), which covered some similar issues.


   As regards the library, I'd like to get rid of some of the
"special casing" and duplication of effort (such as file descriptor
handling),  and split some of the more cumbersome files into more
manageable pieces - 'snmp_api.c' is the obvious contender here.
This probably wouldn't affect the visible APIs - just the internal
code structure.
  It might also be worth providing some simple "one-shot" wrapper
routines, to allow basic queries while hiding all the session stuff.
Something like

	snmpget( host, community, OID );
	snmpset( host, community, OID, type, value );

Now that would be an additional API, so wouldn't affect the existing
ones.   Similarly, we've talked for some time about providing a
WinSNMP-compatible interface - which again would be in addition to
existing APIs.   But other changes might be a little more intrusive.

  Obviously, the greater the impact on existing code, the more reluctant
we'd be to make a change - but if the benefits were great enough, this
would be the time to do it.

Dave

Re: How can I create a tarball from cvs sources?

[Dave S. <D.T...@cs...>]

> 	Given a copy of the CVS sources, how can I build a tarball to compile
> 	on a mchine that does not hout the auto* stuff (automake et all).

If you 'make touchit' *before* running make, it shouldn't try to regenerate
the configure stuff.

  If that doesn't work (and it's a little unreliable for me), try editing
the Makefile, and removing the entry for 'configure'
i.e:

	configure: configure.in aclocal.m4
		cd ${srcdir} && $(AUTOCONF)
		echo "Please run configure now."
		sh -c exit 2


Dave

How can I create a tarball from cvs sources?

[Stan B. <st...@aw...>]

	Given a copy of the CVS sources, how can I build a tarball to compile
	on a mchine that does not hout the auto* stuff (automake et all).

	Thnaks.

-- 
Stan Brown     st...@aw...                                    843-745-3154
Charleston SC.
-- 
Windows 98: n.
	useless extension to a minor patch release for 32-bit extensions and
	a graphical shell for a 16-bit patch to an 8-bit operating system
	originally coded for a 4-bit microprocessor, written by a 2-bit 
	company that can't stand for 1 bit of competition.
-
(c) 2000 Stan Brown.  Redistribution via the Microsoft Network is prohibited.

about ucd-snmp

[Shiow J. J. <sj...@cl...>]

Hi:
I try to write C code to implement my transmission MIB by using mib2c.
Is there anything wrong I plan to do in the following procedure:
(1) setenv MIBS EtherLike-MIB
(2) ./mib2c transmission
When I did this step, I got the message as follows:
Modification of a read-only value attempted at ./mib2c line 261, <GEN1>
line 59.
Could you tell me what is the meaning of this message?
Your response will be appreciated!

SJJ

Re: Setting the uid and gid via a configuration file

[Harrie H. <ha...@co...>]

ni...@ba... wrote:
> 
> On Thu, 02 Nov 2000 08:26:04 -0800 Harrie Hazewinkel <ha...@co...>
> wrote:
> >Wes Hardaker wrote:
> >> I'd love to apply the patch, but I'll have to protect it against
> >> machines that don't have pwd.h and/or grp.h files plus the associated
> >> functions (eg, windows).
> >
> >An option would be if pwd.h and grp.h are not present
> >the snmpuser and snmpgroup are just read from the configuration file,
> >but ignored.
> 
> I would hate to think that I had configured something, and it then didn't work
> that way.

I tend to agree. So we now have the following options:
	1) If a platform does not support this
		ignore 'snmpuser' and 'snmpgroup'.
	2) If a platform does not support this
		print error message and exit (with suggestion to fix it).

Should we go for option 2.

After investigating I think we are fine on most unixes, but not on
Windows. The usage of running on this platform as a different user
needs top be done via 'services'. These 'services' need a complete
different configuration.

Cheers,
Harrie
0- Harrie Hazewinkel ---------------------------------------0
 mailto:ha...@co...            phone:+1-415-536-5221
0-----------------------------------------------------------0

Re: Setting the uid and gid via a configuration file

[<ni...@ba...>]

On Thu, 02 Nov 2000 08:26:04 -0800 Harrie Hazewinkel <ha...@co...>
wrote:
>Wes Hardaker wrote:
>> I'd love to apply the patch, but I'll have to protect it against
>> machines that don't have pwd.h and/or grp.h files plus the associated
>> functions (eg, windows).
>
>An option would be if pwd.h and grp.h are not present
>the snmpuser and snmpgroup are just read from the configuration file,
>but ignored.

I would hate to think that I had configured something, and it then didn't work
that way.

/Niels

-- 
Get your firstname@lastname email for FREE at http://Nameplanet.com/?su

Re: Pluggable transport domains via register_readfd-like API?

[Mark H. W. <mh...@am...>]

If re-engineering the API means that I could write SNMP/IPX applications,
then it's got my vote.  NetSNMP is way ahead of any product I have to talk
to with it, so a longer development cycle for 5.0 would not be a problem
for me.

-- 
Mark H. Wood, radical centrist     OpenPGP ID 876A8B75     mh...@am...
Only three more shopping days before the election

Re: Checking out ucd-snmp-4.2-pre1

[Wes H. <wjh...@uc...>]

>>>>> On Fri, 03 Nov 2000 13:18:01 -0800, Harrie Hazewinkel <ha...@co...> said:

Harrie> I was wondering if why the distribution was not renamed to
Harrie> net-snmp-4.2-pre1?

Long story.  But we've decided to release the 4.2 release under the
ucd-snmp name, simply because its so close to the release time and
we originally promised it under that name and want to keep to our
promises.

Harrie> { EXAMPLETRIGGERTRAP, ASN_INTEGER, RWRITE, var_example, 2, {7, 0}},
Harrie> { EXAMPLETRIGGERTRAP2, ASN_INTEGER, RWRITE, var_example, 2, {7, 0}}

Harrie> Attached patch fixes this.

Thanks for the patch!  It has been applied to the next release of the
ucd-snmp package.

-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: Pluggable transport domains via register_readfd-like API?

[John N. <jb...@ca...>]

>   Every time I have to work on 'snmp_api.c' (in particular), my
> head starts to hurt.   I've been wondering about trying to make use
> of the {read,write,notify}_fd mechanism for the "normal" SNMP traffic
> as well.  What you propose sounds (at first glance) to be along the
> same sort of lines.

  Great! -- it's always encouraging to know that you're not the only person 
thinking about some issue.

>   My aims would be two-fold.  Firstly, to try and simplify the
> arrangement of the code, to make it easier to understand, and maintain.
> Secondly, to look at our current APIs, and use the change of project
> name as an opportunity to make any (non-backward-compatible) amendments
> that we think would be useful.

  I completely agree that now is a really good time to make this type of 
architectural change (but also see below).  I also really think there is the 
potential not just to simplify what currently exists and make it more 
transparent to new users, but also to make the toolkit the natural choice 
for people who want to extend it in interesting/unusual ways.  (IME it's 
already way out in front in this regard in any case).

  I do think that a great deal of what we are talking about (and it really 
does sound like we are on the same wavelength here) can probably be achieved 
without sacrificing the "simple API" too, which is like having your cake and 
eating it.  There is the danger of bloat, but then again there's nothing 
quite like getting new features for free.  Are there specific 
non-backward-compatible changes that you are thinking of?

>   Obviously, any such undertaking would be a fair amount of work, and
> would probably result in a significant delay in the next release, so
> this is very much a post-4.2 project.

  Yes, absolutely.  4.2 looks like it is going to be a rock-solid base on 
which to build.

>   And it would only be sensible to attempt this if there was a general
> consensus that it was worth while.   But since I've come out into the
> open with the idea, what does anyone think?

  Well, we've got to do something with the OTHER 24 hours in the day, right? 
 I'm really looking forward to hearing everyones' opinions on this.

  Oh -- by the way, I really applaud the move to sourceforge.net; I hope and 
believe it will really raise the profile of all the good work you guys have 
been doing for so long.

John

-- 
// Dr. John Naylon // Senior Software Engineer // Cambridge Broadband Ltd.
// The future of broadband wireless access  // www.cambridgebroadband.com

Re: Binding to a Single Interface

[Patrick R. <dm...@ad...>]

On 03 Nov 2000 11:12:45 -0800, Wes Hardaker wrote:

Great.  Thank you for your time

Patrick

:>>>>>> On Fri, 03 Nov 2000 03:25:55 -0600, "Patrick Reich"
<dm...@ad...> said:
:>
:>Patrick> Is the ability to listen on a specified interface being
:>Patrick> considered for a future release?  Perhaps a flag or
directive
:>Patrick> in the config file?
:>
:>Yes, it'll be possible in the 4.2 release.
:>
:>-- 
:>Wes Hardaker
:>Please mail all replies to net...@li...
:>