--> bergia has joined #net-snmp
[2003/01/13 00:48:47] #net-snmp <BeerGummA> I've installed and compiled the net-snmp package but I cannot find the snmpd.conf file...where is it? (not in /etc/snmp or /usr/local/share/snmp)
[2003/01/13 01:33:37] #net-snmp <hampa> maby /usr/share/snmp
[2003/01/13 01:33:49] #net-snmp <hampa> do a find / -name "snmpd.conf"
[2003/01/13 01:46:18] #net-snmp <BeerGummA> Yes i did..but it seems that the "make install" doesn't copy (or generate) snmpd.conf...
[2003/01/13 01:47:47] #net-snmp <BeerGummA> in fact the snmpd.conf present on my system is the one from the ucd-snmp rpm previously installed...
[2003/01/13 01:48:40] #net-snmp <BeerGummA> but the net-snmp doesn't generate a new snmpd.conf...
--> wan has joined #net-snmp
--> wes has joined #net-snmp
--> MezoWork has joined #net-snmp
[2003/01/13 06:54:10] #net-snmp <MezoWork> hi
--> dts has joined #net-snmp
[2003/01/13 06:56:54] #net-snmp <wes> :-)
[2003/01/13 06:57:03] #net-snmp <dts> Sorry wes - happy now?
[2003/01/13 06:57:11] #net-snmp <wes> yep.
[2003/01/13 06:57:20] #net-snmp <wes> did you happen to glance at the iterator patch, by the way?
[2003/01/13 06:57:36] #net-snmp <dts> Briefly - it looked plausible.
[2003/01/13 06:57:49] #net-snmp <wes> yeah. Not sure it was ideal, but looked fine.
[2003/01/13 06:57:57] #net-snmp <wes> I need to rewrite the entire file soon.
[2003/01/13 06:58:00] #net-snmp <dts> But I'm not really clear on how the various 'free' hooks are meant to work.
[2003/01/13 06:58:10] #net-snmp <wes> oh, and did I mention document it?
[2003/01/13 06:58:24] #net-snmp <dts> Well as long as you commit your changes little and often :-)
[2003/01/13 06:58:25] #net-snmp <wes> Actually, I was hoping to get to that in the next few weeks (gasp)
[2003/01/13 06:58:32] #net-snmp <wes> heh.
[2003/01/13 06:58:53] #net-snmp <wes> btw, robert and I were thinking it's time for a branch after the 5.0.7 publication.
[2003/01/13 06:58:54] #net-snmp <wes> agree?
[2003/01/13 06:59:25] #net-snmp <dts> Hmmm.... that'd probably be sensible, yes.
[2003/01/13 06:59:43] #net-snmp <dts> If I'm likely to start re-writing some of the MIB modules,
[2003/01/13 06:59:53] #net-snmp <dts> and you've got plans....
[2003/01/13 07:00:22] #net-snmp <wes> I have lots of wants-to-do.
[2003/01/13 07:00:35] #net-snmp <wes> perl handlers for the snmptrapd, trap forwarding, etc.
[2003/01/13 07:01:01] #net-snmp <dts> And in the afternoon....... ?
[2003/01/13 07:01:36] #net-snmp <wes> the perl/manager directory.
[2003/01/13 07:03:18] #net-snmp <wes> did you ever try my linkup enabling ;-)
[2003/01/13 07:03:27] #net-snmp <dts> ?
[2003/01/13 07:03:36] #net-snmp <wes> sent to -coders a while back.
[2003/01/13 07:03:46] #net-snmp <wes> using the disman event mib to enable linkup traps.
[2003/01/13 07:04:07] #net-snmp <dts> Oh, I remember. No - I didn't get around to it. Sorry.
[2003/01/13 07:04:07] #net-snmp <wes> (there was a script given that runs a whole bunch of snmpsets, the result of whic is that linkup/down traps are sent)
[2003/01/13 07:05:00] #net-snmp <dts> My immediate reaction was that it felt a bit complicated :-)
[2003/01/13 07:07:13] #net-snmp <wes> I did say that we had to add a simple token for it in the snmpd.conf file...
[2003/01/13 07:07:18] #net-snmp <wes> I just hadn't done it yet.
[2003/01/13 07:09:37] #net-snmp <dts> Yes - I sort-of realised that. But I was put off trying it by the look of the thing.
[2003/01/13 07:09:50] #net-snmp <dts> I can be something of a wimp at times!
[2003/01/13 07:10:14] #net-snmp <wes> :-)
--> delanne_ has joined #net-snmp
--> mike has joined #net-snmp
--> TrogL has joined #net-snmp
--> kastar has joined #net-snmp
[2003/01/13 07:56:56] #net-snmp <TrogL> dts: you will remember that agent/mibgroup/host/hr_storage.h contains some hard-coded values that are causing me problems
[2003/01/13 07:57:02] #net-snmp <TrogL> specifically, I'm limited to 100 partitions
[2003/01/13 07:57:16] #net-snmp <TrogL> by HRS_TYPE_FS_MAX 100
[2003/01/13 07:57:52] #net-snmp <TrogL> in earlier discussion there had been talk of moving HRS_TYPE_MEM etc. down to low numbers
[2003/01/13 07:57:58] #net-snmp <TrogL> then putting the disks above
[2003/01/13 07:58:07] #net-snmp <dts> Ye s- I remember
[2003/01/13 07:58:24] #net-snmp <TrogL> will this break the spirit of the controlling FRC?
[2003/01/13 07:58:31] #net-snmp <TrogL> RFC
[2003/01/13 07:58:57] #net-snmp <TrogL> ...and how will this affect your recently discussed notions about the indexes?
[2003/01/13 07:59:18] #net-snmp <dts> I don't think it's a problem as far as the MIB is concerned.
[2003/01/13 07:59:40] #net-snmp <dts> The indexes are arbitrary, and can legitimately change from one invocation of the agent to the next.
[2003/01/13 07:59:54] #net-snmp <dts> Let alone between agent releases!
[2003/01/13 08:00:34] #net-snmp <dts> As far as the ideas about "index registries" are concerned, this feels sort-of-orthogonal.
[2003/01/13 08:01:04] #net-snmp <dts> That's mostly to do with keeping consistency between "the same type" of quantity.
[2003/01/13 08:01:19] #net-snmp <dts> So that an interface gets the same index every time
[2003/01/13 08:01:44] #net-snmp <dts> (and this can be used consistently by different MIB modules)
[2003/01/13 08:02:14] #net-snmp <dts> Similarly for a disk - say keeping a consistent value of hrDevIndex (or whatever it's called)
[2003/01/13 08:02:47] #net-snmp <dts> The design of the HOST-RESOURCES-MIB is deliberately such that the hrDevIndex and hrFSIndex aren't
[2003/01/13 08:03:08] #net-snmp <dts> closely coupled - and the linkage is handled by the MIB data itself, rather than being "hardwired".
[2003/01/13 08:03:28] #net-snmp <dts> So changing the default fsIndex values shouldn't really be a problem.
[2003/01/13 08:04:27] #net-snmp <TrogL> I'm a little confused about what exactly HRS_TYPE_MEM, HRS_TYPE_SWAP, and HRS_TYPE_MBUF are supposed to represent
[2003/01/13 08:04:43] #net-snmp <TrogL> solaris only delivers MEM and SWAP
[2003/01/13 08:04:48] #net-snmp <TrogL> linux delivers all three
[2003/01/13 08:05:22] #net-snmp <TrogL> is it the intention of the RFC to deliver additional swap information such as the size of individual swap partitions (as opposed to total swap)?
[2003/01/13 08:06:00] #net-snmp <dts> The RFC deliberately talks in fairly general terms.
[2003/01/13 08:06:22] #net-snmp <dts> This MIB table is intended to monitor "storage" - however the admin might want to define this.
[2003/01/13 08:06:50] #net-snmp <dts> The most obvious example is file systems, but it could equally well apply to free memory,
[2003/01/13 08:07:16] #net-snmp <dts> swap space, memory buffers, disk buffers, network buffers, or free shelves in the admin's bookcase!
[2003/01/13 08:07:42] #net-snmp <dts> The agent tries to implement whatever is easy to find out.
[2003/01/13 08:08:09] #net-snmp <dts> Hence including memory and swap - sometimes including memory buffers, but (unfortunately) not
[2003/01/13 08:08:21] #net-snmp <dts> including the important metric of book space.....
[2003/01/13 08:09:38] #net-snmp <TrogL> I'm on a box running Solaris 8. snmpwalk delivers me:
[2003/01/13 08:10:23] #net-snmp <TrogL> HOST_RESOURCES-MIB::hrstorageSize.102 - INTEGER: 122160
[2003/01/13 08:10:48] #net-snmp <TrogL> HOST-RESOURCES-MIB::hrStorageUsed.102 - INTEGER:11386
[2003/01/13 08:11:28] #net-snmp <TrogL> swap -s returns 68928k bytes allocated + 5864k reserver = 74792k used, 902976k available
[2003/01/13 08:11:33] #net-snmp <TrogL> how do these relate?
[2003/01/13 08:12:55] #net-snmp <dts> Well, it's a *long* time since I worked on this code (and I wasn't involved in the Solaris port)
[2003/01/13 08:13:25] #net-snmp <dts> But checking the code, the swap figures seem to be retrieved using 'swapctl'
[2003/01/13 08:13:49] #net-snmp <TrogL> unfortunately it uses an "undocumented" feature of swapctl for which I can't get a straight answer from Sun
[2003/01/13 08:14:14] #net-snmp <dts> Yes - that sounds familiar!
[2003/01/13 08:14:45] #net-snmp <dts> All I can suggest is writing a simple application, to repeatedly call swapctl and dump out the results.
[2003/01/13 08:14:58] #net-snmp <dts> Then compare that with repeated invocations of swap -s
[2003/01/13 08:15:16] #net-snmp <dts> That's how I ended up puzzling out some of the HP-UX internal data structures.
[2003/01/13 08:15:41] #net-snmp <dts> (Network related, rather than swap - but the principle's the same)
[2003/01/13 08:16:00] #net-snmp <dts> Unfortunately, I don't have easy access to Solaris kit.
[2003/01/13 08:16:38] #net-snmp <TrogL> would it be worthwhile to deliver the extra infmration contained in swap-s as part of what the agent delivers?
[2003/01/13 08:16:43] #net-snmp <dts> But that's actually a different issue from the indexing used.
[2003/01/13 08:16:56] #net-snmp <TrogL> or for that matter data about individual swap partitions?
[2003/01/13 08:17:03] #net-snmp <dts> Ummm.... probably - yes. If you can work out how to get it!
[2003/01/13 08:17:37] #net-snmp <dts> This is where we *are* getting towards the question of indexes.
[2003/01/13 08:17:38] #net-snmp <TrogL> is there something wthin the MIB to let me know what to call it?
[2003/01/13 08:18:05] #net-snmp <dts> Different architectures may well report different things, and "fixed" indexes start to look less sensible.
[2003/01/13 08:18:14] #net-snmp <TrogL> yep
[2003/01/13 08:18:49] #net-snmp <dts> As for what to call it - the MIB doesn't care. It's "some form of storage". End of Story.
[2003/01/13 08:19:04] #net-snmp <TrogL> here's my other problem...and this probably IS associated with indexes
[2003/01/13 08:19:09] #net-snmp <dts> Put a suitable string in the description field, and the MIB police will be happy.
[2003/01/13 08:19:17] #net-snmp <TrogL> my bugaboo is a CD-changer
[2003/01/13 08:19:25] #net-snmp <TrogL> it's got 144 disks in it
[2003/01/13 08:19:34] #net-snmp <dts> Ah.... I can see where this might be going....
[2003/01/13 08:19:39] #net-snmp <TrogL> if I do an snmpwalk of the changer, it will report such and usch number of disks
[2003/01/13 08:19:49] #net-snmp <TrogL> then Jim (my sidekick) changes one of the disks on me
[2003/01/13 08:20:20] #net-snmp <TrogL> so should disk #56 change its description? or is #56 retained forever and the NEW disks becomes something else
[2003/01/13 08:20:30] #net-snmp <TrogL> within the spirit of the RFC as I udnerstand it...
[2003/01/13 08:20:40] #net-snmp <TrogL> it should retain the old value and cobble up a new one
[2003/01/13 08:21:21] #net-snmp <TrogL> or am I on the wrong leve, and its actually the index i'm talking about?
[2003/01/13 08:21:29] #net-snmp <dts> Ummm.... "A unique value for each logical storage area" ....
[2003/01/13 08:21:48] #net-snmp <dts> Yes - I think each individual CD is probably a different "logical storage area"!
[2003/01/13 08:21:56] #net-snmp <TrogL> grrrr
[2003/01/13 08:22:13] #net-snmp <dts> Qn: can you get some sort of identifier as to which CD is loaded at any particular time?
[2003/01/13 08:22:25] #net-snmp <TrogL> I dont' think the existing Solaris code takes this into account
[2003/01/13 08:22:45] #net-snmp <TrogL> yes the CD does deliver a unique label
[2003/01/13 08:23:11] #net-snmp <dts> What form is the label?
[2003/01/13 08:25:47] #net-snmp <rstory> dts: did you get a chance to look at Jay's latest patch to table_iterator.c?
[2003/01/13 08:26:56] #net-snmp <dts> rstory: not properly - it looks plausible, but I don't fully understand how the free hooks are meant to work.
[2003/01/13 08:27:01] #net-snmp <TrogL> dts: df -jk reports something like /opt1/jukebox/may23_5 ...but this label is controlled by stuff inside the jukebox
[2003/01/13 08:27:15] #net-snmp <dts> I was hoping Wes would say a little more.
[2003/01/13 08:27:48] #net-snmp <TrogL> what about an even simpler case - changing cd
[2003/01/13 08:27:50] #net-snmp <TrogL> 's
[2003/01/13 08:27:56] #net-snmp <TrogL> in /cdrom
[2003/01/13 08:27:57] #net-snmp <wes> as I mentioned in the mail, I'd apply it.
[2003/01/13 08:28:01] #net-snmp <rstory> yeah, me too.. ok, well, i guess it's going into 5.0.7 untested...
[2003/01/13 08:28:14] #net-snmp <dts> TrogL: And presumably the "may23_5" bit is the bit that changes?
[2003/01/13 08:28:20] #net-snmp <TrogL> yep
[2003/01/13 08:28:24] #net-snmp <wes> quick test for you: use it against plutoplus and make sure plutoplus works.
[2003/01/13 08:29:02] #net-snmp <dts> OK - let's stick with that one for now, and come back to /cdrom (or /floppy) later.
[2003/01/13 08:29:29] #net-snmp <dts> Given that this is alphabetic, my gut reaction is to follow one of two routes.
[2003/01/13 08:30:08] #net-snmp <dts> Set up a "storage registry" that maps between (opaque) identification strings and arbitrary indexes.
[2003/01/13 08:30:34] #net-snmp <dts> You could strip off the /opt1/jukebox prefix to make things smaller, but it probably doesn't matter either way.
[2003/01/13 08:31:04] #net-snmp <dts> That's very much the same idea as the interface registry. Just working with a different domain.
[2003/01/13 08:36:12] #net-snmp <TrogL> I just talked to Jim. the disk handling is done using 3rd party software called "tracer" for which there is no known API
[2003/01/13 08:36:44] #net-snmp <TrogL> so to build the partition tree, I'm reliant upon the operating system
[2003/01/13 08:37:33] #net-snmp <dts> What gives you the /opt1/j/xxxx label - 'tracer' or the O/S?
[2003/01/13 08:37:45] #net-snmp <TrogL> the OS
[2003/01/13 08:38:32] #net-snmp <dts> Then that's not a problem then. As long as the agent can find out the labels, it looks them
[2003/01/13 08:38:42] #net-snmp <dts> up in the registry and uses the corresponding index value.
[2003/01/13 08:39:02] #net-snmp <dts> You can either prime the registry initially, or let it build up the values as you use the CDs.
[2003/01/13 08:39:20] #net-snmp <TrogL> there's another scenario, on-the-fly mounting and umounting of NFS mounted volumes
[2003/01/13 08:39:28] #net-snmp <dts> Now all that's needed is to write the registry,
[2003/01/13 08:40:05] #net-snmp <dts> OK - same question applies. Is there an "identifier" for the NFS volumes?
[2003/01/13 08:40:19] #net-snmp <dts> E.g. the local mount point, or remote export point.
[2003/01/13 08:40:30] #net-snmp <TrogL> well...yes
[2003/01/13 08:40:53] #net-snmp <TrogL> but we could have multiple volumes hung off /mnt in the course of the day
[2003/01/13 08:41:13] #net-snmp <TrogL> again the RFC implied (at least to me) that they get their own "index"
[2003/01/13 08:41:48] #net-snmp <dts> Yes - I think that's correct. It certainly feels the Right Thing To Do.
[2003/01/13 08:42:28] #net-snmp <dts> But as long as different volumes can be distinguished in some way, the registry should handle it fine.
[2003/01/13 08:42:29] #net-snmp <TrogL> we're talking HOST-RESOURCES-MIB::hrDeviceIndex ... right?
[2003/01/13 08:43:34] #net-snmp <TrogL> in the case of /mnt - they could be determined by their raw mount point ie. mysever:/mountpoint
[2003/01/13 08:43:50] #net-snmp <dts> Ummm... sort of. Up to now, we've been discussing hrStorageTable/hrStorageIndex
[2003/01/13 08:44:04] #net-snmp <dts> The same technique would work for hrDeviceTable/hrDeviceIndex.
[2003/01/13 08:44:30] #net-snmp <dts> I don't think that remote devices (i.e. NFS volumes) belong in the device table.
[2003/01/13 08:44:40] #net-snmp <dts> But they're fine in the storage table.
[2003/01/13 08:45:32] #net-snmp <dts> (or at least, they're *potentially* fine in the storage table - some places might not want this)
[2003/01/13 08:46:58] #net-snmp <dts> I'd originally been thinking of separate registries for your CD changer, NFS volumes, local disks, etc
[2003/01/13 08:47:14] #net-snmp <dts> But the more I think about it, a single registry should work fine.
[2003/01/13 08:47:39] #net-snmp <dts> You might end up with different types of storage intermixed, but that's not a fundamental problem.
[2003/01/13 08:48:05] #net-snmp <dts> And a suitable priming of the registry would keep things separated - at least initially.
[2003/01/13 08:48:37] #net-snmp <dts> And if you *really* wanted to keep related blocks together, then you could have special code in
[2003/01/13 08:48:57] #net-snmp <dts> the registry lookup routines - say to apply a "base index" for any new allocation request.
[2003/01/13 08:49:25] #net-snmp <dts> But that would start to stretch the AgentX capabilities, unless we were very careful....
--> TrogL has joined #net-snmp
--> mike has joined #net-snmp
--> delanne_ has joined #net-snmp
--> rstory has joined #net-snmp
[2003/01/13 08:50:45] #net-snmp <dts> Was it something I said.....?
[2003/01/13 08:51:20] #net-snmp <rstory> heh
[2003/01/13 08:51:21] #net-snmp <TrogL> no, a net split
[2003/01/13 08:52:22] #net-snmp <TrogL> I"m still a bit lost as per the distinction between "registry", "hrStorageTable" and "hrDeviceTable" and "index"
[2003/01/13 08:53:04] #net-snmp <dts> OK very quickly - since it's coming up to 5, and I've got a church meeting this evening.....
[2003/01/13 08:53:19] #net-snmp <dts> We've got two separate tables:
[2003/01/13 08:53:37] #net-snmp <dts> 'hrDeviceTable' lists local hardware connected to "this box".
[2003/01/13 08:53:45] #net-snmp <dts> this includes disks.
[2003/01/13 08:54:10] #net-snmp <dts> 'hrStorageTable' lists "storage" blocks - in whatever form this might take.
[2003/01/13 08:54:38] #net-snmp <dts> Each of these have a (separate) arbitrary index value - used to identify individual entries.
[2003/01/13 08:54:48] #net-snmp <dts> All of this is part of the official MIB.
[2003/01/13 08:54:56] #net-snmp <dts> OK so far?
[2003/01/13 08:55:28] #net-snmp <TrogL> yep
[2003/01/13 08:55:53] #net-snmp <dts> Right - the "storage registry" is a private Net-SNMP invention.
[2003/01/13 08:56:02] #net-snmp <dts> (That currently only exists in my mind!)
[2003/01/13 08:56:21] #net-snmp <dts> This serves to map between some natural string identifier, and a numeric value.
[2003/01/13 08:56:44] #net-snmp <dts> This numeric value can then be used as the index to the hrXxxxTable.
[2003/01/13 08:57:10] #net-snmp <dts> By keeping a local database of this mapping, we can ensure a consistent index allocation across the life
[2003/01/13 08:57:33] #net-snmp <dts> of the agent (and even from one run to the next, if we dump/reload the registry)
[2003/01/13 08:57:51] #net-snmp <TrogL> ACTION starts to see the light
[2003/01/13 08:57:52] #net-snmp <dts> Does that make sense?
[2003/01/13 08:58:40] #net-snmp <TrogL> ok on one of my boxes i've got four entries in hrDeviceIndex...769, 1536, 1539 and 3072
[2003/01/13 08:58:48] #net-snmp <TrogL> 769 is the processor
[2003/01/13 08:59:18] #net-snmp <TrogL> 1536 is cotodo
[2003/01/13 08:59:30] #net-snmp <TrogL> 1539 is c0t3d0
[2003/01/13 08:59:51] #net-snmp <dts> Sorry I'll have to run - bear in mind that I've been talking about a *new* mechanism.
[2003/01/13 09:00:12] #net-snmp <TrogL> so what you want is the 1536 eg. to stay consistent between runs?
[2003/01/13 09:00:19] #net-snmp <dts> Currently the Device table uses a 'major/minor' mechanism, to handle different types of device.
[2003/01/13 09:00:30] #net-snmp <dts> Yes - 1536 should stay consistent.
[2003/01/13 09:00:40] #net-snmp <TrogL> does it now?
[2003/01/13 09:01:00] #net-snmp <dts> But by registering "cotodo=1536" rather than saying "the first network interface is 1234"
[2003/01/13 09:01:14] #net-snmp <TrogL> OK, i'll let you go
[2003/01/13 09:01:16] #net-snmp <dts> and they're consective from that. (or whatever this device is).
[2003/01/13 09:01:21] #net-snmp <TrogL> thanks for the lesson
[2003/01/13 09:01:29] #net-snmp <dts> G'night al.
--> TrogL has joined #net-snmp
[2003/01/13 09:15:54] #net-snmp <TrogL> logging's working - right?
--> benr has joined #net-snmp
[2003/01/13 10:31:17] #net-snmp <benr> ACTION is away: meeting.
--> jonny_ has joined #net-snmp
[2003/01/13 10:50:17] #net-snmp <jonny_> Hi!
[2003/01/13 10:52:59] #net-snmp <wes> hi!
[2003/01/13 10:53:36] #net-snmp <jonny_> I'm having a little problem with the library...
[2003/01/13 10:54:00] #net-snmp <jonny_> snprint_objid(buf, sizeof(buf), vars->val.objid, vars->val_len);
[2003/01/13 10:54:24] #net-snmp <jonny_> results in buf having:
[2003/01/13 10:54:41] #net-snmp <jonny_> .iso.org.dod.internet.private.enterprises.43.10.27.4.1.2.2.41.135989616.136028600.19.1836008243.1886737184.1951625829.543908705.18761.0.57.136028560.135989648.40.8.7.2.0.136028668.136028668.136028724.136029028.135257116.65536.57.135989648.136028712.40
[2003/01/13 10:54:51] #net-snmp <jonny_> (and returns -1)
[2003/01/13 10:55:21] #net-snmp <wes> vars->val_len looks wrong unless that's a real oid with those wacky large (but legal) numbers in it.
[2003/01/13 10:56:17] #net-snmp <jonny_> why is val_len wrong?
[2003/01/13 10:56:36] #net-snmp <jonny_> the correct value is: ...enterprises.43.10.27.4.1.2.2
[2003/01/13 10:57:08] #net-snmp <benr> ACTION is back (gone 00:25:49)
[2003/01/13 10:57:51] #net-snmp <jonny_> hmmm... just seeing "var->val_len / sizeof(oid)"... is this correct?
[2003/01/13 10:58:01] #net-snmp <jonny_> i.e. val_len is the number of numbers in the oid??
[2003/01/13 10:58:14] #net-snmp <wes> If thatsa varbind list, then yes.
[2003/01/13 10:58:32] #net-snmp <wes> that should fix it
[2003/01/13 10:59:16] #net-snmp <jonny_> ahhh... looks better :)
[2003/01/13 11:00:08] #net-snmp <jonny_> another question: what value should I use for ASN_BOOLEAN? *vars->val.integer?
[2003/01/13 11:07:24] #net-snmp <TrogL> is it my imagination, or is there a logarthmic leap in usage of net-snmp on Solaris (or at lease people asking for help)? Wonder if it's got anything to do with Sun's new "service"?
[2003/01/13 11:07:53] #net-snmp <rstory> jonny_: yes, boolean is an integer
[2003/01/13 11:08:09] #net-snmp <jonny_> thx...
[2003/01/13 11:14:28] #net-snmp <jonny_> one last thing for today... :)
[2003/01/13 11:14:35] #net-snmp <jonny_> could somebody please have a look at
[2003/01/13 11:14:39] #net-snmp <jonny_> http://www.bettina-attack.de/jonny/phpsnmp.c
[2003/01/13 11:15:06] #net-snmp <jonny_> and tell me, if this is the right way to get the different snmp value types?
[2003/01/13 11:20:29] #net-snmp <wes> jonny_: ASN_BOOLEAN is actually an illegal SNMP type. You must use an integer instead.
[2003/01/13 11:21:46] #net-snmp <jonny_> ok, thank you! so i will test the stuff tomorrow and submit a patch to php-dev...
[2003/01/13 11:36:26] #net-snmp <jonny_> i have to leave... c u!
--> nostaw has joined #net-snmp
[2003/01/13 11:55:12] #net-snmp <nostaw> question, is there a --disable-openssl using ./configure ?
[2003/01/13 11:56:51] #net-snmp <rstory> try --with-openssl=none
[2003/01/13 12:06:23] #net-snmp <nostaw> looks like --without-openssl is working
[2003/01/13 12:07:00] #net-snmp <nostaw> tho, it still finds the openssl header files...
[2003/01/13 12:07:34] #net-snmp <nostaw> I'm hoping with the #define USE_OPENSSL undefined it will use the internal MD5
[2003/01/13 12:08:28] #net-snmp <nostaw> there doesn't seem to be a -Dparm to confirm the use of internal MD5 vs Openssl
[2003/01/13 12:09:23] #net-snmp <TrogL> are you using make test?
[2003/01/13 12:10:00] #net-snmp <nostaw> nope
[2003/01/13 12:11:05] #net-snmp <nostaw> trying to compare the output of the generate_Ku on my ported platform vs. linux
[2003/01/13 12:11:22] #net-snmp <TrogL> at the end of the ./configure script there's a blub indicating what was used. Is that sufficient?
[2003/01/13 12:11:26] #net-snmp <nostaw> linux always gives the correct Ku, but on MVS it doesn't
[2003/01/13 12:12:12] #net-snmp <nostaw> make test skipped the MD5DES and SHA, so I think I'm ok.
[2003/01/13 12:13:22] #net-snmp <nostaw> I finally got around the spin loop problem...
[2003/01/13 12:27:05] #net-snmp <TrogL> the processor is always 769 and the co-processor 3072 in hrDeviceType. Is this hard-coded somewhere (if so I can't find it) or a standard?
[2003/01/13 12:27:46] #net-snmp <TrogL> The first disk controller appears to always be 1536, the next 1538 or later. what happened to 1537?
[2003/01/13 12:33:42] #net-snmp <TrogL> ACTION is comparing implementations on Solaris (various breeds) and linux
[2003/01/13 12:38:09] #net-snmp <nostaw> ACTION cannot comment because he doesn't know.
[2003/01/13 12:38:18] #net-snmp <nostaw> Hmmm... I guess I did comment.
[2003/01/13 12:40:06] #net-snmp <TrogL> what time's Dave get on here in the morning (our time)?
--> bitInit has joined #net-snmp
[2003/01/13 12:42:09] #net-snmp <bitInit> hello
[2003/01/13 12:42:19] #net-snmp <TrogL> hello
[2003/01/13 12:43:03] #net-snmp <bitInit> is there any good mib (free) mib browsers.. that will convert a given mib to all of it's OID values for extracting values?
[2003/01/13 12:43:35] #net-snmp <nostaw> like snmptranslate does ?
[2003/01/13 12:44:01] #net-snmp <bitInit> was not aware of snmptranslate
[2003/01/13 12:44:12] #net-snmp <bitInit> that comes with net-snmp i'm guessing...
[2003/01/13 12:44:16] #net-snmp <TrogL> yep
[2003/01/13 12:44:21] #net-snmp <nostaw> it's one of the applications.
[2003/01/13 12:44:36] #net-snmp <nostaw> give it a name or OID and it gives you oodles of info.
[2003/01/13 12:44:39] #net-snmp <bitInit> a little rtfm goes a long way
[2003/01/13 12:44:40] #net-snmp <nostaw> very nice.
[2003/01/13 12:44:54] #net-snmp <bitInit> but the mib must be in your snmp.conf correct?
[2003/01/13 12:45:16] #net-snmp <nostaw> well, now you can RTFM on snmptranlate to see if it does you
[2003/01/13 12:45:45] #net-snmp <nostaw> well, you can override it with -m and -M as long as it can find the text files.
[2003/01/13 12:46:05] #net-snmp <bitInit> thanx.. i will have to try that when i get back home
[2003/01/13 12:46:13] #net-snmp <nostaw> very cool.
[2003/01/13 12:46:24] #net-snmp <nostaw> let us know if we can be helpful
[2003/01/13 12:46:47] #net-snmp <bitInit> already have been helpful.. and even when the answer was staring me in the face :)
[2003/01/13 12:46:48] #net-snmp <bitInit> thanx
[2003/01/13 12:50:15] #net-snmp <TrogL> ACTION didn't know about -m/M
[2003/01/13 12:50:33] #net-snmp <nostaw> ACTION uses that to test out new MIBbers.
[2003/01/13 12:53:32] #net-snmp <bitInit> you don't really need the mib installed to use snmpwalk correct? i can just use the OID to get the values i need correct?
[2003/01/13 12:53:42] #net-snmp <bitInit> just need the mib to use names
[2003/01/13 12:56:04] #net-snmp <nostaw> correct a
[2003/01/13 12:56:15] #net-snmp <nostaw> nd to 'translate' the output at times.
[2003/01/13 12:56:24] #net-snmp <nostaw> like with displayhints & etc.
[2003/01/13 12:56:41] #net-snmp <nostaw> some stuff, if walk doesn't know how to interpret it, it will drop into hex.
[2003/01/13 12:56:57] #net-snmp <nostaw> no biggie, but can be surprising at times.
[2003/01/13 12:59:05] #net-snmp <bitInit> k
[2003/01/13 12:59:15] #net-snmp <bitInit> just checking
[2003/01/13 12:59:52] #net-snmp <benr> ACTION is away: meeting
[2003/01/13 13:12:32] #net-snmp <nostaw> here's a question I haven't seen asked... is there a utility that will take the Ku and display the passphrase used to create it ?
[2003/01/13 13:12:52] #net-snmp <wes> you can't.
[2003/01/13 13:12:57] #net-snmp <wes> It's a one-way hash.
[2003/01/13 13:12:59] #net-snmp <nostaw> a degenerate_Ku in effect
[2003/01/13 13:13:02] #net-snmp <nostaw> drat.
[2003/01/13 13:13:07] #net-snmp <wes> no, not drat.
[2003/01/13 13:13:15] #net-snmp <nostaw> laugh
[2003/01/13 13:13:17] #net-snmp <wes> It's a good thing.
[2003/01/13 13:13:22] #net-snmp <wes> (assuming you like security at all)
[2003/01/13 13:13:28] #net-snmp <wes> actually, that's not true.
[2003/01/13 13:13:45] #net-snmp <wes> Ku could be reversable without compromising much security-wise. Kul couldn't, however.
[2003/01/13 13:14:09] #net-snmp <wes> You can use randomly generated Ku's though, or even use your own password->key program if you wanted.
[2003/01/13 13:14:46] #net-snmp <nostaw> I do like it, but I have to fix MD5... I keep getting the same Ku, but it's not correct... this leads me to believe that something is getting managled on it's way to generate_Ku
[2003/01/13 13:15:02] #net-snmp <nostaw> but I don't see how... snmp_parse_args calls it directly.
[2003/01/13 13:16:49] #net-snmp <nostaw> I get the passphrase (Apsz) from a EBCDIC commandline, convert Apsz to ascii and pass it along...
[2003/01/13 13:16:53] #net-snmp <wes> is this in your embedded system?
[2003/01/13 13:16:55] #net-snmp <nostaw> something is getting munched.
[2003/01/13 13:17:01] #net-snmp <nostaw> yepperz...
[2003/01/13 13:17:28] #net-snmp <nostaw> i feared that the internal MD5 was broke, but I confirmed it's working on linux.
[2003/01/13 13:17:31] #net-snmp <wes> print the hex values to the screen after converting to ascii?
[2003/01/13 13:17:44] #net-snmp <wes> no, internal md5 is working...
[2003/01/13 13:17:56] #net-snmp <nostaw> 2e40fa2fa08ba9be0a815cb2e037fdc5
[2003/01/13 13:18:14] #net-snmp <wes> and compare those to hex values from a real linux box
[2003/01/13 13:18:24] #net-snmp <wes> (I don't mean Ku, I mean the pass phrase)
[2003/01/13 13:18:38] #net-snmp <nostaw> 46168ff686f072e9a3dbb8b58d5264c4
[2003/01/13 13:18:40] #net-snmp <nostaw> oh...
[2003/01/13 13:19:04] #net-snmp <wes> in other words, make sure that the passwords passed to generate_ku are equiv.
[2003/01/13 13:22:22] #net-snmp <nostaw> the trouble is that I cannot see ascii characters only EBCDIC, but you've given me an idea or two.
[2003/01/13 13:22:28] #net-snmp <nostaw> thanks.
[2003/01/13 13:27:51] #net-snmp <wes> right, which is why I suggested printing hex versions instead of raw versions since hex output will be in ebcdic
[2003/01/13 13:32:47] #net-snmp <nostaw> what's the difference between DEBUGMSG & DEBUGMSGTL ?
[2003/01/13 13:33:10] #net-snmp <nostaw> in a nutshell, I can go read the go code.
[2003/01/13 13:47:06] #net-snmp <wes> use debugmsgtl to start (prints token and line information)
[2003/01/13 13:47:16] #net-snmp <wes> if you don't terminate that call with "\n" then use DEBUGMSG till you do.
[2003/01/13 13:51:09] #net-snmp <nostaw> thanks...
[2003/01/13 13:51:41] #net-snmp <nostaw> nekkid printf's go to "syslog" and not the console...
[2003/01/13 13:57:25] #net-snmp <nostaw> I've proven that it gets mangled... now to prove how.
[2003/01/13 13:57:26] #net-snmp <nostaw> :)
[2003/01/13 13:58:09] #net-snmp <wes> well, and that means I've proven it's not in our code!
[2003/01/13 13:58:49] #net-snmp <nostaw> it gets mangled on the call of generate_Ku
[2003/01/13 13:59:29] #net-snmp <nostaw> Apsz is correct just before the call...
[2003/01/13 13:59:44] #net-snmp <nostaw> and trash inside of generate_Ky
[2003/01/13 13:59:48] #net-snmp <nostaw> ooops... Ku
--> benr has joined #net-snmp
--> jdwatson has joined #net-snmp
[2003/01/13 14:16:34] #net-snmp <nostaw> I was mistaken, the passphrase is intact thru the call.
[2003/01/13 14:16:57] #net-snmp <nostaw> I left in a previous __etoa call
[2003/01/13 14:18:55] #net-snmp <nostaw> I wonder what *bufp has in it...
[2003/01/13 14:19:25] #net-snmp <nostaw> I mean buf
[2003/01/13 14:20:22] #net-snmp <wes> ACTION thinks you should open your window and listen for his scream (this getting to you faster at the speed of light you might make the window by the time the speed of sound catches up)
[2003/01/13 14:20:51] #net-snmp <nostaw> ACTION doesn't have a window.
[2003/01/13 14:21:06] #net-snmp <wes> openssl changes its api quite a bit between releases.
[2003/01/13 14:21:06] #net-snmp <nostaw> ACTION waits for the sound to get thru the walls.
[2003/01/13 14:21:19] #net-snmp <wes> calls in 0.9.6 that didn't free memory now do it in 0.9.7
[2003/01/13 14:21:44] #net-snmp <nostaw> that would make me scream...
[2003/01/13 14:22:07] #net-snmp <nostaw> good thing I can't use openssl on my embedded platform, eh ?
[2003/01/13 14:22:32] #net-snmp <wes> heh.
[2003/01/13 14:22:37] #net-snmp <TrogL> when did 0.9.7 get released?
[2003/01/13 14:22:45] #net-snmp <wes> Um, december I think.
[2003/01/13 14:22:54] #net-snmp <TrogL> lovely
[2003/01/13 14:23:02] #net-snmp <TrogL> is it worth the upgrade?
[2003/01/13 14:23:03] #net-snmp <wes> (I've been using a beta for a while, and there were api changes from the beta to the real as well)
[2003/01/13 14:23:08] #net-snmp <wes> It'll give you AES.
[2003/01/13 14:23:26] #net-snmp <wes> and, uh, segfaults!
[2003/01/13 14:23:46] #net-snmp <TrogL> ACTION pauses, significantly
[2003/01/13 14:23:59] #net-snmp <wes> (only because it's freeing memory it shouldn't)
[2003/01/13 14:24:03] #net-snmp <wes> or didn't used to.
[2003/01/13 14:24:21] #net-snmp <TrogL> hmmmmmm
[2003/01/13 14:24:32] #net-snmp <wes> and actually, the only way I get it to segfaut is inside of apache in a mod_perl script which calls the SNMP perl module to get MIB information.
[2003/01/13 14:24:38] #net-snmp <wes> apps and demons don't.
[2003/01/13 14:24:39] #net-snmp <wes> very odd.
[2003/01/13 14:25:00] #net-snmp <wes> probably apache's reworked malloc.
[2003/01/13 14:28:26] #net-snmp <TrogL> as in apache has or apache implements?
[2003/01/13 14:29:47] #net-snmp <wes> apach has a reworked memory allocation system.=
[2003/01/13 14:29:52] #net-snmp <wes> probably the problem.
--> jdwatson has joined #net-snmp
[2003/01/13 14:35:16] #net-snmp <TrogL> apache ver?
[2003/01/13 14:35:34] #net-snmp <TrogL> ACTION wonders if this might be associated with a bug in a related proejct
--> aowi8445 has joined #net-snmp
--> benr has joined #net-snmp
--> nostaw has joined #net-snmp
[2003/01/13 15:32:05] #net-snmp <nostaw> wes: you still out there ?
[2003/01/13 15:32:28] #net-snmp <wes> no, not me. nope. very gone.
[2003/01/13 15:32:35] #net-snmp <nostaw> oh ok...
[2003/01/13 15:32:40] #net-snmp <nostaw> found the MD5 problem.
[2003/01/13 15:32:49] #net-snmp <nostaw> code is good... me is dumb
[2003/01/13 15:32:57] #net-snmp <wes> (note that my name will wake me up (or annoy me by making my window pop forward till I turn it off to ignore people)
[2003/01/13 15:32:59] #net-snmp <wes> heh.
[2003/01/13 15:33:01] #net-snmp <wes> what was it?
[2003/01/13 15:33:51] #net-snmp <nostaw> I'm running on a Big Endian system...
[2003/01/13 15:34:16] #net-snmp <nostaw> didn't change that in net-snmp-config.h
[2003/01/13 15:34:46] #net-snmp <TrogL> shouldn't "configure" figure that out?
[2003/01/13 15:35:06] #net-snmp <wes> cross compiler?
[2003/01/13 15:35:07] #net-snmp <nostaw> I can't run ./configure
[2003/01/13 15:35:24] #net-snmp <TrogL> :(
[2003/01/13 15:35:34] #net-snmp <nostaw> ACTION == ./configure
[2003/01/13 15:35:38] #net-snmp <wes> You can run configure with a cross compiler. I think there are instructions in the INSTALL script.
[2003/01/13 15:35:43] #net-snmp <nostaw> TrogL: you're teling me.
[2003/01/13 15:36:46] #net-snmp <nostaw> i'm just happy that MD5 is working as ported and I don't have to pollute the mainline code.
[2003/01/13 15:37:00] #net-snmp <nostaw> ports go much faster when I don't make changes.
[2003/01/13 15:37:02] #net-snmp <nostaw> :)
[2003/01/13 15:37:34] #net-snmp <TrogL> do we have this working on AS400?
[2003/01/13 15:37:43] #net-snmp <TrogL> ACTION is wondering because he might inherit one during a reorg
[2003/01/13 15:38:23] #net-snmp <wes> # grep AS400 FAQ
[2003/01/13 15:38:24] #net-snmp <wes> nope
[2003/01/13 15:38:24] #net-snmp <nostaw> it might work in the *nix emulator
[2003/01/13 15:40:11] #net-snmp <nostaw> well, my office time has expired... time to go work from home.
[2003/01/13 16:27:03] #net-snmp <TrogL> niet
[2003/01/13 16:27:04] #net-snmp <TrogL> nite
[2003/01/13 16:27:21] #net-snmp <TrogL> lovely, a misspelling of a misspelling
--> JerJer has joined #net-snmp
[2003/01/13 16:46:32] #net-snmp <JerJer> does someone have a basic snmp.conf file example so i can make the 'interfaces' mib work ?
[2003/01/13 16:51:30] #net-snmp <wes> whats the problem?
[2003/01/13 16:51:50] #net-snmp <wes> ie, what aspecto f the interfaces mib is broken.
[2003/01/13 16:52:08] #net-snmp <JerJer> snmpwalk 192.168.1.1 public interfaces
[2003/01/13 16:52:36] #net-snmp <JerJer> Timeout: NO response from 192.168.1.1
[2003/01/13 16:52:58] #net-snmp <JerJer> but if i don't put anything after pubic i get everything
[2003/01/13 16:53:43] #net-snmp <JerJer> hmmm i just found snmpconf -- leme run through this
[2003/01/13 16:58:30] #net-snmp <JerJer> ok something is still odd... i can do snmpwalk 127.0.0.1 public interfaces and everything works but i can't do it from a real network interface (and i didn't specify any restrictions in snmpconf)
[2003/01/13 17:02:22] #net-snmp <rstory> JerJer: snmpwalk -c pulic 192.168.1.1 interfaces
[2003/01/13 17:03:26] #net-snmp <JerJer> Timeout: No Response from 192.168.1.1
[2003/01/13 17:03:45] #net-snmp <rstory> what version of net-snmp?
[2003/01/13 17:04:01] #net-snmp <JerJer> but i can go onto that specific machine (using 127.0.0.1) and everything works
[2003/01/13 17:04:26] #net-snmp <JerJer> ucd-snmp-4.2.5-7.73.0
[2003/01/13 17:04:58] #net-snmp <rstory> run snmpd as 'snmp -f -d -L' in a window on the machine...
[2003/01/13 17:05:16] #net-snmp <rstory> then do a query, and make sure it is dumping the packet in, and another one out...
[2003/01/13 17:05:58] #net-snmp <JerJer> /etc/snmp/snmpd.conf: line 83: Error: bad SUBTREE object id
[2003/01/13 17:06:09] #net-snmp <JerJer> /usr/share/snmp/snmpd.conf: line 83: Error: bad SUBTREE object id
[2003/01/13 17:06:30] #net-snmp <rstory> hm... you probably only want one snmpd.conf file...
[2003/01/13 17:06:48] #net-snmp <rstory> is line 83 related to access control?
[2003/01/13 17:07:14] #net-snmp <JerJer> view systemview included all <--- line 83 (from a snmpconf generated snmpd.conf)
[2003/01/13 17:10:16] #net-snmp <rstory> try changing 'all' to '.1'
[2003/01/13 17:14:10] #net-snmp <JerJer> ok something is really strange... i just did snmpconf again but deleted all snmpd.conf files first... now i don't have that line but I did everything the same exact way i did it b4 and now nothing works
[2003/01/13 17:17:25] #net-snmp <JerJer> very strage..if i do snmpwalk -c public 192.168.1.1 interfaces (from the acutal 192.168.1.1 machine everything works) but i can't move to another server on this private network and i get a timeout
[2003/01/13 17:18:31] #net-snmp <rstory> do you see the packets coming in in the snmpd -d -f -L window?
[2003/01/13 17:19:46] #net-snmp <JerJer> nothing
[2003/01/13 17:20:03] #net-snmp <JerJer> [root@frat snmpd]# snmpd -f -d -L
[2003/01/13 17:20:03] #net-snmp <JerJer> UCD-SNMP version 4.2.5
[2003/01/13 17:20:09] #net-snmp <JerJer>
[2003/01/13 17:20:41] #net-snmp <rstory> then the packets are getting in... maybe a firewall rule? tcpwrappers?
[2003/01/13 17:20:47] #net-snmp <rstory> s/are/are not/
[2003/01/13 17:21:42] #net-snmp <JerJer> no firewal... these machines are plugged into a dumb hub
[2003/01/13 17:21:50] #net-snmp <JerJer> into the same dumb hub
[2003/01/13 17:22:47] #net-snmp <rstory> ok, try a walk on the local host, and verify that it dumps packets...
[2003/01/13 17:23:00] #net-snmp <rstory> (in the agent window)
[2003/01/13 17:23:13] #net-snmp <JerJer> just tried that.. just sits there... but i get a response
[2003/01/13 17:24:03] #net-snmp <rstory> ok, control-c to kill it, and try a walk again... (without restarting the agent)
[2003/01/13 17:24:12] #net-snmp <rstory> should get a timeout
[2003/01/13 17:24:20] #net-snmp <JerJer> yep drop
[2003/01/13 17:24:24] #net-snmp <JerJer> er timeout
[2003/01/13 17:25:53] #net-snmp <rstory> vi /var/log/snmpd.log (or cat it) and see if maybe messages are going there instead...
[2003/01/13 17:26:25] #net-snmp <JerJer> yeah i see waht looks like a hex display of the protcol
[2003/01/13 17:27:11] #net-snmp <rstory> hmm... -L is supposed to direct output to the console... i wonder why that's not working...
[2003/01/13 17:27:34] #net-snmp <rstory> ok, so, open another terminal to that box, and tail -f /var/log/snmpd.log
[2003/01/13 17:27:50] #net-snmp <rstory> query local and verify packet is logged, then try again remotely
[2003/01/13 17:28:00] #net-snmp <JerJer> ko
[2003/01/13 17:28:53] #net-snmp <JerJer> very odd... everything works now
[2003/01/13 17:28:56] #net-snmp <JerJer> local and remote
[2003/01/13 17:29:13] #net-snmp <rstory> hmm....
[2003/01/13 17:29:15] #net-snmp <JerJer> but nothing shows up on the snmpd -f -d -L line
[2003/01/13 17:29:24] #net-snmp <JerJer> orhter than UCD-SNMP version 4.2.5
[2003/01/13 17:29:38] #net-snmp <rstory> do you have anything about logging in your snmpd.conf file?
[2003/01/13 17:29:59] #net-snmp <JerJer> this was an RPM i just got from a redhat mirror .. in the updates directory
[2003/01/13 17:30:05] #net-snmp <JerJer> um...
[2003/01/13 17:42:27] #net-snmp <JerJer> that was pretty odd... it seems to be working now... even survived a reboot
[2003/01/13 17:42:46] #net-snmp <rstory> excellent
[2003/01/13 17:42:56] #net-snmp <JerJer> thanks for helping
[2003/01/13 17:43:01] #net-snmp <rstory> np
[2003/01/13 17:43:07] #net-snmp <JerJer> next topic
[2003/01/13 17:44:14] #net-snmp <JerJer> a while ago i registered for our own number with whoever.. i can make net-snmp use this number, right ?
[2003/01/13 17:44:48] #net-snmp <JerJer> like a enterprises.NNNN number
[2003/01/13 17:47:17] #net-snmp <rstory> yes
[2003/01/13 17:47:36] #net-snmp <JerJer> cool when i get to that point i'll snuggle up with the documentation : )
[2003/01/13 17:48:41] #net-snmp <rstory> though it depends on what you mean by 'use'... you may have to install from source instead of an rpm...
[2003/01/13 17:49:16] #net-snmp <JerJer> ahh ok ... we have our own software package we want to have some SNMP variables / Traps
[2003/01/13 17:51:03] #net-snmp <rstory> when you say variables, you want snmpd to respond to snmpget/set for your variables? or do you only want to send traps?
[2003/01/13 17:51:13] #net-snmp <JerJer> both
[2003/01/13 17:51:47] #net-snmp <JerJer> we are tossin the idea around for an SNMP method of configuration along with variables that get queried (then graphed)
[2003/01/13 17:51:50] #net-snmp <rstory> ok.. if you make a sub-agent (via AgentX), you can use snmpd as is.. if you don't want to use agent x, you'll be building a custom snmpd from source, and have to install that
[2003/01/13 17:53:21] #net-snmp <JerJer> hmmm ok ... i'll have to figure out how to go about doing all that... i sorta was invisioning hooking our source into an API of net-snmp's
[2003/01/13 17:54:42] #net-snmp <rstory> ah, I spoke too quickly.. there is actually another way, using dynamically loaded modules...
[2003/01/13 17:55:07] #net-snmp <JerJer> ahh coool
[2003/01/13 18:31:40] #net-snmp <JerJer> thanks again... i better go home b4 the better half calls the police
[2003/01/13 18:44:19] #net-snmp <rstory> wes: u there?
[2003/01/13 19:20:00] #net-snmp <wes> yep.
[2003/01/13 19:20:09] #net-snmp <wes> (now)
[2003/01/13 19:20:26] #net-snmp <rstory> uh, never mind...
[2003/01/13 19:20:36] #net-snmp <wes> done!
[2003/01/13 19:21:23] #net-snmp <rstory> 5.0.7 coming soon...
[2003/01/13 19:21:29] #net-snmp <wes> excellent!
[2003/01/13 19:21:41] #net-snmp <wes> did you tag it already?
[2003/01/13 19:22:40] #net-snmp <rstory> yeah, a few days ago, so I had to re-tag some stuff.. i messed up (which is what I was going to ask about earlier), but I think i've cleaned it up now...
[2003/01/13 19:22:52] #net-snmp <rstory> testing tarball on sf cf..
[2003/01/13 19:23:10] #net-snmp <wes> cool
[2003/01/13 19:24:22] #net-snmp <rstory> yeah, it's already save me from a next-day embarrassment..
[2003/01/13 19:24:34] #net-snmp <wes> heh.
[2003/01/13 19:29:57] #net-snmp <rstory> btw, i was wrong about the mibs... the v3 rfcs changed the notation for display string from 255a to 255t... mib.c now treats them the same...
[2003/01/13 19:30:34] #net-snmp <wes> Ah.
[2003/01/13 19:30:43] #net-snmp <wes> let me guess, ascii -> utf8?
[2003/01/13 19:31:09] #net-snmp <rstory> no idea.. i didn't track down the source of the change...
[2003/01/13 19:31:41] #net-snmp <rstory> the framework doc had a comment 'update to be in sync with current smi' or some such...
[2003/01/13 20:01:00] #net-snmp <rstory> 5.0.7 is out... night all...
[2003/01/13 20:21:29] #net-snmp <uathome> wtg
[2003/01/13 22:32:42] #net-snmp <wes> night!