Mikko Rapeli
2009-01-23 05:10:57 UTC
The pppd patch seems to be a "try and try again until you get real DNS
server IPs" approach. Checkout this later post in the thread by the same
Patching pppd seems a bit extreme to me. Once the DNS servers are known
I would personally prefer to manually put them in /ect/resolv.conf and
seek out and remove the usepeerdns pppd option. That option would likely
in the script /etc/ppp/peers/gprs (as in 'pppd call gprs') or something
called by it.
I tried the patch and it works with a Huawei USB and an Option PC cardserver IPs" approach. Checkout this later post in the thread by the same
Patching pppd seems a bit extreme to me. Once the DNS servers are known
I would personally prefer to manually put them in /ect/resolv.conf and
seek out and remove the usepeerdns pppd option. That option would likely
in the script /etc/ppp/peers/gprs (as in 'pppd call gprs') or something
called by it.
modems. I can remove all sleeps and pppd call gprs with success straight
from udev scripts when the modems are connected.
If I got it right, the patch forces pppd to use the latest received DNS
configuration from the peer instead of the first one. That would be the
correct thing to do with these modems, but I'm not sure what else this
might break. A quick look at the PPP rfc does not say this would be
wrong.
For comparison I took AT command and PPP logs from a Vista machine which
uses the Vodafone connection manager:
http://koti.kapsi.fi/~mcfrisk/gprs_debug/qualcomm_ppp/vista_ModemLog_HUAWEI%20Mobile%20Connect%20-%203G%20Modem.txt
http://koti.kapsi.fi/~mcfrisk/gprs_debug/qualcomm_ppp/vista_ppp.log
Here are successfull connection setups with and without the patch:
http://koti.kapsi.fi/~mcfrisk/gprs_debug/qualcomm_ppp/ppp_log_huawei_fixed_pppd.txt
http://koti.kapsi.fi/~mcfrisk/gprs_debug/qualcomm_ppp/ppp_log_success_without_ppp_fix.txt
I will host failing cases too when I manage to copy some older log files
from the host in question.
-Mikko