Re: NM using Option card

[Dan Williams <dcbw redhat com>]

On Fri, 2008-02-08 at 12:39 +0100, Stefan Seyfried wrote:
> Markus Becker wrote:
> > No. Debian. It might be that I do not get the correct DNS server from the 
> > peer:
> > 
> > Feb  7 20:55:56 shelbyville pppd[10716]: Using interface ppp0
> > Feb  7 20:55:56 shelbyville pppd[10716]: Connect: ppp0 <--> /dev/ttyUSB0
> > Feb  7 20:55:56 shelbyville pppd[10716]: PAP authentication succeeded
> > Feb  7 20:56:34 shelbyville pppd[10716]: Could not determine remote IP 
> > address: defaulting to 10.64.64.64
> > Feb  7 20:56:34 shelbyville pppd[10716]: Cannot determine ethernet address 
> > for proxy ARP
> > Feb  7 20:56:34 shelbyville pppd[10716]: local  IP address 90.186.19.42
> > Feb  7 20:56:34 shelbyville pppd[10716]: remote IP address 10.64.64.64
> > Feb  7 20:56:34 shelbyville pppd[10716]: primary   DNS address 10.11.12.13
> > Feb  7 20:56:34 shelbyville pppd[10716]: secondary DNS address 10.11.12.14
> 
> This happens for me (using umtsmon) when the dialup takes too long. Apparently
> the card is not patient enough and just returns some standard DNS server
> addresses. Also this happens more often with vodafone than, say, eplus as
> provider.
> 
> Generally goes away if you hang up and dial in again.
> 
> BTW, there is a lot of debugging and magic quirks for different cards already
> done in umtsmon, if somebody working on UMTS features for NM would ask Klaas
> for some hints, this would probably spare you lots of unnecessary work and you
> could profit from his knowledge.

We've been talking to the VMC developers, who have added a D-Bus
interface to VMC.  You're right, it's pointless to have many projects
duplicate the same quirks and workarounds for cards, and using some
existing tool is the way to go.  Since VMC is adding the D-Bus
interface, Tambet and I thought that using VMC like we currently use
wpa_supplicant would be a good option.

> The 10.64.64.64 default peer address is also no problem - the network just
> does not return a peer address, so pppd uses this default. It does not matter,
> as long as your default route points to the ppp interface, it just works.
> At least for me, with a quite some hardware and providers that have tested.

Not really; I needed a valid peer address for Sprint here in the US
otherwise my packets would go nowhere.  Previously, the NM
implementation would just assign the local address as the peer address,
and that simply didn't work.  I can't imagine how assigning the random
10.64.64.6x address would work any better?

dan