I have that IP in gconf slp_address and agps_srv_address and it just refreshed.

Curious, mine doesn't any more either (last known good refresh was at the end of February) :-(

In fact tcpdump shows the server doesn't even respond to the SYN packet so maybe they're filtering geographically?

So, I came across this and thought I'd build and run it on my desktop to try to see where it's going wrong (with the servers that do respond at least).

It turns out that supl-proxy must sanitise the dialog somehow, because with it in the middle everything works fine!

I'm not sure about the legalities of running a public proxy so I'm not going to do that. However running the proxy on the device itself should be ok, so I fired up scratchbox and built it.

To test, install supl from extras-devel, then run:

and start agps-ui as usual. This is only good for one request, supl-proxy terminates and you have to restart it (or run it in a loop, whatever).

The above needs to be automated and integrated in the package of course, but in the meantime any feedback is welcome.

Also, anyone know if there's some dbus incantation to launch it dynamically on demand? It's RAM footprint isn't that big, but why keep it around if it's not needed.

Perhaps modify the desktop file for agps to launch the proxy before launching agps.

It's a bit dirty, but could work. Another option that comes to mind to "port" and use some inetd, which would also take care of the terminates-after-one-request issue, but that would still introduce a permanently running daemon.