Re: ppp strangeness

[Rick Jones <rick activeservice co uk>]

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 <jmahoney waav com> wrote:

> On Sat, Aug 1, 2009 at 5:08 PM, Rick Jones <rick activeservice co uk> 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
> NetworkManager-list gnome org
> 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
> 
>