Article View: chi.internet
Article #77Re: MacBook weidness
From: smr
Date: Thu, 21 Feb 2013 18:03
Date: Thu, 21 Feb 2013 18:03
88 lines
5670 bytes
5670 bytes
On Thu, 21 Feb 2013 12:52:48 -0500, Mark Anderson wrote: > In article bje@ripco.com says... >> >> Mark Anderson <mea@nospambradnylion.com> wrote: >> >>> I am now a bit more curious thus this post. >> >> "The reason why it's sending the query over and over is because the DNS >> server is returning a DNS response of RCODE: 2 (ServFail), which is not a >> normal response. It indicates a server misconfiguration. If the server were >> to return the standard RCODE: 3 (NXDOMAIN) response, then mDNSResponder >> would stop sending queries. It's still a bug in mDNSResponder that it's not >> handling the ServFail very well, but it explains why only a few people are >> seeing this issue. Most people have DNS servers that return NXDOMAIN as the >> response." >> >> It seems this bug comes up with various updates to OSX. > > I went over the traces again and these devices aren't attempting any > normal DNS. They get an IP from my DHCP server and then they instantly > start into IPv6 MDNS broadcasts which goes to every device that happened > to be connected at the time. Every now and then they'll dump a cache > flush which is how I know that one device was my neighbor's because her > computer name got dumped. I see no normal traffic from anyone once the > blasts start and in short time my server shuts off the interface for > protection (my code). > > A typical set of packet broadcasts look like this: > > 16:41:00.517556 60:33:4b:0a:8d:6d > 33:33:00:00:00:fb, ethertype IPv6 > (0x86dd), length 276: fe80::6233:4bff:fe0a:8d6d.mdns > ff02::fb.mdns: 0 > [2a] [6q] PTR (QM)? _apple-mobdev._tcp.local. PTR (QM)? _afpovertcp. > _tcp.local. PTR (QM)? _smb._tcp.local. PTR (QM)? _rfb._tcp.local. PTR > (QM)? _adisk._tcp.local. PTR (QM)? _airport._tcp.local. (214) > > 16:41:00.517611 60:33:4b:0a:8d:6d > 33:33:00:00:00:fb, ethertype IPv6 > (0x86dd), length 86: fe80::6233:4bff:fe0a:8d6d > ff02::fb: HBH ICMP6, > multicast listener reportmax resp delay: 0 addr: ff02::fb, length 24 > > over and over and over ad infinitum. > > My servers simply ignore this. > >> The simpliest solution it seems is to have only one dns entry on the > macbook >> for the dns resolvers. With only one entry it'll time out even with the >> servfail being returned. > > So it does sound like there may be something funny in the MacBook > network stacks. > >> I dunno what you are doing with this network, handing out free wifi or >> whatever, but changing the dhcp configuration so the connecting computers >> only get one dns server should work also. > > I do only give out one dns server IP in DHCP and I block all attempts to > use an outside dns. They must use my dns server. It is funny how some > devices try and try to use their own only to succumb to the Borg. The > bug here is in the MacBook's IPv6 stack and how they deal with mdns. I > heard Apple is big into MDNS whereas other device manufacturers don't > use it that much if at all. > > As for giving out free wifi, I'm giving out free wifi much like Facebook > gives out "free" web services. The devices that connect to my network > unknowingly test various software I'm working on and contribute > analytics for my study. The bandwidth they use is rather trivial since > I turn off Netflix streaming (a huge BW hog) and the well known porn > streaming sites like xvideo.com and xhamster.com. Once porno addicts > get wind of free streaming my network will get overloaded with perverts > so I shut it off. Last year I had 1200 unique visitors averaging around > 250 unique visitors per month. Lots of regulars and the number of > tablets connecting is through the roof now. > > My network is fairly secure from p2p abuse and other tom foolery but > it's still a work in progress. At first I thought these mdns blasts > were malicious but now not so much. I wonder how open wifis at places > like Starbucks and McDonalds deal with these kind of situations since > these blasts will bring down any open wifi. Maybe they have access > points that can deal with this -- I don't know. They deal with it by not having morons such as Mark Anderson design the wifi network in the first place. This is seriously one of the dumbest fucking things I've ever heard of. -- smr
Technical Details
Message-ID:
<7p7c5v1qg1qu.148l7etp0ylk0$.dlg@40tude.net>Path:
arc1-ca.pugleaf.net!jm3ni12353pbb.0!nntp.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!news.ripco.com!not-for-mailReferences:
<MPG.2b8f65ac3d0bcab3989a89@news.speakeasy.net> <kg560r$r2l$1@remote5bge0.ripco.com> <MPG.2b9028ff74163f5e989a8a@news.speakeasy.net>Show Full Headers
Complete Article Headers
X-Google-Thread: 10d5fa,4161bdfa34ad1ceb
X-Google-NewGroupId: yes
X-Google-Attributes: gid837b0c45a0,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
X-Received: by 10.66.227.7 with SMTP id rw7mr3591144pac.19.1361470201837;
Thu, 21 Feb 2013 10:10:01 -0800 (PST)
Path: arc1-ca.pugleaf.net!jm3ni12353pbb.0!nntp.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!news.ripco.com!not-for-mail
From: smr <me@shawnritchie.com>
Newsgroups: chi.internet
Subject: Re: MacBook weidness
Date: Thu, 21 Feb 2013 12:03:12 -0600
Organization: ftupet.com
Lines: 88
Message-ID: <7p7c5v1qg1qu.148l7etp0ylk0$.dlg@40tude.net>
References: <MPG.2b8f65ac3d0bcab3989a89@news.speakeasy.net> <kg560r$r2l$1@remote5bge0.ripco.com> <MPG.2b9028ff74163f5e989a8a@news.speakeasy.net>
NNTP-Posting-Host: ftupet.com
Mime-Version: 1.0
X-Trace: remote5bge0.ripco.com 1361470201 10932 66.246.138.5 (21 Feb 2013 18:10:01 GMT)
X-Complaints-To: usenet@ripco.com
NNTP-Posting-Date: Thu, 21 Feb 2013 18:10:01 +0000 (UTC)
User-Agent: 40tude_Dialog/2.0.15.1
Bytes: 5242
X-Received-Bytes: 5290
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit