Re: [homenet] [Babel-users] Detecting bridges

"STARK, BARBARA H" <> Thu, 17 December 2015 16:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CF9351A21C0 for <>; Thu, 17 Dec 2015 08:11:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7r-ZkR2YQEvr for <>; Thu, 17 Dec 2015 08:11:06 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E8CB1B2F21 for <>; Thu, 17 Dec 2015 08:11:06 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id tBHG9pHd003415; Thu, 17 Dec 2015 11:11:05 -0500
Received: from ( []) by with ESMTP id 1ytsjgj8ch-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 17 Dec 2015 11:11:04 -0500
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id tBHGB26x022474; Thu, 17 Dec 2015 11:11:03 -0500
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id tBHGApBw022342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 17 Dec 2015 11:10:57 -0500
Received: from ( []) by (RSA Interceptor); Thu, 17 Dec 2015 16:10:37 GMT
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Thu, 17 Dec 2015 11:10:37 -0500
To: Juliusz Chroboczek <>, Dave Taht <>
Thread-Topic: [homenet] [Babel-users] Detecting bridges
Thread-Index: AQHROCOHFfH7u4YUEkeE6QhmdWvwNZ7PUf0A
Date: Thu, 17 Dec 2015 16:10:37 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-17_02:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310007 definitions=main-1512170267
Archived-At: <>
Cc: "" <>, "" <>, Mikael Abrahamsson <>
Subject: Re: [homenet] [Babel-users] Detecting bridges
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Homenet WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Dec 2015 16:11:11 -0000

> Homenet, the issue we're dealing with is that babeld performs badly when
> there is a transparent wireless bridge connected to a wired interface: the
> interface is treated as a lossless wired interface, and if it suffers packet loss,
> there is repeated link flapping.  

I've had a lot of experience with trying to use both Wi-Fi and powerline bridges. Powerline bridges can suffer from a lot of the same flapping as Wi-Fi. 
I'm aware of an IPTV provider who experimented with using 802.11-Ethernet bridges to connect set-top boxes (STBs) to the router. They wanted super-duper good wireless for the STBs, so they used proprietary 802.11-based technology and this 802.11 was dedicated to just the STBs (so it wasn't using the same Wi-Fi as the home network). They ended up building this 802.11 technology into the STBs and into the home router (separate radio from the home Wi-Fi), because the bridged connection just wasn't resilient. I'm also aware of powerline bridges being used in lots of IoT "smart home" deployments. And then there are the powerline to Wi-Fi bridges (Wi-Fi extenders) which I'm seeing more and more of. 

The main problem I've seen with frequently flapping bridges is host IP/Ethernet stacks (where the host -- including router WAN "host" -- thinks it has an Ethernet connection) that give up "quickly" on the connection. Reboots or even just disabling and then enabling the network interface cause the connection to be seen again and IP connectivity re-established. Forced DHCP release/renew doesn't tend to work, which leads me to believe the problem may be in the Ethernet stack, and not with IP and DHCP. I've never bothered trying to figure out the root cause -- instead I just stop using the bridges that don't work, and do something different that does work. I've definitely seen this problem a lot, though.

My take-away from my experiences:
Bridges are incredibly useful -- when they work. The better they work, the more people will use them. Homenets (including hosts) need to be resilient to flapping Ethernet links.
There are host IP/Ethernet interface issues (including router WAN "host") that are prevalent and need to be solved independent of anything Babel does. Issues that cause hosts to decide there is no connectivity on Ethernet links that flap.
The problem is not limited to Wi-Fi bridges. It also exists on powerline.
I'm curious as to the prevalence of LLDP in bridges. If LLDP is being included in bridges, it could be used to detect them. Hmm. I should try to find out.
I don't know right now what the right answer is for Babel.