Debunking the Multi-NAI Myth

[ebmorgan]

I've been doing research into this reg hack that has become to be beleived somehow hides your devices connection method from your carrier. The purpose of this would be so you can tether a device without your carrier finding out.

I don't think Multi-NAI does what everyone thinks it does.

NAI (Network Access Identifier) is, simply put, a roam-able method of identifying users to authentication server accross multiple providers. All that an NAI contains is a user name and routing info regarding the location of your carriers authentication server(s). So basically what it's used for is the authentication of your phone for IOTA handoff over multiple systems, including other carriers towers for IOTA while roaming.

If you're interested you should go read the RFC 4282 document which defines the NAI technology. NOWHERE is it stated that NAIs have anything to do with connection types or even connection states....only user names for authentication and auth server location info....that's it.

So, in my conclusion, disableing Multi-NAI does NOT hide your connection method from your provider. Why? Because that's not what NAIs do. In fact, with out NAIs you may have a problem with your IOTA when you roam because your phone may not be able to find it way to Sprint IOTA authentication servers.

[letsgoflyers81]

I think you're missing the point. You say that NAI has to do with authentication but that's why it works. According to other sources, the Sprint 6800 can log into Power Vision with two different accounts. There's the Power Vision username and password that you set that controls using data on the device. The second account is supposed to be the devices ESN and it authenticates when you use Internet Sharing to tether. By disabling multi-NAI, you disable the second account so it can only log in with your Power Vision account, making it seem as if you're not tethering.

I've read recently that may only have to do with WModem and not with Internet Sharing at all. If that's the case it's not affecting anything. However I think your point about it not helping because it doesn't technically hide the connection type is incorrect.

[Krayziepop]

My point about it was that the WModem registry key that people are editing only affects the WModem.exe program - the ICS program has its own set of reg keys. Previously on the PPC-6700, we were able to use the ICS app from a different device to simply click connect and have the phone dial in and authenticate in one step. We lost that functionality with ICS on the Mogul. When you dial out THROUGH the ICS program, I believe the program itself pre-selects the 2nd NAI before it dials. Which would completely explain why it fails with an Error 67 every time. However when you dial out through the device first, then tell ICS to connect through the same connection, there is no call in the software to make it disconnect then reconnect - so it shares the already live connection through the device NAI.

I have wondered on a few different occasions if the ICS that was used for the Apache could be used on the Mogul - just to see if there is something coded in the OEM executable that changes NAI automatically... If there isn't something in the code of the ICS executable or its accompanying DLL's, then there must be something in the registry that I can't find telling the program to use the alternate NAI...

Sorry.. just thinking out loud I guess

[hunterdg]

************************************************** ******************************
-11/1/07-
As this is a rather lengthy thread to pour through, i've excerpted/posted the most important details into this (my first) post

--------------------------------------------------------------------------------------------------------------------------------------------------
To bypass tether-detection for Internet Sharing: (from post #35 in this thread, courtesy of Luv2Chill: http://forum.ppcgeeks.com/showpost.p...5&postcount=35)

Those of you running Sprint ROMs should remove the following registry value:

[HKEY_LOCAL_MACHINE\Comm\InternetSharing
"Extension"="rilphone.dll"

Usual caveats about editing the registry apply here--don't do this unless you know how.
---------------------------------------------------------------------------------------------------------------------------------------------------


Explanation is below:

I like (parens) and improper usage of single quotation marks to show 'emphasis'

Sprint employs tether-detection logic via a dynamic NAI domain prefix mechanism. This mechanism identifies the nature (tethered/untethered/datalink,etc) of a data connection request during the data authentication process. As Windows Mobile does not natively support such a mechanism, Sprint has elected to 'enhance'(cripple) Microsoft's extensible Internet Sharing (IS) application with pseudo-tether-detection 'logic' to approximate said mechanism: When in use, IS authenticates data sessions as 'tethered'. Fortunately, this 'logic' is implemented through a registry entry and .dll file, thus being (power)user-configurable.

As of ROM version 2.09, the 'logic' implemenation is flawed such that if a data session exists prior to invoking IS (data session has already authenticated as 'un-tethered'), IS simply NAT's the existing connection, rather than re-authenticating as 'tethered'. This explains the heretofore seemingly inconsistent connection successes/failures users without a PAM plan were experiencing.

The above registry tweak, discovered by Luv2Chill, bypasses Sprint's 'logic', allowing IS to work as provided by Microsoft: simple IP NAT of the device's data connection.


For those curious about how/why, below appear my relevant and correct/accurate discussion tidbits that were posted prior to Luv2Chill's tweak, with various clarifications interspersed. Again, i have excerpted/posted them here because several initial theories/posts (mine included) were dis-proven after trial and error, and until now, a reader had to read the entire thread to obtain accurate information. I hereby save readers from this necessity. Please be aware the original posts (besides this one) have not been edited for correctness, and thus may contain misinformation. They continue after the line of *asterisks* below.


[With a factory-fresh Titan/Mogul] Internet sharing WITHOUT a PAM (Phone As Modem) plan is possible if a data connection exists/is initiated (white or gray arrows above signal strength meter) prior to invoking the 'internet sharing' application. To be clear, it is NOT that one must connect with PIE before using ICS, it is that launching PIE is just a method of creating said necessary pre-existing data connection.
When ICS is invoked without a pre-existing data connection, ICS sees that M.IP 1 is NOT already connected and thus prefixes the NAI domain with 'pam', becoming 'username@pam.sprintpcs.com'. The phone then attempts to connect, and gets booted (error 67) when no PAM plan is found on the users account.
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.

At NO POINT is M.IP 2 (or any other M.IP besides 1) used for PAM authentication.


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.


************************************************** **********************
Original post:


just wrote a huge breakdown of this process and the #$&*#& backspace button took me back a page instead of back a space.. i'll see if i feel like explaining this process tomorrow from work. anyone want to encourage me? (Former sprint tier II (ATS) Tech support rep) (ebmorgan is sorely misinformed)

[ebmorgan]

Originally Posted by hunterdg

just wrote a huge breakdown of this process and the #$&*#& backspace button took me back a page instead of back a space.. i'll see if i feel like explaining this process tomorrow from work. anyone want to encourage me? (Former sprint tier II (ATS) Tech support rep) (ebmorgan is sorely misinformed)

Not "sorely misinformed"....just not aware of the clever way Sprint puts NAIs to use. What I gether from your post, not only does Sprint use NAIs for their native intention (authentication and auth server locating), but Sprint also recognize NAIs on the Sprint server side as indicators of which M.IP profile is in use....because each M.IP profile has a different NAI. It still not the NAIs that contain connection state....it's an additional process the Sprint runs on their end. So I'm right...but didn't have the knowledge about Sprints provisiong topology to follow it through to conclusion.

So, after reading your post...you're correct: MultiNAI disableing would keep Sprint from knowing you're tethering.....but only if you use the wModem app....which we don't because of the inception on ICS.

So the next questions are.....is there a MultiNAI reg key for ICS? My guess is probably not because ICS is an on-phone process of handing off the data from the tethered connection and not honding off the tethered connection itself.

[letsgoflyers81]

If you can explain technically why it does or doesn't work, I'd love to hear it. More information is better.

[specv]

Originally Posted by letsgoflyers81

If you can explain technically why it does or doesn't work, I'd love to hear it. More information is better.

+1 id also like to know the technical break down. Type it in word first then paste it in so you wont lose it

[hunterdg]

here's a breakdown... the condensed version.. i can expand if needbe
Disclaimer: my knowledge is of Sprint ONLY, this may or may not apply to other CDMA carriers.
Please be aware the info below is fairly low-level but comprises enough to understand the basic process... i can get more specific if necessary

first a few terms

error 1012: failure to IOTA
error 67: failure to authenticate

IOTA = Internet Over The Air, the process of populating M.IP 1 (and M.IP 2 if PAM capable) automatically, otherwise called "provisioning"

NAI = Network Access Identifier, a component of an M.IP Profile, specifically the username

M.IP Profile = Mobile IP Profile, a 'profile' (aptly named) that contains, amongst other things, the NAI and associated password necessary for authentication to sprint's servers (for data transmission ONLY, this has NOTHING to do with voice)

API: Active Profile Index, a setting in the phone that corresponds with the M.IP Profiles and tells the phone which profile to use when attempting a data connection. Settings are by number, 0,1,2 are the only settings in use today, 0 is default from factory.

All internet capable devices have at LEAST 2 M.IP's, and PAM capable devices have 3 (for now)

M.IP's can be viewed/edited by ##778#
anything in brackets [] below is dynamic, different for every user, and is entered into the phone WITHOUT said brackets

M.IP '0' (often called Default M.IP Profile) is set at the factory as follows:
NAI: [hex esn]@hcm.sprintpcs.com
password: ???
DO NOT EDIT THIS ENTRY! (reason below)

M.IP '1' is set by IOTA as follows:
NAI: [username]@sprintpcs.com (no parens)
password: randomly generated

M.IP '2' is set by IOTA for PAM capable devices as follows:
NAI: [username]@pam.sprintpcs.com
password: randomly generated

process is as follows, keep in mind this occurs on EVERY data-capable phone regardless of whether a data plan exists. ALL 3G accounts are assigned a plan code that automatically generates an NAI and associates it with the MDN/MSID combo. This plan code is REQUIRED for ANY sort of internet connectivity on the phone. You never see this plan code on your bill. Without an additional data pack, data usage is charged per-kb, i believe 2 cent/kb right now

brand spankin new phone:
API is set to 0 (from factory)
gets ##MSL#'d with MDN & MSID (phone number)
phone reboots
first time phone requests data connection, it references the API
API = 0 so phone uses M.IP 0 (M.IP's 1 & 2 are currently blank)
NAI of M.IP 0 is [hex esn]@hcm.sprintpcs.com, HCM = Handset Configuration Manager
HCM cross references the esn with the device's MDN/MSID, and initiates an IOTA***
IOTA automatically programs M.IP 1 (and M.IP 2 if the device supports PAM)
IOTA then changes the API to '1' so that the device will use M.IP 1 henceforth.

*** You MUST NOT edit M.IP '0', as if you do, though your data connection may still work (assuming you have a valid M.IP 1 and 2), if for whatever reason these fail, you will NOT be able to IOTA, as IOTA depends on a valid M.IP '0' BEWARE, there is NO reset (NONE WHATSOEVER) that will restore the M.IP 0 to defaults. If you edit it, you will need to visit a store for OTW (Over The Wire) provisioning should your M.IP 1 or 2 fail.


Newer sprint devices have the ability to detect when the device is tethered. when this occurs, the API is switched to '2', triggering the M.IP 2, with the NAI: [username]@pam.sprintpcs.com. (notice the PAM, for Phone As Modem)
when connecting to the server, this NAI tells the server the device is tethering. The server checks the customer's account for a PAM plan, and if none is found, the connection is refused. If a PAM plan IS found, the connection authenticates as usual.

Some have posited that the M.IP 2 (PAM NAI) redirects through a sprint proxy that does not compress jpeg images, like the regular M.IP 1, but i can neither confirm nor deny this.

the whole idea behind the "Disable Multiple NAI" reg hack is to disable the device's ability to switch from M.IP 1 to M.IP 2 when tethering is enabled. Thus fooling the sprint servers, and appearing as a normal M.IP 1 NAI, where the usage is billed straight to your 'vision pack'

I have not had time to test the "disable multiple NAI hack, but rest assured i will, and i will post my findings.

i have a few questions if anyone can give me definitive answers (please no "i think"s)

1. is wmodem ICS?

2. i know that using ICS over bluetooth does not use the DUN profile, rather it uses the PAN profile. while this is all well and good, is there a way to FORCE DUN instead of PAN

3. does the mogul/titan's bluetooth support multiple simultaneous connection over PAN?

4. I'm assuming the ICS via USB identifies as an NDIS device.. is there a way to FORCE it to identify as a MODEM?

5. the reg hacks that "unhide" BT, USB, and IRDA Dun (in the reg hacks thread)... do they do what i'm looking for? If so, after i have applied them, how can i 'find' the options to USE them? (they are NOT in ICS dropdown)

Thanks in advance for any answers to my question, and i hope this clears things up about the NAI/IOTA/blah blah issues.

please let me know if i can be more explicit. i'd be happy to, though it may be in a not-so timely manner

[letsgoflyers81]

Wow, thanks for the write up. I guess I was right about what disabling NAI does, to a point.

1. That's the $64,000 question. If it's not then I suppose disabling NAI in WModem is pointless for ICS.

2. I've only used a BT PAN on my Mogul, I have no idea if it can be switched to DUN.

3. I haven't tried it, but I think it might be possible. When I connect my laptop I get a private IP in the 192.168 range. That tells me the Mogul is doing NAT and that's a good sign for multiple connections.

4. No clue.

5. Again, I don't know. The only reg hacks I've done regarding tethering has been to disable NAI.

[luv2chill]

Hehe letsgoflyers81, he said "no 'I thinks'"

1. No, wmodem is not ICS. Wmodem is the old tethering app (has existed in more or less that same form for 4+ years) whereby the PPC becomes (for all intents and purposes) a modem on the connected PC and the data connection is created and initiated on the PC side (which by nature disables the connection on the PPC itself). ICS/Internet Sharing debuted with later builds of WM5 and WM6 is most peoples' first occasion to use it. Rather than a modem-based setup, Internet Sharing uses IP NAT to actually share the PPC's internet connection with the PC, so both devices are connected to the internet simultaneously. The PPC hands the PC an IP address and directs traffic from the PC just as a home router (or PC setup to do ICS) would.

2. Internet Sharing is incompatible with bluetooth DUN, because they use two different paradigms to accomplish tethering.

3. Yes, you can have multiple PAN connections to a WM device... however due to the processor speed of the PPC doing the NAT coupled with the modest speeds of the EV-DO network my hunch is you would not really get very good performance out of such a setup.

4. Again, Internet Sharing is an IP NAT application, so no modem stuff there. That's where wmodem comes in.

5. Unhiding them in the reg unhides them for wmodem.exe, not Internet Sharing. Internet Sharing is via USB (NDIS) or BT PAN only. Actually there's a recently-published hack to do it over wifi as well but still--no modem-based anything. Wmodem is what you're after--it is capable of USB (serial) or BT DUN and simulates a modem on the connected PC. However, I have not checked to see if the BT DUN profile is included with the mogul. If it isn't then that probably explains why the DUN reg entry keeps getting set back to 0 automatically.

The multiNAI reg entry, BTW, is useless... always has been. Useless for wmodem and doubly useless for Internet Sharing.

If I can answer any more questions let me know.