Project

General

Profile

Actions

Bug #2055

open

ssh + IPV6 + bridge => connection freezes

Added by steve almost 13 years ago. Updated almost 13 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Hi,

If IPV6 is enabled on a box and a bridge interface is enabled on
the same interface then any ssh connection to the box using the IPv6
address will freeze after a little activity (30 seconds of typing random
commands seems to be enough), bringing the bridge down with ifconfig will
restore activity to the ssh sessions (left alone they time out). I have seen
this with both 32 and 64 bit systems using up to date master code.
I'm also not sure that it's appropriate for a bridge interface to
have an IPv6 link local address - perhaps this is connected.
Actions #1

Updated by dillon almost 13 years ago

: Hi,
:
: If IPV6 is enabled on a box and a bridge interface is enabled on
:the same interface then any ssh connection to the box using the IPv6
:address will freeze after a little activity (30 seconds of typing random
:commands seems to be enough), bringing the bridge down with ifconfig will
:restore activity to the ssh sessions (left alone they time out). I have seen
:this with both 32 and 64 bit systems using up to date master code.
:
: I'm also not sure that it's appropriate for a bridge interface to
:have an IPv6 link local address - perhaps this is connected.
:
:--
:Steve O'Hara-Smith | Directable Mirror Arrays

This is probably an issue with the MAC learning for the bridge.
IPV6 works differently than IPV4, I think the MAC is built into
the IPV6 address and there's no interface ARP (not sure though).
We would need to explicitly support that in the bridge code.
The reason it works for 30-seconds is probably due to the bridge's
auto-learning. When the bridge doesn't know how to route a packet
it basically just broadcasts it. It is probably learning the wrong
thing, thinks it knows how to route the packet, but is not actually
routing it to the right place. You can test this by issuing a bridge
flush command with ifconfig (man bridge), then determine if bridging
works again for a little bit. That isn't optimal since it's
broadcasting in that state, so we will have to figure out the correct
solution.
Another problem is the MAC munging the bridge does.  When you connect
an interface to a bridge all packets sent from that interface use
the bridge's MAC address (otherwise there would be mass confusion).
IPV6 is probably circumventing this by pulling the MAC out of the IPV6
address (which is initially formed using the interface MAC) instead
of using the interface MAC.
-Matt
Matthew Dillon
<>
Actions #2

Updated by steve almost 13 years ago

On Sun, 24 Apr 2011 11:04:30 -0700 (PDT)
Matthew Dillon <> wrote:

: Hi,
:
: If IPV6 is enabled on a box and a bridge interface is enabled on
:the same interface then any ssh connection to the box using the IPv6
:address will freeze after a little activity (30 seconds of typing random
:commands seems to be enough), bringing the bridge down with ifconfig will
:restore activity to the ssh sessions (left alone they time out). I have
seen :this with both 32 and 64 bit systems using up to date master code.
:
: I'm also not sure that it's appropriate for a bridge interface to
:have an IPv6 link local address - perhaps this is connected.
:
:--
:Steve O'Hara-Smith | Directable Mirror Arrays

This is probably an issue with the MAC learning for the bridge.
IPV6 works differently than IPV4, I think the MAC is built into
the IPV6 address and there's no interface ARP (not sure though).

IPv6 has autogenerated addresses (both link local which is always
there - the fe80 ones and global ones issued by something running rtadvd or
similar - but only if rtsold is running) with the MAC embedded in the
address, but you can also use explicitly issued addresses with no relation
to the MAC, which I do for anything I actually want to be able to reach
reliably.

IPv6 uses NDp (Neighbor Discovery Protocol) which looks pretty
complex (five kinds of ICMP involved).
Actions #3

Updated by steve almost 13 years ago

Hi,

Forgot to mention - IPv6 connections to the vkernels attached to
the bridge work fine.

On Sun, 24 Apr 2011 11:04:30 -0700 (PDT)
Matthew Dillon <> wrote:

: Hi,
:
: If IPV6 is enabled on a box and a bridge interface is enabled on
:the same interface then any ssh connection to the box using the IPv6
:address will freeze after a little activity (30 seconds of typing random
:commands seems to be enough), bringing the bridge down with ifconfig will
:restore activity to the ssh sessions (left alone they time out). I have
seen :this with both 32 and 64 bit systems using up to date master code.
:
: I'm also not sure that it's appropriate for a bridge interface to
:have an IPv6 link local address - perhaps this is connected.
:
:--
:Steve O'Hara-Smith | Directable Mirror Arrays

This is probably an issue with the MAC learning for the bridge.
IPV6 works differently than IPV4, I think the MAC is built into
the IPV6 address and there's no interface ARP (not sure though).
We would need to explicitly support that in the bridge code.

The reason it works for 30-seconds is probably due to the bridge's
auto-learning. When the bridge doesn't know how to route a packet
it basically just broadcasts it. It is probably learning the wrong
thing, thinks it knows how to route the packet, but is not actually
routing it to the right place. You can test this by issuing a bridge
flush command with ifconfig (man bridge), then determine if bridging
works again for a little bit. That isn't optimal since it's
broadcasting in that state, so we will have to figure out the correct
solution.

Another problem is the MAC munging the bridge does. When you connect
an interface to a bridge all packets sent from that interface use
the bridge's MAC address (otherwise there would be mass confusion).
IPV6 is probably circumventing this by pulling the MAC out of the IPV6
address (which is initially formed using the interface MAC) instead
of using the interface MAC.

-Matt
Matthew Dillon
<>

Actions

Also available in: Atom PDF