[ap-utils] interesting discarded messages

[Roman Festchook]

some messages that discarded by maillist server by some reasons - but I think 
messages may has interest for list subscribers:

***********************************************************
Re: A few strange things
From: Jan Rafaj <rafaj at cedric.unob.cz>
To: ap-utils at lists.polesye.net
Date: Wed, 12 Jan 2005 12:54:56 +0100 (MET)

John Coppens wrote:
>> Hi all.
>>
>> First of all, thanks for publishing the programs!
>>
>> 1) If the program is released under the GPL, why do I still get the
>> license warning when modprobing? Am I doing something wrong?
>>
>> 2) Why doesn't the 'radio' option (to set/view power etc) work 'Can not
>> get the data from the AP'... If this is a password problem, why do all
>> the other options work? (Like changing frequency, essid etc)
>>
>> 3) May I suggest a warning when exiting from a modified parameter page?
>> And maybe a warning when exiting without 'uploading' modified parameters?
>>
>> Greetings,
>> John

Roman Festchook replied:
> 1) modprobing never be related to ap-utils - there are not any kernel
> modules:)
> 2) probably your firmware doesn support this options (or one of this) -
> what version you use?
> 3) I will think about it

1) Loading kernel modules has nothing to do with ap-utils at all.


2) Well, I'm sorry to say this, but [and note about this will be included
   in new (not yet released) STABLE ap-utils]:


   ATMEL AT76C510-based devices with 'WA' (a.k.a. 'Wireless Adapter')
   ARE _NOT_ SUPPORTED by ap-utils!
   This includes airBridge flavours, unless you are able to load
   airPoint ('AP' a.k.a. 'Access Point') firmware in it (but I'd strongly
   discourage this).
   The reasons behind this are:


   - there is simply no reliable way of how to automatically distinguish
     whether the loaded firmware is 'AP' firmware or 'WA' firmware.
     Even ATMEL itself uses two separate utilities for 'AP' and 'WA'
     firmware, and it is _users_ responsibility to know which one to pick.


   - code in ap-config would grow too complex. The way would apparently
     be to write 'wa-utils' separately for this.


   - I have no time, dedication, and interrest in supporting 'WA'
     firmware-equipped devices, since they, in reality, contain just
     a subset of AP functionality, and minimum of new features, that
     are not worth the effort from my point of view.
     Wait until Roman releases new STABLE package (I've already committed
     changes, but it is not out yet, as of time of this writing), and
     read about the 'WA' firmware issues in 'README'.


   - I've never had an airBridge sample to do development on (but I'm
     not really going to support it even if I had, now).
     However, airPoint PRO devices (and generally those equipped
     with 'AP' firmware) should be supported to some extent. Complete
     support is, however, not there even for airPoint PROs, becouse
     SmartBridges nor anyone else has provided me with sample
     airPoint PRO device I could do development on.


3) Q: 'Warning when exiting without 'uploading' modified parameters?'
   A: Nice idea, but I think it would slow down management for experienced
      users. Moreover, it is not really feasible - there are some
      parameters that require 'Upload' after saving using 'Write', and
      some that dont.
      Their amount may change among different firmware flavours, and
      there's no reliable way of how to autodetect what would need warning
      and what wouldn't. The eventual code complexity would not be
      worth it, though.


   Q: 'warning when exiting from a modified parameter page?'
   A: Well, I understand your intentions for adding 'fool-proof' code
      here, but imagine case when user just peeks whats in the pulldown
      selection lists and tries what limits are accepted (and he does
      not want to change anything). Again this would mean extra
      complexity.
      Anyway, thats why the highlighting (after changing parameter)
      is for - user sees that he has changed something, and it is _his_
      responsibility to 'Write' the change(s) or not. But maybe removal
      of the highlighting over changed option values, once they are
      'Written', would help? Or highlighting the 'Write' option
      once something has changed? That would be quite easy to add.

Regards,

Jan

-- 
Roman Festchook
Network Engineer
RF2-UANIC FRA11-RIPE