Created attachment 3100 [details]
A mercurial diff that fixes the issue described.

The UseLocal mode of ns-3's TapBridge, according to its source-code comment, applies to set-ups where "we have got to USE a pre-created tap device that will have a different MAC address from the ns-3 net device. In this case we will be spoofing the MAC address of a received packet to match the single allowed address on the Linux side".
As it is right now, the UseLocal mode is broken and will not use correct MAC address from a received packet in most cases, but the MAC address of the host-side TAP device instead.
Please find attached a one-line patch that fixes the problem.
Below, you find a detailed description of the issue and proposed fix.

A typical network set-up that requires UseLocal mode is emulated nodes in virtual machines communicate over a wireless channel that is managed by ns-3 (e.g., OLSR in LXC containers).
In such scenarios, a pre-configured Linux bridge connects two Linux TAP devices, one on the host side (where ns-3 runs) and one on the VM side (where the emulated protocols runs).
It is crucial that the ns-3 NetDevice uses the MAC address of the VM-side TAP device, otherwise MAC-layer acknowledgments will not be sent as the wrong MAC addresses are used in traffic (*).
Since the VM-side MAC address is hard to determine for the ns-3 process, the UseLocal mode uses the source MAC address of the first packet received by the tap bridge as the ns-3 device's MAC address.
The existing source file tap-bridge.cc contains that logic in lines 755 to 765.
However, that logic is usually never executed as another part in the code is invoked prior and sets the ns-3 device's MAC address to the host-side MAC address (lines 635 to 660).
The patch disables that other part's execution specifically for UseLocal mode, thereby re-enabling the already-existing logic to use the first-received packet's MAC address for the ns-3 device.

In an LXC+OLSR wireless test scenario, we could observe in PCAP traces that with the patch, MAC layer acknowledgments are sent indeed and all src/dst/ARP content MAC addresses mirror the VM-side addresses.
As a consequence, in our test scenario packet delivery rates increased from approximately 5% to more than 70% with the patch, thereby more closely resembling the ns-3 model performance (without a TapBridge, in a similar scenario).

(*) Packets will, more by accident than by design, still be received as the Linux tap bridge and ns-3 devices are by default set to promiscuous mode.