Hello,
as of pre 2.6.25 kernels, kismet monitoring tool does not work with the=
message:
# kismet
Launching kismet_server: //usr/bin/kismet_server
Suid priv-dropping disabled. This may not be secure.
No specific sources given to be enabled, all will be enabled.
Non-RFMon VAPs will be destroyed on multi-vap interfaces (ie, madwifi-n=
g)
Enabling channel hopping.
Enabling channel splitting.
Source 0 (iwl4965): Enabling monitor mode for iwl4965 source interface =
wlan0
channel 6...
=46ATAL: Failed to set channel 6 5:Input/output error
Done.
the same tool works in 2.6.24 kernel.
I have 03:00.0 Network controller: Intel Corporation PRO/Wireless 4965 =
AG or
AGN Network Connection (rev 61), 8086:4230=20
I have ThinkPad T61 laptop.
Btw, will there be support for LED with iwl4965 driver?
The driver version is 1.2.23ks.
--=20
Luk=E1=B9 Hejtm=E1nek
On Tue, Feb 19, 2008 at 02:28:58PM -0800, Chatre, Reinette wrote:
> > as of pre 2.6.25 kernels, kismet monitoring tool does not work with
> > the message: # kismet
> > Launching kismet_server: //usr/bin/kismet_server
> > Suid priv-dropping disabled. This may not be secure.
> > No specific sources given to be enabled, all will be enabled.
> > Non-RFMon VAPs will be destroyed on multi-vap interfaces (ie,
> > madwifi-ng) Enabling channel hopping.
> > Enabling channel splitting.
> > Source 0 (iwl4965): Enabling monitor mode for iwl4965 source
> > interface wlan0 channel 6...
> > FATAL: Failed to set channel 6 5:Input/output error
>
> Please load the driver with debugging enabled (debug=0x43fff) and send
> us the log capturing during this kismet startup.
the log is attached.
--
Luk?? Hejtm?nek
On , Lukas Hejtmanek wrote:
> as of pre 2.6.25 kernels, kismet monitoring tool does not work with
> the message: # kismet
> Launching kismet_server: //usr/bin/kismet_server
> Suid priv-dropping disabled. This may not be secure.
> No specific sources given to be enabled, all will be enabled.
> Non-RFMon VAPs will be destroyed on multi-vap interfaces (ie,
> madwifi-ng) Enabling channel hopping.
> Enabling channel splitting.
> Source 0 (iwl4965): Enabling monitor mode for iwl4965 source
> interface wlan0 channel 6...
> FATAL: Failed to set channel 6 5:Input/output error
Please load the driver with debugging enabled (debug=0x43fff) and send
us the log capturing during this kismet startup.
Thanks
Reinette
2008/3/11 Lukas Hejtmanek <[email protected]>:
> On Mon, Mar 10, 2008 at 05:35:32PM -0700, Chatre, Reinette wrote:
> > sorry for the delay - please do submit a bug at bughost.org to enable us
> > to track this problem.
> >
> > The error you get is strange - the reason why the channel could not be
> > set was because the device is not considered to be ready. Yet, from your
> > debug log all the required steps appear to have completed successfully.
> > Could you please add a print to the function
> > iwl4965-base.c:iwl4965_is_ready to see what the value of priv->status
> > is?
>
> I don't have this problem in 2.6.25-rc3 and rc4. However, it seems that the
> card does not associate with AP if I set iwcofnig wlan0 essid any. Is this
> a bug or a feature? The AP does not use key and is visible.
>
It looks more like mac80211 bug but frankly I would prefer if this
'any' feature will be not supported.
It has security implications. The decision about to which AP to
associate should be left solely to user space.
Tomas
On Tuesday, February 19, 2008 2:44 PM, Lukas Hejtmanek wrote:
> On Tue, Feb 19, 2008 at 02:28:58PM -0800, Chatre, Reinette wrote:
>>> as of pre 2.6.25 kernels, kismet monitoring tool does not work with
>>> the message: # kismet Launching kismet_server:
>>> //usr/bin/kismet_server
>>> Suid priv-dropping disabled. This may not be secure.
>>> No specific sources given to be enabled, all will be enabled.
>>> Non-RFMon VAPs will be destroyed on multi-vap interfaces (ie,
>>> madwifi-ng) Enabling channel hopping.
>>> Enabling channel splitting.
>>> Source 0 (iwl4965): Enabling monitor mode for iwl4965 source
>>> interface wlan0 channel 6... FATAL: Failed to set channel 6
>>> 5:Input/output error
>>
>> Please load the driver with debugging enabled (debug=0x43fff) and
>> send us the log capturing during this kismet startup.
>
> the log is attached.
sorry for the delay - please do submit a bug at bughost.org to enable us
to track this problem.
The error you get is strange - the reason why the channel could not be
set was because the device is not considered to be ready. Yet, from your
debug log all the required steps appear to have completed successfully.
Could you please add a print to the function
iwl4965-base.c:iwl4965_is_ready to see what the value of priv->status
is?
Thanks
Reinette
On Mon, Mar 10, 2008 at 05:35:32PM -0700, Chatre, Reinette wrote:
> sorry for the delay - please do submit a bug at bughost.org to enable=
us
> to track this problem.
>=20
> The error you get is strange - the reason why the channel could not b=
e
> set was because the device is not considered to be ready. Yet, from y=
our
> debug log all the required steps appear to have completed successfull=
y.
> Could you please add a print to the function
> iwl4965-base.c:iwl4965_is_ready to see what the value of priv->status
> is?
I don't have this problem in 2.6.25-rc3 and rc4. However, it seems that=
the
card does not associate with AP if I set iwcofnig wlan0 essid any. Is t=
his=20
a bug or a feature? The AP does not use key and is visible.
--=20
Luk=E1=B9 Hejtm=E1nek