Skip to content

Conversation

@ykyohei
Copy link
Contributor

@ykyohei ykyohei commented Apr 22, 2025

Make ibootbarAgent compatible with legecy ibootbar

Description

Make ibootbarAgent compatible with legacy ibootbar. There are differences in SNMP version, MIB. This PR supersedes #860.

Motivation and Context

This legacy iBootBar (iBB-N20) is used in satp3, we tried to swap the iBootBar with agent compatible device, iBoot PDU, but it turned out that it's physically not easy to do. Therefore, we modify the ibootbarAgent to be compatible with legacy ibootbar.

How Has This Been Tested?

Tested by daq-dev. Tested this works for legecy ibootbar, also confirmed this works for iboot-pdu.
One weird point is that the agent tasks works on legacy ibootbar but I see the following timeout failure in log.

2025-04-22T20:19:59+0000 start called for acq
2025-04-22T20:19:59+0000 acq:0 Status is now "starting".
2025-04-22T20:19:59+0000 acq:0 Status is now "running".
2025-04-22T20:20:00+0000 UdpTwistedTransport starting on 53749
2025-04-22T20:20:00+0000 Starting protocol <pysnmp.carrier.twisted.dgram.udp.UdpTwistedTransport object at 0x7fa5fd2057e0>
2025-04-22T20:20:25+0000 start called for set_outlet
2025-04-22T20:20:25+0000 set_outlet:1 Status is now "starting".
2025-04-22T20:20:25+0000 set_outlet:1 Status is now "running".
2025-04-22T20:20:31+0000 192.168.13.24 failure: [Failure instance: Traceback (failure with no frames): <class 'pysnmp.proto.errind.RequestTimedOut'>: No SNMP response received before timeout
]
2025-04-22T20:20:31+0000 None
2025-04-22T20:20:31+0000 set_outlet:1 Set outlet 2 to off
2025-04-22T20:20:31+0000 set_outlet:1 Status is now "done".

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.

Copy link
Member

@BrianJKoopman BrianJKoopman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me. One small comment on one of the tasks below. Thanks for working through the MIB/SNMP complications to get this working on this agent!

On SNMP version -- I was having a hard time finding it in the manual, but some devices will have a version selection within the UI on the device. Is the IBOOTBAR just so old it doesn't support v2? Or is it just set to v1 by default? (Which is fairly common in my experience.)

I'm not sure what to make of the timeout you posted. Does it show up every time you run with the legacy device. @davidvng might have some insights, as he's worked with many SNMP devices.

@BrianJKoopman BrianJKoopman requested a review from davidvng April 24, 2025 20:21
@BrianJKoopman BrianJKoopman added the enhancement New feature or request label Apr 24, 2025
Co-authored-by: Brian Koopman <BrianJKoopman@users.noreply.github.com>
@ykyohei
Copy link
Contributor Author

ykyohei commented Apr 24, 2025

On SNMP version -- I was having a hard time finding it in the manual, but some devices will have a version selection within the UI on the device. Is the IBOOTBAR just so old it doesn't support v2? Or is it just set to v1 by default? (Which is fairly common in my experience.)

SNMP version is written in manual v1.5, top of p7.
https://www.42u.com/pdf/Dataprobe%20iBootBar%20Manual.pdf
Also I contacted dataprobe to get the MIB for legacy ibootbar and they say it supports v1 only.

I'm not sure what to make of the timeout you posted. Does it show up every time you run with the legacy device

Yeah, when I tested it, I saw this every time when I call agent task (snmp.set).

Copy link
Contributor

@davidvng davidvng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this! Overall looks good to me.

As for the SNMP response timeout for the agent tasks, I think it's ok if you've confirmed that it physically changes the state of the correct outlet. Also, one thing to check is the ibootbar SNMP configuration on its webpage. The set command here uses a community_name of "private" by default, but it might be configured to "public" or something else in these ibootbars:

socs/socs/snmp.py

Lines 193 to 194 in dc3fcfc

if version == 1:
version_object = CommunityData(community_name, mpModel=0) # SNMPv1

@ykyohei
Copy link
Contributor Author

ykyohei commented Apr 24, 2025

Thanks, I checked it via telnet and the setting seems to match with agent.

$ telnet 192.168.13.24 23
Trying 192.168.13.24...
Connected to 192.168.13.24.
Escape character is '^]'.


iBootBar Rev 1.5d.275

User Name:  admin
Password:  *****

iBootBar > get snmp
Write Community: private
Read Community:  public
Manager 1:
  IP Address: 192.168.13.24
  Enabled:    yes

@BrianJKoopman BrianJKoopman self-requested a review April 25, 2025 14:40
Copy link
Member

@BrianJKoopman BrianJKoopman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the secondary review @davidvng! Going to merge this. (Ignoring the lack of tests being run, I suspect some strange interaction with the commit via suggestion. And that change was small, and tests ran before that fine.)

@BrianJKoopman BrianJKoopman merged commit cb189c0 into main Apr 25, 2025
2 checks passed
@BrianJKoopman BrianJKoopman deleted the legacy_iboot branch April 25, 2025 14:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants