Web Browsing on Legacy Handsets

1xBTS includes two built-in browser gateways so an older CDMA2000 or IS-95 handset can browse the modern web over packet data. Both run inside the fou-nat packet-data container and are on by default, so once a handset has a working data session its browser can reach one of them:

Which one your phone uses depends on the browser it shipped with. A phone that asks for a “WAP gateway” or “proxy” IP and port 9200 or 9201 uses the WAP 1.x gateway. A phone whose settings mention an “UP.Link” gateway uses the UP.Link gateway. Either way the browser needs a working data session first — see Packet Data Setup and Packet Data.

Status: Experimental. Pages are converted on a best-effort basis, so expect text, headings, links and simple forms rather than full fidelity.

WAP 1.x gateway

The WAP 1.x gateway is a Kannel WAP gateway listening on the tunnel address (10.55.0.1 by default) on the standard WAP ports: 9200 (connectionless) and 9201 (connection-oriented). It fetches the page the handset asks for, converts HTML to WML, and returns the deck to the handset.

How the handset reaches it

A WAP 1.x browser dials a fixed gateway IP and port, provisioned in the phone’s browser or data settings. There are two ways for that to land on the 1xBTS gateway:

• Point the handset at the tunnel address directly. Set the WAP gateway (proxy) IP to 10.55.0.1 and the port to 9200 or 9201. Nothing else needs to change.
• Redirect the handset’s provisioned carrier gateway. Many phones carry a carrier WAP gateway IP that cannot be edited. Add that IP:port to WAP_HIJACK_ENDPOINTS and fou-nat redirects it to the local gateway on the tunnel. The port is preserved by the redirect, so the provisioned endpoint must already use port 9200 or 9201.

Carrier gateway addresses vary per operator, so WAP_HIJACK_ENDPOINTS has no default. The address your phone dials is usually visible in its WAP or data settings menu.

Configuration

These are set on the fou-nat service (defaults shown).

On startup fou-nat prints the active gateway, e.g. wap-gw=10.55.0.1:9200,10.55.0.1:9201 transcode=127.0.0.1:8090 hijack=[...].

UP.Link gateway

The UP.Link gateway serves Openwave UP.Browser handsets. UP.Browser speaks HDTP rather than WAP 1.x, so the gateway terminates the handset’s HDTP session, fetches the requested page, and converts it to HDML before sending it back. Encrypted (cipher-2) browser sessions are supported.

How the handset reaches it

A UP.Browser doesn’t resolve a hostname — it dials a fixed UP.Link proxy IP over UDP, provisioned in the phone’s browser settings. There’s nothing to intercept with DNS, so the gateway instead redirects those fixed proxy endpoints to itself on the tunnel. A handset whose provisioned proxy is one of the built-in defaults just works, with no reprovisioning.

Configuration

These are set on the fou-nat service (defaults shown). You normally don’t need to change anything.

The two default endpoints are common carrier UP.Link proxy addresses, so many stock handsets browse without any changes. On startup fou-nat prints the active hijack, e.g. hdtp-gw=10.55.0.1:1905 hijack=[153.114.115.100:1905,...].

Pointing your handset at the gateway

If your handset’s provisioned UP.Link proxy isn’t one of the built-in defaults, you have two options:

• Add your handset’s proxy to the hijack list. Set HDTP_HIJACK_ENDPOINTS on the fou-nat service to include the IP:port your phone dials. This is the least intrusive — the phone keeps its factory settings.
• Reprovision the handset’s UP.Link gateway IP to ours. In the phone’s WAP/browser settings, change the UP.Link gateway (proxy) IP to one of the built-in defaults, or to the tunnel gateway IP directly. Do this when the phone’s proxy address is unknown or can’t be discovered.

Known issues

• “System Error” on a UP.Browser handset. If the browser shows a System Error, exit and resume (reopen) the browser — the next session recovers and the page loads. This is a known issue and doesn’t require reconnecting data or restarting the phone.