Based on the two data logs submitted it indicates an issue wit the Master Server but for a potential issue of the client information submitted by the client itself.
In the 'bmrsavecfg' debug log (the 121 log), it shows completion of the process on the client as being successful with a completed 'bundle.dat' file.
04/16/2015 10:56:58.257 [CBmrSaveCfg::writeBundle()] Entering.
04/16/2015 10:56:58.258 [CBmrSaveCfg::writeBundle()] Exiting, rc=0
04/16/2015 10:56:58.258 [CBmrSaveCfg::saveDiscovery()] Exiting, rc=0
04/16/2015 10:56:58.258 [CBmrSaveCfg::discover()] Exiting, rc=0
04/16/2015 10:56:58.258 [main.cpp:bmrmain()] Exiting, line=572, return rc=0
It's at this juncture that the process sends the file to the Master (by way of bpbrm) for insertion into the BMRDB.
The 'bmrd' log (id of 119) shows a problem for this:
16/04/2015 12:04:23.239 V-128-906 [ImportCfg.cpp:ImportConfig()] Unable to extract either ./bmrcli.xml or bmrcli.xml file from bundle. Cannot import.
The 'bmrd' process should fail out for the client import and signal back to 'bpbrm' of the non-zero return code. That should then trigger 'bpbrm' to move on and start the actual backup jobs. It appears that this signaling is not happening for the process. The 'bpbrm' process just loops waiting for the process return and not getting anything.
To validate the bundle.dat file created on the client, do the steps to manually import the file on the Master. You can create a new file running the command 'bmrsavecfg -infoonly' on the client and it will generate the client configuration file without any activity to the Master. Then copy the newly created file (assuming no errors are displayed on the client) to a location on the Master Server and manually import that file into the BMRDB, using 'bmrs -o import -res Config -path $PATH_TO_bundle.dat_file'. As an example, if the Master is Unix/Linux and the file was copied to the /tmp directory, the invocation would be 'bmrs -o import -res Config -path /tmp/bundle.dat'. This will verify the validity of the client configuration. If that just hangs, then the client configuration, although created with no visible errors, has an issue parsing the file information and is hanging on something within it. If need be attach the file to a reply for visual review and I can see if their is some sort of client configuration that was not supported in the 6.5.5 release it is coming from.
One last thing of note. In certain scenarios, the bpbrm process cannot properly handle the hand off of the BMR portion of the work and it crashes. If that is what happens, then the 'bmrd' process does not have a parent job to return the status code and the backups will also hang. This was seen in later 7.X release (the version escapes me) where the job would get a status 26 error. One way to debug this is to check the 'bpbrm' debug log and look for the process id that was started as part of the backup. See what happened to it.
Lastly, as noted multiple times above, an upgrade to a later version of NBU (one that is actually supported) is more than highly recommended.