Hi there! I've heard some rumors claiming that EAP/SIM will be available with FreeRadius in the near future. Can anyone tell me what is the current status of this project and an estimated release date?
Thanks a lot, Marcos ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, September 16, 2003 4:39 PM Subject: Freeradius-Users digest, Vol 1 #2312 - 7 msgs > Send Freeradius-Users mailing list submissions to > [EMAIL PROTECTED] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.cistron.nl/mailman/listinfo/freeradius-users > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Freeradius-Users digest..." > > > Today's Topics: > > 1. Re: dialup-admin patch2 (Ulrich Walcher) > 2. Newsletter - Aktivierungslink ([EMAIL PROTECTED]) > 3. Re: Https + RADIUS (Alan DeKok) > 4. RE: [eap] non-wire related comments on eap-sim-11.txt ([EMAIL PROTECTED]) > 5. RE: Wi-fi hotspot (Brynjar Hauksson) > 6. Re: Radiusd service script + daemontools supervise (Alan DeKok) > 7. RE: Wi-fi hotspot (Jeremy Davis) > > --__--__-- > > Message: 1 > Subject: Re: dialup-admin patch2 > From: Ulrich Walcher <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Organization: > Date: 16 Sep 2003 15:22:40 +0200 > Reply-To: [EMAIL PROTECTED] > > and here also... > > --- /usr/local/cvs/radiusd/dialup_admin/lib/sql/defaults.php3 > 2003-01-28 15:14:53.000000000 +0100 > +++ /usr/local/dialup_admin/lib/sql/defaults.php3 2003-09-16 > 15:18:27.000000000 +0200 > @@ -121,10 +121,10 @@ > $link = @da_sql_pconnect($config); > if ($link){ > $res = @da_sql_query($link,$config, > - "SELECT DISTINCT GroupName FROM > $config[sql_usergroup_table];"); > + "SELECT DISTINCT s.groupname FROM > $config[sql_groupcheck_table] CROSS JOIN (SELECT DISTINCT u.groupname > FROM $config[sql_groupreply_table] CROSS JOIN > $config[sql_usergroup_table] u) as s;"); > if ($res){ > while(($row = > @da_sql_fetch_array($res,$config))) > - $member_groups[] = $row[GroupName]; > + $member_groups[] = $row[groupname]; > } > else > echo "<b>Database query failed: " . > da_sql_error($link,$config) . "</b><br>\n"; > > > Am Fre, 2003-09-12 um 16.08 schrieb Ulrich Walcher: > > Oops, > > forgot to add this one... > > > > OoLee > > > > --- /usr/local/cvs/radiusd/dialup_admin/lib/sql/defaults.php3 > > 2003-01-28 15:14:53.000000000 +0100 > > +++ /usr/local/dialup_admin/lib/sql/defaults.php3 2003-09-12 > > 16:04:15.000000000 +0200 > > @@ -121,10 +121,10 @@ > > $link = @da_sql_pconnect($config); > > if ($link){ > > $res = @da_sql_query($link,$config, > > - "SELECT DISTINCT GroupName FROM > > $config[sql_usergroup_table];"); > > + "SELECT DISTINCT c.groupname FROM > > $config[sql_groupcheck_table] c CROSS JOIN $config[sql_groupreply_table] > > r;"); > > if ($res){ > > while(($row = > > @da_sql_fetch_array($res,$config))) > > - $member_groups[] = $row[GroupName]; > > + $member_groups[] = $row[groupname]; > > } > > else > > echo "<b>Database query failed: " . > > da_sql_error($link,$config) . "</b><br>\n"; > > > > > > > > - > > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > > > > > > --__--__-- > > Message: 2 > To: [EMAIL PROTECTED] > From: [EMAIL PROTECTED] > Subject: Newsletter - Aktivierungslink > Date: Tue, 16 Sep 2003 15:59:03 +0200 (CEST) > Reply-To: [EMAIL PROTECTED] > > Hallo, > > Wenn sie diesen Newsletter erhalten wollen klicken sie bitte auf die Internet-Adresse. > Falls sie diesen Newsletter nicht wollen l�schen sie einfach diese E-Mail. > > Aktivierungslink: http://www.1a-network.de/cgi-bin/newsletter/newsletter.cgi?id=mcsmail&[EMAIL PROTECTED]&key=WXIYX3q7yHnwU&action=aktiv > > Mit freundlichen Gr�ssen Newsletter-Team > > > --__--__-- > > Message: 3 > From: "Alan DeKok" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: Https + RADIUS > Date: Tue, 16 Sep 2003 10:16:52 -0400 > Reply-To: [EMAIL PROTECTED] > > "JM Fernandez" <[EMAIL PROTECTED]> wrote: > > Alan can you tell me the details on how the NAS gets the end user > > username and password? > > It depends on the local implementation. > > > I'm planning to nake a web based login with an access point that > > acts as a radius client. > > So have the NAS take the username & password from the web login > form, and put them into a RADIUS packet. > > Am I missing something? > > Alan DeKok. > > > --__--__-- > > Message: 4 > Subject: RE: [eap] non-wire related comments on eap-sim-11.txt > Date: Tue, 16 Sep 2003 17:20:44 +0300 > From: <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, > <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > > > Michael, > > Many thanks for your comments. I agree the document could use some=20 > restructuring and clarification. It's a result of cumulative = > revisioning,=20 > and we haven't really thought about the structure since the beginning. > > It's very hard to structure the document so that you can understand > everything by reading it once. I think we need to have a good overview > section. It's not a good idea to duplicate the same information > in several places of the document, so it may be hard to > avoid referencing sections that follow the current section. > > > A1) please include real packet dumps, including encrypted data > > with keys, to help people. > > We're planning to do that in appendix A.=20 > =20 > > A2) There is no per-attribute description/reference. > > -> AT_VERSION_LIST for instance has no reference. > > ... > > A4) The definitions of the attributes seems to be partially defined > > only in the scenarios of sections 9-15. I would rather the=20 > > attributes were defined seperately from the messages in which > > they are used. Otherwise, it appears that one has to=20 > > code per-message > > marshalling/etc. It is hard to tell if this is true or not. > >=20 > > Most of the attributes can be used in a certain message only, > but there are attributes like AT_MAC that are general. Maybe > we should have a separate section for the attribute definitions, > like for example RFC2865. That would make the message definitions=20 > simpler. > > > A3) paragraph 1 of 5.2. This conversation seems totally out of > > place, and very confusing. > > OK. > =20 > > A5) It was not at all obvious that the AT_MAC is a keyed operation. > > The last sentence of 8.1 says so, but I missed it at=20 > > least twice, > > thinking, but, it must be keyed, I remembered reading about it. > >=20 > > Maybe this is just the way that I read the document. > > Yes, it is a keyed operation, as described in section 8.1. > > > > A5b) Annex A/B might be a little more detailed. > > In particular, I think that you have chosen G to be SHA1, but > > I'm not particularly certain. > > Nor do I understahe what "m" is, or what the "optional=20 > > user input" > > is in this context. > > Please see other postings on the EAP mailing list about the PRF. > > > A6) split normative and informative references. > > OK. > > > A7) section 3, overview, para 3. > > It seemed that this was the only place that the value=20 > > of the Start > > subtype was clearly stated. > > In addition, all protocol numbers are stated in=20 > section 18 (IANA considerations). > > > A8) section 5.1, page 9,=20 > >=20 > > > In this case, the permanent username MUST be of the=20 > > format "1imsi".=20 > > =09 > > It took me awhile to understand that the thing in quotes is a > > pattern, not a string. Please remove "", or use another=20 > > notation. > > OK > > > A9) section 5.1, page 9, para 4. > > This seems really nebulous. > >=20 > > Do you mean it's hard to understand if you don't know > about re-authentication and IMSI privacy, which are > discussed in later sections?=20 > > > A10) section 5.2, first paragraph. > > It seems that you are putting the most complicated "gotcha" > > at the beginning. At this point, I don't even know what you are > > talking about yet! > > The "gotcha" is rationale for the feature. Maybe the first > paragraph can be removed altogether. > > > A11) time-sequence diagrams. They are simply not useful to=20 > > me. They just > > seem to take lots of space. > > They are useful when there are more than two parties. > > > > A12) section 5.1, 5.2 and 5.3 should have *NO* mention of > > re-authentication. Please describe the base protocol first,=09 > > (including state machines), and then give the version that=20 > > supports re-authentication. > > I agree it should be easy to understand the protocol > in a general level by reading the first sections. But I'm > not sure if we really need to first specify the base protocol > only and cut corners in the specification of the Start messages > for example. > > > A13) section 5.3, page 15, para 7. > > " A received AT_PERMANENT_ID_REQ does not necessarily=20 > > originate from " > >=20 > > The advice given seems very complicated and very dubious to me. > > I believe that this must come out from the client state machine. > > The "advice" could be removed from the base description (and even > omitted from state machine if we have such a thing), and we could > discuss protection against active attacks on anonymity separately. > > > A14) section 6. > > Caveat: I read this much less carefully.=20 > > page 22, para 4: > >=20 > > " > > Re-authentication identities are one-time identities. If=20 > > the client=20 > > does not receive a new re-authentication identity, it MUST use=20 > > either the permanent identity or a pseudonym identity on the next=20 > > authentication to initiate full authentication.=20 > > " > >=20 > > Given that the identity is involved in the AT_MACs, are there > > any cryptographic restrictions on the one-time identities? > > The identities are involved in key derivations in order to > get implicit integrity protection by "binding" the derived > keys to the identity string. I'm not sure if I properly > understand your question, but I don't think there are any > restrictions on the identities. > > >=20 > > A15) section 7. basic format. > > What if length =3D=3D 0. Malformed packet. > > Then what? > > The current draft (section 15) specifies silent discard > as the default operation in error cases, but we're going > to change this in response to Glen's comments. If > the client encounters a malformed packet, it sends > an EAP-Response/SIM/Client-Error, to which the server > replies with EAP Failure. If the server encounters > a malformed packet, it issues EAP Failure. > > > > A16) section 7. 0/127, 128-255 as "skippable". > > I recommend that you adopt the terminology from IKEv2. > > The high bit is the "critical" bit (or in this case, the > > "non-critical" bit).=20 > > OK, that's another way to describe the same thing. > > > A17) section 8.2. AT_CHECKCODE. > > ...will be removed from the next version of EAP SIM. > > > > A19) What if it is known that the encapsulator provides integrity=20 > > protection and privacy? I.e. IKEv2? > > You'll still have to use AT_MAC, but you don't have to > use IMSI privacy. If the encapsulator provides fast > reconnect, you don't have to use EAP/SIM's re-authentication. > > >=20 > > A20) section 10. > > I'd like to see real numbers in the entire packet. > > Hex dumps. > > The code/id/Length/etc. break out seems to take way more white > > space that it provides value. > > I think the hex dumps belong to the test vector section. > The packets are not fixed length so hex dumps would be problematic > except as examples. > If we re-arrange the attributes to separate sections, then > the descriptions of the messages will be shorter, but I think > it is still useful to clearly state at least=20 > the Subtype and Code for each message. > > > A21) re: AT_NEXT_PSEUDONYM, and I guess identities in general. > > What about UTF-8? Internationalization? > > Should we specify that all identities contain UTF-8 encoded=20 > ISO 10646 characters and refer to RFC2279? > =20 > > A22) section 18. > > This seems to be the only place that there is a table of > > values. I guess that is okay, but I found it hard to find. > > I'd like to see a table with brief explanations of each=20 > > attribue back in section 10 or earlier. > > Do you think a section with a separate subsection for each attribute > would be good enough? For each message, the section that specifies > the message can list the attributes that may, must and must not=20 > be included. > > > A24) Annex B. I found it to be clear as MUD. I guess I don't > > code very often to FIPS documents, are they all so obtuse? > > C code for this PRF would be welcome, along with test vectors. > > When I get mine working, I'll be happy to contribute them. > > This NIST specification really is very hard to follow. I think > that we need to have pseudo-code too. I posted some test vectors > on the list which we can include. > > Best regards, > Henry > > > --__--__-- > > Message: 5 > From: "Brynjar Hauksson" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>, "'Tom Emerson'" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Subject: RE: Wi-fi hotspot > Date: Tue, 16 Sep 2003 21:28:12 +0700 > Reply-To: [EMAIL PROTECTED] > > Hi Tom > > What prepaid system did you get? > > I've been searching for these systems with little success? > > Thanks in advance > > Kve=C3=B0ja / Best regards / = > =E0=B8=94=E0=B9=89=E0=B8=A7=E0=B8=A2=E0=B8=84=E0=B8=A7=E0=B8=B2=E0=B8=A1=E0= > =B8=84=E0=B8=B4=E0=B8=94=E0=B8=96=E0=B8=B6=E0=B8=87 > Brynjar Hauksson > ICQ# 15512204 > > -----Original Message----- > From: [EMAIL PROTECTED] = > [mailto:[EMAIL PROTECTED] On Behalf Of Tom = > Emerson > Sent: Tuesday, September 16, 2003 2:47 PM > To: [EMAIL PROTECTED] > Subject: Re: Wi-fi hotspot > > On Monday 15 September 2003 1:34 pm, Juliano Moises da Luz wrote: > > Can someone point me some documentation about how to setup hotspot > > authenticantion? > > As Alan mentioned, there is no one simple answer -- mainly because = > there are=20 > several ways of doing "a hotspot", some of which do not even NEED a = > "radius"=20 > server! > > > I need to setup a wi-fi hotspot and I am a little confused. I've = > already > > configured radius to authenticate users based on mac addresses, but = > i'm not > > sure this is the best way. > > A better place to begin is with the "Access point" you'll be using = > [hereafter=20 > referred to as a "NAS"] Some will do "all the work" for you [like the=20 > Proxim/Orinoco AP-2500 that I have] while others will require a=20 > behind-the-scenes approach [such as grabbing the least expensive AP at=20 > Circuit City or Best Buy, then hanging it off of a used/refurbished = > system=20 > running linux to act as a "gateway"] > > Generally the NAS will be responsible for managing connections, IP = > addresses,=20 > and so on. The proxim that I have will intercept a web-request, put up = > a=20 > banner and a login screen, authenticate against an external RADIUS, and=20 > enforce time limits if specified in the "reply" packet. Using a program = > such=20 > as NOCAT will let you do the same in a roll-your-own environment. > > The next question to consider is "are users going to pay for access?" = > For=20 > instance, in a coffee-shop environment, it might make sense to "give = > away"=20 > access time (i.e., don't charge at all) and use it as a "draw" to get=20 > customers into the building. [otoh, coffee-house clientelle are often=20 > "leeches" in that they will gladly sit around all day using your = > internet=20 > connection without a hint of a purchase...] On the third hand, however, = > > folks who hang out at a coffee house are "regular" customers, so a = > "monthly=20 > rate" is often a good compromise. > > Other locations, such as an airport or hotel, have a much more "fluid"=20 > clientelle -- you'll never see the same guy twice in a month [unless = > he's the=20 > pilot...] so these people you want to hit with a per-hour rate, or even=20 > per-quarter-hour [heck, T-mobile charges BY THE MINUTE] > > The next question is HOW are they going to pay? cash is always the = > easiest,=20 > but may lead to difficulties depending on the location [that airport=20 > again...] Credit cards billed-as-used are great, but may require a = > merchant=20 > account [which is OK if you are the owner of the location -- you're = > probably=20 > already set up for such...] Again, the NAS may play a role in this -- = > the=20 > Proxim can be configured to talk to an "industry standard" [hah!] = > website and=20 > thus manage the billing for you. With a roll-your-own, well, you'll be=20 > rolling it anyway, might as well build a custom merchant/CC gateway = > while=20 > you're at it... > > In my case I opted for a pre-paid/pre-printed "card" system. I generate = > a=20 > number of user ID's and passwords, each with an hour's worth of "time"=20 > associated with it, then print regular business-cards with the logo, = > user ID,=20 > and password. Since these are stored in a locked drawer behind the = > counter,=20 > I don't need fancy "scratch-off" style cards. One "hotspot-in-a-box" = > vendor=20 > actually has a thermal printer included with the setup -- pressing a = > button=20 > generates a user ID/password "on the fly" and allocates some amount of = > time=20 > to it. > > I've ALSO set up an interesting compromise to the aformentioned "leech"=20 > problem: I've set up a "counter" that tallies time on a per-MAC basis, = > with a=20 > limit of 15 minutes per day. This actually uses a set user ID/password=20 > combo, which is actually included in the login banner. This lets people = > use=20 > it seemingly like a promo ("with the purchase of a drink, you get...") = > yet=20 > doesn't require extensive configuration on my part [i.e., building=20 > potentially hundreds of "15 minute user ID's"] [search the archive for=20 > details -- I have posted the configuration items neccesary to do this] > > There are probably lots of other things that can be brought up for = > discussion,=20 > but notice VERY LITTLE of the above discussion really "needs" (or = > involves)=20 > Radius -- the NAS/AP can be configured with a list of known acceptible = > MAC=20 > addresses and/or set for "billing" people via a credit card, or you may = > be in=20 > a "don't care" situation in which case you really only need a "typical"=20 > consumer/home "wireless access point" set with a known SSID (and with a = > DHCP=20 > server enabled internally...) About the only thing you'll need a radius = > > server for is managing "pre-printed" access cards (in which case you'll=20 > really be managing a mysql or postgresql database...) or "monthly=20 > subscribers" > > --=20 > Yet another Blog: http://osnut.homelinux.net > > > > --__--__-- > > Message: 6 > From: "Alan DeKok" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: Radiusd service script + daemontools supervise > Date: Tue, 16 Sep 2003 10:35:40 -0400 > Reply-To: [EMAIL PROTECTED] > > "simon mackey" <[EMAIL PROTECTED]> wrote: > > When I boot up I can see the message "Starting radiusd [OK]" amongst all > > the other services like httpd, etc., so I presume it's running, but when I > > log in and type "lsof -i" at the command line I don't see any radiusd > > processes running :( > > 'ps' is the usual command to use. 'lsof' does something else. > > > I would reallllly appreciate it if someone would take me through how to get > > radiusd to start at boot time (with daemontools also monitoring it without > > me having to type supervise /var/svc/radiusd every time I reboot)? > > The 'doc' directory has documentaion on setting up daemontools. > > As for getting it to run on boot, that's a function of your local > OS. Read it's documentation, and look at the scripts for the other > programs which *do* run on boot. > > Alan DeKok. > > > --__--__-- > > Message: 7 > From: "Jeremy Davis" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Subject: RE: Wi-fi hotspot > Date: Tue, 16 Sep 2003 10:38:23 -0400 > Reply-To: [EMAIL PROTECTED] > > I recommend the Colubris CN3000 and the Zyzel 4000 for multi-AP = > deployments and the AP2500 or StarOS for single AP deployments. It is = > relatively easy to build a prepaid card engine due to the modular = > approach of FreeRadius. I have built one, and have another customer in = > the queue for this type of application. If you need help contact me = > off-list. > > Jeremy > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Brynjar > Hauksson > Sent: Tuesday, September 16, 2003 10:28 AM > To: [EMAIL PROTECTED]; 'Tom Emerson' > Cc: [EMAIL PROTECTED] > Subject: RE: Wi-fi hotspot > > > Hi Tom > > What prepaid system did you get? > > I've been searching for these systems with little success? > > Thanks in advance > > Kve=C3=B0ja / Best regards / = > =E0=B8=94=E0=B9=89=E0=B8=A7=E0=B8=A2=E0=B8=84=E0=B8=A7=E0=B8=B2=E0=B8=A1=E0= > =B8=84=E0=B8=B4=E0=B8=94=E0=B8=96=E0=B8=B6=E0=B8=87 > Brynjar Hauksson > ICQ# 15512204 > > -----Original Message----- > From: [EMAIL PROTECTED] = > [mailto:[EMAIL PROTECTED] On Behalf Of Tom = > Emerson > Sent: Tuesday, September 16, 2003 2:47 PM > To: [EMAIL PROTECTED] > Subject: Re: Wi-fi hotspot > > On Monday 15 September 2003 1:34 pm, Juliano Moises da Luz wrote: > > Can someone point me some documentation about how to setup hotspot > > authenticantion? > > As Alan mentioned, there is no one simple answer -- mainly because = > there are=20 > several ways of doing "a hotspot", some of which do not even NEED a = > "radius"=20 > server! > > > I need to setup a wi-fi hotspot and I am a little confused. I've = > already > > configured radius to authenticate users based on mac addresses, but = > i'm not > > sure this is the best way. > > A better place to begin is with the "Access point" you'll be using = > [hereafter=20 > referred to as a "NAS"] Some will do "all the work" for you [like the=20 > Proxim/Orinoco AP-2500 that I have] while others will require a=20 > behind-the-scenes approach [such as grabbing the least expensive AP at=20 > Circuit City or Best Buy, then hanging it off of a used/refurbished = > system=20 > running linux to act as a "gateway"] > > Generally the NAS will be responsible for managing connections, IP = > addresses,=20 > and so on. The proxim that I have will intercept a web-request, put up = > a=20 > banner and a login screen, authenticate against an external RADIUS, and=20 > enforce time limits if specified in the "reply" packet. Using a program = > such=20 > as NOCAT will let you do the same in a roll-your-own environment. > > The next question to consider is "are users going to pay for access?" = > For=20 > instance, in a coffee-shop environment, it might make sense to "give = > away"=20 > access time (i.e., don't charge at all) and use it as a "draw" to get=20 > customers into the building. [otoh, coffee-house clientelle are often=20 > "leeches" in that they will gladly sit around all day using your = > internet=20 > connection without a hint of a purchase...] On the third hand, however, = > > folks who hang out at a coffee house are "regular" customers, so a = > "monthly=20 > rate" is often a good compromise. > > Other locations, such as an airport or hotel, have a much more "fluid"=20 > clientelle -- you'll never see the same guy twice in a month [unless = > he's the=20 > pilot...] so these people you want to hit with a per-hour rate, or even=20 > per-quarter-hour [heck, T-mobile charges BY THE MINUTE] > > The next question is HOW are they going to pay? cash is always the = > easiest,=20 > but may lead to difficulties depending on the location [that airport=20 > again...] Credit cards billed-as-used are great, but may require a = > merchant=20 > account [which is OK if you are the owner of the location -- you're = > probably=20 > already set up for such...] Again, the NAS may play a role in this -- = > the=20 > Proxim can be configured to talk to an "industry standard" [hah!] = > website and=20 > thus manage the billing for you. With a roll-your-own, well, you'll be=20 > rolling it anyway, might as well build a custom merchant/CC gateway = > while=20 > you're at it... > > In my case I opted for a pre-paid/pre-printed "card" system. I generate = > a=20 > number of user ID's and passwords, each with an hour's worth of "time"=20 > associated with it, then print regular business-cards with the logo, = > user ID,=20 > and password. Since these are stored in a locked drawer behind the = > counter,=20 > I don't need fancy "scratch-off" style cards. One "hotspot-in-a-box" = > vendor=20 > actually has a thermal printer included with the setup -- pressing a = > button=20 > generates a user ID/password "on the fly" and allocates some amount of = > time=20 > to it. > > I've ALSO set up an interesting compromise to the aformentioned "leech"=20 > problem: I've set up a "counter" that tallies time on a per-MAC basis, = > with a=20 > limit of 15 minutes per day. This actually uses a set user ID/password=20 > combo, which is actually included in the login banner. This lets people = > use=20 > it seemingly like a promo ("with the purchase of a drink, you get...") = > yet=20 > doesn't require extensive configuration on my part [i.e., building=20 > potentially hundreds of "15 minute user ID's"] [search the archive for=20 > details -- I have posted the configuration items neccesary to do this] > > There are probably lots of other things that can be brought up for = > discussion,=20 > but notice VERY LITTLE of the above discussion really "needs" (or = > involves)=20 > Radius -- the NAS/AP can be configured with a list of known acceptible = > MAC=20 > addresses and/or set for "billing" people via a credit card, or you may = > be in=20 > a "don't care" situation in which case you really only need a "typical"=20 > consumer/home "wireless access point" set with a known SSID (and with a = > DHCP=20 > server enabled internally...) About the only thing you'll need a radius = > > server for is managing "pre-printed" access cards (in which case you'll=20 > really be managing a mysql or postgresql database...) or "monthly=20 > subscribers" > > --=20 > Yet another Blog: http://osnut.homelinux.net > > > -=20 > List info/subscribe/unsubscribe? See = > http://www.freeradius.org/list/users.html > > > > > --__--__-- > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > > > End of Freeradius-Users Digest > > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
