Home   Blog   Evan Doorbell Tapes   Projects   Docs   Mirror

adventures in building a working nortel meridian 1 option 51c

Posted 2025-11-08 | Updated 2025-12-26

As some of you know I've been into telephony for a long while, and the main PBX for my home is a "small system" Nortel Meridian Option 11C. In the Summer of 2025 what was once a "big system" Nortel Meridian 1 Option 61C came up for auction on GovDeals. It was local to me, so I had to buy it. I ended up winning it, but unbeknownst to me it was missing some pretty crucial parts (Call Processors, System Utility cards, System Monitor cards, blowers). Between a friend of mine and yet another GovDeals auction (which was for "half" of what was a "big system" Option 61C, but a complete half), I was finally able to source the missing pieces.

I'm usually pretty bad at documenting personal project stuffs, which will oftentimes leave me with "how did I configure this thing I configured 2 years ago that I now need to reconfigure" which is sub optimal. I am going to try really hard to use this page as living notes of my adventure in getting a working Option 51C going.

You may have noticed the things I bought were 61C builds but I'm aiming to build a 51C. What's the difference? For my purposes, the only difference is that the 61C has redundant core/network shelves.

Password Recovery

Video demonstration of this here

This isn't the only way, but the process I elected to use and was successful. There are two parts to this process depending on how the system was configured, and below are both parts. Note, this does require physical access to the call processor.

  1. Switch to PDT by holding CTRL and typing p d t
  2. Log in using the username resetCAUTH
  3. Answer yes that you'd like to continue
  4. Remove the backup RMD and insert a bootable RMD CF card, then press Enter. You have 60 seconds to do this. This is to verify you are physically in front of the call processor. It must be a bootable RMD as technically it's expecting installation media, but in my experience any CF card formatted as bootable works.
  5. You should get a prompt saying "Successfully switched to local authentication." with a reminder to remove the media and to perform an EDD.

At this point, the system has been removed from the security domain and is now using local auth. If the admin2 and pdt2 accounts were left with default credentials, you may be able to log in now. However, in my case, they were not default, so I had to follow this second process:

  1. Go back into PDT by holding CTRL and typing p d t
  2. Log in using the username resetPWD
  3. Type in admin2 for the PWD2/Admin2 userID
  4. Swap back to your "installation" media, then hit enter
  5. Enter in password of choice for PWD2 user (which is admin2)
  6. Confirm it
  7. Enter in password of choice for PDT2 user
  8. Confirm it
  9. You should get messages saying that the passwords were successfully changed
  10. Log in to the system as normal using admin2 and the password you specified. It will ask you to change it, but you can change it to the same password if you desire.
  11. Do an LD 43 EDD to save

Creating bootable installation media (a bootable RMD)

Write-up coming soon.

Patching

The system I obtained came with 7.65 with patches that extend through the end of 2019. The latest patch bundle I was able to find was from 2017. This patch set is close, but not as complete, so I wanted to figure out how to carry over the patch set to a fresh CS1K install.

The bundle format looks pretty self explanatory and is arranged as follows:

- disk1_1.txt
- PP4
-- PATCH
--- Patch files themselves (.pp4 files)
--- DEPLIST
----- mcore_01.pp4

At the root, you have two items, a file named disk1_1.txt and a directory named PP4. disk1_1.txt is a single line file that contains a timestamp in YYY-MM-DD HH:MM:SS format. I am not quite sure exactly what this is for, but I believe this might be the timestamp of when the bundle was generated. Within the directory PP4 you will find a single directory named PATCH. Within the directory PATCH is all of the actual patch files, ending in .pp4, as well as a directory named DEPLIST. In DEPLIST you will find a single file named mcore_01.pp4 which contains the name of the patch bundle, the issue, a release identifier, when it was created, how many patches are included, and a list of said patches.

When these patches are installed, they are stored on the second partition of the CPPIV's "fixed media disk" (an internal CF card) under a directory named patch. It is very similarly structured to a patch bundle, but not quite. I thought I could shoehorn it into a zip file that would install successfully, but with much futzing I would land at it complaining about the timestamp in disk1_1.txt.

Not being super interested in a yak shaving of reverse engineering patch bundles...I wondered if I could simply copy the patch directory from the existing install over to the new install and if it would simply read the contents at boot and load them. In my case, I'm not patching a live system, so I don't care about needing to bring the system down. The answer is...yes.

In case anyone else needs them I have provided a link to them below. After extracting the archive, simply replace the patch directory on the 2nd partition of the CPPIV's internal CF card with the one provided. Patches will be loaded at startup. To verify, go into LD 143 and issue command MDP ISSP. It should list 417 in service PEPs and show the following:

DepList 1: core Issue: 01 (created: 2019-10-28 06:41:01 (est))
[patch list here]
MDP>LAST SUCCESSFUL MDP REFRESH :2020-01-13 20:24:34(Local Time)
MDP>USING DEPLIST ZIP FILE DOWNLOADED :2019-10-28 07:12:30(est)

Download patch set here.