Bug 132722 - [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
Summary: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: 7.1-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-wireless (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-17 08:20 UTC by Matthias Apitz
Modified: 2018-05-28 19:43 UTC (History)
0 users

See Also:


Attachments
file.txt (23.21 KB, text/plain)
2009-03-17 08:20 UTC, Matthias Apitz
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Apitz 2009-03-17 08:20:02 UTC

Fix: Patch attached with submission follows:
How-To-Repeat: the Wifi ath0 associates successfully to the AP:

# ifconfig ath0
ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 00:15:af:b2:ae:e6
        inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
        media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/36Mbps)
        status: associated
        ssid ConnectionPoint channel 11 (2462 Mhz 11g) bssid 00:01:e3:0e:97:99
        authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpower 31.5
        bmiss 7 scanvalid 60 protmode CTS burst roaming MANUAL

DHCP is not successfull

# dhclient -d ath0
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 13
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 19
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 15
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 2
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
       
side note: a Nokia mobile phone can do DHCP successfull with the same AP, i.e.
there is no MAC addr blacklisting in the AP;


more details, including athstats and tcpdump see attached file ath0.txt
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2009-03-17 08:21:07 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-net

Over to maintainer(s).
Comment 2 Bruce M Simpson 2009-03-17 08:31:38 UTC
Hi,

Can you please try cvsupping RELENG_7 sources to after this date:

%%%

Date: Thu Mar 12 03:09:11 2009
New Revision: 189720
URL: http://svn.freebsd.org/changeset/base/189720

%%%

The Atheros open source HAL from  HEAD was MFC'd and this may or may not 
fix your problem.

thanks,
BMS
Comment 3 Matthias Apitz 2009-03-17 08:42:43 UTC
I forgot to mention that I've applied this patch from Sam to my RELENG_7
kernel:

http://article.gmane.org/gmane.os.freebsd.stable/60383/match=cft+ath+hal+src

I think, updating to 

Date: Thu Mar 12 03:09:11 2009
New Revision: 189720
URL: http://svn.freebsd.org/changeset/base/189720

as suggested will not change anything, or I'm wrong?

	matthias
Comment 4 Matthias Apitz 2009-03-17 10:36:51 UTC
as requested the output of dmesg(1) and the ath0 related part of
'pciconf -lv'; pls note also that the Wifi works fine in general, i.e.
with the AP in my office (WPA) and in my home (WEP);


Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-STABLE #1: Tue Mar 10 11:42:48 CET 2009
    guru@rebelion.Sisis.de:/usr/src/sys/i386/compile/REBELION
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Celeron(R) M processor          900MHz (900.10-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x6d8  Stepping = 8
  Features=0xafe9fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE>
  AMD Features=0x100000<NX>
real memory  = 1064828928 (1015 MB)
avail memory = 1028284416 (980 MB)
ACPI APIC Table: <A M I  OEMAPIC >
ioapic0 <Version 2.0> irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: <A M I OEMRSDT> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, 3f700000 (3) failed
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
acpi_ec0: <Embedded Controller: GPE 0x18> port 0x62,0x66 on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
vgapci0: <VGA-compatible display> port 0xec00-0xec07 mem 0xf7f00000-0xf7f7ffff,0xd0000000-0xdfffffff,0xf7ec0000-0xf7efffff irq 16 at device 2.0 on pci0
agp0: <Intel 82915GM (915GM GMCH) SVGA controller> on vgapci0
agp0: detected 7932k stolen memory
agp0: aperture size is 256M
vgapci1: <VGA-compatible display> mem 0xf7f80000-0xf7ffffff at device 2.1 on pci0
hdac0: <Intel 82801F High Definition Audio Controller> mem 0xf7eb8000-0xf7ebbfff irq 16 at device 27.0 on pci0
hdac0: HDA Driver Revision: 20090131_0127
hdac0: [ITHREAD]
pcib1: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0
pci3: <ACPI PCI bus> on pcib1
pcib2: <ACPI PCI-PCI bridge> irq 18 at device 28.2 on pci0
pci1: <ACPI PCI bus> on pcib2
ath0: <Atheros 5424/2424> mem 0xfbff0000-0xfbffffff irq 18 at device 0.0 on pci1
ath0: [ITHREAD]
ath0: WARNING: using obsoleted if_watchdog interface
ath0: Ethernet address: 00:15:af:b2:ae:e6
ath0: mac 14.2 phy 7.0 radio 10.2
uhci0: <Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A> port 0xe400-0xe41f irq 23 at device 29.0 on pci0
uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0: <Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A> on uhci0
usb0: USB revision 1.0
uhub0: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
uhub0: 2 ports with 2 removable, self powered
uhci1: <Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B> port 0xe480-0xe49f irq 19 at device 29.1 on pci0
uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1: <Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B> on uhci1
usb1: USB revision 1.0
uhub1: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
uhub1: 2 ports with 2 removable, self powered
uhci2: <Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C> port 0xe800-0xe81f irq 18 at device 29.2 on pci0
uhci2: [GIANT-LOCKED]
uhci2: [ITHREAD]
usb2: <Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C> on uhci2
usb2: USB revision 1.0
uhub2: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb2
uhub2: 2 ports with 2 removable, self powered
uhci3: <Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D> port 0xe880-0xe89f irq 16 at device 29.3 on pci0
uhci3: [GIANT-LOCKED]
uhci3: [ITHREAD]
usb3: <Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D> on uhci3
usb3: USB revision 1.0
uhub3: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb3
uhub3: 2 ports with 2 removable, self powered
ehci0: <Intel 82801FB (ICH6) USB 2.0 controller> mem 0xf7eb7c00-0xf7eb7fff irq 23 at device 29.7 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb4: EHCI version 1.0
usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3
usb4: <Intel 82801FB (ICH6) USB 2.0 controller> on ehci0
usb4: USB revision 2.0
uhub4: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb4
uhub4: 8 ports with 8 removable, self powered
umass0: <ENE UB6225, class 0/0, rev 2.00/1.00, addr 2> on uhub4
pcib3: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci4: <ACPI PCI bus> on pcib3
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel ICH6M SATA150 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.2 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
acpi_asus0: <ASUS EeePC> on acpi0
acpi_lid0: <Control Method Lid Switch> on acpi0
acpi_button0: <Sleep Button> on acpi0
acpi_button1: <Power Button> on acpi0
acpi_tz0: <Thermal Zone> on acpi0
battery0: <ACPI Control Method Battery> on acpi0
acpi_acad0: <AC Adapter> on acpi0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model IntelliMouse, device ID 3
cpu0: <ACPI CPU> on acpi0
p4tcc0: <CPU Frequency Thermal Control> on cpu0
pmtimer0 on isa0
orm0: <ISA Option ROM> at iomem 0xc0000-0xcf7ff pnpid ORM0000 on isa0
ppc0: parallel port not found.
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 8250 or not responding
sio0: [FILTER]
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
Timecounter "TSC" frequency 900097206 Hz quality 800
Timecounters tick every 10.000 msec
ad2: FAILURE - SET_MULTI status=51<READY,DSC,ERROR> error=4<ABORTED>
ad2: 3847MB <ASUS-PHISON OB SSD TST2.04P> at ata1-master UDMA66
ad3: FAILURE - SET_MULTI status=51<READY,DSC,ERROR> error=4<ABORTED>
ad3: 15391MB <ASUS-PHISON SSD TST2.04P> at ata1-slave UDMA66
hdac0: HDA Codec #0: Realtek ALC662
pcm0: <HDA Realtek ALC662 PCM #0 Analog> at cad 0 nid 1 on hdac0
(probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 
(probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
(probe0:umass-sim0:0:0:0): SCSI Status: Check Condition
(probe0:umass-sim0:0:0:0): NOT READY asc:3a,0
(probe0:umass-sim0:0:0:0): Medium not present
(probe0:umass-sim0:0:0:0): Unretryable error
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <USB2.0 CardReader SD0 0100> Removable Direct Access SCSI-0 device 
da0: 40.000MB/s transfers
da0: Attempt to query device size failed: NOT READY, Medium not present
Trying to mount root from ufs:/dev/ad2s1a
ath0: link state changed to UP



ath0@pci0:1:0:0:	class=0x020000 card=0x10261a3b chip=0x001c168c rev=0x01 hdr=0x00
    vendor     = 'Atheros Communications Inc.'
    device     = 'AR5006 family 802.11abg Wireless NIC'
    class      = network
    subclass   = ethernet


	matthias
Comment 5 Bruce M Simpson 2009-03-17 10:39:32 UTC
Matthias Apitz wrote:
> as requested the output of dmesg(1) and the ath0 related part of
> 'pciconf -lv'; pls note also that the Wifi works fine in general, i.e.
> with the AP in my office (WPA) and in my home (WEP);
>   

Is this an ASUS Eee PC? If so, which model is it? It looks like a 901.

I tested OK with the 701. Sam said that there may be models of ath(4) 
requiring further changes
to be back-ported from -CURRENT, this could well be one of them.

cheers
BMS
Comment 6 Matthias Apitz 2009-03-17 10:45:48 UTC
El día Tuesday, March 17, 2009 a las 10:39:32AM +0000, Bruce Simpson escribió:

> Matthias Apitz wrote:
> >as requested the output of dmesg(1) and the ath0 related part of
> >'pciconf -lv'; pls note also that the Wifi works fine in general, i.e.
> >with the AP in my office (WPA) and in my home (WEP);
> >  
> 
> Is this an ASUS Eee PC? If so, which model is it? It looks like a 901.

It is an Asus EeePC 900, not the 901.

> I tested OK with the 701. Sam said that there may be models of ath(4) 
> requiring further changes
> to be back-ported from -CURRENT, this could well be one of them.

as I said the Wifi works in all places, but not with this special AP
(while a Nokia cellphone can associate and DHCP without problems);

let me know if you need more info;

Thx

	matthias
-- 
Matthias Apitz
Manager Technical Support - OCLC GmbH
Gruenwalder Weg 28g - 82041 Oberhaching - Germany
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e <matthias.apitz@oclc.org> - w http://www.oclc.org/ http://www.UnixArea.de/
Comment 7 Sean Farley freebsd_committer 2009-03-17 16:55:32 UTC
On Tue, 17 Mar 2009, Matthias Apitz wrote:

> El día Tuesday, March 17, 2009 a las 10:39:32AM +0000, Bruce Simpson escribió:
>
>> Matthias Apitz wrote:
>>> as requested the output of dmesg(1) and the ath0 related part of 
>>> 'pciconf -lv'; pls note also that the Wifi works fine in general, 
>>> i.e. with the AP in my office (WPA) and in my home (WEP);
>>>
>>
>> Is this an ASUS Eee PC? If so, which model is it? It looks like a 
>> 901.
>
> It is an Asus EeePC 900, not the 901.
>
>> I tested OK with the 701. Sam said that there may be models of ath(4) 
>> requiring further changes to be back-ported from -CURRENT, this could 
>> well be one of them.
>
> as I said the Wifi works in all places, but not with this special AP 
> (while a Nokia cellphone can associate and DHCP without problems);
>
> let me know if you need more info;

Is the AP made by Aruba Networks?

On RELENG_7, I needed a newer version (v0.5.11 instead of v0.5.10) of 
wpa_supplicant for it to associate correctly.  With v0.5.10, I could see 
DHCP requests from my laptop but no responses.  This is the patch I am 
using currently:
http://people.freebsd.org/~scf/wpa_supplicant-0.5.11-RELENG_7.patch

Note:  sam@ updated HEAD to v0.5.11 then to the v0.6.x series.

Sean
-- 
scf@FreeBSD.org
Comment 8 Sam Leffler freebsd_committer 2009-03-17 18:56:24 UTC
Sean C. Farley wrote:
> On Tue, 17 Mar 2009, Matthias Apitz wrote:
>
>> El día Tuesday, March 17, 2009 a las 10:39:32AM +0000, Bruce Simpson 
>> escribió:
>>
>>> Matthias Apitz wrote:
>>>> as requested the output of dmesg(1) and the ath0 related part of 
>>>> 'pciconf -lv'; pls note also that the Wifi works fine in general, 
>>>> i.e. with the AP in my office (WPA) and in my home (WEP);
>>>>
>>>
>>> Is this an ASUS Eee PC? If so, which model is it? It looks like a 901.
>>
>> It is an Asus EeePC 900, not the 901.
>>
>>> I tested OK with the 701. Sam said that there may be models of 
>>> ath(4) requiring further changes to be back-ported from -CURRENT, 
>>> this could well be one of them.
>>
>> as I said the Wifi works in all places, but not with this special AP 
>> (while a Nokia cellphone can associate and DHCP without problems);
>>
>> let me know if you need more info;
>
> Is the AP made by Aruba Networks?
>
> On RELENG_7, I needed a newer version (v0.5.11 instead of v0.5.10) of 
> wpa_supplicant for it to associate correctly.  With v0.5.10, I could 
> see DHCP requests from my laptop but no responses.  This is the patch 
> I am using currently:
> http://people.freebsd.org/~scf/wpa_supplicant-0.5.11-RELENG_7.patch
>
> Note:  sam@ updated HEAD to v0.5.11 then to the v0.6.x series.

His setup is static key wep; not wpa so I don't think wpa_supplicant is 
the issue.

Matthias, your tcpdump of the dhclient packets isn't usable; please try:

tcpdump -i ath0 -n -y IEEE802_11_RADIO

I reviewed the driver to the code in HEAD and the only difference in the 
crypto area should not matter in this case.  It's possible wme is 
somehow enabled and causing problems but the ifconfig output doesn't 
indicate that.

If you can find out the model of ap that might be helpful.  
Unfortunately the best thing to try is HEAD.

    Sam
Comment 9 Matthias Apitz 2009-03-23 18:23:11 UTC
I went today evening with my EeePC and CURRENT on USB key
to that Greek restaurant; DHCP does not get IP in CURRENT either;
this is somehow good news, isn't it :-)

below are some information concerning the AP, ifconfig ...
the output of the tcpdump is on my server as
http://www.unixarea.de/ath-current.txt
let me know if you need more information;

HIH

	matthias


info about AP:
    Siemens Gigaset SE 505 dsl/cable
    S30853-S1006-R107-3
    (handwritten label says: "this is no DSL router; IP 192.168.2.1")
    as DSL-modem some Fritz!Box is connected to this box
    http://reviews.cnet.com/routers/siemens-gigaset-se505-dsl/1707-3319_7-30799508.html


# uname -a
FreeBSD tinyCurrent 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Mar 22 11:47:41 CET 2009     root@rebelion.Sisis.de:/usr/src/myHEAD/obj/usr/src/myHEAD/src/sys/GENERIC  i386

# ifconfig -a
ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 2290
	ether 00:15:af:b2:ae:e6
	media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
	status: associated
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
	options=3<RXCSUM,TXCSUM>
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 
	inet6 ::1 prefixlen 128 
	inet 127.0.0.1 netmask 0xff000000 
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	ether 00:15:af:b2:ae:e6
	inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
	media: IEEE 802.11 Wireless Ethernet DS/5.5Mbps mode 11g
	status: associated
	ssid ConnectionPoint channel 11 (2462 Mhz 11g) bssid 00:01:e3:0e:97:99
	regdomain 96 indoor ecm authmode OPEN privacy ON deftxkey 1
	wepkey 1:104-bit txpower 20 bmiss 7 scanvalid 450 bgscan
	bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS
	wme burst roaming MANUAL



# tcpdump -n -i ath0 -y IEEE802_11_RADIO
17:56:24.647835 436598375373us tsft 1.0 Mb/s -80dB signal -96dB noise antenna 1 [0x00000012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11]
17:56:24.750225 436598477774us tsft 1.0 Mb/s -81dB signal -96dB noise antenna 1 [0x00000012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11]
17:56:24.852621 436598580174us tsft 1.0 Mb/s -79dB signal -96dB noise antenna 1 [0x00000012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11]
17:56:24.955019 436598682572us tsft 1.0 Mb/s -80dB signal -96dB noise antenna 1 [0x00000012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11]
...

full log see: http://www.unixarea.de/ath-current.txt
Comment 10 Bruce M Simpson 2009-03-23 18:44:42 UTC
Matthias Apitz wrote:
> I went today evening with my EeePC and CURRENT on USB key
> to that Greek restaurant; DHCP does not get IP in CURRENT either;
> this is somehow good news, isn't it :-)
>   

This may be orthogonal, but:
    A lab colleague and I have been seeing a sporadic problem where the 
ath0 exhibits the symptoms of being disassociated from its AP. We are 
running RELENG_7 on the EeePC 701 since the open source HAL merge.
    In the behaviour we're seeing, we don't see any problem with the 
initial dhclient run, the ath0 just seems to get disassociated within 
5-10 minutes of associating.

If we leave 'ping <ap-ip-address>' running in the background, we don't 
see this problem.

    We have yet to produce a tcpdump to catch it 'in the act' and 
observe the DLT_IEEE80211 traffic when it actually happens, I have only 
seen the symptoms. The AP does not show the EeePC units as being 
associated any more at this point, but ath0 still shows 'status: 
associated'. The AP involved is a Netgear WG602 V2, and is running the 
vendor's firmware.

I'll try to get set up with 'tcpdump -y ieee802_11' from initial boot 
(including dhcp and anything we bump into).

cheers
BMS
Comment 11 Sam Leffler freebsd_committer 2009-03-23 19:12:04 UTC
Matthias Apitz wrote:
> I went today evening with my EeePC and CURRENT on USB key
> to that Greek restaurant; DHCP does not get IP in CURRENT either;
> this is somehow good news, isn't it :-)
>
> below are some information concerning the AP, ifconfig ...
> the output of the tcpdump is on my server as
> http://www.unixarea.de/ath-current.txt
> let me know if you need more information;
>
> HIH
>
> 	matthias
>
>
> info about AP:
>     Siemens Gigaset SE 505 dsl/cable
>     S30853-S1006-R107-3
>     (handwritten label says: "this is no DSL router; IP 192.168.2.1")
>     as DSL-modem some Fritz!Box is connected to this box
>     http://reviews.cnet.com/routers/siemens-gigaset-se505-dsl/1707-3319_7-30799508.html
>
>
> # uname -a
> FreeBSD tinyCurrent 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Mar 22 11:47:41 CET 2009     root@rebelion.Sisis.de:/usr/src/myHEAD/obj/usr/src/myHEAD/src/sys/GENERIC  i386
>
> # ifconfig -a
> ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 2290
> 	ether 00:15:af:b2:ae:e6
> 	media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
> 	status: associated
> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> 	options=3<RXCSUM,TXCSUM>
> 	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 
> 	inet6 ::1 prefixlen 128 
> 	inet 127.0.0.1 netmask 0xff000000 
> wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> 	ether 00:15:af:b2:ae:e6
> 	inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
> 	media: IEEE 802.11 Wireless Ethernet DS/5.5Mbps mode 11g
> 	status: associated
> 	ssid ConnectionPoint channel 11 (2462 Mhz 11g) bssid 00:01:e3:0e:97:99
> 	regdomain 96 indoor ecm authmode OPEN privacy ON deftxkey 1
> 	wepkey 1:104-bit txpower 20 bmiss 7 scanvalid 450 bgscan
> 	bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS
> 	wme burst roaming MANUAL
>
>
>
> # tcpdump -n -i ath0 -y IEEE802_11_RADIO
> 17:56:24.647835 436598375373us tsft 1.0 Mb/s -80dB signal -96dB noise antenna 1 [0x00000012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11]
> 17:56:24.750225 436598477774us tsft 1.0 Mb/s -81dB signal -96dB noise antenna 1 [0x00000012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11]
> 17:56:24.852621 436598580174us tsft 1.0 Mb/s -79dB signal -96dB noise antenna 1 [0x00000012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11]
> 17:56:24.955019 436598682572us tsft 1.0 Mb/s -80dB signal -96dB noise antenna 1 [0x00000012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11]
> ...
>
> full log see: http://www.unixarea.de/ath-current.txt
>
>
>   
If you have the raw pcap capture please provide a url to it.

 From the log it appears you're sending+receiving wep-encrypted frames.  
They keyid is the same and since you're receiving frames I have to 
assume the key matter is correct as otherwise the h/w would drop the 
frame.  You can verify this by feeding the key into wireshark to check 
if the frame contents make sense.

I'm out of ideas.  About the only thing I can suggest is you setup a 
different ap w/ the same wep key and see if things work.  If so then you 
know it's something this ap is doing.  I can't recall when I last tested 
wep on HEAD but I'm pretty sure it works.  I will re-test that when I 
get a chance.

    Sam
Comment 12 jhay 2009-03-23 20:40:50 UTC
On Mon, Mar 23, 2009 at 06:44:42PM +0000, Bruce M Simpson wrote:
> Matthias Apitz wrote:
> >I went today evening with my EeePC and CURRENT on USB key
> >to that Greek restaurant; DHCP does not get IP in CURRENT either;
> >this is somehow good news, isn't it :-)
> >  
> 
> This may be orthogonal, but:
>    A lab colleague and I have been seeing a sporadic problem where the 
> ath0 exhibits the symptoms of being disassociated from its AP. We are 
> running RELENG_7 on the EeePC 701 since the open source HAL merge.
>    In the behaviour we're seeing, we don't see any problem with the 
> initial dhclient run, the ath0 just seems to get disassociated within 
> 5-10 minutes of associating.
> 
> If we leave 'ping <ap-ip-address>' running in the background, we don't 
> see this problem.
> 

I found doing a -bgscan before it happens, make it not happen. I now
have -bgscan in my rc.conf.

John
-- 
John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org
Comment 13 Matthias Apitz 2009-03-23 21:42:07 UTC
El día Monday, March 23, 2009 a las 12:12:04PM -0700, Sam Leffler escribió:

> If you have the raw pcap capture please provide a url to it.

I have to capture it and will provide it;

> 
> From the log it appears you're sending+receiving wep-encrypted frames.  
> They keyid is the same and since you're receiving frames I have to 
> assume the key matter is correct as otherwise the h/w would drop the 
> frame.  You can verify this by feeding the key into wireshark to check 
> if the frame contents make sense.
> 
> I'm out of ideas.  About the only thing I can suggest is you setup a 
> different ap w/ the same wep key and see if things work.  If so then you 
> know it's something this ap is doing.  I can't recall when I last tested 
> wep on HEAD but I'm pretty sure it works.  I will re-test that when I 
> get a chance.
> 
>    Sam

WEP in general works; my AP at home is configured as WEP and the entries
in wpa_supplicant.conf are nearly the same, only the key differs:

# my home
#
network={
        ssid="tarara"
        scan_ssid=0
        key_mgmt=NONE
        wep_tx_keyidx=0
        wep_key0=xxxxxxxxxx
}

# Restaurante Odyssee (2007-11-18)
#
network={
        ssid="ConnectionPoint"
        scan_ssid=0
        key_mgmt=NONE
        wep_tx_keyidx=0
        wep_key0=xxxxxxxxxxxxxxxxxxxx
}

but I will configure another AP to also use the same wep_key0, if you
think that the problem could depend on the key itself;

and I will check if I could get somewhere this model of AP for a test;

	matthias
Comment 14 Bruce M Simpson 2009-03-24 01:08:33 UTC
John Hay wrote:
> I found doing a -bgscan before it happens, make it not happen. I now
> have -bgscan in my rc.conf.
>   

That's exactly the workaround I needed. Thanks John.

As Sam points out, the root fix is probably already in HEAD; it would be 
nice to find time to backport, but this works for us for now as a 
workaround (we are just using ath0 as a STA for testing in the lab at 
the moment, it is likely we will use hostap later).

cheers,
BMS
Comment 15 Adrian Chadd freebsd_committer 2011-04-11 12:43:53 UTC
Responsible Changed
From-To: freebsd-net->freebsd-wireless

punt to freebsd-wiereless
Comment 16 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:43:24 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.