Ability for fetch sysObjectID

[landy2005]

Please add ability for fetch/display numeric sysObjectID (1.3.6.1.2.1.1.2) together with sysDescr.

Can be optional, with output something like:

192.168.120.92 [1234] {.1.3.6.1.4.1.318.1.3.4.5} HP ETHERNET MULTI-ENVIRONMENT,ROM A.05.03,JETDIRECT,
JD24,EEPROM A.05.05
130.160.108.146 [public] {.1.3.6.1.4.1.318.1.3.4.5} Hardware: x86 Family 15 Model 0 Stepping 10 AT/AT
COMPATIBLE - Software: Windows 2000 Version 5.0 (Build 2195 Uniprocessor Free)

Unfortunately I'm not C guru..

[landy2005]

not possible? (

[zeepi222]

I am also looking for sysObjectID

[DFog14]

The way SNMP requests are handled in onesixtyone doesn't allow for multiple OIDs to be fetched in the same request. I'm currently working on a way to cycle through different OID for hosts, but it is not quite there yet.

In the mean time, if you want to pull sysObjectID from a host replace the hexadecimal string in the build_snmp_req() function with "\x30\x0e\x30\x0c\x06\x08\x2b\x06\x01\x02\x01\x01\x02\x0\x05\x00". This is the hex equivalent of the sysObjectID OID. Something to note though, is that sysDescr will no longer be returned, it will instead be sysObjectID.

The way SNMP requests are handled in onesixtyone doesn't allow for multiple OIDs to be fetched in the same request. I'm currently working on a way to cycle through different OID for hosts, but it is not quite there yet.

In the mean time, if you want to pull sysObjectID from a host replace the hexadecimal string in the build_snmp_req() function with "\x30\x0e\x30\x0c\x06\x08\x2b\x06\x01\x02\x01\x01\x02\x0\x05\x00". This is the hex equivalent of the sysObjectID OID. Something to note though, is that sysDescr will no longer be returned, it will instead be sysObjectID.

So, did you get this change to work? I'm looking at using this code too.

[dguido]

Technical Analysis & Implementation Plan for sysObjectID Support

I've done a thorough analysis of this feature request. Here's what's involved and a comprehensive plan for implementation.

What's Being Requested

You're asking for onesixtyone to fetch both sysDescr (1.3.6.1.2.1.1.1) and sysObjectID (1.3.6.1.2.1.1.2) from SNMP-enabled devices. This makes a lot of sense because:

• sysDescr provides a human-readable description of the system
• sysObjectID provides a vendor-specific OID that uniquely identifies the device type/model, which is extremely useful for device fingerprinting and inventory management

Current Architecture Limitations

After reviewing the codebase, here's why this isn't straightforward:

1. Single OID Design: The tool currently hardcodes the sysDescr OID as a hex string in build_snmp_req() at line 380:

   char object[] = "\x30\x0e\x30\x0c\x06\x08\x2b\x06\x01\x02\x01\x01\x01\x0\x05\x00";

2. Response Parser: The parse_snmp_response() function expects exactly one value in the response

3. Performance-First Architecture: onesixtyone's key innovation is sending requests as fast as possible without waiting. Adding multiple OIDs per scan could impact this.

Implementation Options

Option 1: Sequential Scanning (Recommended)

Add a command-line flag to specify which OID(s) to query:

onesixtyone -O sysDescr,sysObjectID 192.168.1.0/24 public

Implementation:

• Add an -O option to specify OIDs (default: sysDescr for backward compatibility)
• Modify build_snmp_req() to accept OID as parameter
• For multiple OIDs, send separate requests in sequence
• Track which OID each response corresponds to
• Display results with clear labeling

Pros:

• Maintains simplicity and reliability
• Backward compatible
• Clear implementation path

Cons:

• Doubles scan time when fetching both OIDs
• More network traffic

Option 2: SNMP GetBulk or Multi-OID GetRequest

Use SNMP's ability to request multiple OIDs in a single packet.

Implementation:

• Redesign packet building to support multiple OIDs
• Completely rewrite response parser to handle multiple values
• Handle various edge cases (some devices may only return partial results)

Pros:

• More efficient network usage
• Single request/response per host

Cons:

• Major refactoring required
• Risk of breaking compatibility with some devices
• Complex error handling

Option 3: Parallel Scanning

Run two concurrent scans - one for each OID.

Pros:

• No change to core architecture
• Could be implemented as a wrapper script

Cons:

• Doubles memory usage
• Coordination complexity
• May overwhelm network

Recommended Approach

I recommend Option 1 with the following implementation plan:

1. Add OID Selection

   • New -O flag to specify OID(s)
   • Support common OID names (sysDescr, sysObjectID, sysUpTime, etc.)
   • Allow raw OID input for flexibility

2. Modify Core Functions

   // Change from:
   int build_snmp_req(char* buf, size_t buf_size, char* target_community)
   // To:
   int build_snmp_req(char* buf, size_t buf_size, char* target_community, const char* oid_hex)

3. Enhanced Output Format

   192.168.1.1 [public] sysDescr: Cisco IOS Software, C2960 Software...
   192.168.1.1 [public] sysObjectID: .1.3.6.1.4.1.9.1.1208
   

4. Backward Compatibility

   • Default behavior unchanged (only query sysDescr)
   • Existing scripts continue to work

Quick Workaround

As @DFog14 mentioned, you can modify line 380 to query sysObjectID instead:

// For sysObjectID (1.3.6.1.2.1.1.2):
char object[] = "\x30\x0e\x30\x0c\x06\x08\x2b\x06\x01\x02\x01\x01\x02\x0\x05\x00";

Then run the tool twice - once for each OID - and merge the results.

Should This Be Implemented?

Yes, this would be a valuable addition. Device identification is crucial for network inventory and security assessments. The sysObjectID provides vendor-specific identification that complements the human-readable sysDescr perfectly.

Next Steps

If there's interest in moving forward with this:

1. Confirm the preferred implementation approach
2. Decide on command-line interface design
3. Determine if backward compatibility is required
4. Consider if other common OIDs should be supported (sysUpTime, sysContact, sysName, sysLocation)

The implementation would involve ~200-300 lines of changes, primarily in:

• Command-line parsing (init_options())
• Request building (build_snmp_req())
• Response handling (new function to track OID context)
• Output formatting

Let me know if you'd like me to elaborate on any part of this analysis or if you'd prefer a different approach!