WAP3GX log file format

WAP3GX log file format SearchSearch
Author Message
Olaf
Unregistered guest
Posted on Monday, November 17, 2003 - 01:26 pm:   

We're looking for a way to identify which mobile network a user of the wap gateway is calling from. It seems like there are an entry or two in the gateway log file that I can't explain, but I'm not sure if this will help. A typical log file entry looks like:

192.168.1.91 - [12/Nov/2003:09:45:13 +0100] "GET http://192.168.1.6:8080/wap11/SID-A684A10A/SESS-0/X-1" 200 606 "" "SonyEricssonT68/R501"

Most of this seems obvious, except the "200 606" just before the phone type. What does this field mean? Are there any ways to get more logging from the gateway - in order to identify where the calls are comming from?

Kent Williams
New member
Username: Kent

Post Number: 10
Registered: 10-2003
Posted on Wednesday, January 14, 2004 - 07:07 pm:   

200 is the HTTP status code (200 = OK, 404 = Not Found, 304 = not modified, 302 = redirect, among others).

606 is the number of bytes transferred for the request.

There is no way to identify where the request is coming from unless you have integration with the access server(s) to which the mobile device is connecting.

This is either the GGSN in a GPRS environment, or a network access server in a dial-up environment.

The GGSN or network access server needs to be configured to see the WAP proxy as a Radius accounting server (and possibly also as a Radius authentication server). This way, when a device makes its connection to the GGSN or network access server (NAS), and gets assigned an IP address, the GGSN/NAS can send a Radius accounting packet to the WAP proxy. This accounting packet can inform the proxy what the MSISDN is of the device that just connected.

So needless to say, it is almost impossible to implement this type of solution if you are not a mobile operator (or a virtual operator with your own GGSN and/or NAS).

At the WAP protocol level, there is no identification for the device other than the IP address that initiated the request. There is a bit more information on this topic at the following link where it discusses how the NowSMS MMSC can be configured to receive the MSISDN from the WAP Proxy:

http://www.nowsms.com/support/bulletins/tb-nowsms-002.htm

--
Kent Williams
Now Wireless Support