# Atheros card not recognized



## jwhendy (Jan 7, 2009)

Hi,


I have a Macbook 2,1 (late 2006) with an Atheros wireless card. I've been hunting and hunting to find a definitive answer regarding whether or not it is supported. In Linux, it was supported by the ath9k driver. 

From what I can gather from my research, I have an AR5418 wireless card based on the AR5008E chipset (http://madwifi-project.org/wiki/Chipsets). Linux, if I recall correctly, saw it as an AR5416 card, but it worked. Either way, they are both based on the 5008* chipset and not the 5005VL that is not supported.

The hardware notes (for 7.0-Release)state:


> [i386,pc98,amd64,sparc64] The ath(4) driver supports all Atheros Cardbus or PCI cards, except those that are based on the AR5005VL chipset. A list of cards that are supported can be found at http://customerproducts.atheros.com/customerproducts/default.asp.



This site (http://goddess-gate.com/dc2/index.php/post/251) states that my macbook has the 5008 chipset (as I thought), but says:


> On a Core 2 Duo MacBook, it's an Atheros AR5008 chipset which lacks a device driver. So you can't use it.


 So, are the hardware notes correct or this referenced site?

The FreeBSD wiki lists nothing about wireless.

When I boot, however, I get no recognition of anything Atheros related. 'dmesg|grep atheros' returns nada. ifconfig shows only msk0 (along with the usual lo0 etc.) which is my ethernet (wired) connection which does work under FBSD 7.0.

Could someone tell me why the card might not be recognized? This was the only other post in these forums I could find that might have any relevance: http://forums.freebsd.org/showthread.php?t=382&highlight=atheros. It states that the ath_hal does not support PCIe - not sure what that means. Could that be the case here?

Anyway, lots of ramblings. The Generic kernel has ath4 built-in, so I doubt it's a module not being loaded issue. I'm EXTREMELY new to FreeBSD, so please forgive me if I did not post something obvious. I could give you my whole dmesg, or ifconfig output if that would be helpful, but I figured for now stating that dmesg has no atheros card recognized and that ifconfig lists no ath* interface would be enough.

Thanks for any help and/or suggestions.


-John


----------



## tingo (Jan 7, 2009)

I don't have a Macbook, but I can help a bit.
Use the pciconf() command to find out what (pci) devices you have in a machine.
Like this `% pciconf -lv` (or probably `% pciconf -lv | more`). Then you will more easily find out what kind of wireless card you have.


----------



## oliverh (Jan 7, 2009)

>It states that the ath_hal does not support PCIe - not sure what that means. Could that be the case here?

Could be possible, if so you have to install a new hal. You could take this hal (http://people.freebsd.org/~sam/hal-20081015-sanitized.tgz) from Sam Leffler and copy it to /usr/src/sys/contrib/dev/ath. Then you have to recompile your kernel.


----------



## jwhendy (Jan 9, 2009)

I did pciconf and did, indeed, see the Atheros card listed, which is weird as I swear I didn't see it in dmesg... I wonder if the driver isn't picking it up/it isn't recognized other than simply being probed also because, for example, the ethernet is identified as something like mskc0@00x00 (I really should have copied down the exact dealio - had to boot into OS X to send this, but you get the picture), however the Atheros card, while listed, has none3@00x00. There are 4 devices with 'none*' as their identifier, which I'm thinking refers to the driver/identified device. The ethernet card is msk0, quite similar to the identifier listed above.

What might be the cause of FreeBSD being able to probe the device but not create an actual node for it in /dev?

Thanks for reading through my ramblings. I'm still learning quite a lot! One of the reasons I switched from Linux is that I read a lot about FreeBSD being sane, understandable, rational, well-engineered, and well documented. I decided if I was going to learn something in the *nix world, I wanted to actually understand what I was doing and _know_ my operating system. On Linux I had no idea what I was doing (well, not entirely true) and just typed commands others told me to without really grasping how the operating system was functioning with respect to the hardware, CPU, etc. Add that to the fact that what worked on my distro (Zenwalk - Slackware based) might not work on another distro... Add that to the fact that 90% of solutions to problems apply to Ubuntu (Debian roots) and might or might not work on my system... bummer. This time around, I'm trying to start from scratch and actually understand the OS 

Thanks for the help,
John


----------



## trev (Jan 9, 2009)

From a quick look through the generic kernel, and the man page for ath_hal, it seems that only the Atheros chipsets connected to a PCI or cardbus interface are supported, but not those connected to a PCI-E (aka PCI-Express) interface.

However, this morning I noticed that last night's csup of 7-STABLE source updates included some new new ath_hal... digging into the source files I now notice:

ah_devid.h:#define AR5416_DEVID_PCIE    0x0024          /* AR5416 PCI-E (XB) Owl */
ah_devid.h:#define AR9280_DEVID_PCIE    0x002a          /* AR9280 PCI-E Merlin */
ah_devid.h:#define AR9285_DEVID_PCIE    0x002b          /* AR9285 PCI-E Kite */

which looks like the beginning of support for PCI-E interfaced Atheros devices. Hmmm... "AR5416_DEVID_PCIE" looks interesting.

You might want to update your source from 7-STABLE and recompile the system.


----------



## tingo (Jan 9, 2009)

jwhendy said:
			
		

> (I really should have copied down the exact dealio - had to boot into OS X to send this, but you get the picture)


Well usually you can do things like `% pciconf -lv > filename.txt` and then copy the file to a usb stick or some other removable media if you don't have network connectivity on a machine.



> , however the Atheros card, while listed, has none3@00x00.
> What might be the cause of FreeBSD being able to probe the device but not create an actual node for it in /dev?


It just means that the driver was unable to attach for some reason. It could be that the card is unsupported, that your need a newer hal, or something else.
To find out why, you need to read the dmesg messages. Try `% dmesg | less`. If you can't find anything out from the normal dmesg, you need to do a verbose boot.
HTH


----------



## jwhendy (Jan 9, 2009)

Perfect - thanks to both for the input.

- I'll get a better post of the pciconf output and post that.
- I'll also hunt through dmesg better and scan for anything related to wireless or Atheros.

How would I know if my card is PCI or PCI-E? Would that be part of the pciconf output? I don't recall seeing that, but could check again. When figuring this out for Linux, I recall that I had a 5418 card, which according to the Madwifi site (linux drivers) is PCI Express. 5416 and 5418 are closely related - one is based on chipset 5008 and the other on 5008E[xpress], respectively. Maybe the changes applying to 5416 you mentioned will work.

I'm in the midst of upgrading to 7.1 - would that incorporate all of the referenced changes in 7.0-stable to Atheros PCI Express support that you referenced?

Thanks,
John


----------



## trev (Jan 10, 2009)

pciconf should show you the relevant interface, for example:


```
re0@pci0:2:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x01 hdr=0x00
    vendor     = 'Realtek Semiconductor'
    device     = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
```

If you upgrade to 7.1-RELEASE, you can the do a csup using the:

*default release=cvs tag=RELENG_7_1

tag to get the current STABLE version source files.


----------



## jwhendy (Jan 10, 2009)

So...

pciconf -lv just shows:

```
none3@pci0:2:0:0: class=0x028000 card=0x0087106b chip=0x0024168c rev=0x01
hrd=0x00
   vendor = 'Atheros Communications Inc.'
   device = 'AR5008 Atheros 802.11a/b/g/n (pre-N) radio'
   class = network
```

I'm not seeing anything about whether it's PCI-E or not... In other places I have seen a distinction made between 5008 and 5008E (pci and pcie, respectively) so I'm not sure if FreeBSD distinguishes or not.

I'll try the new hal perhaps. I used freebsd-update to upgrade to 7.1 today but still don't have the card recognized.

dmesg (attached) shows ath_hal starting and on pci2 (which matches the pciconf output above) has 
	
	



```
pci2:<network> at device 0.0 (no driver attached)
```

I'll try new ath's or something next. I've not rebuilt my kernel yet, so I'll be reading up on that process. It seemed fairly straight forward: edit config (copied version from GENERIC), make buildkernel..., then make installkernel.


Thanks,
John


----------



## trev (Jan 10, 2009)

jwhendy said:
			
		

> So...
> 
> pciconf -lv just shows:
> 
> ...



Bummer.



			
				jwhendy said:
			
		

> I'll try new ath's or something next. I've not rebuilt my kernel yet, so I'll be reading up on that process. It seemed fairly straight forward: edit config (copied version from GENERIC), make buildkernel..., then make installkernel.



To grab the current stable source code,  copy /usr/src/share/examples/cvsup/stable-supfile somewhere (I keep mine in /root) and edit the 

*default host=CHANGE_THIS.FreeBSD.org

line to select a cvsup host close to you (for a list see:http://www.freebsd.org/doc/en/books/handbook/cvsup.html#HANDBOOK-MIRRORS-CHAPTER-SGML-CENTRAL-CVSUP ), then use csup (part of the base system - not cvsup) as in "csup stable-supfile".

Then to just rebuild GENERIC, no need to edit anything, simply cd /usr/src, make -j2 buildkernel && make installkernel && shutdown -r now.


----------



## jwhendy (Jan 10, 2009)

Thanks for the help. I've been using portsnap to keep my ports tree up to date. If I've already run

```
portsnap fetch
portsnap extract
```
is there anything I wouldn't have gotten via the csup method? I have tried to read up on csup/cvsup and portsnap and thought I read portsnap had some advantages. I'm not really experienced with either so I could pretty easily make a switch if this isn't what I should be using... I also read that portsnap and csup are incompatible (use one or the other, not both).

Just wondering if I already done the essential step (I'm imagining this is getting an updated ath/ath_hal source) via portsnap?

As an aside, would you recommend switching from portsnap to csup? Do their duties overlap and is csup better? I've been reading a bunch about them since this post but have not seen anything that really shows me who one is superior...


Thanks!
John


----------



## jwhendy (Jan 10, 2009)

Sorry... figure out the portsnap vs csup problem...

portsnap = update /usr/ports
csup (when used with src-all) = update /usr/src

From my reading it appears on could use csup for everything (ports, doc, and src), but only if it's specified in the supfile by specifying 'ports-all' in the file.

I'm grabbing the stable source for 7.1 (hopefully did that correctly by having '*default release= cvs tag =RELENG_7_1'). I'll recompile and let you know how things turned out.


Thanks,
John


----------



## jwhendy (Jan 10, 2009)

Update: did 
	
	



```
csup stable-supfile
cd /usr/src
make -j2 buildkernel && make installkernel
reboot
```
dmesg is the same wrt the device at pci2 - says <network> device no driver attached...

Any other suggestions?

ath9k from madwifi worked in linux for me, and was built into the kernel. Could I grab that module (ath9k.ko I think) and use it in FreeBSD somehow? I also found AR5008/AR5008E windows drivers online. Is it possible to use those somehow?

Thanks,
John


----------



## Djn (Jan 10, 2009)

It is actually possible to use windows drivers for some network cards by using the NDISulator - see this.

There's also another thing you can try, if you feel slightly brave: Updating to 8-CURRENT (the very newest, most experimental FreeBSD version) isn't very hard. The canonical procedure is here, but in short:

Edit the supfile to read "tag=." instead of "tag=RELENG_7_1"
csup
mergemaster -p
make buildworld buildkernel installkernel
reboot
make installworld
mergemaster -i (let it install new versions of anything except config files you've edited)
reboot again

I have no idea if CURRENT supports it, though - it's basically a shot in the dark (until someone knowledgeable can check).


----------



## jwhendy (Jan 11, 2009)

I tried the ndis method, but not quite as you said. I found some posts and followed those. First I downloaded the win drivers (.inf/.sys files), then did 
	
	



```
ndisgen ./file.inf ./file.sys
kldload createdModule.ko
kldload ndis
kldload if_ndis
```

The site I followed said that I should have seen something in dmesg noting that the driver had attached to the wireless device. I saw no such method. I thought maybe a reboot was required... I moved the module to /boot/modules/ and then put this in /boot/loader.conf

```
createdModule_load="YES"
ndis_load="YES"
if_ndis_load="YES"
```

After a reboot I still see no driver attached to pci2 via 'pciconf -lv' (looks just like above posting) and nothing in dmesg other than what is posted above ('pci2: <network> at device 0.0 (no driver attached)). I did check kldstat after rebooting and verified that createdModule, ndis, and if_ndis had all loaded.

I'd prefer not to try the upgrade-to-8 method at this point. Not worth it for me. I'd love to have wireless, but I'm planning to use FreeBSD mostly for learning Unix and working on my programming. It will be a bummer not to have internet, as I use it mostly for searching for answers and how tos for things I don't know how to do!

Is what I did different than the ndisemulator method or should this have worked? I did try two sets of drivers I found. One of the downloads had 2 sets, an ath.sys and athx.sys (I think for 5008 and 5008X, respectively). Ndisgen worked for both but twice when I tried 'kldload athx.ko' it crashed my system (mouse froze, no keyboard shortcuts worked, etc.). I figure that can't be the right module then...  

Thoughts?

Thanks,
John


----------



## jwhendy (Jan 12, 2009)

Success!

I started wondering if it was the amd64 version I was using that was messing up the drivers by chance. I did a reinstall of i386 and repeated the exact steps for the ndisgen of the drivers and _boom_, ndis0 appeared! I read, and read, and read online about how to get the interface configured with little success. Then at the last second I, just for the heck of it, did 'dhclient ndis0' and it worked! I couldn't believe it.

It really would be helpful to have a better tutorial of ifconfig and related things. Trying to follow the handbook, for whatever reason, was tough for me. I kept getting 'host could not be resolved' when trying to ping an address (http://www.google.com) and 'no route to host' when trying to ping an IP directly. dhclient fixed all that. I turned security off on my router for now just to give me one less thing to worry about. My next task will be to get WPA working.

Anyway, thanks all for the generous help and suggestions. I should be all set on this issue now. I'm upgrading my 7.0-i386 to 7.1 as we speak via wireless.

This was about the only thing I just COULDN'T see myself living without when considering sticking with FreeBSD as any sort of major-usage OS (vs. being in Mac OS X world most of the time). Now I'm definitely sticking with it!

Thanks!! 
John

P.S. Any input regarding why amd64 didn't work with those drivers and if/when they might work with the amd64 FBSD version?


----------



## Sylgeist (Jul 22, 2010)

I was looking at picking up the mini-pcie version for the infamous D510 Intel board. Does anyone know if the PCIE version is supported in 8/8.1? The hardware notes still only say everything except the 5005VL chipset is supported.


----------

