Wifi problems (FC 6)

Anne Wilson cannewilson at googlemail.com
Sun Jun 10 10:06:01 UTC 2007

On Saturday 09 June 2007 23:30:26 Joe Barnett wrote:
> Anne Wilson wrote:
> > On Saturday 09 June 2007, Gene Heskett wrote:
> >> On Saturday 09 June 2007, Joe Barnett wrote:
> >>> Anne Wilson wrote:
> >>>> On Saturday 09 June 2007, Joe Barnett wrote:
> >>>>> 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 apologize for the confusion.
> >>>
> >>> "ntpd -gq" runs the daemon only long enough to sync the clock, then
> >>> it quits.  Think of ntpdate.
> >>
> >> Which is exactly what it did the last time I studied that startup script
> >> in /etc/init.d.  It runs ntpdate once to crash synch the clock, and then
> >> runs the ntpd.
> >>
> >>> Why not just use ntpdate?  Good
> >>> question.  man ntpd indicates that ntpdate is going to be retired at
> >>> some point, and that ntpd -q should be used instead.  -q seems to
> >>> stand for quit (as soon as the clock is adjusted).  -g tells ntpd
> >>> not to exit with error if the offset is greater than 1000 seconds.
> >>>
> >>> I am not sure why they want to retire ntpdate as it seems a very
> >>> useful tool.  Anyway...
> >>
> >> I agree, however retiring such a usefull tool might be desirable from
> >> the standpoint of being replaced by a better way, possibly built into
> >> ntpd, but I've not noted any discussion about it.  And I'm of course not
> >> on a mailing list that would make me privy to that either.  I would hope
> >> that they would make an attempt at advising the users that there was a
> >> change coming first.
> >>
> >>> Both the stock ntpd and openntpd have features which should bring
> >>> the clock to good time as soon as they get a good feed from one or
> >>> more of the servers for which they are configured to use.  ntpd -gq,
> >>> in theory, should not be needed if either ntpd is going to be run as
> >>> a daemon.
> >>>
> >>> That being said, my experience (with both the stock ntpd and
> >>> openntpd) is that it is best to do a gross adjustment first (whether
> >>> by ntpd -gq, ntpdate, rdate, etc.) *then* start the daemon.  That is
> >>> why I use two commands to get my ntp stuff going.
> >>
> >> Which is what the current (fc6 anyway) startup script does.  Quite well
> >> in fact if the network is available at runtime.  In Anne's case, that
> >> can't be assumed.  Probably because its miss-configured in ways I'm not
> >> familiar with since I don't yet use wpa_supplicant, in fact its all done
> >> by the network script on my lappy.  The WEP key is actually listed in
> >> my /etc/sysconfig/network-scripts/ifcfg-wlan0 using the KEY=syntax but I
> >> have NDI if the WAP(2) key Anne is using could be similarly defined
> >> there or not.
> >>
> >> It might be worth a try, Anne.
> >
> > ntpd was attempting to run before wpa_supplicant could join the network. 
> > I'm torn between re-numbering it and removing it in favour of the two
> > commands in rc.local.  I think I'll take those commands out again, for a
> > trial, and see whether the re-numbering does the trick.
> >
> > Anne
> Given what Gene wrote about the startup files, and that you are
> using the stock ntpd, I would suggest just playing with the startup
> order in rc3 (rc5?), rather than mess with rc.local.
I tried that for the overnight shutdown.  It didn't work because there was 
still a problem with the wifi connection.

> Not to sound completely ignorant, but is there a
> management/configuration interface which can be used to set up the
> wifi services?  I have just been calling scripts from rc.local in
> order to get wifi working.
There is - system-config-network, and it doesn't help at all.  It appears that 
I either accept what network manager decrees - and that means dhcp, or do 
without.  I'm fed up of struggling with this.


More information about the fedora-list mailing list