Debunking the Multi-NAI Myth
 

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.

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.

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 :p

Muti-NAI hack BUSTED: How to tether via Internet Sharing without a PAM plan
 

************************************************** ******************************
-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)

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

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

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.

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.

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.

Ok, so if I'm following, all the technical aspects lead to the conclusion that no registry tweaks perform any valuable contribution towards using the ICS progam to tether. Meaning the process should work simply by launching ICS, launching PIE, connecting desktop, and remembering to disconnect on Mogul when finished on PC.

Sprint is allowing the tethering, and currently has the means to be aware of it despite currently used registry tweaks. Unless there is a true ICS Multi-NAI disable, we are able to tether only due to Sprint's good graces, which only last as far as our data usage patterns don't get red-flagged, or Sprint decides to no longer look favorably upon casual tethering.

What is hard to understand is the multitude of forum posts indicating an Error 67 is solved or influenced by the (useless) registry tweaks. It also calls into question whether PDAnet truly provides an "invisibility" in the sharing process it invokes, or simply a simpler, 1-click pretty interface operating the same "detectable" tethering process detailed above.

Well, if you disable NAIs then your phone will have no way to to locate Sprint's auth servers to authenticate while roaming. That might be the cause of the error 67s.

What someone needs to confirm is if ICS uses the wmodem.exe app that the MultiNAI disable reg heack applies to. If it doesn't use wmodem, then the MultiNAI hack is useless. But then again, if people are getting error 67 while using ICS, then the NAIs might be needed.

As for PDAnet, since it requires ActiveSync as the connection transport, I would assume that Sprint sees it as normal device operation and not tethering.

Thought, people?

luv2chill, thank you for your invaluable answers.. i suppose had i considered that ICS uses PAN over BT rather than DUN, i could've figured out that ICS ≠ Modem...(that and the correlation btw xp ICS and wm ICS).. My brain is slow.. It's a friday! But seriously thank you for the straightforward answers. You've been a great help!

WHAAAAAA???!!! this is the MOST obvious solution to me, i was peeeved when i found out only BT & USB were supported! .. you wouldn't happen to have a linky would you???


I'm amazed how much mis-information is floating around these forums then.. i've waded through pages and pages of crap!! Your theory concerning the BT DUN profile/DUN reg entry sounds way too legitimate for it to be coincidence.

when i get a chance to play around i'll post back.. hopefully this weekend.. but the fair's in town so i can't guarantee anything.. haha

@ ebmorgan, my apologies for the 'sorely' comment.

it appears (as luv2chill stated) that the wmodem application and the ICS application are unrelated. This makes logical sense.

I'll have to play around and see how i get error 67's..

anyone know why we have both "Sprint PCS" and "Phone as Modem" connection options if they both do the same thing?


I've read all over these forums that people are tethering without PAM plans.. but now i'm not sure how much of that is BS...

my goal is to find a way to tether WITHOUT a PAM plan, and WITHOUT any third party software..(pdanet)

prior to obtaining my mogul, i was on the 39.99 unlim PAM with my Fusic & BT DUN..NO Sprint connection manager.. i hate un-necessary complication.

the second i read the "disable multi nai" hack thread, i called up and removed the pam plan..Now i'm regretting it!

if there's a way around it though, then no sense in paying un-necessarily. (I'm a firm believer in "if it can be done a better, cheaper way, then i want to figure out how to DO it)

Is it possible that "Sprint PCS" = M.IP1 and "Phone as Modem" = M.IP2? That's my theory. Thus using ICS and "Sprint PCS" results in Sprint seeing the connection as normal on-device usage. "Phone as Modem" results in the use of the wmodem app and M.IP2 resulting in Sprint seeing a tethered connection.

Thoughts?

Well that theory is out the window because there is no MIP.2 in use on the mogul. Look for yourself--dial ##PST# and click view. Then click the left softkey and you can see the MIPs for yourself. The Default is the ESN-based, the MIP Profile 1 is the user name auth added by IOTA. That's it--the rest are all blank.

BTW, I am moving this thread to the mogul/titan forum since it relates directly to that device.

Go read hunterdg's big post in the first page of this thread. According to him it is used. It's M.IP for PAM. Just because it's blank doesn't mean the phone doesn't use it. Example: even M.IP1 is blank when you first get the phone proir to it being provisioned.

(Emphasis mine)

You can't use a blank MIP connection. The MIP1 is blank when you get the phone because it doesn't have any of your personal data in it yet (how could it? That's how it ships from the factory). When you do an IOTA then that MIP gets filled in with your user name as the NAI. Similarly if the handset were PAM-enabled the IOTA would have populated the MIP 2 field with a NAI of:

username@modem.sprintpcs.com

If the phone has been provisioned and it doesn't have a modem NAI in it then there is no way for Sprint to know you're tethering.

Hope that clears it up for you.

guys.. I had just 'assumed' (we all know what that does) that the mogul was PAM-enabled, and thus M.IP 2 was populated with [username]@pam.sprintpcs.com.

i have not eer verified this, i just 'assumed'...

as of now, (and according to sprint, as a result of my removal of the 'pam' plan), my device is failing to IOTA.. (ticket has been opened on sprint's end)
in my troubleshooting steps i have reset all the M.IP's so for me, M.IP 1 & 2 are blank till my device can once again IOTA. I will at that time double check the M.IP 2 field and verify luv2chill's statement that it is, infact, NOT used on the MOGUL..

I can only assume he's correct though, as he has a mogul..

if a phone is PAM-capable (or rather, capable of detecting tethering), regardless of whether a PAM plan is attached, BOTH M.IP's are populated as i described in my long post..

the code i mentioned briefly, that creates these two M.IP's, is called IP_BASIC.
(i mention this so that no assumption is made that the M.IP 2 is not created/populated unless a PAM plan exists.. this is simply not true)..

If the mogul infact, does NOT get M.IP 2 populated, this explains how users are able to tether without any usage charges. the M.IP nai disable myth is BUSTED!!!

will keep you updated, although i trust that luv2chill knows what he's talking about

p.s.... if an M.IP is blank, it is useless...

this is certainly a valid assumption if M.IP 2 is in use...
I'll have a 'second opinion' confirmation hopefully sometime within the next 36hrs (ticket ETR)

hunterdg, I had to go through this with Sprint twice myself, so I think I may know the solution to your problem. Even after Sprint had attempted several things on their end to fix it, nothing worked. So the tech I had on the line told me to do a Master Reset of the phone. Before you do this though, you will need to go into the ##(MSL)# PST tool and get your MDN and your MSID (this will save you from having to call Sprint later to reactivate) I can't remember which ## code brings up the menu where you can do the master reset from... maybe someone else in here can shed some light on it. I would find it, but I am running colonel's hybrid rom on my Mogul, and most of the ## codes dont work... Anyway, once you get it master reset and it all comes back up, just ##(MSL)# back into PST and put in your MDN and MSID values you wrote down earlier and let the phone reset. Once thats done, the phone is reprogrammed and your first IOTA should work as normal now. The master reset wipes out ALL data on the phone, including your M.IP profiles and all provisional information. Basically its like pulling the phone out of the box again.

Its up to you if you want to try it... but thats more than likely what they will have you do anyway. It worked right away for me, so maybe it will help you out some.

Ok... watery eyes... itchy eyes... its gotta be time for bed. :p

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!!

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! :p

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'

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.

do you have a pam plan?

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

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

@ 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 *

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

@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)??

So, does this imply that you could have a PAM account with a simple DNS hack?

EDIT: Oops, no, since that is the user id, that wouldn't be a DNS hack.

I just tried this for you and i get the error 67.
I also tried it with a data connection established and got the same error.

perhaps i need to reset before trying with the connection.

I've never tried to connect to ICS without an existing Vision connection. I'm practically always connected due to other apps. Since I'm already connected I've never had an authentication error with ICS.

A couple of questions.
 

I have some questions, and if this is the wrong post I apologize, but it applies to a question that I have ask Sprint (on their worthless *2 talk helpline and in the store, and did not get a clear answer). I have a PPC-6700, through Sprint, I downloaded sprint mobile broadband and connected my phone. I did not buy a PAM account, I do have unlimited internet access on my phone.

My Questions are:

What is the charge per kb?

I read that the PPC-6700 can teather without charges or a PAM, is this true?

Is there a charge from Sprint if I use PDAnet?

Thanks for any help.

OK I've poked into things a bit more and yes it seems Sprint is up to no good in regards to tethering. 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.

Can you elaborate on what this value does?

Holy shit LUV! You are incredible! That fixed things up in a flash :D

No more clicking on PIE to start the connection first! YAY! It dials right in now without a quarrel. Thank you very much for that fix!

So this RILphone file (assuming its something along the lines of Radio Interface Layer?) has something to do with how the cellular radio communicates with the rest of the device then... Funny that a specific call has to be made through the registry in order to invoke the error code when dialing through ICS.

*goes and digs up hex editor*

I would explain this and get input before suggesting an unknown reg hack so we don't have another one to debunk.

Also, is this a hack simply to solve the error 67, or is this also something you suspect might have something to do with tethering detection?

Thanks Luv2chill, tested and as Krayziepop said, IS will now initiate the data connection itself.

Just hit connect. :)