7.0-RELEASE && panic after ~4 hours

[Sepherosa Ziehau]

On Thu, Mar 27, 2008 at 1:53 PM, Sam Leffler <sam at freebsd.org> wrote:
>
> Sepherosa Ziehau wrote:
>  > On Thu, Mar 27, 2008 at 1:56 AM, Sam Leffler <sam at freebsd.org> wrote:
>  >> Alphons "Fonz" van Werven wrote:
>  >>
>  >>> Sam Leffler wrote:
>  >>  >
>  >>  >> I am aware only of issues with USB adapters being removed while
>  >>  >> wpa_supplicant is running.
>  >>  >
>  >>  > Actually, there's more I'm afraid.
>  >>  >
>  >>  > iwi: Don't know because I don't use that one. But it's a "cousin" of
>  >>  > wpi and
>  >>  >      if I'm not mistaken it was the same person who initiated
>  >>  > development of
>  >>  >      both drivers.
>  >>  >
>  >>  > wpi: No panics, but just doesn't work with wpa_supplicant at all
>  >>  > (fails to
>  >>  >      associate). This is a known problem and people are working on it.
>  >>
>  >>  You said there were panics; please point me at PR's that show them or
>  >>  stop saying it.  Also these drivers are completely different and linking
>  >>  them is uninformed.
>  >>
>  >>  The problem with almost all the reports I've seen is they lack
>  >>  sufficient info to even respond.  Understand that most all Intel
>  >>  wireless cards up to the 4965 have issues with firmware mis-design that
>  >>  make developing reliable drivers hard (even more so given Intel's
>  >>  unwillingness in helping anyone not using linux).  For example the
>  >>  ipw+iwi drivers try to work around the fact there is no way to scan w/o
>  >
>  > I can't comment on iwi.  For ipw+1.3firmare and in STA mode, clearing
>  > BSSID before starting the firmware can prevent firmware from
>  > auth/assoc.  However, the scan channel mask in STA mode is completely
>  > ignored by firmware, but in IBSS mode, the scan channel mask is
>  > obeyed.  In dfly, I did following stuffs in the new driver (ipw was
>  > dumped):
>  > 1) before scanning (i.e. before starting the firmware; since once the
>  > firmware is started, it will start scanning; scan command is actually
>  > ignored), the BSSID is cleared
>  > 2) After 802.11 generic layer has picked up the BSS to join, reinit
>  > the firmware but this time set the BSSID of the selected BSS to
>  > firmware.
>
>  That's basically how my rewrite of ipw deals with the issue(s).  I
>  invalidate the state so the firmware cannot locate an ap to join.  The
>  problem however is that the firmware will continue to scan until the
>  host resets state such that it can join.  This "skid" leads to various
>  issues that are made worse by the scan abort command not working reliably.

I stop the firmware completely if I want to make some configuration
changes.  Rest of the ways like what Intel's Linux driver does promise
to give a firmware fatal error.  My way obvious does not work with
bgscan :(

>
>  I just did a rewrite of wi that takes a different tack that might also
>  work for ipw.  I set the card in monitor mode and scan using net80211 to

I tried that way, when I wrote the new driver for ipw2100.  It does
not work on certain parts though: some parts can't hear packets or
receive junked packets on channels above 11 when in monitor mode, but
these parts work (e.g. scan) just fine in STA mode on channels above
11.
Linux's intel driver uses different channel mask (different location
in EEPROM) for IBSS and monitor mode, this channel mask contains less
channels than the BSS channel mask.  Though IBSS mode just works fine
on all BSS channels listed in BSS channel mask, monitor mode only work
on channels listed in the other channel mask.

BTW, do you also imply that you inject scan probe packets in monitor mode ;)?

Best Regards,
sephe

>  handle the hard work.  Once scan results are collected the driver then
>  brings the firmware up and instructs it to join a specific bssid on a
>  specific channel.  I expect this will finally allow proper integration
>  with wpa_supplicant.
>
>         Sam
>
>



-- 
Live Free or Die