Ath0 not detected on Alix 2D13
-
Can you show a pciconf -lv
Also did you try to boot without acpi or ahci? -
Could be the same as this:
https://forum.pfsense.org/index.php?topic=74571.msg407448#msg407448 -
@ermal:
Can you show a pciconf -lv
Also did you try to boot without acpi or ahci?$ pciconf -lv hostb0@pci0:0:1:0: class=0x060000 card=0x20801022 chip=0x20801022 rev=0x33 hdr=0x00 class = bridge subclass = HOST-PCI none0@pci0:0:1:2: class=0x101000 card=0x20821022 chip=0x20821022 rev=0x00 hdr=0x00 class = encrypt/decrypt vr0@pci0:0:9:0: class=0x020000 card=0x01061106 chip=0x30531106 rev=0x96 hdr=0x00 class = network subclass = ethernet vr1@pci0:0:10:0: class=0x020000 card=0x01061106 chip=0x30531106 rev=0x96 hdr=0x00 class = network subclass = ethernet vr2@pci0:0:11:0: class=0x020000 card=0x01061106 chip=0x30531106 rev=0x96 hdr=0x00 class = network subclass = ethernet none1@pci0:0:12:0: class=0x020000 card=0x1012185f chip=0x0013168c rev=0x01 hdr=0x00 class = network subclass = ethernet isab0@pci0:0:15:0: class=0x060100 card=0x20901022 chip=0x20901022 rev=0x03 hdr=0x00 class = bridge subclass = PCI-ISA atapci0@pci0:0:15:2: class=0x010180 card=0x209a1022 chip=0x209a1022 rev=0x01 hdr=0x00 class = mass storage subclass = ATA ohci0@pci0:0:15:4: class=0x0c0310 card=0x20941022 chip=0x20941022 rev=0x02 hdr=0x00 class = serial bus subclass = USB ehci0@pci0:0:15:5: class=0x0c0320 card=0x20951022 chip=0x20951022 rev=0x02 hdr=0x00 class = serial bus subclass = USBI haven't tried any different boot options. I simply upgraded from 2.1.1-RELEASE to 2.2. The ath0 wireless was working fine on 2.1.1-RELEASE.
I am surprised these things are not upwardly compatible and I expected that any previously-working not-too-old hardware and its driver config from 8.3 would "just work the same" on a later FreeBSD 10.
Let me know anything you would like me to do or show… -
Try tomorrow snapshots please.
-
Yes, will report back tomorrow.
Just a comment about this process now. We cannot see anything of what is happening to pfSense-tools repo. We are flying blind. Yes, that is the way it is with Microsoft products, we try things and report apparent bugs and some time later a "magic fix" (might) appear. But this is an open source project!
I used to debug OpenVMS device drivers. I do have some skills and if I could look at what is in pfSense-tools then I could help spot what some of the issues are. Sure, Ermal can do this stuff himself behind the scenes, but IMHO it is useful to have other sets of eyes to help in the debugging process.
And then people will quickly assume that some security agency is working with ESF to insert "bonus code" into pfSense. Actually I don't think that will be the case, but unless people can see the pfSense mods made to "pf" and other standard FreeBSD components, then they will naturally start to think these things.
Come on ESF, sort out a way for community members to see the code.
-
This was mostly related to kernel config handling.
The tools repo issues is being handled slowly but being handled.
-
Just a comment about this process now. We cannot see anything of what is happening to pfSense-tools repo. We are flying blind. Yes, that is the way it is with Microsoft products, we try things and report apparent bugs and some time later a "magic fix" (might) appear. But this is an open source project!
I used to debug OpenVMS device drivers. I do have some skills and if I could look at what is in pfSense-tools then I could help spot what some of the issues are. Sure, Ermal can do this stuff himself behind the scenes, but IMHO it is useful to have other sets of eyes to help in the debugging process.
And then people will quickly assume that some security agency is working with ESF to insert "bonus code" into pfSense. Actually I don't think that will be the case, but unless people can see the pfSense mods made to "pf" and other standard FreeBSD components, then they will naturally start to think these things.
Come on ESF, sort out a way for community members to see the code.
Phil, these comments distill my concerns exactly, too bad it's buried in this thread (not that these comments make any difference apparently).
A less nefarious concern than three letter agencies and 'bonus code' is simply documentation. When a newbie like me say, tries to dig into a problem using available freebsd documentation, it's very frustrating to find that pfsense contains mods that are not reflected in the docs. Often pfsense relies on these changes, yet they are undocumented. I'm thinking of my on-going issues with state killing in 2.1 (pfctl mods) and of course the new tracker numbers.
I recall a post where someone said in effect ' … if we wanted to close it, we took away the wrong repo', referring to removing the pfsense-tools repo rather than pfsense repo. Well, IMHO pfsense is effectively closed until the tools repo is available again.
-
Please send this discussion on its own thread not related to this.
This is about ath0.
-
I will be a couple of days before being able to try this. I am away and something happened at home - the home laptop is not getting out through the setup I left behind so I can't TeamViewer in to it. And OpenVPN client is not working on that pfSense 2.2 box, so it did not make a site-to-site connection out to the intended place, so I can't get back to it over that. Bit hard for the wife to troubleshoot - she is getting internet from a WiFi ADSL device until I get back.
-
Just want to throw it out there, if anyone does get their ath0 wireless N card working, it would be handy to know any steps you did to set it up. I went to test my atheros 5416 chipset card (Dlink DWA-552) and am happy to report it no longer causes a kernel panic. (anything FreeBSD 8 and it's not happy) I set it up as the WAN interface on a test box and it automatically connected itself to an open network, got an IP and appears to have internet. I wasn't able to get it to connect to a secured network however and it didn't look like the rescan option worked as it couldn't find any networks. Haven't had time to investigate why yet.
This was done on the April 7th snapshot..
-
2.2-ALPHA (i386)
built on Wed Apr 9 09:01:59 CDT 2014
FreeBSD 10.0-STABLEStill no "ath0" available in Interfaces->Assign on my Alix 2D13.
-
2.2-ALPHA (i386)
built on Sun Apr 13 15:35:58 CDT 2014
FreeBSD 10.0-STABLEath0 is back on Alix 2D13! Very good. I have set it up in Access Point mode, enabled DHCP and added firewall rules and it is working as expected. I am posting across that now.
-
-
I don't know about that. I think the card in my Alix 2D13 is only b/g
-
I tested an N card and it's not recognised anymore.
It was recognised in an earlier version.Is still shown as:
none2@pci0:4:0:0: class=0x028000 card=0x3123168c chip=0x0033168c rev=0x01 hdr=0x00
class = network -
Can you tell me which vrsion it was recognized before?
Its a PCI card and nothing should have changed there afaik.
I see it even supported by ath AR9300_DEVID_AR9580_PCIE
-
The march 27 version.
It seems these files aren't on the snapshot server anymore. -
A March 27th image was the last time I saw if_cdce.ko; I suspect many modules have been missing since then.
-
Those are inside the kernel nowdays.
And if_cdce iirc is for USB interfaces while this is a PCIe one.
Judging on the other seeing the ath interface for assignment this is a bit strange happening.Though can you try with the next set that will come out?
-
As a test i downloaded the current amd64 memstick serial and booted from this one.
There the card is detected correctly.The version on the sata was upgraded with the autoupgrade function.
I reinstalled and the card seems to work now.
