On Saturday 09 June 2007, Joe Barnett wrote:
> Anne Wilson wrote:
> > I need to run this box on a wireless connection, and am having some
> > problems.
Hi, Joe. There is good news and bad news :-)
> >
> > 1 - I have a very poor signal, considering that the box is only around 3m
> > (10ft) from the router. I changed the antenna on the router to one that
> > says it increases range by up to 50%, maximum 40m, but the strength
> > received hasn't altered. I still get only 40% strength.
>
> Maybe time for a new router/access point? I was having issues with
> my original access point (similar: it started to lose power/signal,
> if that is the correct way to phrase it) and finally just replaced
> it. Of course this happened just following expiration of the
> warranty...
No, it's not the router. That's a brand-new Netgear634g, and my Mandrive
laptop with ipw2200 gets an excellent signal from it. I think it must be
either a misconfiguration or a driver problem, madwifi not suiting this card.
I wonder about this, as I have another box that runs Mandriva, but has the
same wireless card as this box. It has the same connection problems. To me,
that makes the driver a prime suspect.
>
> > 2 - I thought that wpa_supplicant cached the passphrase, but it doesn't
> > seem to. I still have to give the passphrase after bootup completes.
>
> Maybe I am doing this wrong, but I keep the passphrase in
> /etc/wpa_supplicant/wpa_supplicant.conf:
>
> network={
> ssid="ssid name"
> #psk="passphrase"
> psk="hashed passphrase"
> }
>
Here comes the good news. I had in there 'proto=WPA'. Changing it
to 'proto=RSN' has brought the signal up to 55-58% - not good, but a good
deal better.
> Keep wpa_supplicant.conf readable only by root: 0400 or 0600
>
It's 600.
There seems to be a war going on, between NetworkManager and wpa_supplicant.
I get two dialogues requesting the passphrase, and NetworkManager seeme to
win. It presumably brings up the network on dhcp, as it gets 192.168.0.2. I
work entirely on static, and that's not the address it should be using.
OTOH, I would have thought that it would work, being on the same sub-net, but
it doesn't find my server. There seems to be nothing I can do with it apart
from shut down the connection, then run wlassistant, re-entering all the
configuration afresh.
> I run my script to kick off wpa_supplicant at the start of rc.local.
> There may be a better way, but it works well enough.
>
I'll come back to that.
> > 3 - At bootup, ntpd tries to run before there is a connection. I'd like
> > to get the connection up in time to use ntpd at boot. What would I need
> > to do?
> >
>
> Try running "ntpd -gq" at the end of rc.local to sync the clock.
> Then kick off nptd (with your normal settings) following that.
>
I'm not sure I understand that - what do you mean by the second statement?
> I have been using OpenNTPD (www.openntpd.org) for several years.
> Starting OpenNTPD with the "-s" flag should obviate the need for
> "ntpd -gq" or ntpdate earlier in the sequence, but I do both (if for
> no other reason than to feel I am covering all bases).
>
> Two notes: 1) I am not trying to start an ntpd war by mentioning
> OpenNTPD, and 2) "ntpd -gq" is valid only for the stock ntpd
> (/usr/sbin/ntpd), OpenNTPD accepts only two or three startup
> options, and "-gq" are not among them.
>
> So my rc.local looks something like this:
>
> # wpa_supplicant
> /path/to/script
>
> # sync clock
> /usr/sbin/ntpd -gq
>
> # start OpenNTPD
> /usr/local/sbin/ntpd -s -f /usr/local/etc/ntpd.conf
>
> One final note: the laptop to which I am referring stays in the
> house and uses a local timeserver from which to sync; I have high
> confidence that "ntpd -gq" will sync quickly, exit, and allow
> rc.local to continue to be processed. I have a MacBook which
> travels and I use the same sequence in it (sans the wpa_supplicant
> stuff, of course) and it seems to work well. YMMV.
>
Thanks
Anne
Attachment:
pgpyv2kmuH9fU.pgp
Description: PGP signature
