1094287 - Mis-configured DHCP server in MTV Mozilla WiFi

Status: RESOLVED INVALID

(Infrastructure & Operations Graveyard :: NetOps: Office Wireless, task)

Description

[Nils Ohlmeier [:drno]]

When I opened my MacBook Pro this morning it connected to the Mozilla WiFi in MTV just fine. But I got these values assigned:

/etc/resolv.conf
...
domain corp.mtv2.mozilla.com
nameserver 10.0.1.1

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether b8:e8:56:2d:3d:96 
	inet6 fe80::bae8:56ff:fe2d:3d96%en0 prefixlen 64 scopeid 0x4 
	inet6 2620:101:80fc:224:bae8:56ff:fe2d:3d96 prefixlen 64 autoconf 
	inet6 2620:101:80fc:224:f9d4:53e9:9394:36ff prefixlen 64 autoconf temporary 
	inet 10.252.27.142 netmask 0xfffff800 broadcast 10.252.31.255
	nd6 options=1<PERFORMNUD>
	media: autoselect
	status: active

To no one surprise the DNS server at 10.0.1.1 is not reachable and therefore my Internet is/was not working.
I have had this problem already since middle of last week, that some times my Mac shows a proper WiFi symbol, but then the network does not seem to work properly.

BTW after turning the WiFi off and on again I got these values which work just fine:

/etc/resolv.conf
...
search mtv2.mozilla.com
nameserver 10.252.75.5
nameserver 10.252.75.6
nameserver 10.252.75.7

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether b8:e8:56:2d:3d:96 
	inet6 fe80::bae8:56ff:fe2d:3d96%en0 prefixlen 64 scopeid 0x4 
	inet 10.252.27.142 netmask 0xfffff800 broadcast 10.252.31.255
	inet6 2620:101:80fc:224:bae8:56ff:fe2d:3d96 prefixlen 64 autoconf 
	inet6 2620:101:80fc:224:a1a0:3338:7038:8c0e prefixlen 64 autoconf temporary 
	nd6 options=1<PERFORMNUD>
	media: autoselect
	status: active

Comment 1

[James Barnell [:jbarnell]]

looking at this but I'm not seeing a whole lot.  If you get a chance can you turn off wifi and turn it on.  If this happens again open a terminal window and type in the following command:  ipconfig getpacket en0.  Can you paste the output from the command or the lines labeled:


server_identifier (ip): 
domain_name_server (ip_mult):
ciaddr = 
yiaddr =

Comment 2

[Nils Ohlmeier [:drno]]

It happened this morning again. But from the debugging I did this morning it appears more likely that this is not caused by a rouge DHCP server, but instead some timing issue when using the Viscosity VPN client and the Mac WiFi over-writing (?) each other the /etc/resolv.conf?!

ipconfig getpacket en0
op = BOOTREPLY
htype = 1
flags = 0
hlen = 6
hops = 1
xid = 3287902690
secs = 4
ciaddr = 0.0.0.0
yiaddr = 10.252.28.40
siaddr = 0.0.0.0
giaddr = 10.252.24.1
chaddr = b8:e8:56:2d:3d:96
sname = 
file = 
options:
Options count is 9
dhcp_message_type (uint8): ACK 0x5
server_identifier (ip): 10.252.75.7
lease_time (uint32): 0xe10
subnet_mask (ip): 255.255.248.0
router (ip_mult): {10.252.24.1}
domain_name_server (ip_mult): {10.252.75.5, 10.252.75.6, 10.252.75.7}
domain_name (string): corp.mtv2.mozilla.com
domain_search (dns_namelist): {mtv2.mozilla.com}
end (none): 
nohlmeier-19930:mozilla-central nohlmeier$ dig cnn.com

; <<>> DiG 9.8.3-P1 <<>> cnn.com
;; global options: +cmd
;; connection timed out; no servers could be reached
nohlmeier-19930:mozilla-central nohlmeier$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=47 time=25.477 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=47 time=25.273 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=47 time=34.705 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=47 time=25.387 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=47 time=25.003 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=47 time=27.720 ms
^C
--- 8.8.8.8 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 25.003/27.261/34.705/3.449 ms
nohlmeier-19930:mozilla-central nohlmeier$ dig @10.252.75.5 cnn.com

; <<>> DiG 9.8.3-P1 <<>> @10.252.75.5 cnn.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32627
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;cnn.com.			IN	A

;; ANSWER SECTION:
cnn.com.		300	IN	A	157.166.226.26
cnn.com.		300	IN	A	157.166.226.25

;; AUTHORITY SECTION:
cnn.com.		73432	IN	NS	ns2.p42.dynect.net.
cnn.com.		73432	IN	NS	ns1.timewarner.net.
cnn.com.		73432	IN	NS	ns3.timewarner.net.
cnn.com.		73432	IN	NS	ns1.p42.dynect.net.

;; ADDITIONAL SECTION:
ns1.timewarner.net.	73433	IN	A	204.74.108.238
ns3.timewarner.net.	73433	IN	A	199.7.68.238
ns2.p42.dynect.net.	73433	IN	A	204.13.250.42
ns1.p42.dynect.net.	73433	IN	A	208.78.70.42

;; Query time: 8 msec
;; SERVER: 10.252.75.5#53(10.252.75.5)
;; WHEN: Thu Nov 13 10:57:03 2014
;; MSG SIZE  rcvd: 218
nohlmeier-19930:mozilla-central nohlmeier$ cat /etc/resolv.conf 
#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
domain corp.mtv2.mozilla.com
nameserver 10.0.1.1

Comment 3

[Nils Ohlmeier [:drno]]

James I had the problem again. Meanwhile I figured out that the DNS server in /etc/resolv.conf is actually the DNS resolver in my home WiFi. Strangely the search domain properly gets updated to the mozilla domain. But I think this looks really more like a Yosemite WiFi/DHCP problem where it under some bizarre circumstances only updates the DNS search domain, but "forgets" to replace the name servers in /etc/resolv.conf

Comment 4

[Nils Ohlmeier [:drno]]

I had the issue happening at home where Mac OSX remembered the DNS from the previous WiFi network. So it is an Mac OSX Yosemite issue and not related to the Mozilla WiFi's.