Unable to connect to wireless 802.11 AP with hidden SSID
brooks at one-eyed-alien.net
Fri Aug 26 17:53:12 GMT 2005
On Fri, Aug 26, 2005 at 04:09:33PM +0200, Rudolf Cejka wrote:
> Doug Barton wrote (2005/08/26):
> > I'm 100% sure it was happening with my ndis card, fairly certain it was
> > happening with ath too, but I wouldn't swear to it.
> So maybe the behavioral change would be somewhere in the ndis layer?
> I took a fast look into sys/dev/if_ndis/* and it seems that it would
> be the real source of the problem, like if ssid is not acquired, the
> old setting is leaved as is. Unfortunately, I'm going on vacation right
> now, so I can return to this problem after Sep 5.
> > Did you have a chance to review the patch submitted by Rudolf?
> I meant the patch mainly as a fast workaround for those, who have the
> same problem, however if developers find useful and logical, so that
> ifconfig does not call SIOCSIFFLAGS unnecessarily, why not, I would
> be pleased ;o), but I'm very unsure, if it can be skipped in all cases.
I don't think we should debounce the interface in ifconfig, that will
just mean it will break when someone else writes another utility. We
should do it in the kernel instead.
> Btw, I think that I have a better candicate for commit - new dhclient
> really annoys me, that it writes "unknown dhcp option value ..." for
> every unknown DHCP option (e. g. for PXE), whereas the old was simply quiet
> (chunk 3). And new dhclient makes me mearly crazy :o), when it waits
> 10 seconds on interface with link down - I have done primitive patch
> (chunks #1 and #2), which simply removes waiting, but this is not very
> good to make it public, so I have a plan to create a patch, which will
> add -t seconds option, so that the timeout is configurable, with the
> default value eqal to 0, because I have never seen any reason to wait
> so such a long time.
I agree the unknown option message is a bit useless. Though in point of
fact, it was in the ISC code this was derived from (that's a different
code base than our previous ISC code though.) I'm not sure what the
best answer is. Ideally we should add the options rather then
supressing the warning be default unless the options are totally
non-standard. I'd tend to treat any FreeBSD specific options as
A patch to set the timeout would be acceptable though a default of
0 would not be. Removing it is bogus. Much better to remove the
syncronous call to dhclient entierly (that's on my radar for 7.0).
The current timeout may be a bit long, but gigabit nics and wireless
networks with non-broadcast SSIDs do take quite some time. I'm not
actually sure 10 seconds would be enough for some systems. For
instance, I've found systems with em(4) nics that will not PXE boot even
with portfast enabled unless I configure the other nice to try and fail
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20050826/312200e9/attachment.bin
More information about the freebsd-current