configure PDU AP7932 network management card

[Anonymous user]

We have a lot of AP7932 PDUs and we would like to configured them via DHCP/BOOTP.

I don't have any difficulties in configuring their basic TCP/IP settings via DHCP. But I would like to configure other stuff also, i.e outlet name, ntp server, syslog server, etc. I have a boot.ini file ( I copied from the PDU via ftp) on my tftp server, and my dhcpd is configured with filename and next-server. I reboot the management card in bootp mode and dhcp/bootp mode, but it did not try to get the boot.ini file.

I must have missed something. Can you help?

thx

[Anonymous user]

I was using tcpdump on the dhcp server. It is definitely using promiscuous mode. I see the dhcp/bootp request, and the reply. The PDU then ARPs a couple times, and then goes silent.

[BillP]

no problem. yes, perhaps the firmware upgrade did not go properly on this PDU so i can help with that or we'll let it go 🙂

[Anonymous user]

We have a lot of AP7932 PDUs and we would like to configured them via DHCP/BOOTP.

I don't have any difficulties in configuring their basic TCP/IP settings via DHCP. But I would like to configure other stuff also, i.e outlet name, ntp server, syslog server, etc. I have a boot.ini file ( I copied from the PDU via ftp) on my tftp server, and my dhcpd is configured with filename and next-server. I reboot the management card in bootp mode and dhcp/bootp mode, but it did not try to get the boot.ini file.

I must have missed something. Can you help?

thx

[Anonymous user]

I did that. No dice.

My PXEboot works fine with a similar configuration.

I concluded it does not worth more effort to get this to work and I decided to use an ftp script to get them configured after network is configured by dhcp. It might be even better since I have control when to update their configurations.


Thanks for you help.

[BillP]

the card uses config.ini (not boot.ini) for all of its configuration settings. but, by what i found below, it looks like you can use any .ini as you already have. i cant say i've tried this method before but i've heard about it.

i have looked at the manual attached to this post which stats the following:

BOOTP. For the Network Management Card to use a BOOTP server to configure its TCP/IP settings, it must find a properly configured RFC951-compliant BOOTP server. In the BOOTPTAB file of the BOOTP server, enter the Management Card’s MAC address, IP address, subnet mask, and default gateway, and, optionally, a bootup file name. For the MAC address, look on the bottom of the Management Card or on the Quality Assurance slip included in the package. When the Management Card reboots, the BOOTP server provides it with the TCP/IP settings.

• If you specified a bootup file name, the Management Card attempts to transfer that file from the BOOTP server using TFTP or FTP (make sure FTP is enabled on the PDU). The Management Card assumes all settings specified in the bootup file.

• If you did not specify a bootup file name, you can configure the other settings of the Management Card remotely through its Web interface or control console - user name and password are both apc, by default.

A user configuration (.ini) file can function as a BOOTP or DHCP boot file. For more information, see the TCP/IP configuration section of the Network Management Card User’s Guide, available
from the Utility CD or the APC Web site, www.apc.com. To create a bootup file, see your BOOTP server documentation.

I also found all this:

Other options: The Management Card also uses these options within a valid DHCP response. All of these options except the last are described in [RFC2132|http://www.ietf.org/rfc/rfc2131.txt?number=2132].

• Network Time Protocol Servers (option 42): Up to two NTP servers (primary and secondary) that the Management Card can use.
• Time Offset (option 2): The offset of the Management Card's subnet, in seconds, from Coordinated Universal Time (UTC).
• Domain Name Server (option 6): Up to two Domain Name System (DNS) servers (primary and secondary) that the Management Card can use.
• Host Name (option 12): The host name that the Management Card will use (32-character maximum length).
• Domain Name (option 15): The domain name that the Management Card will use (64-character maximum length).
• Boot File Name (from the file field of the DHCP response, described in [RFC2131|http://www.ietf.org/rfc/rfc2131.txt?number=2131]):
The fully qualified directory-path to an user configuration file (.ini file) to download.* The siaddr field of the DHCP response specifies the IP address of the server from which the Management Card will download the .ini file. After the download, the Management Card uses the .ini file as a boot file to reconfigure its settings.

also, you can alsouse something such as APC's INI utility as an alternative.

[see this article, the utility is attached to the bottom of the article|http://nam-en.apc.com/cgi-bin/nam_en.cfg/php/enduser/std_adp.php?p_faqid=8979]

we can look at the INI utility after we try to get what you are trying to do to work first though.

hope this helps!

[Cap1_apc]

Hey there.

I took a look at your capture and I see the PDU requesting:

Option: (t=55,l=14) Parameter Request List
Option: (55) Parameter Request List
Length: 14
Value: 0603010F42430D2C2B3A3B2A020C
6 = Domain Name Server
3 = Router
1 = Subnet Mask
15 = Domain Name
66 = TFTP Server Name
67 = Bootfile name
13 = Boot File Size
44 = NetBIOS over TCP/IP Name Server
43 = Vendor-Specific Information
58 = Renewal Time Value
59 = Rebinding Time Value
42 = Network Time Protocol Servers
2 = Time Offset
12 = Host Name

However, I do not see your DHCP server responding to options 66 and 67 (unless I'm missing something). Are these set?

Message was edited by: Cap1

[BillP]

let me do a little investigating and get back to you.

i will see if Cap1 (another user on the forum) can give us any insight. i'll keep you posted. thanks for all the info.

[Anonymous user]

I use ISC dhcpd v3.

Originally option 66 and 67 are configured as:
next-server 10.0.4.1;
filename "/configs/pdu/xxx.ini";

And my bootp reply has following:

Bootstrap Protocol
Message type: Boot Reply (2)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0x0000d20b
Seconds elapsed: 4
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 10.0.4.185 (10.0.4.185)
{color:#ff0000}Next server IP address: 10.0.4.1 (10.0.4.1){color}
Relay agent IP address: 0.0.0.0 (0.0.0.0)
Client MAC address: American_2f:85:e9 (00:c0:b7:2f:85:e9)
Server host name not given
{color:#ff0000}Boot file name: /configs/pdu/t-11-pdu1.ini{color}
Magic cookie: (OK)
Option: (t=1,l=4) Subnet Mask = 255.255.255.0
Option: (1) Subnet Mask
Length: 4
Value: FFFFFF00
Option: (t=3,l=4) Router = 10.0.4.1
Option: (3) Router
Length: 4
Value: 0A000401
Option: (t=6,l=8) Domain Name Server
Option: (6) Domain Name Server
Length: 8
Value: 0A0004010A000402
IP Address: 10.0.4.1
IP Address: 10.0.4.2
Option: (t=43,l=5) Vendor-Specific Information
Option: (43) Vendor-Specific Information
Length: 5
Value: 0104315043
Option: (t=15,l=10) Domain Name = "blekko.com"
Option: (15) Domain Name
Length: 10
Value: 626C656B6B6F2E636F6D
End Option
Padding

You can see that they are not sent as options, so I change them to:

option tftp-server-name "10.0.4.1";
option bootfile-name "/configs/pdu/xxx.ini".

Now I got option 66 in my reply:

Option: (t=66,l=8) TFTP Server Name = "10.0.4.1"
Option: (66) TFTP Server Name
Length: 8
Value: 31302E302E342E31

But option 67 still missing.

It seems bootp does not use "option bootfile-name "/configs/pdu/xxx.ini". for option 67. What does it use then?

thanks.

[Cap1_apc]

This is spec'ed out in RFC 2131:

http://www.ietf.org/rfc/rfc2131.txt?number=2131

file 128 Boot file name, null terminated string; "generic"
name or null in DHCPDISCOVER, fully qualified
directory-path name in DHCPOFFER.

Message was edited by: Cap1

[Cap1_apc]

If you still can't get it to work, you may want to try dropping the config.ini file into the root directory of tftp server.

[Anonymous user]

I tried using config.ini, as well as several other names. I tried in the tftp/ftp root, as well as with a path. The APC never sends any packets at all after getting an IP.

I am using isc-dhcpd-4.1.1-P1 on Debian.

[Anonymous user]

Sorry for resurrecting such an old thread, but I am having the same problem. (I also settled for the same solution of uploading the file via ftp.) I am redoing the management system I created for our PDUs, and I would like to get them to bootp/tftp properly. tcpdump of the reply from my bootp server:

Your-IP 10.0.0.63
Server-IP 10.0.0.4
Client-Ethernet-Address 00:c0:b7:cb:d1:ac
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 10.0.0.1
Domain-Name-Server Option 6, length 4: 10.1.0.66
TFTP Option 66, length 8: "10.0.0.4"
BF Option 67, length 21: "00:C0:B7:CB:D1:AC.ini"

It looks to me like this is a correct response. I have tried with different names for the config file name, but it doesn't ever try to grab anything via tftp. I can tell it to tftp after logging in via serial, and it works fine. Any ideas?

Thanks!

Message was edited by: Jeremy_S

[BillP]

i know i have gone through testing this before and the card takes 5-10 minutes to try and initiate a file transfer. i am just going off the top of my head but how long have you waited after the initial request?

h3. EDIT - I also remembered I had some notes on this and actually found them..

In the user's manual for Network Management Card 1 (AP9617, AP9618, AP9618), the following feature set of the NMC is noted:

When the Management Card reboots, the BOOTP server provides it with the TCP/IP settings.

• If you specified a bootup file name, the Management Card attempts to transfer that file from the BOOTP server using TFTP or FTP. The Management Card assumes all settings specified in the bootup file.

In NMC firmware revisions 1.x and 2.x, this feature works as designed. While using an NMC with BOOTP to assign an IP address, the NMC will accept an IP address from a BOOTP server, and five minutes later, attempt a TFTP transfer of a specified bootup file. If no TFTP server is reachable, it will attempt FTP transfer of a specified bootup file.

In NMC firmware revision 3.x, the NMC does not attempt a TFTP transfer, only an FTP transfer. Customers relying on TFTP will not have success in specifying a bootup file.

Though TFTP does not work, customers can use FTP to configure their NMC device using a boot file (config.ini). FTP normally requires a client login. Since the NMC device is at its default settings, the customer will need to create an "apc" user on the FTP server. At default settings, the NMC device will attempt an FTP login using apc for both the username and password. The customer will need to create such an account on their FTP server in order for a successful upload of the boot file.

This knowledgebase article also applies to any other devices that have an embedded Network Management Card 1 inside of it.+

[Anonymous user]

Thanks for the reply. I have waited about 15 minutes while watching tcpdump. The APC never tries to tftp or ftp. The PDU I am testing with is running:

Network Management Card AOS v3.5.6

Any ideas? I'm about to give up on this.

[BillP]

ok so you'll have to do FTP as it mentions in the article which may require you to configure so that it does not prompt the PDU. Also, that is several revisions behind - we are at 3.7.3.

if you are interested in updating, i can provide you with the update file or you can download it from apc.com -> software and firmware->Rackmount Power Distribution. I think the SKU is SFRPDU373. just let me know. i dont think it will necessarily solve the issue here but who knows!

[Anonymous user]

I tried with 2.0.2, and got the same thing. tcpdump shows it never tries to tftp or ftp. Either this functionality just doesn't work, or my bootp/dhcp option settings are wrong.

[BillP]

i had watched someone try it before i created that section of notes that i pasted to you so i have seen it in action. i knew it was slow, as i mentioned, but i do believe that it will work. i have never personally set it up though to be honest with you.

[Anonymous user]

I gave it close to an hour, but the PDU didn't do anything other than ARP after getting an IP. Thanks for all your help anyway.

[BillP]

hmm the only thing that stuck out to me was the name of the ini file you are using. if you still want to pursue it, can you just try using config.ini as the file name or something shorter and without special characters? also, if you dont mind me asking, what DHCP/bootp server are you using?

[BillP]

question i just thought of - are you using wireshark for packet captures? if you are on a switch, you will only see the data that is being passed on your switch port if you are not in promiscuous mode to see everything on your switch. even in this mode on my particular dell laptop, i still cannot see all of the traffic because of my particular network adapter. wasn't sure if you were doing the network capture from the DHCP server though where we should see the request from the PDU.

just want to make sure we arent assuming the PDU is not trying anything if this could be the case. just thought i'd throw it out there.

[BillP]

ok. well i asked someone else about it if they had any ideas so i'll let you know what i find out, hopefully in the next day or two. i know you sort of gave up on it but i really feel it should be working.

[BillP]

i got some more info on this that i will post later once i clarify one thing after we did some testing over here for you.

[Anonymous user]

Sweet, thanks!

[BillP]

alrighty..here is what I got so far since i would like to help you get this working 🙂

so DHCP and BootP both only make the bootfile request on FTP in the 3.xx firmwares. there is no TFTP request for NMC1 based devices, like these PDUs, at 3.x.x (which is logged as bug but the firmware will most likely not be rev'd anymore since we have Rack PDU 2nd generation now).We tried this on an Rack PDU at 2.7.4 firmware - Put the Rack PDU in DHCP mode, watched it get the IP settings, five minutes later there was a TFTP request from the card. We upgraded to 3.7.3 and performed the same steps mentioned above. There was no TFTP request after five minutes but there was an FTP request. So either way, we definitely have to be using FTP to transfer the file. You'll need to create an apc account on their FTP (default username/password is used to log into the FTP server) server which will allow the card to access the FTP server and grab the boot file.

the part i am waiting on double checking is what username and password would be required for the FTP server - if its what you program in the telnet menu under system->tools->file transfer or if it is just the username and password you use to access the device or if it just always uses apc/apc.

i believe it just uses apc/apc regardless so you'd need to set up an FTP server with those credentials.

Edit - I confirmed it always tries a default of apc/apc for the FTP transfer. this could be changed for any future DHCP offers if you wanted by editing the .ini file to have the following:

(NetworkFTPClient) - substitute ] and [ for the ) and ( because the forum turns it into a link
RemoteServer=0.0.0.0
RemoteUserName=apc
RemotePassword=apc

but, it does not help us for this initial file transfer request.

[Anonymous user · Accepted solution]

I think the PDU I am using to test might just be broken. After updating it to the latest firmware/software, it doesn't want to let me in on the web interface, and I can't ftp upload a file to it.

I have a system in place that uploads the proper config via ftp when a PDU boots up, and requests an IP. So, I think I am done trying to make this work "correctly". Thanks again for your help. Hopefully someone else will get some use out of this thread.