Bug 496010

Summary: pppd sets Wins servers as DNS servers
Product: [Fedora] Fedora Reporter: Bill Gradwohl <bill>
Component: pppAssignee: Jiri Skala <jskala>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 10CC: aglotov, bugzilla.redhat, jskala, piotr.kral
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-01 07:50:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Here is an example of a connection that worked.
none
Heres one tahat doesn't work none

Description Bill Gradwohl 2009-04-15 23:14:43 UTC 
Description of problem:
My internet connection is via a mobile broadband service.
My laptop is dual boot VISTA & F10 (patched)

When I connect with a VISTA Windows boot, I see the result of the connection via ipconfig /all and note what it says. When I reboot to F10 and get a connection, the DNS is always incorrect. It is using the WINS servers instead of the DNS servers.


Reply With Quote

Version-Release number of selected component (if applicable):


How reproducible:
Allow NetworkManager to connect to a GSM broadband connection where the ISP has defined WINS servers as part of his DHCP setup.

Steps to Reproduce:
1.
2.
3.
  
Actual results:
Here is a sample from /var/log/messages

Mar 11 07:48:48 billlaptop pppd[12475]: Plugin /usr/lib64/pppd/2.4.4/nm-pppd-plugin.so loaded.
Mar 11 07:48:48 billlaptop pppd[12475]: pppd 2.4.4 started by root, uid 0
Mar 11 07:48:48 billlaptop pppd[12475]: Using interface ppp0
Mar 11 07:48:48 billlaptop pppd[12475]: Connect: ppp0 <--> /dev/ttyUSB0
Mar 11 07:48:48 billlaptop NetworkManager: <info> (ttyUSB0): device state change: 5 -> 6
Mar 11 07:48:48 billlaptop pppd[12475]: CHAP authentication succeeded
Mar 11 07:48:48 billlaptop pppd[12475]: CHAP authentication succeeded
Mar 11 07:48:48 billlaptop NetworkManager: <info> (ttyUSB0): device state change: 6 -> 7
Mar 11 07:48:55 billlaptop pppd[12475]: Could not determine remote IP address: defaulting to 10.64.64.64
Mar 11 07:48:55 billlaptop pppd[12475]: local IP address 10.247.196.216
Mar 11 07:48:55 billlaptop pppd[12475]: remote IP address 10.64.64.64
Mar 11 07:48:55 billlaptop pppd[12475]: primary DNS address 10.11.12.13
Mar 11 07:48:55 billlaptop pppd[12475]: secondary DNS address 10.11.12.14

Under Windows, the DNS info specifies the real DNS servers. Under F10 I always get the ISP's WINs servers instead. When I manually fix /etc/resolv.conf everything works as expected, but the ISP changes the DNS settings frequently, so periodically I have to boot VISTA to see what they are today and then reboot to F10 and patch resolv.conf . I had the same issue with F9.


Expected results:


Additional info:
Comment 1 Bill Gradwohl 2009-04-17 13:44:47 UTC 
As root, 

Did :
echo 'debug' >>/etc/ppp/options 
and had Network manager disconnect the connection.

Checked, via 
ps -ef|grep pppd 
and pppd was not loaded.

Had Network Manager attempt a reconnect.

WHOLE BOX LOCKED UP. Another box monitoring this one via a ping and ssh session confirmed that the box was hard hung. Had to power down the box.

BTW I believe the box locking up after I added the debug option is pure coincidence. The box has locked up on me numerous times before I touched anything. 
It appears that if I ask for a connect about 3 times and it fails (that's why I keep asking for a connect) on the 3rd time it will lock up hard. The icon showing green dots with the blue swirl stops moving, and music I have playing gets stuck like an old broken record. The same few notes keep playing over and over again. The box is hung, but somehow music still manages to play about a 1 second fragment of a song repeatedly. Maybe that's a pure hardware thing. I mention it in case its important.

After power up I had Network Manager connect.
Looked in /var/log/messages and found no debug info. Obviously adding debug to the options file had no effect. THAT IS A PROBLEM IN ITSELF.

Did:
echo 'logfile /var/log/pppd.log' >>/etc/ppp/options 
touch /var/log/pppd.log

Had Network Manager disconnect & reconnect.
Now I had debug info in /var/log/pppd.log as follows:

Plugin /usr/lib64/pppd/2.4.4/nm-pppd-plugin.so loaded.
using channel 3
Using interface ppp0
Connect: ppp0 <--> /dev/ttyUSB0
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x65af42b9> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x6 <asyncmap 0x0> <auth chap MD5> <magic 0xf46708> <pcomp> <accomp>]
sent [LCP ConfAck id=0x6 <asyncmap 0x0> <auth chap MD5> <magic 0xf46708> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x65af42b9> <pcomp> <accomp>]
rcvd [LCP DiscReq id=0x7 magic=0xf46708]
rcvd [CHAP Challenge id=0x1 <76c2e3bb5831f465b2bcd382388d091b>, name = "UMTS_CHAP_SRVR"]
sent [CHAP Response id=0x1 <bd2508290b7d400cea5600f1ff90e91a>, name = ""]
rcvd [CHAP Success id=0x1 ""]
CHAP authentication succeeded
CHAP authentication succeeded
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15>]
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
rcvd [LCP ProtRej id=0x8 80 fd 01 01 00 0c 1a 04 78 00 18 04 78 00]
Protocol-Reject for 'Compression Control Protocol' (0x80fd) received
rcvd [IPCP ConfNak id=0x1 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
rcvd [IPCP ConfNak id=0x2 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x3 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
rcvd [IPCP ConfNak id=0x3 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x4 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
rcvd [IPCP ConfNak id=0x4 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x5 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
rcvd [IPCP ConfNak id=0x5 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x6 <compress VJ 0f 01> <addr 0.0.0.0>]
rcvd [IPCP ConfNak id=0x6 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x7 <compress VJ 0f 01> <addr 0.0.0.0>]
rcvd [IPCP ConfReq id=0x2]
sent [IPCP ConfNak id=0x2 <addr 0.0.0.0>]
rcvd [IPCP ConfRej id=0x7 <compress VJ 0f 01>]
sent [IPCP ConfReq id=0x8 <addr 0.0.0.0>]
rcvd [IPCP ConfReq id=0x3]
sent [IPCP ConfAck id=0x3]
rcvd [IPCP ConfNak id=0x8 <addr 10.247.228.77>]
sent [IPCP ConfReq id=0x9 <addr 10.247.228.77>]
rcvd [IPCP ConfAck id=0x9 <addr 10.247.228.77>]
Could not determine remote IP address: defaulting to 10.64.64.64
local  IP address 10.247.228.77
remote IP address 10.64.64.64
primary   DNS address 10.11.12.13
secondary DNS address 10.11.12.14
Script /etc/ppp/ip-up started (pid 6009)
Script /etc/ppp/ip-up finished (pid 6009), status = 0x0


I don't understand the conversation, but I know Windows Vista can extract the DNS from the ISP. 

Is it possible the wrong question is being asked? 
Why is the same question (sent) being asked numerous times? 
I can see the original question (sent) has 'ms-dns1' & 'ms-dns3' in it. 
What happened to 'ms-dns2'?
Should the question not include the 'ms-' prefix to get the real DNS info?

Observations:

man pppd suggests that info would be written to the main syslog file with the 'debug' option set, and that's not true. It also references /etc/syslog.conf and that file doesn't even exist. I found rsyslog.conf but backed off from touching it.

The docs need work.
Comment 2 Bill Gradwohl 2009-05-14 15:27:55 UTC 
Created attachment 343990 [details]
Here is an example of a connection that worked.

All of a sudden the error went away for a few days, and here is an example of the conversation that worked.

A day later it stopped working again.
Comment 3 Bill Gradwohl 2009-05-14 15:30:15 UTC 
Created attachment 343993 [details]
Heres one tahat doesn't work

A day later it stopped working again.
Comment 4 Piotr 2009-06-19 22:15:26 UTC 
I have similar problem with Fedora 10 and 11 (x86). But in my case it's about 50% chance to get good reslov.conf. I can't find any correlations between good and bad connections.
Comment 5 Jiri Skala 2009-10-01 07:27:00 UTC 
Hi,
first of all I suppose you've installed ppp-2.4.4-11 and the issue occurs on this release. The release 11 contains a fix for bogus DNS.
I'm unable to reproduce the problem but I found info how to fix it.

I'm not sure if the first trick could be helpful but this is only adding one line to options file. Please try use:

"connect-delay 5000" in /etc/ppp/options to fix.

The second I've built scratch build of ppp with an extension in the bogus DNS patch applied in rel. 11. That is reachable on:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1721764

Let me know results of both solution. If the first one will work It would be fine to avoid adding additional patch.

Thank you

Jiri
Comment 6 Jiri Skala 2009-10-01 07:50:23 UTC 

*** This bug has been marked as a duplicate of bug 467004 ***
Comment 7 Bill Gradwohl 2009-10-05 12:49:50 UTC 
I added the delay line to options and will see what happens. 

In the last few months since I started this incident, this hasn't been a problem as often. Now I get real servers more often than not, so its going to take some time before I can guestimate if this option trick works.