adventures in building a working nortel meridian 1 option 51cPosted 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 RecoveryVideo 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.
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:
Creating bootable installation media (a bootable RMD)Write-up coming soon. PatchingThe 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) |