Bug 1777

Summary:	TapBridge address learning patch
Product:	ns-3	Reporter:	Tom Henderson <tomh>
Component:	tap-bridge	Assignee:	Tom Goff <tgoff>
Status:	RESOLVED FIXED
Severity:	enhancement	CC:	ns-bugs
Priority:	P5
Version:	pre-release
Hardware:	PC
OS:	Linux
Attachments:	Modified patch Updated patch

Description Tom Henderson 2013-10-20 09:44:26 UTC

From Piotr Jurkiewicz's email to ns-developers:

Theoretical model:
As defined in model description, TapBridge has three operating modes: ConfigureLocal, UseLocal and UseBridge. The modes are different in details regarding how the arrangement is created and configured. In ConfigureLocal mode ns-3 takes responsibility for configuring Linux tap interface (and particularly its MAC address). In UseBridge and UseLocal modes the TapBridge adapts to the configuration of existing tap interface. Particularly, it should take MAC address of the tap interface and set (inside ns-3) address of bridged ns-device to the same address.

This model is well defined and consistent. However, current implementation does not follow that model strictly, what causes some problems.

Current implementation:
In UseLocal mode there is implemented MAC learning functionality (tapbridge.cc lines 734-744). TapBridge basically waits for the first packet received from tap interface and sets address of the bridged device to the source address of the first packet. Such an unnatural approach leads to the problems, for example with WiFi connectivity.

Sta device is bridged with TapBridge. In Infrastructure mode, Sta starts association with the Ap immediately after simulator start up. As there have been no packets received from tap interface yet, Sta device still has the default MAC address. It associates with that address to the Ap. When first packet from tap interface appears, TapBridge changes Sta device address to the new one. From that point, Sta device sends packets with the new source address. However, Ap is associated with the old address and silently drops packets from the new address. Despite that, Sta device continuously thinks that it is associated and consequently sends packets.

In UseBridge mode there is no implemented MAC learning functionality at all. Bridged device stays with the default address. So, despite "Use" term in the mode name, that mode does not use existing interface address.

Proposed patch:
This patch implements the more direct way of "using" configuration of existing tap interface: after connection to the tap interface, ns-3 obtains MAC address of that interface with system call and immediately sets address of the bridged device to the obtained one. This approach:
- solves WiFi connectivity problem (new address is set before association start)
- can be used in UseBridge mode too, without any changes
- follows strictly theoretical model
- is more natural

The patch is available here:
http://gist.github.com/piotrjurkiewicz/6067858

Comment 1 Tom Goff 2013-10-27 22:38:03 UTC

Created attachment 1690 [details]
Modified patch

I agree with the suggested changes but think the proposed patch can be
improved.  The attached version includes the following modifications:

 - maintain the current for-loop logic in CreateTap() where all
   ancillary data is considered

 - prefer AF_INET to PF_INET

 - check that socket() succeeds

 - prefer strncpy to strcpy

 - use Mac48Address::CopyFrom() instead of an intermediate string
   representation

 - close the socket file descriptor when done

 - include an error message if finding the mac address fails

 - leave the SetAddress() logic in ForwardToBridgedDevice() unchanged
   in case setting the mac address from CreateTap() fails for some
   reason

 - some style nits and trailing whitespace removed

It also remove comments related to NO_CREATOR because it doesn't seem
to be currently supported.  This could be a separate patch.

Comment 2 Tom Goff 2013-10-29 01:45:15 UTC

Created attachment 1692 [details]
Updated patch

This is a slightly simplified version of the previous patch that uses
the existing unix domain socket instead of opening a new socket.

It also closes the unix domain socket when done.

Comment 3 Tom Henderson 2013-11-19 12:35:05 UTC

pushed in changeset:  10432:7a23bec8c567