Debunking the Multi-NAI Myth

[hunterdg]

thanks for the sugg.. the code you're looking for is ##786#.. and i've done that about three times now along with a hard reset and an ##3282#>reset..
no worky... they said it's an error in Service Pro (provisioning server) on their end.. thanks for the valuable input though!!

[Krayziepop]

Hey no prob.. I figured it wouldn't hurt to suggest. It seems to me that there are a LOT of people having random issues over the last few days with the Vision service... perhaps this is all just a phenomenon on Sprint's end, and we are all jumping to conclusions too soon. It wouldn't be the first time a major company had systemwide issues that brought down a good chunk of their network... I would almost lay the blame to them for now. I am sure they have gotten plenty of calls stating - "My vision is borked... FIX IT"

Beyond that, this is as good a time as any to call them up and tell them you want service credits for all the downtime!

[hunterdg]

For purposes of this thread, the "\HKLM\Software\OEM\WModem\Multi-NAI" registry hack is DEBUNKED/BUSTED. This registry key has absolutley no effect on tethering via "Internet Sharing"

Internet sharing WITHOUT a PAM plan is possible if a data connection is initiated (white or grey arrows above signal strength meter) prior to invoking the 'internet sharing' application

If one attempts to invoke 'Internet Sharing' without a pre-existing data connection, the device attempts to make a connection, but returns an error 67 (assuming no PAM plan exists. This is proof that the 'Internet Sharing application does indeed attempt to pass a different NAI to the sprint server authentication process. I am unable to determine the location of this M.IP/NAI. It is NOT M.IP 2 as i previously posited.

M.IP 2 is NOT populated via IOTA with a [username]@pam.sprintpcs.com NAI, as i previously mentioned. I'm starting to question Sprint's method of verifying tethering.. It seems that instead of populating a completely separate M.IP with the PAM NAI (as was once the case), the phone may now simply dynamically prefix the standard M.IP with 'pam' when tethering is detected. This certainly seems like a legitimate method sprint may have adopted to reduce the ease of fooling the PAM nai authentication process..

It appears that, as far as authentication is concerned, there is no difference between the 'Sprint PCS' and 'Phone As Modem' connections. There is no correlation btw the error 67 (failure to authenticate) and the network connection chosen in 'Internet Sharing'. Regardless of which is selected, the error 67 only occurs when there is no EXISTING data connection.

make sense?

Now we need to find the reg key or piece of 'Internet Sharing' app that prefixes M.IP1 with 'pam'. once we find this, we will no longer have to ensure a data connection exists before invoking 'Internet Sharing'

[ebmorgan]

Okay...so the reg hack is debunked.

My next thing is....I don't get error 67s when starting up ICS. I can have no "arrows", just the "EV" block....and ICS still starts up fine.

[hunterdg]

do you have a pam plan?

[gameross]

The reg hack does apply when you use WModem, though, right?

[ebmorgan]

Originally Posted by hunterdg

do you have a pam plan?

Nope...just std SERO with TXT and ins added.

[Krayziepop]

@ gameross - IF, and only if a device were to support the PAM NAI (which the Mogul does not appear to have the capability), and you were to use the WModem app, then yes I believe the hack would have some credibility. Since we have what appears to be a non PAM supportive device with the Mogul, there is no reason to bother hacking the value as it won't have any effect anywhere else in the system.

I still wonder about my original assumption though... why on earth would the ICS program not dial the connection when called through itself? Why do we have to connect PIE first and then share the web? Methinks that the ICS installed on the Mogul, is a patched version to deter casual tethering... ICS only reports PAM as a connection option because Sprint has a separate PAM account setup under connections from the factory. ICS is simply reporting all the connections it sees under the connections control panel. If you delete the PAM connection, it disappears under ICS. So why can a 6700 user hit connect on his/her Apache and it will connect fine, but the same program on the Mogul throws up 67 errors?

I wish I had the patience/time to sit and fiddle with it myself... perhaps someone such as colonel or ImCokeMan could extract the ICS files from the Mogul and compare them to the one used with Apache builds... I just can't help but wonder if - by replacing the Mogul's ICS with the older build we used on the Apache - perhaps ICS would funtion once again without the added step of connecting first through PIE?

* once again... just thinking out loud *

[kilmarac]

Maybe MIP2 is not filled in until you have a PAM plan that fills it in on an OTA update?

[hunterdg]

@krayziepop.. It appears the Mogul does indeed support/detect/recognize tethering/PAM. This is the explanation for why one must create a data connection (with pie or otherwise) before invoking ICS..

To clarify, it is NOT that one must use PIE to initiate a connection before using ICS, it is that a DATA connection must exist (grey or white arrows above signal bars) prior to invoking ICS. Launching PIE is just a method of creating that necessary data connection...

@ all.. it appears my initial description of M.IP 2 being populated by the IOTA is no longer correct. PAM phones no longer use a separate M.IP for PAM authentication. Instead, the NAI of M.IP 1 is dynamically prefixed with 'pam' when tethering is detected...(M.IP 1 is essentially changed while the phone is tethered).... shall i edit my original post for purposes of removing misinformation?

When ICS is invoked without a pre-existing data connection, ICS sees that M.IP 1 is NOT connected and thus prefixes M.IP 1 NAI with 'pam', becoming 'username@pam.sprintpcs.com' (this is normal behavior for all phones) the phone then attempts to connect, and gets booted (error 67) when no PAM plan is found on users account

the following appears to mogul specific..
when ICS is invoked with a pre-existing data connection, ICS sees that M.IP 1 is already connected, and thus simply uses the existing data connection and shares it.

some testing i've done that proves ICS uses the 'dynamic' M.IP 1 instead of M.IP 2...:

i cleared my M.IP 1 slot completely, and transferred all the data to M.IP 2 (normally blank), and changed my Active profile Index to '2' (told the phone to use M.IP 2 to connect instad of 1)

I then initaited a data connection with PIE, and was able to surf sucessfully. I then invoked ICS, which promptly disconnected my existing data connection (M.IP2), tried to re-connect (presumably using MIP1) and subsequently threw an error 67. This is proof that ICS dynamically prefixes M.IP 1, and has nothing to do with M.IP 2.. (it did not recognize the existing data connection with M.IP2 as it does with M.IP1)

i then restored my data to M.IP 1, cleared M.IP 2, and all was back to normal (error 67 without existing data connection, no error WITH existing data connection)

@ krayziepop... i like your theory about using the 6700's ICS on the 6800.. though i don't consider myself affluent enough to attempt the hack myself.. I bet if someone could compare the two, they'd notice the 'dynamic prefixing' i speak of and could likely remove it!

@ ebmorgan/all
from what i've read, it seems users with SERO plans are having fewer problems with tethering than others.. this leads me to believe that a SERO plan includes authentication for PAM/tethering built in (as apparently one cannot ADD a PAM pack to a SERO plan)

Can anyone else with a SERO plan confirm or deny their ability to invoke ICS (Internet Sharing) WITHOUT a pre-existing data connection (NO horizontal arrows above signal bars)??