Bug 547999 - NetworkManager always gets nameserver 4.2.2.1/4.2.2.2 for broadband mobile connection
NetworkManager always gets nameserver 4.2.2.1/4.2.2.2 for broadband mobile co...
Status: CLOSED DUPLICATE of bug 467004
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
12
All Linux
low Severity high
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-16 05:18 EST by Miroslav Pragl
Modified: 2010-01-31 13:26 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 467004
Environment:
Last Closed: 2009-12-16 13:15:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Miroslav Pragl 2009-12-16 05:18:41 EST
Description of problem:
NetworkManager gets incorrect nameservers although pppd reports reasonable ones

Version-Release number of selected component (if applicable):
ppp-2.4.4-13.fc12.x86_64
NetworkManager-0.7.996-7.git20091113.fc12.x86_64

How reproducible:
daling mobile broadband (*99)

Steps to Reproduce:
1. just dial
2.
3.
  
Actual results:
/etc/resolv.conf:
# Generated by NetworkManager
nameserver 4.2.2.1 <--
nameserver 4.2.2.2 <--

Expected results:
according to messages it should be:
...
Dec 16 11:06:31 mirek-nb pppd[3528]: pppd 2.4.4 started by root, uid 0
Dec 16 11:06:31 mirek-nb pppd[3528]: Using interface ppp0
Dec 16 11:06:31 mirek-nb pppd[3528]: Connect: ppp0 <--> /dev/ttyUSB3
Dec 16 11:06:31 mirek-nb pppd[3528]: CHAP authentication succeeded
Dec 16 11:06:31 mirek-nb pppd[3528]: CHAP authentication succeeded
Dec 16 11:06:42 mirek-nb pppd[3528]: Could not determine remote IP address: defaulting to 10.64.64.64
Dec 16 11:06:42 mirek-nb pppd[3528]: local  IP address 85.161.57.218
Dec 16 11:06:42 mirek-nb pppd[3528]: remote IP address 10.64.64.64
Dec 16 11:06:42 mirek-nb pppd[3528]: primary   DNS address 10.11.12.1 <--
Dec 16 11:06:42 mirek-nb pppd[3528]: secondary DNS address 10.11.12.14 <--
...

Additional info:
Comment 1 Dan Williams 2009-12-16 13:15:29 EST
This is because pppd isn't able to get correct nameservers from the 3G stick.

*** This bug has been marked as a duplicate of bug 467004 ***
Comment 2 Uno 2010-01-31 13:26:30 EST
This is not simply a bug. It is a "bug" in security procedures and programming procedures:

1. Security: Faking DNS server data is a very serious thing. This creates great doubt on the security of Fedora (and also Ubuntu, where the same "bug" has suddenly appeared). On whose behalf is this done? Which organization is covertly spying on our DNS lookups and, possibly, forging the responses? I definitely do not want DNS servers in the UK, a foreign NATO country, to be my primary servers (traceroute 4.2.2.1 goes to the UK). 

2. Programming: The DNS server data "4.2.2.1" is not visible to or changeable by the user in any obvious way. In other words, it can be described as placed in the software code in stead of in the configuration data. That is extremely bad programming practise.

As is obvoius from Miroslav Pragl's listing, the correct DNS server data are _definitely_ collected from the "3G stick.

With the same hardware (my 4 laptops and 2 E220 modems and 2 GSM operators) the dual-booting MS Windows XP always gets the correct DNS server data from the modems.

Note You need to log in before you can comment on or make changes to this bug.