From owner-freebsd-mobile Tue Apr 9 14: 9:14 2002 Delivered-To: freebsd-mobile@freebsd.org Received: from sj1-3-4-13.securesites.net (sj1-3-4-13.securesites.net [192.220.127.206]) by hub.freebsd.org (Postfix) with SMTP id 5AE5937B400 for ; Tue, 9 Apr 2002 14:08:48 -0700 (PDT) Received: (qmail 53596 invoked by uid 18862); 9 Apr 2002 21:08:44 -0000 Message-ID: <20020409210844.53595.qmail@introrse.com> Subject: Addtron AWP-100 packets still encapsulated? To: freebsd-mobile@freebsd.org Date: Tue, 9 Apr 2002 21:08:44 +0000 (GMT) From: Jason Campbell X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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: 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 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 ppp0: flags=8010 mtu 1500 sl0: flags=c010 mtu 552 faith0: flags=8002 mtu 1500 wi0: flags=8943 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 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 0 0 0 0 0 sl0* 552 0 0 0 0 0 faith 1500 0 0 0 0 0 wi0 1500 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