Current-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: if_iwn.c patch to support the 5100...
On Thu, 30 Jul 2009 14:35:26 -0400 christos%zoulas.com@localhost (Christos
Zoulas) wrote:
> This patch seems to work (thanks to Manuel and Sverre for working on it),
>
> [~10000 line patch deleted]
> ...
I have a laptop (Dell Latitude E6400) with a 5300AGN wireless card, but
unfortunately I run NetBSD 5.0 on it and its not really feasible for me
to upgrade right now.
So I decided to see if I could get these patches working in a 5.0 system.
And I've nearly, but not quite, managed it...
I have a 5.0 STABLE kernel that boots, recognises the wireless card and
successfully loads the firmware.
Furthermore wpa_supplicant is able to negotiate with my wireless router
(a Linksys WRT54G) using WPA-PSK to associate with it.
And even better, dhclient is able to successfully request an IP address
from the router.
But then it all goes wrong... :-(
Any attempt to communicate via the wireless network fails, and the kernel
logs the following messages.
arplookup: unable to enter address for AA.BB.CC.DD@ff on null (could
not allocate llinfo)
arpresolve: can't allocate llinfo on iwn0 for AA.BB.CC.DD
I've found the place in sys/netinet/if_arp.c where these messages are
written, but don't understand what the code there is doing well enough to
figure out what is going wrong.
One possibility is that, since this driver was written for -current, perhaps
there has been some change in the way the ARP code interfaces with network
device drivers since 5.0. But again, I don't know enough about this area
of the kernel to see what this might be.
I'd like to hear from anyone who has any pointers as to what I should be
looking for.
For those who are interested, here is more detail on what I did to get
this far.
The patch Christos posted was based on version 1.31 of if_iwn.c. The
version in the 5.0 kernel had been 1.22 at the time the branch was created
and now is 1.22.4.3. The 1.26, 1.23, and 1.24 patches had already been
pulled up to the branch (as versions 1.22.4.1, 1.22.4.2 and 1.22.4.3
respectively).
The 1.25 patch looked like a fairly significant set of changes that might
need to touch a lot of files in the kernel so I decided to skip that one.
Though it actually only adds a call to ifioctl_common() to if_iwn.c, so
maybe I should apply it after all?
I ended up applying just the 1.27 - 1.31 patches and then the patch that
Christos posted. The latter patch applied cleanly apart from a couple of
lines of fuzz caused by the unapplied 1.25 patch.
Both if_iwnreg.h and if_iwnvar.h were at 1.4 in the netbsd-5 branch and needed
to be at 1.5 for the patches Christos posted. So I applied the 1.4 -> 1.5
patches to those files first.
I also needed to add some lines to dev/pci/pcidevs and regenerate the
pcidevs.h and pcidevs_data.h files so that the device would be
recognised.
The result of all this was, as mentioned above, a kernel which booted and
which seems to allow the device to get most of the way towards working.
If anyone knows what I'm missing that is causing the arp problems I'd
love to hear from them.
Finally, I'm more than happy to make my patches available if anyone is
interested. But note that my approach (effectively upgrading the if_iwn
driver to -current) may not be the right way of approaching this problem.
A better approach may be to modify the patches Christos posted so they
apply cleanly to the driver shipped with 5.0.
Thanks,
Duncan
Home |
Main Index |
Thread Index |
Old Index