Bell K1m firmware upgrade 2402_01.16.00 available

[speedrguy1]

Try this:

Connect your phone
Open QPST Service Programming

Click Read from Phone..

Save to File...

NOTE: MAKE SURE YOU MAKE A BACK UP OF THIS. SAVE IT AS YOURESN_spBACKUP TO ENSURE YOU DON'T OVERWRITE ANY PREVIOUS BACKUPS.

Scroll over to the MIP Tab.

Click Add...

Change the values to the following:

Check - Profile Enabled
NAI - <your10digitnumber@vzw3g.com>
Tethered NAI - <your10digitnumber@dun.vzw3g.com>
Check - Rev tunnel preferred
Home Address: 0.0.0.0
Primary HA Address: 255.255.255.255
Secondary HA Address: 255.255.255.255

Now here's the tricky part.

Exit the Menu you just made, and click Save to File..

Name it something you'll remember in 30 seconds.

Click Load from File...

Load your backup copy of "YourESN_sp" that you created when you initially flashed your phone from VZW (if you were following the mark.cdmaforums guide, you would have done this ages ago, I imagine)

When that file loads, read the "ha spi" and "aaa spi" numbers, jot them down, you'll need them in about 30 more seconds.

Click Load from File...

Load the file you just saved around 60 seconds ago, the one you were supposed to remember.

Click the second entry, the one you just made 80 seconds ago or so, and click Edit.

Type in the values for the ha spi and aaa spi you wrote down on that menu, and for the dmu pub put the value 10.

Click OK, and the values will save, you'll have two options to choose from, one with be labeled 0, one will be 1.

On the righthand side of the screen, there is a "Active User" setting, change that from 0 to 1, then click write to phone.

That should keep the NAI and Tethered NAI values active with your new settings, which in turn will eventually allow you to use data.

[GoldMembr]

I've restarted the phone several times, also edited seems, and the data services continue to work.

The main benefit of this firmware is J2me apps instead of BREW. From what I understand, you can't use BREW (and I've tried several modifications to folders and redirecting my mma menu to confirm that), so you'd need to download a java app like google maps for your Navigation/GPS program instead of VZNav.

Initially, I had been fiddling around with the Alltel firmware first, and didn't have much luck getting my features to work (probably because when I backed up the seem table, it was under another phone number, not my own ), and in order to get data working AT ALL, I had to edit the MIP tab in service programming.

I had trouble getting this to stick, so I had a brilliant idea, which was to create a new value on the table, and set the active user to that table instead. I didn't think it would work, but low and behold, it did, and when I read the information from the phone, the "0" User information was still stuck with Alltel's addresses on the NAI and Tethered NAI, but my information stuck, as well, with what I had used for values.

To determine which values to use on the "Add.." MIP table, I opened up my backup of service programming, and copied the addresses written on there into the new table exactly. Also, instead of changing the address for the online album after I reflashed, I left it alone (which was a 6 digit number, I believe, instead of min@mms.vtext.com or whatever the address they suggested was).


I screwed up the flash the first time by not master reset/master clearing after the flash, so my default skin at the time wasn't Moto, and left me a black screen. The possibility that you may have to go back to VZW fw and start clean is there.

I went from VZW> Vivo > Bell FW.

I took the normal steps in backing up seems, service programming, data, etc. as outlined in mark.cdmaforums

I did NOT use RadioComm to restore seems, only P2kseem, but I did restore each seem.

Also, when you initially flash to Bell, you'll have to edit your 2742 seems to appropriate values to enable your Web Sessions menu, and various other menus as outlined in mark.cdmaforums flash guide under MMS Fix.

--
Down to the knitty gritty.
--

When you do restore your seems, you will be replacing the Bell FW's addresses for Get It Now (which were initially ip addresses) with the ones you backed up (apps.vzw3g.com) and (testapps.vzw3g.com).

Confirm this by #073887* code 236197 to get to your programming menu.
Get It Now -> ADS

This will show you your addresses.
This is what I did to make Data work.

Programming Menu -> Web Sessions -> [New Entry]

Name: VZW_MMS
Homepage: http://homepage
Gateway IP 1: 000.000.000.000
Gateway 1: http://mms.vtext.com/
Service Type 1: HTTP
Port 1: 80
E2E Port 1: 9201
LXL Port 1: 323
--- And left the remainder of the values the same.

NOTE: I'm not quite sure how, but up until I edited the LXL Port 1 to 323, my data didn't work. I'm also not sure where that value came from, but somewhere I remember seeing 323, and randomly typed it in, and worked first try. Not sure if the value would be different for you, but hey, it worked for me.

After that is saved, go to Messages -> Options -> Inbox Setup -> MMS Message Setup -> Server Info -> Options -> Edit

Assuming you've done the proper seem edits, you should have no problem getting here.

My values are:

Service Name: VZW
Server Name: http://mms.vtext.com/servlets/mms
Web Session Name: VZW_MMS

After you set these values, clr out to your main screen, then

##DATA#
Service Code: 000000 worked for me
then
Service Type: QNC Only

1XRTT Settings should show:

<min>@vzw3g.com
and Password: **** (32 *'s total)


Exit out of this menu, and attempt to send an MMS to yourself, just as I did, and get very excited when you see the percentage meter moving.

Setting your Service Type to QNC Only will not get you EVDO data and any kind of Packet data will not work with that set. Set it to Auto or Packet Only then try your data and report back if everything is still working for you.

[speedrguy1]

I tried switching it over to Packet Only and you're right, data wouldn't transfer.

I suppose being under QNC severely limits data processing, but in the meantime, having the firmware work with MMS and mobile through QNC works for me until I discover a way to get packet data working.

I guess for anyone who would be willing to take a cut in download/upload speeds for Java to help further process the firmware, this method would work?

Also, if you have any other ideas that might make Data work, let me know and I'll try them.

[2x4u]

Well now I got it to Network not found instead of Authentication failed...so I guess Im making some improvement

[speedrguy1]

I took the plunge and installed the Telus FW this morning to find two issues:

1) I could SEND mms at EV-DO speeds, but I couldn't receive them.
2) I got the delivery confirmation text after reply to Verizon customers.

So, I reflashed back to VZW -> Vivo -> Bell, running QNC Data only.

I'm determined to find a way to get EV-DO working on this firmware, mainly for the delivery confirmation text not being there.

[Mad Mike 96]

for the problem with number one did you have the offset 74 edit in place?

[speedrguy1]

Off the top of my head, I'm not positive, but if I remember correctly, thats the seem edit that enables data transfer with most carriers, or something to that effect, with several bits (namely 4-7) as options to control different Providers? I think?

Yeah, initially the 2nd option of the three was unchecked, I did the seem edit, and still I couldn't receive MMS, only send.

Not that it matters anyway. I don't particularly need data running at EV-DO speeds, I don't tether or watch streamed videos, or even use VZNav, so QNC speeds for downloading of mms doesn't bother me. Besides, its not like I know when my phone is downloading the MMS until I get the chime.

What drives me absolutely bonkers is sending a text message to immediately receive one that tells me the other guy got it. That I can take a hit in data speed for, and on Bell FW, I don't get that text.

Still determined to get data working, I'm running through service programming and PST for any minor tweaks that might give me a glimpse of hope that one day I CAN get data working on it.

[Mad Mike 96]

fair enough I've not once had any issue with the Telus flash other than the text message delivery notification. I'm curious as to why they would be none exsistant in the bell flash......... any chance I could get you to send me a file system dump of your phone? and mabey a copy of your 2742, 275a and 275e seems?

[onestraybulle]

Are you talking about the delivery confirmation issue that your receive the message? I can't find it right now, but there is a seem that changes it so that you don't get the message.

[speedrguy1]

Mad Mike - I'm going to do a system dump today, and get copies of the seems posted so you can compare.

onestraybullet - Do you mean a seem edit for the Telus FW? The issue has been people have their delivery confirmation set to default at no, but when replying to a text from another Verizon customer, the reply will automatically default to yes (or so the story is told), and I've experienced that exact same issue. I send a text, but only when I send a reply do I get "Message to ### delivered." immediately following the text.

The most important seem edits I could find right now would involve either:
1) Data access through EV-DO on the Bell FW;
2) A seem edit that would enable the checkmark to appear on my outbox messages (viewing only the outbox screen and sent messages, not outbox > options > Message status)
3) A Telus FW seem edit that has been confirmed to eliminate the delivery confirmation text message, or defaults the reply text to NO for delivery confirmation, because honestly I'm tired of reflashing my phone

[speedrguy1]

This might seem noob, but hey, I'm really interested in data working on Bell, so could someone tell me if this might have any direct relation to the Bell FW?

"Security Authentication
The NotifyLink Hosted Edition supports an AES standards based authentication
between the wireless device and the NotifyLink Hosted Server.

Authentication Key
Device to HTTP Authentication key is a unique 24 byte key created from an 8 character
password.

Registration
When a user is added to the server an authentication password is generated for the
user. Also, when the device is being registered, it will prompt the user for their
authentication password if it is not already entered at registration time.

Authentication Steps between the Device and Server

NotifyLink Device Client
The device will use the authentication password to generate an AES encryption key,
which is used to encrypt the information being sent to the server.
The device encrypts the information to be sent to the server, and also sends an
encrypted SHA-1 hash of the unencrypted parameters.
The device does not store the encryption key on the device, only the authentication
password is stored (the key is generated each time it is needed).

NotifyLink Hosted Server
When the server receives an authenticated request from the device it will decrypt the
information requested from the device and also the SHA-1 hash of the request,
using an AES encryption key generated from the authentication password.
The server verifies that the request decrypted successfully and that the decrypted
SHA-1 hash sent in the request matches the SHA-1 hash of the decrypted request.
If decryption is successful and the SHA-1 hash matches, then the request is
processed by the server and a response is sent to the client.
11
If decryption is unsuccessful or the SHA-1 hash does not match, then the server
responds with a message indicating that authentication failed, and the user is
prompted for their authentication password.
The authentication password can be changed at any time either through the admin
or client portion of the NLES web interfaces. We have an option to generate a new
key, or a key can be typed in manually. If the authentication password is changed
on the server, the device will not be able to send/receive emails until the new
password is entered on the device -- they will be prompted to enter their password
each time the device tries to connect to the server NotifyLink leverages standard NT
authentication. This allows for a single point to manage access rights.

Message Content Security - Encryption
NotifyLink Enterprise Server (NLES) supports Triple Data Encryption Standard (TDES) and
the American Encryption Standard (AES) algorithms for encrypting message content
delivered from NLES to wireless device. AES is a Federal Information Processing Standard
(FIPS), specifically, FIPS Publication 197, that specifies a cryptographic algorithm for use by
U.S. Government organizations to protect sensitive, unclassified information. The AES key
size: 192 and 256 bits. In decimal terms, this means that there are approximately: 6.2 x 1057
possible 192-bit keys. Many security systems will almost certainly use both Triple DES and
AES for at least the next five years. After that, AES may supplant Triple DES as the default
algorithm on most systems. Triple DES takes three 64-bit keys, for an overall key length of
192 bits.
It is up to the administrator which algorithm they wish to use as NotifyLink supports both.
This is settable via the Administration Console. Please see User Guides for more
information. The encryption key is 24 bytes (192 bits) in size. The server and device share
this private key.
Once a message is retrieved from the associated mail server it is encrypted before passing
to the wireless device. Once it reaches the device it is decrypted then placed in the device’s
INBOX. This also stands true in reverse. That is, when a reply or origination is done via the
device it is encrypted before leaving the device and decrypted at the NotifyLink Enterprise
Server.
SSL (HTTPS) is also supported from device to HTTP server. This applies to RIM Phones w/ OS 3.7
and above, Palm based devices with OS 5.1 and above, Microsoft Pocket PC 2002 and 2003
devices and Microsoft Smartphone 2002 and 2003.
"

[Mad Mike 96]

ok thank you. I'll wait for them. as for what you are wondering. I don't believe that info will be much help for you. I'm thinking it may well be something in the bell seems that's messing with the info on the phone that VZW needs to authenticate the phone on the high speed network. If I come into a bit of free time I will try flashing to bell and see what I can come up with. I'm planning on doing a comparison of all the files on the telus flash as oposed to the Bell. Hopefully I can come up with something interesting or even come up with the info as to why there is no issue with the delivary report messages on bell. If I can get that issue fixed on telus I could likely fix it on all the flashes. If I can come up with info on why the Bell phone can't access EVDO service or authenticate through the default proxy I'll be sure to pass it on. If we can get the bell flash working with data and everything It would be the perfect flash for the phone.

[kbman]

This has all been discussed hundreds of times in numerous threads. There is no question about what it is that causes the problems in the Bell firmware with VZW's network. Their authentication uses a fixed password which is hardcoded into the NVM and cannot be changed by any known methods because it automatically rewrites the default values to particular seems at bootup if they are altered in any way.

In the case of the e815, V3c, and K1m, they were able to authenticate on the EvDO network because bell used the PPP uername and password as their fixed seems, leaving open 01d2 and the shared secrets so they still functioned under VZW's HDR(EvDO)network authentication scheme utilizing RADIUS authentication servers and encrypted dynamic hardware ID keys(shared secrets).

So, as long as you use either unauthenticated proxies, ot your own proxy using the bell authentication, you could use VZW's EvDO network.

Now, with the newer phones(6550 chipset), they use the MEID as the first portion of 01d2, which means that it is impossible for it to ever work with VZW's EvDO authentication servers, which require dynamically assigned shared secrets.

Therefore, the nature of the problem is how to unlock and reconfigure the NVM to allow writing VZW values to those critical authentication seems.

It has little to do with how the authentication works on the network end...we aren't about to change that...

OK?

[speedrguy1]

By the way,

I flashed back to Telus yet again, hoping that I could compare seems between different firmwares (more at Bell, to try to ditch the delivery notification text).

Followed the guide to a T, and made sure I had all data working on the initial VZW reflash before I flashed to Telus, even sent mms to myself on the VZW firmware, but for some reason, I can't receive MMS text messages, only send them.

Anyone have any other ideas? Would be greatly appreciated.