Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 9 Apr 2002 21:08:44 +0000 (GMT)
From:      Jason Campbell <jdc_freebsd-mobile@introrse.com>
To:        freebsd-mobile@freebsd.org
Subject:   Addtron AWP-100 packets still encapsulated?
Message-ID:  <20020409210844.53595.qmail@introrse.com>

next in thread | raw e-mail | index | archive | help
Howdy,

I recently installed 4.5-RELEASE on my IBM Thinkpad 240, and have been
attempting (unsuccessfully) to get 802.11 to work via my Addtron
AWP-100 pcmcia card and Linksys BEFRS41 access point / gateway.  I'm
hoping the symptoms might ring a bell to someone here.  It's as though
the SNAP encapsulated packets from the AP aren't being unencapsulated
on the laptop, or perhaps as though no incoming traffic is being
accepted on layer 3 on the laptop.  (but the laptop isn't firewalling)

Background:

The AWP-100 card is recognized upon insertion, the wi driver seems to
load OK, I can configure it all via ifconfig and assuming I set the
channels and WEP settings to the same as those on the linksys AP then
'ifconfig wi0' shows 'status: associated'.  The card is defaulting to
BSS mode and I leave it that way.  I get the same results with and
without encryption (changing both AP and card to make them match).
The laptop's IP address is configured statically as part of the
wireless card setup, and a default route is established to the IP of
the access point.  The laptop's IP address and netmask are set
correctly, at least according to ifconfig.  I've verified that the
hardware in question does work when the Thinkpad is booted into
Windows 98 instead of FreeBSD.

Symptoms in detail:

The latop receives, but ignores ARP replies to its own requests, and
receives but ignores other hosts' ARP requests for the laptop's IP.
This seems part of an overall theme on the laptop's part of not
recognizing any data coming from the wireless card above layer 2
processing.

Running tcpdump from a wired machine I can see that the laptop is able
to send packets to the wired LAN just fine.  (using hardwired arp
entries)

Running tcpdump on the laptop, I can see all kinds of traffic from
wired hosts (unicast packets sent from wired hosts to the laptop,
broadcast packets from the wired lan, and even responses to ICMP echo
packets sent by the laptop).  BUT, nothing ever shows up arriving at
layer 3 on the laptop.  For instance, while sniffing from the laptop
and pinging the AP I can see outbound ICMP echo requests and the
corresponding responses coming back from the access point, but the
ping process reports zero responses received.  'netstat -i -n' agrees
that the wireless ethernet interface is receiving lots of packets but
the wireless IP interface is not.

The traffic received on the laptop is reported by tcpdump as being
SNAP encapsulated.  I can't tell from the output whether tcpdump had
to do the unencapsulation itself, or whether it's looking into some
part of the networking stack to see this. 

Inline below are the outputs from the serveral status commands, etc.,
described above.  

Does this ring a bell for anyone?  I've been looking thru the mailing
list archives since last night and can't find something particularly
similar.  

Thanks very much for any help anyone can suggest!

Jason. 

(I'd appreciate being cc-ed on responses, and I will also monitor this
mailing list on the freebsd web site.  I simply suspect there might be
some lag involved in messages getting to the web interface there.)


The card being inserted:
------------------------
Apr  9 12:16:10 patter /kernel: pccard: card inserted, slot 0
Apr  9 12:16:16 patter pccardd[42]: Card "Addtron"("AWP-100 Wireless PCMCIA") [Version 01.02] [] matched "Addtron" ("AWP-100 Wireless PCMCIA") [(null)] [(null)] 
Apr  9 12:16:21 patter /kernel: wi0: <WaveLAN/IEEE 802.11> at port 0x240-0x27f irq 11 flags 0x10000 slot 0 on pccard0
Apr  9 12:16:21 patter /kernel: wi0: Ethernet address: 00:90:d1:07:2b:14
Apr  9 12:16:21 patter pccardd[42]: wi0: Addtron (AWP-100 Wireless PCMCIA) inserted.


commands I use for configuring the card, post-insertion  
-------------------------------------------------------
ifconfig wi0 inet 192.168.1.61 netmask 255.255.255.0 channel 2 ssid perch wepmode off
arp -s 192.168.1.1 0:4:5a:cf:92:a7
arp -s 192.168.1.51 0:60:8:1a:d8:23

'ifconfig' output with no args, post configuration
--------------------------------------------------
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
	inet6 ::1 prefixlen 128 
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
	inet 127.0.0.1 netmask 0xff000000 
ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 552
faith0: flags=8002<BROADCAST,MULTICAST> mtu 1500
wi0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
	inet 192.168.1.61 netmask 0xffffff00 broadcast 192.168.1.255
	inet6 fe80::290:d1ff:fe07:2b14%wi0 prefixlen 64 scopeid 0x5 
	ether 00:90:d1:07:2b:14 
	media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps)
	status: associated
	ssid perch
	stationname "FreeBSD WaveLAN/IEEE node"
	channel 2 authmode NONE powersavemode OFF powersavesleep 100
	wepmode OFF weptxkey 1


the output of 'netstat -i -n'  (note missing 192.168.1 Ipkts!)
-----------------------------
Name  Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs  Coll
lo0   16384 <Link#1>                            88     0       88     0     0
lo0   16384 ::1/128     ::1                      0     -        0     -     -
lo0   16384 fe80:1::1/6 fe80:1::1                0     -        0     -     -
lo0   16384 127           127.0.0.1             88     -       88     -     -
ppp0* 1500  <Link#2>                             0     0        0     0     0
sl0*  552   <Link#3>                             0     0        0     0     0
faith 1500  <Link#4>                             0     0        0     0     0
wi0   1500  <Link#5>    00:90:d1:07:2b:14      165     0       69     0     0
wi0   1500  192.168.1     192.168.1.61           0     -       64     -     -
wi0   1500  fe80:5::290 fe80:5::290:d1ff:        0     -        0     -     -


the output of 'wicontrol -i wi0'
--------------------------------
NIC serial number:			[ 99SA01000000 ]
Station name:				[ FreeBSD WaveLAN/IEEE node ]
SSID for IBSS creation:			[ perch ]
Current netname (SSID):			[ perch ]
Desired netname (SSID):			[ perch ]
Current BSSID:				[ 00:04:5a:cf:92:a7 ]
Channel list:				[ 2047 ]
IBSS channel:				[ 2 ]
Current channel:			[ 2 ]
Comms quality/signal/noise:		[ 46 93 0 ]
Promiscuous mode:			[ On ]
Port type (1=BSS, 3=ad-hoc):		[ 1 ]
MAC address:				[ 00:90:d1:07:2b:14 ]
TX rate (selection):			[ 3 ]
TX rate (actual speed):			[ 11 ]
RTS/CTS handshake threshold:		[ 2347 ]
Create IBSS:				[ Off ]
Access point density:			[ 1 ]
Power Mgmt (1=on, 0=off):		[ 0 ]
Max sleep time:				[ 100 ]
WEP encryption:				[ Off ]
TX encryption key:			[ 1 ]
Encryption keys:			[  ][  ][  ][  ]


the output of 'wicontrol -i wi0 -o'
-----------------------------------
Transmitted unicast frames:		64
Transmitted multicast frames:		0
Transmitted fragments:			77
Transmitted unicast octets:		7152
Transmitted multicast octets:		0
Single transmit retries:		0
Multiple transmit retries:		0
Transmit retry limit exceeded:		0
Transmit discards:			0
Transmit discards due to wrong SA:	0
Received unicast frames:		77
Received multicast frames:		8882
Received fragments:			8959
Received unicast octets:		8418
Received multicast octets:		557067
Receive FCS errors:			2
Receive discards due to no buffer:	0
Can't decrypt WEP frame:		0
Received message fragments:		0
Received message bad fragments:		0


the contents of /etc/rc.conf on the laptop  (note that xl0 doesn't exist
------------------------------------------   anymore and is from the OS
                                             install as I performed it on a
                                             different machine with wired net.)
accounting_enable="NO"
apm_enable="YES"
check_quotas="NO"
defaultrouter="192.168.1.1"
hostname="patter.jasonc.com"
ifconfig_xl0="inet 192.168.1.61  netmask 255.255.255.0"
inetd_enable="NO"
kern_securelevel_enable="NO"
moused_enable="YES"
moused_port="/dev/psm0"
moused_type="auto"
moused_flags="-m 2=3 -m 3=2"
nfs_client_enable="YES"
nfs_reserved_port_only="YES"
pccard_enable="YES"
saver="snake"
scrnmap="NO"
sendmail_enable="NO"
sshd_enable="YES"
tcp_extensions="YES"
usbd_enable="YES"


the output of 'netstat -r -n'
-----------------------------
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
127.0.0.1          127.0.0.1          UH         44       88    lo0
192.168.1          link#5             UC          1        0    wi0
192.168.1.1        0:4:5a:cf:92:a7    UHLS        0       26    wi0
192.168.1.51       0:60:8:1a:d8:23    UHLS        0       28    wi0
192.168.1.53       link#5             UHLW        0        4    wi0

Internet6:
Destination                       Gateway                       Flags      Netif Expire
::1                               ::1                           UH          lo0
fe80::%lo0/64                     fe80::1%lo0                   Uc          lo0
fe80::1%lo0                       link#1                        UHL         lo0
fe80::%wi0/64                     link#5                        UC          wi0
fe80::290:d1ff:fe07:2b14%wi0      0:90:d1:7:2b:14               UHL         lo0
ff01::/32                         ::1                           U           lo0
ff02::%lo0/32                     ::1                           UC          lo0
ff02::%wi0/32                     link#5                        UC          wi0




     Traceroute results made during various ping operations
     ======================================================

Note that traceroute was running on the laptop -- that is, on the
wireless host -- for all of the following tests.

    192.168.1.1  == linksys access point (a wireless AP and a 4 port switch)
    192.168.1.51 == wired host
    192.168.1.53 == wired host
    192.168.1.61 == laptop

- - - - - - - pinging from laptop to the linksys access point - - - - - - -
The ping process here reported 0 packets received, although the gateway 
clearly does respond, and the responses are clearly seen on the laptop
sniffer. 
...
12:31:41.175039 0:90:d1:7:2b:14 0:4:5a:cf:92:a7 0800 98: 192.168.1.61 > 192.168.1.1: icmp: echo request (ttl 64, id 219, len 84)
12:31:41.177967 0:4:5a:cf:92:a7 0:90:d1:7:2b:14 005c 106: snap ff:ff:ff:8:0 192.168.1.1 > 192.168.1.61: icmp: echo reply (ttl 64, id 219, len 84)
12:31:42.183762 0:90:d1:7:2b:14 0:4:5a:cf:92:a7 0800 98: 192.168.1.61 > 192.168.1.1: icmp: echo request (ttl 64, id 220, len 84)
12:31:42.186527 0:4:5a:cf:92:a7 0:90:d1:7:2b:14 005c 106: snap ff:ff:ff:8:0 192.168.1.1 > 192.168.1.61: icmp: echo reply (ttl 64, id 220, len 84)
12:31:43.193757 0:90:d1:7:2b:14 0:4:5a:cf:92:a7 0800 98: 192.168.1.61 > 192.168.1.1: icmp: echo request (ttl 64, id 221, len 84)
12:31:43.197002 0:4:5a:cf:92:a7 0:90:d1:7:2b:14 005c 106: snap ff:ff:ff:8:0 192.168.1.1 > 192.168.1.61: icmp: echo reply (ttl 64, id 221, len 84)
...
- - - - - - - - pinging from laptop to a wired host - - - - - - - -
This wired host was not not hardcoded into the laptop's arp cache, and the 
laptop ignores the arp replies seen below. 
...
12:31:47.660369 0:90:d1:7:2b:14 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.1.53 tell 192.168.1.61
12:31:47.663787 0:b0:d0:76:89:ac 0:90:d1:7:2b:14 0036 68: snap ff:ff:ff:8:6 arp reply 192.168.1.53 is-at 0:b0:d0:76:89:ac
12:31:48.663800 0:90:d1:7:2b:14 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.1.53 tell 192.168.1.61
12:31:48.667259 0:b0:d0:76:89:ac 0:90:d1:7:2b:14 0036 68: snap ff:ff:ff:8:6 arp reply 192.168.1.53 is-at 0:b0:d0:76:89:ac
12:31:49.673807 0:90:d1:7:2b:14 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.1.53 tell 192.168.1.61
12:31:49.676822 0:b0:d0:76:89:ac 0:90:d1:7:2b:14 0036 68: snap ff:ff:ff:8:6 arp reply 192.168.1.53 is-at 0:b0:d0:76:89:ac
12:31:50.683816 0:90:d1:7:2b:14 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.1.53 tell 192.168.1.61
12:31:50.686512 0:b0:d0:76:89:ac 0:90:d1:7:2b:14 0036 68: snap ff:ff:ff:8:6 arp reply 192.168.1.53 is-at 0:b0:d0:76:89:ac
...
- - - - - - - - pinging from laptop to a wired host - - - - - - - -
This wired host has had its ethernet address manually added to the 
laptop's arp cache.  Note that the ping process *still* reported 0 
packets received during this test, despite these responses.
...
12:31:52.932312 0:90:d1:7:2b:14 0:60:8:1a:d8:23 0800 98: 192.168.1.61 > 192.168.1.51: icmp: echo request (ttl 64, id 226, len 84)
12:31:52.934981 0:60:8:1a:d8:23 0:90:d1:7:2b:14 005c 106: snap ff:ff:ff:8:0 192.168.1.51 > 192.168.1.61: icmp: echo reply (ttl 64, id 48210, len 84)
12:31:53.933916 0:90:d1:7:2b:14 0:60:8:1a:d8:23 0800 98: 192.168.1.61 > 192.168.1.51: icmp: echo request (ttl 64, id 227, len 84)
12:31:53.936892 0:60:8:1a:d8:23 0:90:d1:7:2b:14 005c 106: snap ff:ff:ff:8:0 192.168.1.51 > 192.168.1.61: icmp: echo reply (ttl 64, id 48211, len 84)
12:31:54.943925 0:90:d1:7:2b:14 0:60:8:1a:d8:23 0800 98: 192.168.1.61 > 192.168.1.51: icmp: echo request (ttl 64, id 228, len 84)
12:31:54.946907 0:60:8:1a:d8:23 0:90:d1:7:2b:14 005c 106: snap ff:ff:ff:8:0 192.168.1.51 > 192.168.1.61: icmp: echo reply (ttl 64, id 48212, len 84)
12:31:55.953936 0:90:d1:7:2b:14 0:60:8:1a:d8:23 0800 98: 192.168.1.61 > 192.168.1.51: icmp: echo request (ttl 64, id 229, len 84)
12:31:55.956885 0:60:8:1a:d8:23 0:90:d1:7:2b:14 005c 106: snap ff:ff:ff:8:0 192.168.1.51 > 192.168.1.61: icmp: echo reply (ttl 64, id 48213, len 84)
12:31:56.963953 0:90:d1:7:2b:14 0:60:8:1a:d8:23 0800 98: 192.168.1.61 > 192.168.1.51: icmp: echo request (ttl 64, id 230, len 84)
12:31:56.967459 0:60:8:1a:d8:23 0:90:d1:7:2b:14 005c 106: snap ff:ff:ff:8:0 192.168.1.51 > 192.168.1.61: icmp: echo reply (ttl 64, id 48214, len 84)
...
- - - - - - - -  pinging from wired host to laptop - - - - - - - -
Note that laptop doesn't respond, though these packets logged on the 
laptop's sniffer are proof that the data did indeed get to the laptop, 
just not any further in the IP stack. 
...
12:31:59.764946 0:60:8:1a:d8:23 0:90:d1:7:2b:14 005c 106: snap ff:ff:ff:8:0 192.168.1.51 > 192.168.1.61: icmp: echo request (ttl 64, id 48216, len 84)
12:32:00.767858 0:60:8:1a:d8:23 0:90:d1:7:2b:14 005c 106: snap ff:ff:ff:8:0 192.168.1.51 > 192.168.1.61: icmp: echo request (ttl 64, id 48218, len 84)
12:32:01.777622 0:60:8:1a:d8:23 0:90:d1:7:2b:14 005c 106: snap ff:ff:ff:8:0 192.168.1.51 > 192.168.1.61: icmp: echo request (ttl 64, id 48219, len 84)
12:32:02.787549 0:60:8:1a:d8:23 0:90:d1:7:2b:14 005c 106: snap ff:ff:ff:8:0 192.168.1.51 > 192.168.1.61: icmp: echo request (ttl 64, id 48220, len 84)
12:32:03.797740 0:60:8:1a:d8:23 0:90:d1:7:2b:14 005c 106: snap ff:ff:ff:8:0 192.168.1.51 > 192.168.1.61: icmp: echo request (ttl 64, id 48221, len 84)
12:32:04.807725 0:60:8:1a:d8:23 0:90:d1:7:2b:14 005c 106: snap ff:ff:ff:8:0 192.168.1.51 > 192.168.1.61: icmp: echo request (ttl 64, id 48222, len 84)


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-mobile" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020409210844.53595.qmail>