Since I'm having a couple of problems lately that will ultimately require me to hard-reset my TyTN in the near future, I figured I could document the steps I take to salvage the configuration as I go and learn this stuff.
My primary tool will be the Windows Mobile 5.0 Pocket PC SDK, especially the rapiconfig tool, that allows to process and query configuration information in the form of provisioning xml files.
RapiConfig sends the provisioning file to the device, processes it and saves the answer to RapiConfigOut.xml.
Lesson #1:
How to retrieve Messaging account settings, even if they appear to have vanished, using the EMAIL2 configuration service provider:
<!-- query-email2.xml -->
<wap-provisioningdoc>
<characteristic-query type="EMAIL2" recursive="TRUE" />
</wap-provisioningdoc>
C:\>RapiConfig.exe /p query-email2.xml
The result will be a list of manually configured messaging accounts, plus Hotmail and MMS.
The result will not include passwords (parm name="AUTHSECRET). To be later able and use the output file for restore, these params should be added for those accounts with (parm name="AUTHREQUIRED" value = "1") and the file should be saved under a meaningful name. Since MMS will be commonly setup by the ExtRom setup, it should be removed.
Next time we'll look at wireless connection setup.
Lesson #2:
How to enable RAPI access with manager privileges and retrieve WLAN settings.
The attempt to retrieve WLAN settings using the "Wi-Fi" characteristic will fail with "Access denied", because the Wi-Fi configuration provider requires manager level access, which is like Administrator on a PC.
By default, RAPI only uses user access level, and users can obviously not be allowed to manage WLAN settings using RAPI.
The SDK provides a way around this. Allowing RAPI access to manager-level features can be enabled by a security policy. This policy must be set using a signed configuration file.
The SDK contains a file "RapiAllowed.cpf" in the rapisecurity folder that can be used for this purpose.
However, first the certificate used to sign this file must be installed on the device.
For this, the SDKCerts.cab must be run on the device. This step might fail however, if the network provider chose to prevent the user from using unknown certificates.
The the RapiAllowed.cpf can be copied and run as well. There will be no feedback other than a SMS confirming the installation.
RAPI is a powerful interface, so the inverse, RapiRestricted.cpf, must be run before the device is brought into possible hostile enviroments (e.g. where some people might run Bluetooth scanners, USB ports on public computers, etc).
There is also a tool available from Microsoft called "Security Configuration Manager" that allows reviewing and resetting device security.
With RAPI security disabled, querying Wi-Fi is a piece of cake:
<!-- query.xml -->
<wap-provisioningdoc>
<characteristic-query type="Wi-Fi" recursive="TRUE"/>
</wap-provisioningdoc>
C:\>rapiconfig /p query.xml
The RapiConfigOut.xml will show all configured WLANs grouped into access-point-based and ad-hoc networks, with a characteristic for each network.
The network key is included as dummy string "****************" that needs to be replaced by the real passphrase.
I guess the next thing is to take a look into the network settings provided by CM_Networks and CM_GPRS_Entries.
HB_TyTN, very interesting stuff in your lessons, thanks for your effort
Also you may like to check rapi unlocker here:
http://forum.xda-developers.com/showthread.php?t=252356
Excellent thread! Will definitely keep mentioining it in my forthcoming, related articles!
About networks
The network thing in Windows Mobile seems pretty messed up. In an attempt to make things easier, safer and more automated, I think, Microsoft left anybody on the way.
Here is what I understand and (warning), I may be totally off.
There are four pre-defined networks Internet, Corp, WAP and Secure WAP.
Although those may have different names based on OS language and HTC, provider or user choosing, the IDs of these networks are fixed and can be looked up in the SDK/include/connmgr.h file. E.g. Internet, is identified by 436EF144-B4FB-4863-A041-8F905A62C572.
These networks describe different setups in terms of routing, security or proxy settings or are used from different applications (e.g. WAP/MMS).
Of all networks, one is selected as Internet (public) and another can be chosen as private under Select Networks in Advanced Connections.
Internet will provide TCP/IP only. Private will provide access to Windows shares, and may connect to the internet, usually thru a proxy.
The Connection Manager separates the world into Internet and private, based on the URL of the server.
Non local server names, e.g. www.xda-developers.com will be connected with the network specfied as Internet.
Yes, this includes any directly entered IP address, as the detection is based on the occurrence of a "." dot in the server name. The only way around this is to specify the URL in Settings, Connections, Advanced, Exceptions (using * as a wildcard if necessary).
Sole server names and except URLs will be connected thru the network designated as private.
With each network, connections, network cards and wireless networks can be associated, so that, finally, the connection manager uses or dials one of those connections based on the network it chose to use.
That's a long intro into lesson #3: Querying network information
I'll start resetting RAPI security to restricted, by copying RapiRestricted.cpf to the device, running it and checking the SMS message for success. This should prevent any actual messing up something.
Now to querying networks using the CM_Networks configuration provider.
<!-- query.xml>
<!--<!DOCTYPE wap-provisioningdoc SYSTEM "msprov.dtd">-->
<wap-provisioningdoc>
<characteristic-query type="CM_Networks" recursive="TRUE"/>
</wap-provisioningdoc>
C:\>rapiconfig /p query.xml
C:\>notepad RapiConfigOut.xml
The introduction above is to explain why this query does not reveal anything useful, other than a list network names, their ID and an obscure "Secure" value, which is 0 for all my connections.
I find it more interesting to query the CM_PPPEntries or the CM_GPRSEntries providers. They use a similar, yet somewhat convoluted schema.
Here are the notable parts:
DestID associates the entry with one of the networks I talked about and queried above.
Phone is the number to dial for the connection. For GPRS, this entry is set to "~GPRS!". I wonder who came up with that string.
Username and Password are obvious and so is RequirePw.
DnsAddr, AltDnsAddr are not out of the ordinary, and if SpecificIpAddr is "1", the ip address is in IpAddr, although I'd assume it is assigned dynamically in most cases.
DeviceType and DeviceName are set to "modem" and "Cellular Line" for the connections that use the phone network.
DeviceSpecificRAW is the most dangerous entry here, since it contains the parameters for the phone device in binary form. I wonder if there is any point in looking into those other than to inflict pain.
Some of the device parameters are set verbosely, so let's rather look at those. However, your provider may not like it if you modify these vigorously.
If BearerInfoValid is 1, BearerInfoService and BearerInfoSpeed are supposed to specify the type of modem and it's speed. Values in my case are 1 -Async Modem and 15 - 9600 v32, which goes to show that the latter value is rather useless, because I know I get more than that with both UMTS and GPRS. So better not tamper with these.
CompressionInfoValid and RadioLinkInfoValid are set to 0 in my case, so one can easily do without.
GRPSInfoValid is set to 1, but the only real interesting parameter is GPRSInfoAccessPointName, which must be set for the GPRS connection to know whom to talk to.
GPRSInfoQOSSettingsValid and GPRSInfoMinQOSSettingsValid are 0, which is sad, because I'm really not happy with my GPRS Quality of Service and would have loved to improve it.
Now, that was a joke. QoS is a way of classifying network traffic for bandwidth and latency and I doubt any provider supports it for Joe Average.
For all the parameters documentation is in the Smartphone SDK about the Telephony and TSP API structures.
Finally, a list of default URL mappings, as found in the CM_Mapping provider documentation.
*://*.*/* The Internet
*://*/* My Corporate Network
wsp://*/* WAP Network
wsps://*/* Secure WAP Network
To query my personalization settings, next time I'll dive into the registry and see what I can do with RAPI configuration queries.
I have been attempting to get my HTC Wizard running WM6 working with BT Broadband Voice but I have hit an issue.......
I have managed to get a PC Softphone working with the service (3CX Phone) and have captured the SIP registration with a network Sniffer (Wireshark). I have replicated the settings into the provisioning XML file and installed this on the Wizard through the .CAB method described in another thread. However when using the Wizard I never get a response to any of the registration requests it sends. I have managed to get the Wizard working with a test-lab Asterisk server I have so I know the SIP client works.
The differences in the traces between the PC softphone and WM6 registrations seems to be a 'Branch' message that is sent in the SIP header that isn't sent from the Wizard:
From 3CX Phone:
Code:
P.WES=Dd<Qj(rWREGISTER sip:btsip.bt.com SIP/2.0
Via: SIP/2.0/UDP 192.168.100.60:5061;branch=z9hG4bK8019d72590f1db11be898000600fe800
From: <sip:[email protected]>;tag=16764
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 2 REGISTER
Contact: <sip:[email protected]>
Max-Forwards: 70
User-Agent: SIPPER for 3CX Phone
Expires: 0
Content-Length: 0
From WM6:
Code:
[email protected]/->2E>b)REGISTER sip:btsip.bt.com SIP/2.0
Via: SIP/2.0/UDP 192.168.130.1:5061
Max-Forwards: 70
From: <sip:[email protected]>;tag=04d52dd0d6;epid=0ceca78c1f
To: <sip:[email protected]>
Call-ID: 000098f4000012188099efbe2d87c701
CSeq: 1 REGISTER
Contact: <sip:192.168.130.1:5061thods="INVITE, INFO, OPTIONS, BYE, CANCEL, ACK"
User-Agent: RTC/1.5.5374
Event: registration
Content-Length: 0
I am thinking there may be some additional stuff that needs to go into the provisioning file but I am not sure what
Has anyone managed to get this working with BT Broadband Voice? If so what changesdid you have to make? Does anyone know what the 'Branch:' header is and whether this is implemented in the WM6 SIP stack?
Thanks
Andy
Replying to my own posts.....
Right after a bit more playing around and debugging pre and post firewall logs I think I have narrowed this down to being a NAT/Firewall issue.
I originally thought the issue was the lack of the 'Branch' message in the SIP header from the WM6 device - it isn't. It is in fact the 'Contact' header. With the WM6 registration packet this includes the source IP address of the SIP User/Server Agent (the Wizard's SIP Phone) which is using RFC1918 private addressing (sip:192.168.130.1:5061) as I am behind a router/firewall performing NAT. In the 3CX Phone registration it contains the phone number in the Contact header (sip:[email protected]). I checked on my router/firewall and this was not receiving any replies from the SIP Registrar/Proxy, however it was sending the Registrations. Luckily my Router supports SIP Protocol inspection so can intercept the SIP headers and modify them. I enabled this feature and now I can see the router changing the Contact header in the SIP Registrations and can see the replies returning from the SIP Registrar/Proxy
I'll continue testing this and let you know my results..........
Andy
Did you ever resolve this??? I've noticed the same thing, and my SIP provider keeps sending a 400 bad request when trying to register because the contact header isn't how it should be.
chavonbravo said:
Did you ever resolve this??? I've noticed the same thing, and my SIP provider keeps sending a 400 bad request when trying to register because the contact header isn't how it should be.
Click to expand...
Click to collapse
Yes it is resolved but only because my router supports SIP inspection. When my phone attempts to register with BT Broadband my router intercepts the registration packets and replaces the RFC1918 address in the 'contact' header with it's own 'real' IP address.
Andy
Can someone explain on a technical level the process a modern smartphone goes through to establish the APN for a particular SIM? Does the SIM contain any information about the APN itself? I would prefer not to prejudice the explanation beyond those questions.
Thank you for any information you can provide.
AFAIK, vendors include a database of service providers and their associated APNs in the firmware. Once service provider is identified based on SIM (IMSI) and country/network code (MCC/MNC), connection parameters are configured based on the contents of the database.
New Voice Authentication Process
Effective today, new security enhancements are in place to prevent unauthorized access to Sprint's network. Due to these new enhancements, you may encounter a device that is not recognized on the network after you have performed a ##RTN (786).
If you receive the message "Due to Error #16, your call has failed to complete" while placing a test call, you'll be required to contact a dedicated Care Team to have the device authenticated on the network.
For complete details, see the Voice Authentication Error M&P located at ISC > Service and Repair > Resources > ASC Methods and Procedures > Voice Authentication Error (5/2/11). ISCPortal Link: Voice Authentication Error (5/2/11)
What would this affect?
Its not like we could import other CDMA phones to begin with.
The only phone/ devices I'd even expect them to allow would be the Nokia N810w & the New $1,500 Qualcomm Phone... Maybe.
Noiro said:
What would this affect?
Its not like we could import other CDMA phones to begin with.
The only phone/ devices I'd even expect them to allow would be the Nokia N810w & the New $1,500 Qualcomm Phone... Maybe.
Click to expand...
Click to collapse
It looks like it would not do hands free activation anymore. It has to be called in so the device can retrieve the network settings so it can establish a data connection with the towers.
Edit:
I have figured out that you can have logging softwares within the system however the logging system will log all details from NAT to the client but what it cant log is the Transversing of Port numbers at the gateway...so my question is do mobile operators keep log of these tables after the expired session. So here is the scenario, to backtrace. you would need the website host to give you the ip address, source and destination port, timestamp etc to start the process, the ISP will then look at its Logs to find out the traffic requests but map each of these requests, the ISP will need to know the table which was used for transversing but according to my knowledge the table gets deleted or releases the port number and ip address information after its timed out idle.
Anyone who can let me know if network operators keep a copy of this table?
Thanks
Gents,
I was looking for some information regarding IPV4 implementation on mobile networks. I have read in detail the IPV4 implementation on mobile networks and also IPV6 theoretical implementation on mobile networks. So here is my analysis so far – For IPV4 on mobile networks.
Mobile networks use NAT for giving dynamic IP addresses to its mobile device users who connect to the internet. On the outside the mobile network operator might have a few external static or dynamic IP addresses. You can get a static external ip address for your mobile device or group of devices but you will have to pay for it. GPRS runs on the back of GSM or UTMS (3G) but looking at GPRS implementation, you have GSGN, SGSN and mobile node all working in harmony in a triangular modulation however where I am lost is with CDRs (call detail record) which are sent by CGF (charging gateway function). Do these records keep a record of internal IP assigned to the mobile device for which the packet was transmitted or not? So far what I have found looking at the format of a CDR is it records the ip of GSGN but not the mobile device. What I am trying to understand is if the mobile users can be traced back from external ip all the way back like reverse lookup? Please note this question is in regards to IPV4 on mobile networks not IPV6.
Can someone please shed some light on this?
Many thanks in advance
V