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 standard. 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 first. -- Brooks -- 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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:42 UTC