Re: GPRS and bad DNS servers like 10.11.12.13
Mikko Rapeli
> A Google search for "GPRS PPP DNS 10.11.12.13" yielded this:
>
> http://www.archivum.info/linux-...@vger.kernel.org/2008-07/msg00238.html
>
> 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
> poster to see why:
>
> http://www.archivum.info/linux-...@vger.kernel.org/2008-07/msg09189.html
>
> 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
> 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
> 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.
> 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
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.
> 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
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-
--
Clifford Kite