# WG311T (net.ath0) needs to start twice before it works

## pezplaya

I just bought a Netgear WG311T (rev 01) because it uses the atheros chipset (so I can use the madwifi drivers). I'm using madwifi-ng drivers  0.9.3.1.  After lots of toying with my kernel and everything I got the card to work.   I was using a gentoo-sources kernel (linux-2.6.21-gentoo-r4)  which would not work at all with the madwifi drivers.  I switched to vanilla-sources (2.6.21.6) and the card was finally detected (with the same kernel config).  Also using wireless-tools version 28.

Like my subject line says I need to start the card twice before it will actually work.  For example, when the system boots and starts net.ath0 everything works fine (gets an IP and everything).  After it's done booting, it won't connect to anything.  I must issue a /etc/init.d/net.ath0 restart.  Then the card starts working.  The same thing happens if I don't have the card start automatically on boot.  When I got to start it (/etc/init.d/net.ath0 start) it doesn't work, but then when I restart it again it starts working.

Does anybody know why this would be happening?

To not have a ridiculously long post, here are links to my dmesg and kernel config

Here is a link to dmesg:  dmesg

Here is a link to my kernel config:  kernel config

----------

## didymos

What about /etc/conf.d/net?  That should be short enough to post (you could've posted the other stuff. People do it all the time, though I can't say I'm fond of the practice).

----------

## pezplaya

Ya, I just don't like scrolling through pages and pages of kernel config. 

Here is /etc/conf.d/net:

```
modules=("iwconfig")

key_Amnesia="[1] xxxxxxxxxx key [1] enc open"

preferred_aps=( "Amnesia" )

config_ath0=( "192.168.1.180 netmask 255.255.255.0 brd 192.168.1.255" )

routes_ath0=( "default gw 192.168.1.1" )

```

----------

## didymos

Well, I can think of a hack that should work, even though it ought not be necessary.  Add this to /etc/conf.d/net:

```

preup() {

        local exit_status

        if [ "${IFACE}" = "ath0" ]; then

                if [ -d /sys/class/net/ath0 ]; then

                        einfo "Destroying ath0..."

                        /sbin/wlanconfig ath0 destroy

                fi

                einfo "Recreating ath0..."

                exit_status=$(/sbin/wlanconfig ath0 create wlandev wifi0 wlanmode sta)

                if [ "$exit_status" = "ath0" ]; then

                        einfo "ath0 created"

                        return 0

                else

                        eerror "ath0 creation failed"

                        return 1

                fi

        fi

        return 0

}

```

You can remove all the messages if you want.  They're just useful if it fails, because then you know roughly where. I actually used a function like this a few madwifi versions back when I was having almost the same problem. The only difference is, I'm using the card for an AP.  At some point, I decided to see if I still needed it, and I didn't.  Still have no idea why.

Oh, yeah, it'll run this for any other interface, but it only fiddles with ath0, so just ignore the messages about "running preup...".

----------

## pezplaya

so the script above actually made the problem worse... where it won't connect at all.  when i removed the script from /etc/conf.d/net and restarted the device it started working.

any other ideas?  i've tried a lot of things... i have no idea where to go from here.

----------

## didymos

Strange.  What happened when it ran?  Did the interface exist or did it just disappear or something?

[edit] Well, instead of using wlanconfig, you could actually do "rmmod ath_pci" then a "modprobe ath_pci".  By default, inserting ath_pci will create ath0 in station mode.

----------

## pezplaya

So this is the output WITH the script in /etc/init.d/net

```
barbossa pezplaya # /etc/init.d/net.ath0 restart

 * Caching service dependencies ...                                       [ ok ]

 * Stopping ath0

 *   Bringing down ath0

 *     Shutting down ath0 ...                                             [ ok ]

 * Starting ath0

 *   Running preup function

 *     Destroying ath0...

 *     Recreating ath0...

 *     ath0 created                                                       [ ok ]

 *   Configuring wireless network for ath0

Warning: Driver for device ath0 has been compiled with version 22

of Wireless Extension, while this program supports up to version 20.

Some things may be broken...

Warning: Driver for device ath0 has been compiled with version 22

of Wireless Extension, while this program supports up to version 20.

Some things may be broken...

Warning: Driver for device ath0 has been compiled with version 22

of Wireless Extension, while this program supports up to version 20.

Some things may be broken...

Warning: Driver for device ath0 has been compiled with version 22

of Wireless Extension, while this program supports up to version 20.

Some things may be broken...

Warning: Driver for device ath0 has been compiled with version 22

of Wireless Extension, while this program supports up to version 20.

Some things may be broken...

Warning: Driver for device ath0 has been compiled with version 22

of Wireless Extension, while this program supports up to version 20.

Some things may be broken...

 *     ath0 connected to ESSID "Amnesia" at 00:18:39:51:79:43

 *     in managed mode on channel 6 (WEP enabled - open)

 *   Bringing up ath0

 *     192.168.1.180                                                      [ ok ]

 *   Adding routes

 *     default gw 192.168.1.1 ...                                         [ ok ]

barbossa pezplaya # 

```

the warning about the device ath0 has been compiled with version..... i don't think thats a problem, but what should i do to fix it?

----------

## didymos

Yeah, that's popping up a lot lately.  The only way to get rid of it is to unmask wireless_tools and install one of the 29_preXX versions.  The package has been in pre-release state for ages now, and I've yet to have any problems with it, so it's pretty safe.  Besides, it's not critical, so downgrading isn't a big deal if it won't work.  Just don't delete the tarball for version 28.  Or quickpkg version 28.

----------

## pezplaya

ya, actually i just figured that out and those errors went away... 

still same problem though.  it's driving me nuts.  suggestions?

----------

## didymos

OK, so it was connecting when the function was in, but you couldn't send or receive anything, right? And without it, it does the same thing until restarted.  That is...odd. OK, how is the module being loaded?  Is udev doing it automatically, or do you have an entry in /etc/modules.autoload.d/kernel-2.6 and/or /etc/modules.d/ath_pci?

----------

## pezplaya

OK, so it was connecting when the function was in, but you couldn't send or receive anything, right? And without it, it does the same thing until restarted. That is...odd. OK, how is the module being loaded? Is udev doing it automatically, or do you have an entry in /etc/modules.autoload.d/kernel-2.6 and/or /etc/modules.d/ath_pci?

it was connecting, but i couldn't ping anything.  without it, it does the same thing without restarting the service.

modules are being loaded by udev.  nothing is in /etc/modules.autoload.d/kernel-2.6 or /etc/modules.d/ath_pci

in my /etc/conf.d/rc file i have these lines (along with many others):

RC_HOTPLUG="yes"

RC_COLDPLUG="yes"

RC_PLUG_SERVICES="!net.*"  (i tried this with allowing net.ath0 still doesn't work.  I have it set to not load anything because it just takes more time to boot if i let it try)

RC_NET_STRICT_CHECKING="lo"

can you let me know what options you have set for these settings?

----------

## didymos

In /etc/conf.d/rc I've got:

```

RC_HOTPLUG="yes"

RC_COLDPLUG="yes"

RC_PLUG_SERVICES=""

RC_NET_STRICT_CHECKING="yes"

```

However, I've got this in /etc/modules.autoload/kernel-2.6:

```

ath_pci autocreate=ap

```

Maybe udev is bringing the device up too early, and by having that line, it's introducing a needed delay.  In your case, try:

```

ath_pci autocreate=sta

```

There shouldn't be any difference, but obviously the device is not initializing correctly.  So, if udev is starting the service, you probably don't have it in any runlevels, right?

----------

## pezplaya

I tried putting 

```
ath_pci autocreate=ap 
```

in my /etc/modules.autoload/kernel-2.6 file, but it doesn't help.

It is possible udev is loading the module(s) too early.  It starts loading them shortly after it starts booting.  Is there anyway to delay it other than the way you mentioned?

[right now i'm changing everything to how you have it setup and i'm restarting. i'll post back]

----------

## pezplaya

i added that line to /etc/modules.autoload/kernel-2.6, and also changed my /etc/conf.d/rc to match yours. still the same problems.

----------

## didymos

Is it still set to:

```

ath_pci autocreate=ap

```

?

If so, change the ap to sta.  I only have ap because my system is also the access point for other computers in the house.

----------

## pezplaya

i'm not at home right now, but i'm pretty sure i tried that before.  i'll try it later tonight and post back.  (thanks for the advice so far)

----------

## pezplaya

ok so changing it to sta didn't work.

I think I may have figured out what is wrong.  When it initially tries to connect, it tries channel 11.  The router is set to channel 9.  When I restart (net.ath0) for some reason it changes to channel 9 and starts working.

So the question now is, how do you specify a channel you want to use?

I added 

```
channel_ath0="9"
```

to /etc/conf.d/net but it doesn't work if i restart my computer.  it always defaults back to channel 11 on boot.

suggestions?

----------

## didymos

Yeah, that's a problem I've never managed to figure out.  I'm surprised it picks the same channel each time.  Usually if seems to just pick one at random.  Other than setting it manually, you could try a postup function:

```

postup() {

    if [ "${IFACE}" = "ath0" ]; then

        iwconfig ath0 channel 9 &>/dev/null  # may want to leave the redirect out until you know if it works

     fi

}

```

or you could put the command in /etc/conf.d/local.start and add local to the default runlevel. A third option is to try this in /etc/conf.d/net:

```

iwconfig_ath0="channel 9"

```

instead of using channel_ath0.

----------

## pezplaya

tried all of those and none of them change the channel initially.  It seems to me that it should know what channel the router is using (which it might detect the SECOND time around).  

if you do a iwlist ath0 scanning it will pick up all the wireless routers/ap's around and specifically tell you what channel it's using.  you shouldn't need to specify any channel.

very annoying.

anything else you can think of?

----------

## didymos

 *pezplaya wrote:*   

> tried all of those and none of them change the channel initially.

 

Do any of those work on the restart?

 *Quote:*   

>  It seems to me that it should know what channel the router is using

 

Yeah, it's intended to work that way. Doesn't always seem to quite work out.  There's a station with another atheros card in the house, and sometimes it gets confused and just starts rotating the channels endlessly.  And it's not just linux.  The card will do that under XP sometimes too. 

 *Quote:*   

> you shouldn't need to specify any channel. 

 

Not for a station, but for an AP it's needed to avoid a crowded channel. Still, it'd be nice if the driver would pick an empty channel or the least populated one.  Too often,  I find it's picked the channel with the largest number of other APs.  For some reason, people around here are into channel 11.

 *Quote:*   

> 
> 
> very annoying.
> 
> anything else you can think of?

 

Other than the general observation that wireless is just flaky, not really.  I'm hoping the new wifi stack in Linux will help solve some of these problems once driver writers have made the transistion. And like I said, it's not only Linux.  I've seen some pretty erratic behavior under Windows which can't necessarily be blamed on Windows itself.  Eg., sometimes the Atheros card in XP will decide that it's not going to work with wpa_supplicant, which I prefer, so I use the one provided by Trendnet.  But that's prone to random failure as well.  Usually, it requires disabling the driver, or re-installing, or, being Windows, a reboot so that the card is completely reset.  Sometimes I can get away with just killing the atheros service and restarting that. Then it's fine, and it'll stay that way for a couple months.  But even stuff as innocuous as accidentally moving the antenna can send the card off to la-la land sometimes.  I may just be Atheros stuff as well, especially in station mode.  There's a Wii in the house, and that thing has never not worked once it was configured correctly.  The only time it can't connect is if the actual Internet connection is down on the AP, or hostapd isn't running.

----------

## pezplaya

Ya, they all worked after restarting net.eth0.  The second time around it always goes to channel 9.

Thanks for your help.  I guess I'll just wait and deal with this for now.  Something new will come out and hopefully fix the problem.

Nothing is perfect, I know windows has its share of wireless problems as well.  I was tempted to try a different distro, but I know I'll regret switching because I really like gentoo.  My other option is to return the card and buy a wireless bridge so I don't have to deal with any wireless config in linux itself.  Just frustrating because I bought this card after doing research on which card to buy and which one would work the best in linux.

Just for reference, there are no other atheros chipset cards in the house.  I'll post back if I figure something out.

Thanks again

----------

## Graymi

know this is a bit late of an answer, but i just had the same problem...

anyways, i reemerged wpa_Supplicant without madwifi useflag, and removed the -Dmadwifi from all wpa configurations.

problem solved.

seems compiling with madwifi support breaks madwifi compatibility. strange.

----------

