John Hawkinson writes:
> Huh? That's not how it works.

I don't know for sure, but that was the case when I run the tcpdump.
All packets ware sent to the base station, and it forward it then back
to the wireless network or ethernet depending where the other wireless
node was. 

> If you could show traces that demonstrate this behavior, that would
> be best... 

I cannot demonstrate this now, but I can demostrate duplicate packets
when I turn on the promiscuous mode:

One one window:
----------------------------------------------------------------------
kaakeli (2:07) ~>ping x46
PING x46.portalify.fi (212.16.98.46): 56 data bytes
64 bytes from 212.16.98.46: icmp_seq=0 ttl=255 time=3.576 ms
64 bytes from 212.16.98.46: icmp_seq=1 ttl=255 time=3.640 ms
64 bytes from 212.16.98.46: icmp_seq=2 ttl=255 time=3.602 ms
64 bytes from 212.16.98.46: icmp_seq=3 ttl=255 time=3.633 ms
64 bytes from 212.16.98.46: icmp_seq=4 ttl=255 time=3.601 ms
64 bytes from 212.16.98.46: icmp_seq=5 ttl=255 time=3.623 ms
64 bytes from 212.16.98.46: icmp_seq=6 ttl=255 time=3.628 ms
64 bytes from 212.16.98.46: icmp_seq=7 ttl=255 time=3.644 ms
64 bytes from 212.16.98.46: icmp_seq=8 ttl=255 time=3.622 ms
64 bytes from 212.16.98.46: icmp_seq=9 ttl=255 time=2.988 ms
64 bytes from 212.16.98.46: icmp_seq=9 DUP! ttl=255 time=3.648 ms
64 bytes from 212.16.98.46: icmp_seq=10 ttl=255 time=2.967 ms
64 bytes from 212.16.98.46: icmp_seq=10 DUP! ttl=255 time=3.632 ms
64 bytes from 212.16.98.46: icmp_seq=11 ttl=255 time=2.972 ms
64 bytes from 212.16.98.46: icmp_seq=11 DUP! ttl=255 time=3.643 ms
64 bytes from 212.16.98.46: icmp_seq=12 ttl=255 time=3.004 ms
64 bytes from 212.16.98.46: icmp_seq=12 DUP! ttl=255 time=3.659 ms
64 bytes from 212.16.98.46: icmp_seq=13 ttl=255 time=3.646 ms
64 bytes from 212.16.98.46: icmp_seq=14 ttl=255 time=3.647 ms
^C
----x46.portalify.fi PING Statistics----
15 packets transmitted, 15 packets received, +4 duplicates, 0.0% packet loss
round-trip min/avg/max/stddev = 2.967/3.493/3.659/0.272 ms
kaakeli (2:07) ~>
----------------------------------------------------------------------
And on the another window:
----------------------------------------------------------------------
kaakeli (2:07) ~>sudo tcpdump -i wi0 -e -vv -n
tcpdump: listening on wi0
02:07:50.080257 0:60:1d:f6:32:db 0:60:1d:f6:34:86 0800 98: 212.16.98.48 > 212.16.98.46: icmp: echo request (ttl 255, id 33204)
02:07:50.081844 0:60:1d:f6:32:db 0:60:1d:f6:34:86 0800 98: 212.16.98.48 > 212.16.98.46: icmp: echo request (ttl 255, id 33204)
02:07:50.082977 0:60:1d:f6:34:86 0:60:1d:f6:32:db 0800 98: 212.16.98.46 > 212.16.98.48: icmp: echo reply (ttl 255, id 13526)
02:07:50.083633 0:60:1d:f6:34:86 0:60:1d:f6:32:db 0800 98: 212.16.98.46 > 212.16.98.48: icmp: echo reply (ttl 255, id 13526)
02:07:50.692759 0:0:c0:15:fa:f8 0:60:1d:f6:32:db 0800 142: 193.64.193.124.22 > 212.16.98.48.65513: P 3957006394:3957006470(76) ack 92254667 win 17520 <nop,nop,timestamp 37427213 73992> (ttl 56, id 287)
02:07:50.732103 0:60:1d:f6:32:db 0:0:c0:15:fa:f8 0800 66: 212.16.98.48.65513 > 193.64.193.124.22: . [tcp sum ok] ack 76 win 17520 <nop,nop,timestamp 74048 37427213> (ttl 64, id 33205)
02:07:50.863205 0:0:c0:15:fa:f8 0:60:1d:f6:32:db 0800 126: 193.64.193.124.22 > 212.16.98.48.65513: P 76:136(60) ack 1 win 17520 <nop,nop,timestamp 37427214 73992> (ttl 56, id 293)
02:07:50.930182 0:60:1d:f6:32:db 0:0:c0:15:fa:f8 0800 66: 212.16.98.48.65513 > 193.64.193.124.22: . [tcp sum ok] ack 136 win 17520 <nop,nop,timestamp 74048 37427214> (ttl 64, id 33206)
02:07:51.080234 0:60:1d:f6:32:db 0:60:1d:f6:34:86 0800 98: 212.16.98.48 > 212.16.98.46: icmp: echo request (ttl 255, id 33208)
02:07:51.081824 0:60:1d:f6:32:db 0:60:1d:f6:34:86 0800 98: 212.16.98.48 > 212.16.98.46: icmp: echo request (ttl 255, id 33208)
02:07:51.082958 0:60:1d:f6:34:86 0:60:1d:f6:32:db 0800 98: 212.16.98.46 > 212.16.98.48: icmp: echo reply (ttl 255, id 13527)
02:07:51.083616 0:60:1d:f6:34:86 0:60:1d:f6:32:db 0800 98: 212.16.98.46 > 212.16.98.48: icmp: echo reply (ttl 255, id 13527)
02:07:51.536848 0:3:6b:c5:18:11 1:80:c2:0:0:0 0026 52: sap 42 ui/C len=35
                         0000 0000 0080 0000 036b c518 0e00 0000
                         0080 0000 036b c518 0e80 1f00 0014 0002
                         000f 00
02:07:52.080244 0:60:1d:f6:32:db 0:60:1d:f6:34:86 0800 98: 212.16.98.48 > 212.16.98.46: icmp: echo request (ttl 255, id 33210)
02:07:52.081826 0:60:1d:f6:32:db 0:60:1d:f6:34:86 0800 98: 212.16.98.48 > 212.16.98.46: icmp: echo request (ttl 255, id 33210)
02:07:52.082961 0:60:1d:f6:34:86 0:60:1d:f6:32:db 0800 98: 212.16.98.46 > 212.16.98.48: icmp: echo reply (ttl 255, id 13528)
02:07:52.083625 0:60:1d:f6:34:86 0:60:1d:f6:32:db 0800 98: 212.16.98.46 > 212.16.98.48: icmp: echo reply (ttl 255, id 13528)
^C
24 packets received by filter
0 packets dropped by kernel
kaakeli (2:07) ~>
----------------------------------------------------------------------

So immediately when I start tcpdump I will see duplicate packets
coming to me. I have interpreted this so that when I turn on
promiscuous mode I see both the x46 sending packet to base station and
the base station sending it back to me, thus I see two packets instead
of only one.

The ethenet hardware addresses still seem to be ours, i.e I cannot see
the base station there at all. The base station is Apple Airport.

I think that before I have also seen the hardware address of the base
station there, but then the airport was configured to do NAT and etc,
thus it might change things.
-- 
kivinen@ssh.fi                               Work : +358 303 9870
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/