DRM Forward Lock Bug

There is a recently-discovered bug in NCPT (version 2.01 only, which is the version that shipped with NMIT 4.0) where Forward Lock files are created missing the final CR LF after the last MIME boundary string. This bug causes these Forward Lock files to be unreadable on phones that support DRM.

The workaround is to edit the Forward Lock file (with HexEdit, for example) and append the file with CR LF characters before sending the file to the phone.

The next version of NCPT (version 2.1), will be available shortly and will fix this problem.

We apologize for any confusion or inconvenience this bug may have caused.

Forum Nokia Tools

This version fixes the forward-lock bug. Download it here: [url]http://forum.nokia.com/main/1,6566,030,00.html?fsrParam=2-3-/main/1,6566,030,00.html&fileID=3383[/url]

Hi Toolkit Team,

Does the missing CR LF at the end of the .dm file definitely make the file not reachable to user's mobile?

I have packaged some jar files with the 2.01 Content Publishing Tool and the wrapped items can downloaded fine, at least most of the time. But there are times that I got "File " is corrupted" message when downloading, which seems like a on-and-off problem. Do you think it is related to the missing CR LF?

Thank you very much for helping.

.

The Nokia toolkit generated PDU has an extra CR/LF pair of characters on the end of the DRM package (hex 0d 0a). The Encapsulation spec I have says that a DRM FL envelope ends with 2 - characters, so why the NMIT is adding the CR/LF I don't know. The previous version of the NMIT never did this.

If another body part follows on from a DRM FL body part the first 2 bytes of a body part can legally be 0d 0a, so it is not allowable sometimes to put these extra characters in and sometimes not.

Relevant line from the Encapsulation Spec...

'The last boundary delimeter is identical to the other delimeters except that it has two more hyphens at the end.'

I use NCPT 2.1 , but when i tried to download a FWD Lock GIF file to be downloaded on Nokia 6820 V 3.70 NHL -9 [05-02-2004] and also the Combined Delivery , the cell gets a Soft Reboot .
Is this a Mobile S/w Problem or the Toolkit Problem
Rgds
Norbert

even version 2.1.7 didn't fixed that bug.
I still have 2 use the tool I managed 2 create that deletes this crlf from the end of the file.
I am using the command line utility (the batch file).
when this will b fixed? I tought this bug was discussed months ago and u (nokia) already fixed this.
hope u will fix that bug soon- couz my tool just makes the server much slower (requirs 2 recopy the file without the crlf at the end).

When I download the .dm file directly it works very fine however when I use the OMA download method (with a .dd file) the phone gives a "FILE CORUPTED" error for the .dm file. How can I solve this problem. You are talking about removing some characters but I could not understand what to do and with what editor.

use any hex editor u can find on the internet- the simpler, the better.
delete the last two characters of the *.dm file.
which will appear to u in ur hex editor as char 13 and char 10.
or character 0D and character 0A. (depends on ur hex editor configuration).
the file then will work.
good luck.
in hope 4 a less bugy software from nokia.com.

/* PROBLEM SOLVED
I am really ashamed of myself to bother you with an old topic. I found my answer, I put the exact ip of the server instead of the name and everything works fine.
*/
I tried the chair example OMA download with forward-lock however the dd file works but when I accept the dm file the phone (6610) gives service time-out error. I can do any other downloads like melodies.
Are these examples are wrong or am I doing something wrong.

Does somebody knows which kind of phones supports drm forward lock, and how to use it in phones that doesn't have either infrared or bluetooth, because with dku-5 i can enter and extract the files. How to avoid that?

[QUOTE=Jemch]Does somebody knows which kind of phones supports drm forward lock [/QUOTE]
look at the uaprof of of handset and search for "<rdf:li>ForwardLock</rdf:li> "
if the uaprof contains it then the phone model supports forward lock
[QUOTE=Jemch]and how to use it in phones that doesn't have either infrared or bluetooth, because with dku-5 i can enter and extract the files. How to avoid that?[/QUOTE]you can download it from servers if u have access to them from ur mobile.

I found the "<rdf:li>ForwardLock</rdf:li>" but the nokia 3220 still doesn't recognize the file "unknown file format" but as sample, try to extract acceleration.mid and look what happens. That's what I want.

[QUOTE=Jemch]I found the "<rdf:li>ForwardLock</rdf:li>" but the nokia 3220 still doesn't recognize the file "unknown file format" but as sample, try to extract acceleration.mid and look what happens. That's what I want.[/QUOTE]
hi Jemch

I have not tested forward lock on nokia 3220 but it is for sure that if "<rdf:li>ForwardLock</rdf:li>" is there in the UAProf of the handset it is sure that the handset is intended to support forward lock.
I think the problem is with the way you are tranferring the file to the handset .
A gprs download should work. I think. While blutooth and infrared transfer may not work on some handset and show the message "unknown file format".

Phoneynk,

Why would DRM content downloaded through bluetooth or IrDA not work?

I tried transferring a .dm file (created by wrapping a jpg through NMIT) with bluetooth and encountered a Unknown file format. Why does it not work?
Any workarounds?