John
Thanks for your reply, it gave me a good starting point.
I've found I can reduce some of the negotiation using extra options in a
/etc/ppp/options.ttyUSBx file. Adding ":10.64.64.64" makes remote IP
explicit, and "novj" stops compression requests (unchecking TCP Header
Compression in NM does not affect this). So there are fewer IPCP messages
for a successful connection.
But it doesn't seem to affect whether it makes the connection or not. In
the failure case it looks like the basic problem is that the remote refuses
to supply a local IP address. My understanding is that the PPP server is
actually in the modem, and somehow this maps onto the over-air protocol of
GPRS, HSDPA, or whatever. As you say, how this works is pretty obscure.
I think it must be some weird problem between the modem and the carrier,
which is probably never going to be solved. My modem actually roams for its
2G service, because the carrier is "3" who have no 2G infrastructure, so
they allow roaming on the Orange 2G service (though they don't like to
admit it :). I can actually connect to Orange 2G via my phone, without this
problem, and I've used 2G roaming on French carriers also without this
problem.
I think I'm just going to have to live with it. :(
Thanks for your thoughts anyway.
Cheers, Rick
--On Monday, August 03, 2009 02:19:13 -0400 John Mahoney
<[email protected]> wrote:
On Sat, Aug 1, 2009 at 5:08 PM, Rick Jones <[email protected]>
wrote:
I only have one remaining problem with mobile broadband, which I don't
think is really anything to do with NM, but maybe some of the knowledgeable
people here might be able to provide some insight.
It's a problem establishing the ppp session, and only happens when the
modem falls back to 2G, when out of range of a 3G connection. I've attached
some syslog outputs which show the ppp exchange for when 2G fails, for when
it succeeds, and the normal 3G case.
The connection only succeeds about one time in 5. I suspect it's a
carrier issue, but I just wonder if there is anything that can be done to
overcome it, maybe by tweaking the default ppp options?
Modem is a ( horrible :) ZTE MF627.
Any ideas appreciated.
Thanks, Rick
_______________________________________________
NetworkManager-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/networkmanager-list
"Jul 1 11:29:30 mineee pppd[11260]: rcvd [IPCP ConfRej id=0x1 <compress
VJ 0f 01>]"
This line in the logs leads me to believe that you may want to uncheck
the box "use TCP header compression". It should at minimal speed up the
connection process.
"Jul 1 11:29:30 mineee pppd[11260]: Could not determine remote IP
address: defaulting to 10.64.64.64"
This line also leads me to believe you could try setting the ppp option
"<src ip>:<dest ip>" to "0.0.0.0:10.64.64.64", but I do not know if that is
set-able in network manager, yet I have seen you brewing up some patches,
so you may be able to figure it out ; )
Still, these two setting should take care of themselves. For IPCP to
complete there must be an IPCP ConfReq and matching IPCP ConfAck in both
directions. I do not see the other side even sending a IPCP ConReq(in the
2g bad log) which makes one wonder if anyone really is there. Isn't ppp
just so magical. After three years of messing with this it is unclear how
the ppp states translate into celluar tower states. And even if it was
clear the carriers would all do one or two things different.
--
John
_______________________________________________
NetworkManager-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/networkmanager-list
