Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Alex Hulse <ah@amch.net>
To: Phil Pennock <cerowrt-devel+phil@spodhuis.org>
Cc: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] MacBook Pro (Snow Leopard) constantly renaming
Date: Sun, 3 Feb 2013 11:34:42 +0000	[thread overview]
Message-ID: <90C20247-4E2C-4AA3-98CF-8F82B9806209@amch.net> (raw)
In-Reply-To: <20130202015228.GA6468@redoubt.spodhuis.org>

Hi there

A while ago this problem was reported as happening and it was decided that it is to be blamed on avahi and the reflector functionality in it. I think Dave said that the bug had been reported but that nothing had been done about it upstream - I looked but couldn't find a specific bug on avahi's trac.

When I had a cero like set up with plain openwrt (routed rather than bridged) with avahi running I had the same happen to my apple devices (iMac, MacBook, airport express, time capsule and appletv). I think this points to something "wrong" in avahi's implementation of the spec or an apple specific (but not device specific) quirk in handling it. 

Alex

On 2 Feb 2013, at 01:52, Phil Pennock <cerowrt-devel+phil@spodhuis.org> wrote:

> On 2013-02-01 at 16:22 -0500, William Allen Simpson wrote:
>> Anyway, it's probably a simple bug where they don't properly
>> check the MAC address as they decide whether a machine of the
>> same name is already present on the lan.  If anybody has an
>> idea where to look, I'll try fixing it.
> 
> Something is re-broadcasting the announcements back onto a network.
> 
> I wasn't involved in diagnosis, so going from what I was told: At work,
> they had this exact same problem in the SF office and they discovered
> that Sonos music players automatically bridge together any networks they
> find and join, so there's a bridge built into a player device, which
> caused packets from MacOS on wifi to go out on wifi, be bridged onto the
> wired VLAN on the Sonos, then come back into the laptops; from this, it
> seems it would only affect machines plugged into a wired network.
> 
> (At which point, one of them suddenly remembered that $previous_employer
> had banned these devices and now knew why).
> 
> Something similar may be happening?
> 
> -Phil
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

      parent reply	other threads:[~2013-02-03 11:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-01 21:22 William Allen Simpson
2013-02-02  1:52 ` Phil Pennock
2013-02-02 19:20   ` William Allen Simpson
2013-02-03 11:34   ` Alex Hulse [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=90C20247-4E2C-4AA3-98CF-8F82B9806209@amch.net \
    --to=ah@amch.net \
    --cc=cerowrt-devel+phil@spodhuis.org \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox