[Madwifi-users] odd solution to (what I mistakenly assumed was a DHCP) problem

[Rosenstrauch, D. <dav...@cs...>]

Hi.  I'd been having a problem which I thought was the DHCP issue many people reported here, but it looks like was not the case after all.  I think I've solved the problem, but I'd like to know 1) if I understand what the problem actually was, and 2) if I solved it properly.

I've got a D-Link DWL-G650 card, and it worked fine with madwifi for several months.  I don't pull the latest CVS updates too often, though, and was running on a CVS snapshot from June for quite a while.  However, every time I tried to upgrade to a more recent snapshot I could never get it to work properly.  I was finally determined to fix this though, and spent the last 2 evenings digging into it.

I originally suspected that I was suffering from some DHCP issues, but the solution posted here in the list archives (use dhcpcd -s) didn't fix it.  After reading the archives some more I then thought that perhaps it might be an issue with turbo mode, that could be solved with some iwpriv commands, but that failed too.

Anyway, it turns out that the last possibility at least put me on the right track, and I was finally able to solve it last night.  I just wanted to get some clarification on my solution though.


In the past it had always been pretty easy for me to get madwifi working.  I just set a bare minimum of iwconfig parameters (ESSID, rate, key, and channel) and everything worked great.  Everything else would get autonegotiated with my AP to the proper settings (e.g., 80211.g mode, etc.).  One thing that I was specifying explictly however was a rate of 54M.  With the June CVS code, the card would accept that setting, associate properly, and hold the connection steady at 54M (or at least report that it was doing so) for the duration of the session.

However, it turns out that this rate setting of 54M is what was causing my problems with the latest CVS code.  Once I took that out of the iwconfig settings, I was finally able to get it running no problem.  The card would now associate initially at 54M, but then periodically change the rate up or down (e.g., 48, 36, 22) during the session - I assume due to link quality fluctuations.


My questions then (finally) are:

* Why should my specifying a rate of 54M prevent the card from associating properly?  (And why did that setting work with the old code?)

* Does the solution that I'm using (only setting 3 settings:  ESSID, key, and channel) sound OK?  Or to use the card properly, should I really be setting more iwconfig/iwpriv settings?

* Is it normal for the connection speed to fluctuate like it now does from 54 down to 22 and back?  It never used to do that with the old CVS code.

And lastly,

* How does one go about debugging problems more efficiently?  I wasted a lot of time going on the assumption that the problem was a DHCP issue, when it wasn't.  If I had known that the card wasn't associating - and why not - I could have saved a lot of time.  Is there any easy way to debug what the card is doing?  i.e., whether it's associated, with which AP, at what settings, etc.  The entries in everything.log weren't much help.  In fact the most helpful thing I could find was the KDE wireless network monitor, but even that would only tell me when it was associated (and assigned an IP) but no helpful information when it wasn't associating.


These issues aside, I do want to give my kudos to the developers on making this driver available.  It's a great help to me!

TIA for the help,

DR


==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer: 

http://www.csfb.com/legal_terms/disclaimer_external_email.shtml

==============================================================================