Hello list!
Sorry for this slightly off-topic post (as I have not tried the latest wirless-dev git version)...
When trying to set up an ad-hoc interface on iwl4965 (version 1.2.23 according to modinfo) on recently released kernel 2.6.25-rc1 it seems to work at first glance (accepts setting of channel and essid, starts beaconing and receives frames just fine) but the TX part does not work at all. Frames are shown in "tcpdump -i wlan0" but never make it into the air (checked with dedicated machine equipped with an Atheros card running in monitor mode).
With 2.6.24 (iwl4965 version 1.1.17) everything worked fine. System is Debian Lenny amd64 on a Thinkpad T61p.
Unfortunately I do not have the time to debug this intensively, so any hints what to check first are welcome! Did something with the last big API change in mac80211 went wrong?
Richard
On Wednesday, February 13, 2008 1:07 AM, Richard Scherping wrote:
>> iwl4965: I iwl4965_tx_skb Dropping - !iwl4965_is_associated:
>> iwl4965_is_associated(priv)=1; priv->assoc_id=0;
>> priv->assoc_station_added=1
>
> Simply uncommenting the check for priv->assoc_id to be
> non-zero (line 2938 in iwl4965-base.c) made ad-hoc working.
> Thanks for helping me to find this!
> Does this change have any negative side effects?
>
> Richard
Could you please try the attached patch instead?
Thanks
Reinette
Am Freitag, 15. Februar 2008 01:21:15 schrieb Chatre, Reinette:
> On , Chatre, Reinette wrote:
> > On Thursday, February 14, 2008 3:40 PM, Patrick Grimm wrote:
> >> For me not.
> >> I use 3945ABG card in an ad-hoc network with 4 other wlan devices
> >> like rt2500 and ath5k. I have applied your
> >> 0001-iwlwifi-only-check-for-association-id-when-associat.patch
> >> patch. But i can't see incoming packets witch tcpdump.
> >> I have try to commet out the check for associat with the same
> >> result.
> >>
> >> dmesg
> >> iwl3945: I iwl3945_rx_handle r = 76, i = 75, REPLY_3945_RX, 0x1b
> >> iwl3945: I iwl3945_rx_handle r = 77, i = 76, REPLY_3945_RX, 0x1b
> >> iwl3945: I iwl3945_mac_tx enter
> >> iwl3945: I iwl3945_tx_skb Dropping - !iwl3945_is_associated
> >> iwl3945: I iwl3945_mac_tx leave
> >> iwl3945: I iwl3945_rx_handle r = 78, i = 77, REPLY_3945_RX, 0x1b
> >> iwl3945: I iwl3945_rx_handle r = 79, i = 78, REPLY_3945_RX, 0x1b
> >
> > When you say "with the same result" does it mean that you comment out
> > the check for priv->assoc_id and you still see the error "Dropping -
> > !iwl3945_is_associated" or do you then see traffic with tcpdump?
I mean that I don't see traffic with tcpdump and I don't see the Dropping
error.
> >
> > Could you please print out the values of fc, priv->iw_mode,
> > iwl3945_is_associated(priv) and priv->assoc_id just before that error
> > message is printed?
Yes
iwl3945: I iwl3945_tx_skb fc: 8<3>
iwl3945: I iwl3945_tx_skb mode: 2<3>
iwl3945: I iwl3945_tx_skb assoc_id: 0<3>
iwl3945: I iwl3945_tx_skb Dropping - !iwl3945_is_associated
My changes
IWL_DEBUG_DROP("fc: %d\n", fc);
IWL_DEBUG_DROP("mode: %d\n", priv->iw_mode);
IWL_DEBUG_DROP("assoc_id: %d\", priv->assoc_id);
if ((!iwl3945_is_associated(priv) ||
((priv->iw_mode == IEEE80211_IF_TYPE_STA) && !priv->assoc_id)) &&
((fc & IEEE80211_FCTL_FTYPE) == IEEE80211_FTYPE_DATA)) {
IWL_DEBUG_DROP("Dropping - !iwl3945_is_associated\n");
goto drop_unlock;
}
Was it right?
>
> One more question ... did ad-hoc work for you before this patch?
No. In my tests only ipw3945 works in Ad-Hoc mode.
Chatre, Reinette schrieb:
>>> One more question ... did ad-hoc work for you before this patch?
>> No. In my tests only ipw3945 works in Ad-Hoc mode.
>
> ok - that explains things. The patch assumes that ad-hoc mode is
> working, which is unfortunately not the case. We have to fix this.
>
> Reinette
As I said, I have tested with iwl4965 only. Seems as if there are more problems with ad-hoc and iwl3945.
Did ad-hoc work in the "old" iwl3945 (before the API change with old version 1.1.17, compared to new version 1.2.23/26)?
Richard
On Friday, February 15, 2008 1:13 PM, Richard Scherping wrote:
> Chatre, Reinette schrieb:
>>>> One more question ... did ad-hoc work for you before this patch?
>>> No. In my tests only ipw3945 works in Ad-Hoc mode.
>>
>> ok - that explains things. The patch assumes that ad-hoc mode is
>> working, which is unfortunately not the case. We have to fix this.
>>
>> Reinette
>
> As I said, I have tested with iwl4965 only. Seems as if there
> are more problems with ad-hoc and iwl3945.
I understand. Thanks for your testing. There indeed appears to be more
problems with ad-hoc and iwl3945, but they are unrelated to the patch
that you tested.
> Did ad-hoc work in the "old" iwl3945 (before the API change
> with old version 1.1.17, compared to new version 1.2.23/26)?
This needs to be checked. We do have some bug reports about ad-hoc mode
in iwl3945 (see http://www.bughost.org/bugzilla/show_bug.cgi?id=1472).
In this case it was specific to ad-hoc mode in b mode. We will look more
into ad-hoc mode with iwl3945.
Reinette
On Thursday, February 14, 2008 5:29 PM, Patrick Grimm wrote:
>>> Could you please print out the values of fc, priv->iw_mode,
>>> iwl3945_is_associated(priv) and priv->assoc_id just before that
>>> error message is printed?
>
> Yes
> iwl3945: I iwl3945_tx_skb fc: 8<3>
> iwl3945: I iwl3945_tx_skb mode: 2<3>
> iwl3945: I iwl3945_tx_skb assoc_id: 0<3>
> iwl3945: I iwl3945_tx_skb Dropping - !iwl3945_is_associated
> My changes
> IWL_DEBUG_DROP("fc: %d\n", fc);
> IWL_DEBUG_DROP("mode: %d\n", priv->iw_mode);
> IWL_DEBUG_DROP("assoc_id: %d\", priv->assoc_id);
> if ((!iwl3945_is_associated(priv) ||
> ((priv->iw_mode == IEEE80211_IF_TYPE_STA) &&
> !priv->assoc_id)) &&
> ((fc & IEEE80211_FCTL_FTYPE) == IEEE80211_FTYPE_DATA)) {
> IWL_DEBUG_DROP("Dropping - !iwl3945_is_associated\n");
goto
> drop_unlock; }
> Was it right?
great - thanks!
I think you have given us hints about why ad-hoc does not work in
iwl3945. From the above the device thinks it is in STA mode, it should
be in IBSS mode. This is thus a different bug from what the patch is
trying to solve. The patch is still good for iwl3945.
>> One more question ... did ad-hoc work for you before this patch?
>
> No. In my tests only ipw3945 works in Ad-Hoc mode.
ok - that explains things. The patch assumes that ad-hoc mode is
working, which is unfortunately not the case. We have to fix this.
Reinette
Am Samstag, 16. Februar 2008 01:19:07 schrieb Patrick Grimm:
> Am Freitag, 15. Februar 2008 22:12:36 schrieb Richard Scherping:
> > Chatre, Reinette schrieb:
> > >>> One more question ... did ad-hoc work for you before this patch?
> > >>
> > >> No. In my tests only ipw3945 works in Ad-Hoc mode.
> > >
> > > ok - that explains things. The patch assumes that ad-hoc mode is
> > > working, which is unfortunately not the case. We have to fix this.
> > >
> > > Reinette
> >
> > As I said, I have tested with iwl4965 only. Seems as if there are more
> > problems with ad-hoc and iwl3945. Did ad-hoc work in the "old" iwl3945
> > (before the API change with old version 1.1.17, compared to new version
> > 1.2.23/26)?
>
> I have made some short tests with my working kernel 2.6.23.
With 2 Ad-Hoc Nodes.
> Version 1.1.17 - 1.1.22 Ad-Hoc mode is working.
> Version 1.1.23 - Ad-Hoc mode is not working.
The iwlwifi versions 1.1.17 - everything is not working
with more then 2 Ad-Hoc Nodes.
Please keep me updated I will test your patches again.
Patrick
On , Richard Scherping wrote:
> Hello list!
>
> Sorry for this slightly off-topic post (as I have not tried
> the latest wirless-dev git version)...
>
> When trying to set up an ad-hoc interface on iwl4965 (version
> 1.2.23 according to modinfo) on recently released kernel
> 2.6.25-rc1 it seems to work at first glance (accepts setting
> of channel and essid, starts beaconing and receives frames
> just fine) but the TX part does not work at all. Frames are
> shown in "tcpdump -i wlan0" but never make it into the air
> (checked with dedicated machine equipped with an Atheros card running
> in monitor mode). With 2.6.24 (iwl4965 version 1.1.17) everything
> worked fine. System is Debian Lenny amd64 on a Thinkpad T61p.
>
> Unfortunately I do not have the time to debug this
> intensively, so any hints what to check first are welcome! Did
> something with the last big API change in mac80211 went wrong?
We have not done ad-hoc testing in the recent code. Any debugging you
can do will be greatly appreciated (anything interesting in your logs?).
Just to confirm the monitor mode is ok, can you confirm that your
monitoring machine can see data between a host and AP? We have seen some
problems with monitoring in iwlwifi so I would like to make sure.
Please load the driver with debugging (debug=0x43fff) and send us what
you see during data transmission. It may be useful to open a bug at
bughost.org at this point for us to keep track of the problem.
Thanks!
Reinette
Chatre, Reinette schrieb:
> On Wednesday, February 13, 2008 1:07 AM, Richard Scherping wrote:
>
>>> iwl4965: I iwl4965_tx_skb Dropping - !iwl4965_is_associated:
>>> iwl4965_is_associated(priv)=1; priv->assoc_id=0;
>>> priv->assoc_station_added=1
>> Simply uncommenting the check for priv->assoc_id to be
>> non-zero (line 2938 in iwl4965-base.c) made ad-hoc working.
>> Thanks for helping me to find this!
>> Does this change have any negative side effects?
>>
>> Richard
>
> Could you please try the attached patch instead?
Works for me (iwl4965). Thanks!
Richard
On Thursday, February 14, 2008 3:40 PM, Patrick Grimm wrote:
> Am Donnerstag, 14. Februar 2008 19:26:54 schrieb Richard Scherping:
>> Chatre, Reinette schrieb:
>>> On Wednesday, February 13, 2008 1:07 AM, Richard Scherping wrote:
>>>>> iwl4965: I iwl4965_tx_skb Dropping - !iwl4965_is_associated:
>>>>> iwl4965_is_associated(priv)=1; priv->assoc_id=0;
>>>>> priv->assoc_station_added=1
>>>>
>>>> Simply uncommenting the check for priv->assoc_id to be
>>>> non-zero (line 2938 in iwl4965-base.c) made ad-hoc working.
>>>> Thanks for helping me to find this!
>>>> Does this change have any negative side effects?
>>>>
>>>> Richard
>>>
>>> Could you please try the attached patch instead?
>>
>> Works for me (iwl4965). Thanks!
> For me not.
> I use 3945ABG card in an ad-hoc network with 4 other wlan devices
> like rt2500 and ath5k. I have applied your
> 0001-iwlwifi-only-check-for-association-id-when-associat.patch
> patch. But i can't see incoming packets witch tcpdump.
> I have try to commet out the check for associat with the same result.
>
> dmesg
> iwl3945: I iwl3945_rx_handle r = 76, i = 75, REPLY_3945_RX, 0x1b
> iwl3945: I iwl3945_rx_handle r = 77, i = 76, REPLY_3945_RX, 0x1b
> iwl3945: I iwl3945_mac_tx enter
> iwl3945: I iwl3945_tx_skb Dropping - !iwl3945_is_associated
> iwl3945: I iwl3945_mac_tx leave
> iwl3945: I iwl3945_rx_handle r = 78, i = 77, REPLY_3945_RX, 0x1b
> iwl3945: I iwl3945_rx_handle r = 79, i = 78, REPLY_3945_RX, 0x1b
When you say "with the same result" does it mean that you comment out
the check for priv->assoc_id and you still see the error "Dropping -
!iwl3945_is_associated" or do you then see traffic with tcpdump?
Could you please print out the values of fc, priv->iw_mode,
iwl3945_is_associated(priv) and priv->assoc_id just before that error
message is printed?
Thanks!
Reinette
On , Chatre, Reinette wrote:
> On Thursday, February 14, 2008 3:40 PM, Patrick Grimm wrote:
>> For me not.
>> I use 3945ABG card in an ad-hoc network with 4 other wlan devices
>> like rt2500 and ath5k. I have applied your
>> 0001-iwlwifi-only-check-for-association-id-when-associat.patch
>> patch. But i can't see incoming packets witch tcpdump.
>> I have try to commet out the check for associat with the same
>> result.
>>
>> dmesg
>> iwl3945: I iwl3945_rx_handle r = 76, i = 75, REPLY_3945_RX, 0x1b
>> iwl3945: I iwl3945_rx_handle r = 77, i = 76, REPLY_3945_RX, 0x1b
>> iwl3945: I iwl3945_mac_tx enter
>> iwl3945: I iwl3945_tx_skb Dropping - !iwl3945_is_associated
>> iwl3945: I iwl3945_mac_tx leave
>> iwl3945: I iwl3945_rx_handle r = 78, i = 77, REPLY_3945_RX, 0x1b
>> iwl3945: I iwl3945_rx_handle r = 79, i = 78, REPLY_3945_RX, 0x1b
>
> When you say "with the same result" does it mean that you comment out
> the check for priv->assoc_id and you still see the error "Dropping -
> !iwl3945_is_associated" or do you then see traffic with tcpdump?
>
> Could you please print out the values of fc, priv->iw_mode,
> iwl3945_is_associated(priv) and priv->assoc_id just before that error
> message is printed?
One more question ... did ad-hoc work for you before this patch?
Thanks
Reinette
Am Donnerstag, 14. Februar 2008 19:26:54 schrieb Richard Scherping:
> Chatre, Reinette schrieb:
> > On Wednesday, February 13, 2008 1:07 AM, Richard Scherping wrote:
> >>> iwl4965: I iwl4965_tx_skb Dropping - !iwl4965_is_associated:
> >>> iwl4965_is_associated(priv)=1; priv->assoc_id=0;
> >>> priv->assoc_station_added=1
> >>
> >> Simply uncommenting the check for priv->assoc_id to be
> >> non-zero (line 2938 in iwl4965-base.c) made ad-hoc working.
> >> Thanks for helping me to find this!
> >> Does this change have any negative side effects?
> >>
> >> Richard
> >
> > Could you please try the attached patch instead?
>
> Works for me (iwl4965). Thanks!
For me not.
I use 3945ABG card in an ad-hoc network with 4 other wlan devices
like rt2500 and ath5k.
I have applied your
0001-iwlwifi-only-check-for-association-id-when-associat.patch
patch. But i can't see incoming packets witch tcpdump.
I have try to commet out the check for associat with the same
result.
dmesg
iwl3945: I iwl3945_rx_handle r = 76, i = 75, REPLY_3945_RX, 0x1b
iwl3945: I iwl3945_rx_handle r = 77, i = 76, REPLY_3945_RX, 0x1b
iwl3945: I iwl3945_mac_tx enter
iwl3945: I iwl3945_tx_skb Dropping - !iwl3945_is_associated
iwl3945: I iwl3945_mac_tx leave
iwl3945: I iwl3945_rx_handle r = 78, i = 77, REPLY_3945_RX, 0x1b
iwl3945: I iwl3945_rx_handle r = 79, i = 78, REPLY_3945_RX, 0x1b
Patrick
> iwl4965: I iwl4965_tx_skb Dropping - !iwl4965_is_associated:
> iwl4965_is_associated(priv)=1; priv->assoc_id=0;
> priv->assoc_station_added=1
Simply uncommenting the check for priv->assoc_id to be non-zero (line 2938 in iwl4965-base.c) made ad-hoc working. Thanks for helping me to find this!
Does this change have any negative side effects?
Richard
Am Freitag, 15. Februar 2008 22:12:36 schrieb Richard Scherping:
> Chatre, Reinette schrieb:
> >>> One more question ... did ad-hoc work for you before this patch?
> >>
> >> No. In my tests only ipw3945 works in Ad-Hoc mode.
> >
> > ok - that explains things. The patch assumes that ad-hoc mode is
> > working, which is unfortunately not the case. We have to fix this.
> >
> > Reinette
>
> As I said, I have tested with iwl4965 only. Seems as if there are more
> problems with ad-hoc and iwl3945. Did ad-hoc work in the "old" iwl3945
> (before the API change with old version 1.1.17, compared to new version
> 1.2.23/26)?
I have made some short tests with my working kernel 2.6.23.
Version 1.1.17 - 1.1.22 Ad-Hoc mode is working.
Version 1.1.23 - Ad-Hoc mode is not working.
Changes in 1.2.23
* fix problem when rf_kill switch change during suspend/resume
* fix possible priv->mutex deadlock during suspend
* 3954 renames iwl3945_rate_scale_priv to iwl3945_rs_sta
* 4965 unify rate scale variable names for station data
* move uCode helper functions to iwl-helpers.h
* Makefile: enable building using "make -C /path/to/iwlwifi"
* fix iwl_mac_add_interface handler
* Fix race conditional panic
* remove redundant declaration of 'iwl3945_priv' and 'iwl4965_priv' structs
* document scan command
* remove iwl4965_tx_cmd
* move iwl4965_get_dma_hi_address function to iwl-helpers.h
* fix rate control algo reference leak
* fix rf_kill state inconsistent during suspend and resume
* fix priv->ucode_data_backup save problem
* iwl4965: fix mutex_unlock missed problem in iwl_mac_config exit path
* iwl4965: Remove redundant code in iwl4965_tx_cmd
* fix compilation warnings
* use pci_save_state() before calling pci_disable_device()
* skip mac80211 conf during a hardware scan and replay it afterwards
* delay firmware loading from pci_probe to network interface open
* Makefile: enable HT and HT_AGG by default
Patrick
Chatre, Reinette schrieb:
> We have not done ad-hoc testing in the recent code. Any debugging you
> can do will be greatly appreciated (anything interesting in your logs?).
> Just to confirm the monitor mode is ok, can you confirm that your
> monitoring machine can see data between a host and AP? We have seen some
> problems with monitoring in iwlwifi so I would like to make sure.
The monitoring (as well as the counterpart for ad-hoc operation) was done with madwifi 0.9.3.3 on a different machine with kernel 2.6.22 - a setup that has proven to work for me already.
> Please load the driver with debugging (debug=0x43fff) and send us what
> you see during data transmission. It may be useful to open a bug at
> bughost.org at this point for us to keep track of the problem.
Looking at the debugging output helped a bit:
Feb 12 23:27:37 merom kernel: iwl4965: I iwl4965_mac_tx enter
Feb 12 23:27:37 merom kernel: iwl4965: I iwl4965_tx_skb Dropping - !iwl4965_is_associated
Feb 12 23:27:37 merom kernel: iwl4965: I iwl4965_mac_tx leave
I changed that output to be more verbose:
iwl4965: I iwl4965_tx_skb Dropping - !iwl4965_is_associated: iwl4965_is_associated(priv)=1; priv->assoc_id=0; priv->assoc_station_added=1
This is in line with the following output:
Feb 12 23:44:08 merom kernel: iwl4965: U iwl4965_bg_post_associate Associated as 0 to: 2a:20:22:f0:4f:f0
The full log is available at http://www.scherping.de/misc/iwl4965-2625rc1.txt
What I did is:
merom:/home/richard# uname -a
Linux merom 2.6.25-rc1 #1 SMP Mon Feb 11 08:18:47 CET 2008 x86_64 GNU/Linux
merom:/home/richard# modprobe iwl4965 debug=0x43fff
merom:/home/richard# iwconfig wlan0 mode ad-hoc
merom:/home/richard# ifconfig wlan0 10.0.0.1 up
merom:/home/richard# iwconfig wlan0 channel 1
merom:/home/richard# iwconfig wlan0 essid test
merom:/home/richard# iwconfig wlan0
wlan0 IEEE 802.11g ESSID:"test"
Mode:Ad-Hoc Frequency:2.412 GHz Cell: 2A:20:22:F0:4F:F0
Tx-Power=27 dBm
Retry min limit:7 RTS thr:off Fragment thr=2352 B
Encryption key:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
merom:/home/richard# ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
>From 10.0.0.1 icmp_seq=1 Destination Host Unreachable
>From 10.0.0.1 icmp_seq=2 Destination Host Unreachable
>From 10.0.0.1 icmp_seq=3 Destination Host Unreachable
^C
--- 10.0.0.2 ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4016ms
, pipe 3
merom:/home/richard#
The same thing worked with 2.6.24 - 10.0.0.2 is the other ad-hoc station (MadWifi-based).
Thanks for your help!
Richard