Re: ppp strangeness

[Dan Williams <dcbw redhat com>]

On Mon, 2009-08-03 at 13:15 +0100, Rick Jones wrote:
> 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.

Correct, PPP is only used between the firmware and the computer.  No PPP
packets ever go out over the air.  So it's likely that there are
firmware bugs or oddities in the modem.  The process should be something
like this:

1) you send the APN + user + password to the firmware with AT+CGDCONT
2) you dial the modem
3) firmware begins a GPRS session with the network using the specified
APN (which identifies a specific GGSN/SGSN)
4) firmware uses the user + password you specify when authenticating to
the SGSN during GPRS session setup
5) when the GPRS session and PDP setup are complete, the modem
encapsulates over-the-air packets with PPP and sends them over the
serial port to the computer, and decapsulates PPP frames the computer
sends to the modem

It's all completely stupid and simply because everything supports PPP,
so modem firmware designers just used the least-effort path to get the
computer and modem to talk to each other.  But emulating a serial port,
it turns out, just makes everything more complicated and less efficient,
as you've already found out through the various ZTE firmware quirks.

Modern designs (from Option or Ericsson) do away with PPP entirely, and
just expose a control channel (AT port) and a data channel
(ethernet-like network device).  That approach actually allows you to
get up to 7.2Mbps HSDPA where previously PPP overhead made that
impossible.  It also means we don't have to screw around with pointless
PPP options like compression, capability negotiation, etc, that just add
another point of failure.

Your specific problem could be a firmware issue, it could be bad 2G
signal coverage at your location, it could be network provider issues
between your home network (3) and the roaming network, anything.
Unfortunately, it shows up as PPP errors and thus obscures what the real
issue is.  Are you sure you have the latest firmware on the modem?

I also now have a ZTE MF627 graciously donated to me, and while I can
use it for testing modem identification, I can't use it to actually
connect to anything since it's apparently 900/1800/2100 only which
doesn't work in the US.

Dan

> 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
> > 
> > 
> 
> 
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list