[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Freedombox-discuss] ppp details

On Tue, Sep 13, 2016 at 07:53:30AM +0530, Sunil Mohan Adapa wrote:
> ...
> > After digging into nm-settings (man nm-settings) I had to set these to
> > duplicate the ppp configuration in /etc/ppp/peers/cell:
> > 
> > $ sudo nmcli con modify "ppp" cdma.username qnc
> > $ sudo nmcli con modify "ppp" cdma.password qnc
> > $ sudo nmcli con modify "ppp" ppp.refuse-chap true
> > $ sudo nmcli con modify "ppp" ppp.crtscts true
> > $ sudo nmcli con modify "ppp" ppp.lcp-echo-interval 65535
> > $ sudo nmcli con modify "ppp" ppp.lcp-echo-failure 4
> > $ sudo nmcli con modify "ppp" ppp.baud 115200
> > 
> > ...
> I have created a separate issue to track the progress[5].  Could you try
> removing all the ppp specific settings and see if your are still able to
> connect?  You can edit the /etc/NetworkManager/ connection file directly

Commenting the entries in the /etc/Network/Manager/ connection file
(with #) didn't do anything, so had to do:

$ sudo nmcli con modify "ppp" ppp.crtscts false
$ sudo nmcli con modify "ppp" ppp.baud 0

Then the changes were reflected in "nmcli con show ppp".  After these
changes, I could still connect.  The connection between the phone and
the freedombox is a usb cable, so these leftovers from the RS-232 days
don't really apply, but if someone were to connect through a real
RS-232 cable these options might be important.


$ sudo nmcli con modify "ppp" ppp.lcp-echo-failure 0
$ sudo nmcli con modify "ppp" ppp.lcp-echo-interval 0

I can still connect.  I originally started using the non-zero numbers
because the Verizon tech support person told me to years ago.  I get
disconnected via "LCP terminated by peer" pretty regularly even with
the high numbers.  I'll keep an eye on this.

The username and password were also specified by Verizon tech support.
This page



  Username and password are generally ignored by the network and the
  device, so they aren?t useful.

so these fields might be used as default for cdma providers.  I have
also been told by Verizon tech support that the user should be
<phone number>@vzw3g.com but decided to leave what works as it was.
This might be necessary to use their mail server or their text to email
gateway, so these fields should probably be included with the default
values if the user does't change them.  I don't use their email servers.

Finally, after

$ sudo nmcli con modify "ppp" ppp.refuse-chap false

I could still connect.  This option was probably not having
any effect due to this other option:

ppp.noauth:                             yes

which was set to yes by default.

> for ease.  This will tell use that we don't have to bother with ppp
> settings which I hope is the case.

You were right.  No need to deal with ppp settings, at least the way
I'm using it.

One more thing: the

cdma.number:                            #777

was correct by default, so this is another item we don't have to
worry about.

Now that the ppp options are again the default, they have disappeared
from the /etc/NetworkManager/ppp<UUID> file.

A question: where are the parameters stored in plinth that are used
to activate a connection? I have noticed that in the "Network
Connections" page, the ppp connection is now shown as active or inactive
(after a refresh).  When it is active and is deactivated it works
correctly.  But if it is inactive and it is activated the activation
fails.  This is probably becauae when I first set up the connection I
did it with an incorrect option.  If I activate with nmcli without that
incorrect option it works fine.  If I could change the command executed
in response to the "activate" button, everything would work.  I'd rather
not delete the connection and have to re-enter all the options.


Reply to: