hosts on bridged wlan can not reliably see each other
Randy Bush
randy at psg.com
Sun Jan 4 06:46:25 UTC 2009
On 09.01.04 15:30, Sam Leffler wrote:
> Randy Bush wrote:
>> On 09.01.04 14:20, Sam Leffler wrote:
>>> Randy Bush wrote:
>>>> soekris 5501 of nov 28, pre new arp
>>>>
>>>> problem description
>>>> o all hosts on the wireless can get outside, no problem
>>>> o they can also get to wired devices on vr[1-3]
>>>> o they can reliably not see/ping/... each other on the wireless
>>>> o the soekris can ping them all
>>>> o higher layers are worse
>>>> o the messages on this list worry me about upgrading this week,
>>>> as this is my home gate to the world and somewhat complex
>>>> (bridge, tunnel, pppoe, ...), whereas the mass of servers are
>>>> all pretty straightforward.
>>>>
>>>> .----------------.
>>>> | |
>>>> | b ---ath0| 192.168.0.0/24
>>>> | r |
>>>> ext iij | i --- vr1| LAN hosts,
>>>> PPP/NAT ---|vr0--- d |
>>>> WAN | g --- vr2| DHCP Clients
>>>> | e |
>>>> | 0 --- vr3| pptp 200-209
>>>> | |
>>>> `----------------'
>>>>
>>>> ath0:<Atheros 5212> mem 0xa0010000-0xa001ffff irq 15 at device 17.0 on
>>>> pci0
>>>> ath0: [ITHREAD]
>>>> ath0: WARNING: using obsoleted if_watchdog interface
>>>> ath0: mac 5.9 phy 4.3 radio 3.6
>>>>
>>>> # uname -a
>>>> FreeBSD soek0.psg.com 8.0-CURRENT FreeBSD 8.0-CURRENT #2: Fri Nov 28
>>>> 19:16:10 UTC 2008 root at soek0.psg.com:/usr/obj/usr/src/sys/SOEK0
>>>> i386
>>>>
>>>> wlans_ath0="wlan0 wlan1"
>>>> create_args_wlan0="wlanmode hostap channel 11 ssid rgnet-aden wep wepkey
>>>> arbitrarykeys weptxkey 1 media autoselect mode 11g up"
>>>> cloned_interfaces=bridge0
>>>> ifconfig_bridge0="192.168.0.1 addm vr1 addm vr2 addm vr3 addm wlan0 addm
>>>> wlan1 up"
>>>> ifconfig_vr1=up
>>>> ifconfig_vr2=up
>>>> ifconfig_vr3=up
>>>> gateway_enable=YES
>>>>
>>>> the soekris can see them all
>>>>
>>>> # arp -an
>>>> ? (192.168.0.10) at 00:15:c5:4a:6f:c5 on bridge0 [bridge]
>>>> ? (192.168.0.12) at 00:1e:52:70:b6:36 on bridge0 [bridge]
>>>> ? (192.168.0.13) at 00:15:00:10:ed:09 on bridge0 [bridge]
>>>> ? (192.168.0.17) at 00:0d:65:27:bd:f2 on bridge0 [bridge]
>>>> ? (192.168.0.128) at 00:23:12:fc:39:b9 on bridge0 [bridge]
>>>> ? (192.168.0.129) at 00:23:df:6a:dc:9b on bridge0 [bridge]
>>>>
>>>> and gets log entries of
>>>>
>>>> Jan 2 00:01:09 soek kernel: rtfree: 0xc2e803c0 has 1 refs
>>>> Jan 2 00:01:16 soek kernel: rtfree: 0xc2e80078 has 1 refs
>>>> Jan 2 00:01:16 soek kernel: rtfree: 0xc2e80078 has 1 refs
>>>> Jan 2 00:01:16 soek kernel: arp_proxy: ignoring request from
>>>> 192.168.0.10 via vr2, expecting bridge0
>>>>
>>>> what more should i do to debug?
>>> Use tcpdump to track where the packets are visible. If this is a
>>> wireless issue you will have stats to identify drops as well as the
>>> usual debug facilities.
>> sorry, this is why i was arp conscious
>>
>> soekris# ping 192.168.0.129
>> PING 192.168.0.129 (192.168.0.129): 56 data bytes
>> 64 bytes from 192.168.0.129: icmp_seq=0 ttl=64 time=113.103 ms
>> 64 bytes from 192.168.0.129: icmp_seq=1 ttl=64 time=349.680 ms
>> 64 bytes from 192.168.0.129: icmp_seq=2 ttl=64 time=366.531 ms
>> ^C
>> --- 192.168.0.129 ping statistics ---
>> 3 packets transmitted, 3 packets received, 0.0% packet loss
>> round-trip min/avg/max/stddev = 113.103/276.438/366.531/115.700 ms
>>
>> then, when pinging (unsuccessfully) from another host on the wireless
>>
>> soekris# tcpdump -i bridge0 host 192.168.0.129
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>> listening on bridge0, link-type EN10MB (Ethernet), capture size 96 bytes
>> 05:40:28.486793 arp who-has 192.168.0.129 tell 192.168.0.12
>> 05:40:29.486335 arp who-has 192.168.0.129 tell 192.168.0.12
>> 05:40:30.486776 arp who-has 192.168.0.129 tell 192.168.0.12
>> 05:40:31.487058 arp who-has 192.168.0.129 tell 192.168.0.12
>> 05:40:32.487227 arp who-has 192.168.0.129 tell 192.168.0.12
>> ^C
>> 5 packets captured
>> 2192 packets received by filter
>> 0 packets dropped by kernel
>>
>>
>> ath ierrors are an old fact of life here, see a thread from almost a
>> year ago
>>
>> soekris# netstat -ni
>> Name Mtu Network Address Ipkts Ierrs Opkts
>> Oerrs Coll
>> vr0 1500<Link#1> 00:00:24:c8:b3:28 139171779 0 102370058
>> 0 0
>> vr1 1500<Link#2> 00:00:24:c8:b3:29 0 0 0 0 0
>> vr2 1500<Link#3> 00:00:24:c8:b3:2a 11034998 0 54497266 0 0
>> vr3 1500<Link#4> 00:00:24:c8:b3:2b 246912 0 321750 0 0
>> ath0 2290<Link#5> 00:0b:6b:83:59:25 192042747 20665363 77278643
>> 27 0
>> lo0 16384<Link#6> 111523 0 111523 0 0
>> lo0 16384 fe80:6::1/64 fe80:6::1 0 - 0 - -
>> lo0 16384 ::1/128 ::1 0 - 0 - -
>> lo0 16384 127.0.0.0/8 127.0.0.1 111523 - 111523 - -
>> bridg 1500<Link#7> d6:9b:35:b7:7c:bd 92627892 0 131886570
>> 0 0
>> bridg 1500 192.168.0.0/2 192.168.0.1 231764 - 146544 - -
>> wlan0 1500<Link#8> 00:0b:6b:83:59:25 81345984 0 77084603
>> 192714 0
>> wlan1 1500<Link#9> 00:0b:6b:83:59:25 0 0 0 0 0
>> tun0 1454<Link#10> 138915852 0 102337216
>> 0 0
>> tun0 1454 210.138.216.5 210.138.216.50 7709196 - 10317194 - -
>>
>>
>> randy
>>
>>
>
> I don't see you looking on the wireless interface to see if the arp
> who-has packet goes out. You know it hit the bridge from the wireless
> sta but not that it went out over the wireless interface. If you don't
> see it hit the air then look for a reason for a drop. wlanstats should
> show you and/or wlandebug +output. Looking at the mac addresses
> registered w/ the bridge might also tell you where packets are being sent.
the soekris sees all
soek# arp -an
soek0.psg.com:/root# ping 192.168.0.129
PING 192.168.0.129 (192.168.0.129): 56 data bytes
64 bytes from 192.168.0.129: icmp_seq=0 ttl=64 time=417.356 ms
64 bytes from 192.168.0.129: icmp_seq=1 ttl=64 time=482.347 ms
64 bytes from 192.168.0.129: icmp_seq=2 ttl=64 time=397.344 ms
^C
--- 192.168.0.129 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 397.344/432.349/482.347/36.286 ms
soek# arp -an
? (192.168.0.10) at 00:15:c5:4a:6f:c5 on bridge0 [bridge]
? (192.168.0.12) at 00:1e:52:70:b6:36 on bridge0 [bridge]
? (192.168.0.13) at 00:15:00:10:ed:09 on bridge0 [bridge]
? (192.168.0.17) at 00:0d:65:27:bd:f2 on bridge0 [bridge]
? (192.168.0.28) at 00:80:77:04:35:16 on bridge0 [bridge]
? (192.168.0.128) at 00:23:12:fc:39:b9 on bridge0 [bridge]
? (192.168.0.129) at 00:23:df:6a:dc:9b on bridge0 [bridge]
but pinging
from a macbook pro on same wireless (192.168.0.12)
to the iphone (192.168.0.129)
as seen from the soekris (192.168.0.1)
Jan 4 06:33:13 soek kernel: rtfree: 0xc2e80000 has 1 refs
Jan 4 06:33:14 soek kernel: wlan0: [ff:ff:ff:ff:ff:ff] discard frame,
sta not associated (type 0x0806)
Jan 4 06:33:14 soek kernel: arp_proxy: ignoring request from
192.168.0.12 via wlan0, expecting bridge0
Jan 4 06:33:14 soek kernel: rtfree: 0xc2e80000 has 1 refs
Jan 4 06:33:15 soek kernel: wlan0: [ff:ff:ff:ff:ff:ff] discard frame,
sta not associated (type 0x0806)
Jan 4 06:33:15 soek kernel: arp_proxy: ignoring request from
192.168.0.12 via wlan0, expecting bridge0
Jan 4 06:33:15 soek kernel: rtfree: 0xc2e80000 has 1 refs
Jan 4 06:33:16 soek kernel: wlan0: [ff:ff:ff:ff:ff:ff] discard frame,
sta not associated (type 0x0806)
Jan 4 06:33:16 soek kernel: arp_proxy: ignoring request from
192.168.0.12 via wlan0, expecting bridge0
Jan 4 06:33:16 soek kernel: rtfree: 0xc2e80000 has 1 refs
Jan 4 06:33:39 soek kernel: wlan0: [01:00:5e:7f:ff:fa] discard frame,
sta not associated (type 0x0800)
Jan 4 06:33:44 soek kernel: wlan0: [01:00:0c:cc:cc:cc] discard frame,
sta not associated (type 0x0074)
Jan 4 06:33:45 soek kernel: wlan0: [ff:ff:ff:ff:ff:ff] discard frame,
sta not associated (type 0x0800)
> BTW I see an ath0 interface in your diagram but wlan0 and wlan1 in your
> netstat output.
did not update diagram when life changed six months ago <blush>.
randy
More information about the freebsd-current
mailing list