GPRS and bad DNS servers like 10.11.12.13

[Mikko Rapeli]

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 card
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

[Mikko Rapeli]

Post by Mikko Rapeli
I tried the patch and it works with a Huawei USB and an Option PC card
modems. I can remove all sleeps and pppd call gprs with success straight
from udev scripts when the modems are connected.

I verified the patch also with Debian Lenny ppp version 2.4.4rel-10.1
and the Huawei E220. Here are logs of failure without the patch and
success with the patch applied:

http://koti.kapsi.fi/~mcfrisk/gprs_debug/qualcomm_ppp/ppp_log_failure_without_ppp_fix.txt
http://koti.kapsi.fi/~mcfrisk/gprs_debug/qualcomm_ppp/ppp_log_success_with_ppp_fix.txt

-Mikko

[Clifford Kite]

Post by Mikko Rapeli
I tried the patch and it works with a Huawei USB and an Option PC card
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

I think the patch removes a limit of 5 on ICMP requests that include
DNS servers. In that case pppd would respond to the peer's NAK of
such a request with another request until an ACK is received or pppd
is terminated. The peer in this situation appears only to ACK when the
request is for the real DNS server addresses, i.e., when the preceding
NAK by the peer supplied pppd with actual server addresses.

Post by Mikko Rapeli
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
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

It appears that the Vodafone connection manager restarts PPP negotiations
from the beginning after each failure until successful. I could be wrong
though since I don't do windows.

Post by Mikko Rapeli
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

It looks to me like the "success_without_ppp_fix" and "fixed_pppd"
logs are switched.

The "success_without_ppp_fix" log shows pppd requesting DNS servers from
the peer 17 times before success which seems reasonable considering the
log [1] alluded to in my previous post and what I think the patch does.
The "fixed_pppd" log showed ICMP negotiation succeeding after only 4 tries
which could occasionally happen without a fix.

The "failure_without_ppp_fix" log shows pppd requesting DNS servers 5
times and then repeatedly requesting only an IP address for itself.
Once it finally gets that IP address it then uses the 10.11.12.1{3,4}
DNS addresses that were always NAKed. Which seems to fit the problem
nicely.

---
1. http://www.archivum.info/linux-***@vger.kernel.org/2008-07/msg09189.html

Cheers-