From edrt@citiz.net  Tue Dec  2 05:34:33 2003
From: edrt@citiz.net (edrt)
Date: Tue, 2 Dec 2003 13:34:33 +0800
Subject: [Xorp-hackers] compiler brokes at EtherMac::valid
Message-ID: <200312020535.hB25Z2l8016741@wyvern.icir.org>

Hi All,
   When porting mac.cc, my compiler broken at EtherMac::valid. 
Is "buf[s.size() + 1]" definition valid ? Instead, when replace it with fixed size definition the 
compiler doesn't complains.
   Is it someting to do with my compiler? My compiler is g++ppc (gcc driver version 
cygnus-2.7.2-960126 egcs-971225), below is the output of the compiler :

/* 
 * ccppc -g -mcpu=860 -ansi -nostdinc -DRW_MULTI_THREAD -D_REENTRANT -fvolatile -fno-builtin	
 * -fno-for-scope -I. -IC:\Tornado\target\h -DCPU=PPC860 -c E:\NIP\source\libxorp\mac.cc
 * E:\NIP\source\libxorp\mac.cc: In function `static bool EtherMac::valid(const class basic_s 
 * tring<char,string_char_traits<char>,__default_alloc_template<true,0> > &)':
 * E:\NIP\source\libxorp\mac.cc:113: Internal compiler error.
 * E:\NIP\source\libxorp\mac.cc:113: Please submit a full bug report to `egcs-bugs@cygnus.com 
 * '.
 * make: *** [mac.o] Error 0x1
 */


Edrt





From pavlin@icir.org  Tue Dec  2 08:13:27 2003
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Tue, 02 Dec 2003 00:13:27 -0800
Subject: [Xorp-hackers] compiler brokes at EtherMac::valid
In-Reply-To: Message from "edrt" <edrt@citiz.net>
 of "Tue, 02 Dec 2003 13:34:33 +0800." <200312020535.hB25Z2l8016741@wyvern.icir.org>
Message-ID: <200312020813.hB28DRSx002680@possum.icir.org>

>    When porting mac.cc, my compiler broken at EtherMac::valid. 
> Is "buf[s.size() + 1]" definition valid ? Instead, when replace it with fixed size definition the 
> compiler doesn't complains.
>    Is it someting to do with my compiler? My compiler is g++ppc (gcc driver version 
> cygnus-2.7.2-960126 egcs-971225), below is the output of the compiler :

The variable-length automatic arrays are GCC-ism.
They are used in few places, because they help to make the code a
bit simpler.

It looks like your compiler is from the gcc family so I guess it
should be able to compile it, but from the compilation error below
the reason it fails is obvious: "Internal compiler error" (i.e., a
compiler bug).

Nevertheless, variable-length arrays make the code more difficult to
port (as you have noticed already), hence I think we should try to
get rid of them (especially given that I am probably the most
frequent user of variable-length arrays :)

In other words, your solution of using fixed-size definition is the
right one.

Thanks,
Pavlin

P.S. BTW, what OS are you trying to port XORP to? Please don't tell
me it is Windows :)

> 
> /* 
>  * ccppc -g -mcpu=860 -ansi -nostdinc -DRW_MULTI_THREAD -D_REENTRANT -fvolatile -fno-builtin	
>  * -fno-for-scope -I. -IC:\Tornado\target\h -DCPU=PPC860 -c E:\NIP\source\libxorp\mac.cc
>  * E:\NIP\source\libxorp\mac.cc: In function `static bool EtherMac::valid(const class basic_s 
>  * tring<char,string_char_traits<char>,__default_alloc_template<true,0> > &)':
>  * E:\NIP\source\libxorp\mac.cc:113: Internal compiler error.
>  * E:\NIP\source\libxorp\mac.cc:113: Please submit a full bug report to `egcs-bugs@cygnus.com 
>  * '.
>  * make: *** [mac.o] Error 0x1
>  */
> 
> 
> Edrt

From adam@hiddennet.net  Tue Dec  2 09:50:55 2003
From: adam@hiddennet.net (Adam Greenhalgh)
Date: Tue, 02 Dec 2003 09:50:55 +0000
Subject: [Xorp-hackers] compiler brokes at EtherMac::valid
In-Reply-To: <200312020813.hB28DRSx002680@possum.icir.org>
References: <200312020813.hB28DRSx002680@possum.icir.org>
Message-ID: <1070358653.22634.3.camel@localhost>

I was wondering what you were trying to port it too. The compile being
g++ppc does suggest it is going to be a power pc though.

If you just want to try xorp , check out the software section of 
http://www.cs.ucl.ac.uk/staff/a.greenhalgh , it contains a bootable cd
which boots linux with a xorp router running. It optionally loads the
xorp config files from a floppy, please note that the floppy isn't part
of the boot process, it only contains config.

Adam

On Tue, 2003-12-02 at 08:13, Pavlin Radoslavov wrote:
> >    When porting mac.cc, my compiler broken at EtherMac::valid. 
> > Is "buf[s.size() + 1]" definition valid ? Instead, when replace it with fixed size definition the 
> > compiler doesn't complains.
> >    Is it someting to do with my compiler? My compiler is g++ppc (gcc driver version 
> > cygnus-2.7.2-960126 egcs-971225), below is the output of the compiler :
> 
> The variable-length automatic arrays are GCC-ism.
> They are used in few places, because they help to make the code a
> bit simpler.
> 
> It looks like your compiler is from the gcc family so I guess it
> should be able to compile it, but from the compilation error below
> the reason it fails is obvious: "Internal compiler error" (i.e., a
> compiler bug).
> 
> Nevertheless, variable-length arrays make the code more difficult to
> port (as you have noticed already), hence I think we should try to
> get rid of them (especially given that I am probably the most
> frequent user of variable-length arrays :)
> 
> In other words, your solution of using fixed-size definition is the
> right one.
> 
> Thanks,
> Pavlin
> 
> P.S. BTW, what OS are you trying to port XORP to? Please don't tell
> me it is Windows :)
> 
> > 
> > /* 
> >  * ccppc -g -mcpu=860 -ansi -nostdinc -DRW_MULTI_THREAD -D_REENTRANT -fvolatile -fno-builtin	
> >  * -fno-for-scope -I. -IC:\Tornado\target\h -DCPU=PPC860 -c E:\NIP\source\libxorp\mac.cc
> >  * E:\NIP\source\libxorp\mac.cc: In function `static bool EtherMac::valid(const class basic_s 
> >  * tring<char,string_char_traits<char>,__default_alloc_template<true,0> > &)':
> >  * E:\NIP\source\libxorp\mac.cc:113: Internal compiler error.
> >  * E:\NIP\source\libxorp\mac.cc:113: Please submit a full bug report to `egcs-bugs@cygnus.com 
> >  * '.
> >  * make: *** [mac.o] Error 0x1
> >  */
> > 
> > 
> > Edrt
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers@icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From edrt@citiz.net  Tue Dec  2 11:20:06 2003
From: edrt@citiz.net (edrt)
Date: Tue, 2 Dec 2003 19:20:6 +0800
Subject: [Xorp-hackers] compiler brokes at EtherMac::valid
Message-ID: <200312021120.hB2BKPl8019645@wyvern.icir.org>

>>    When porting mac.cc, my compiler broken at EtherMac::valid. 
>> Is "buf[s.size() + 1]" definition valid ? Instead, when replace it with fixed size definition the 
>> compiler doesn't complains.
>>    Is it someting to do with my compiler? My compiler is g++ppc (gcc driver version 
>> cygnus-2.7.2-960126 egcs-971225), below is the output of the compiler :
>
>The variable-length automatic arrays are GCC-ism.
>They are used in few places, because they help to make the code a
>bit simpler.
>
>It looks like your compiler is from the gcc family so I guess it
>should be able to compile it, but from the compilation error below
>the reason it fails is obvious: "Internal compiler error" (i.e., a
>compiler bug).
>
>Nevertheless, variable-length arrays make the code more difficult to
>port (as you have noticed already), hence I think we should try to
>get rid of them (especially given that I am probably the most
>frequent user of variable-length arrays :)
>
>In other words, your solution of using fixed-size definition is the
>right one.
>
>Thanks,
>Pavlin
>
>P.S. BTW, what OS are you trying to port XORP to? Please don't tell
>me it is Windows :)

The target OS is vxworks running on powerpc, using cross-development tools 
running on Windows to build and download it to target board.

Thanks
Edrt


>
>> 
>> /* 
>>  * ccppc -g -mcpu=860 -ansi -nostdinc -DRW_MULTI_THREAD -D_REENTRANT -fvolatile -fno-builtin	
>>  * -fno-for-scope -I. -IC:\Tornado\target\h -DCPU=PPC860 -c E:\NIP\source\libxorp\mac.cc
>>  * E:\NIP\source\libxorp\mac.cc: In function `static bool EtherMac::valid(const class basic_s 
>>  * tring<char,string_char_traits<char>,__default_alloc_template<true,0> > &)':
>>  * E:\NIP\source\libxorp\mac.cc:113: Internal compiler error.
>>  * E:\NIP\source\libxorp\mac.cc:113: Please submit a full bug report to `egcs-bugs@cygnus.com 
>>  * '.
>>  * make: *** [mac.o] Error 0x1
>>  */
>> 
>> 
>> Edrt

			




From edrt@citiz.net  Tue Dec  2 11:23:25 2003
From: edrt@citiz.net (edrt)
Date: Tue, 2 Dec 2003 19:23:25 +0800
Subject: [Xorp-hackers] compiler brokes at EtherMac::valid
Message-ID: <200312021123.hB2BNil8019676@wyvern.icir.org>

>I was wondering what you were trying to port it too. The compile being
>g++ppc does suggest it is going to be a power pc though.
>
VxWorks.

>If you just want to try xorp , check out the software section of 
>http://www.cs.ucl.ac.uk/staff/a.greenhalgh , it contains a bootable cd
>which boots linux with a xorp router running. It optionally loads the
>xorp config files from a floppy, please note that the floppy isn't part
>of the boot process, it only contains config.
>
>Adam

Thanks for the info, I'll try it.

Edrt

>
>On Tue, 2003-12-02 at 08:13, Pavlin Radoslavov wrote:
>> >    When porting mac.cc, my compiler broken at EtherMac::valid. 
>> > Is "buf[s.size() + 1]" definition valid ? Instead, when replace it with fixed size definition the 
>> > compiler doesn't complains.
>> >    Is it someting to do with my compiler? My compiler is g++ppc (gcc driver version 
>> > cygnus-2.7.2-960126 egcs-971225), below is the output of the compiler :
>> 
>> The variable-length automatic arrays are GCC-ism.
>> They are used in few places, because they help to make the code a
>> bit simpler.
>> 
>> It looks like your compiler is from the gcc family so I guess it
>> should be able to compile it, but from the compilation error below
>> the reason it fails is obvious: "Internal compiler error" (i.e., a
>> compiler bug).
>> 
>> Nevertheless, variable-length arrays make the code more difficult to
>> port (as you have noticed already), hence I think we should try to
>> get rid of them (especially given that I am probably the most
>> frequent user of variable-length arrays :)
>> 
>> In other words, your solution of using fixed-size definition is the
>> right one.
>> 
>> Thanks,
>> Pavlin
>> 
>> P.S. BTW, what OS are you trying to port XORP to? Please don't tell
>> me it is Windows :)
>> 
>> > 
>> > /* 
>> >  * ccppc -g -mcpu=860 -ansi -nostdinc -DRW_MULTI_THREAD -D_REENTRANT -fvolatile -fno-builtin	
>> >  * -fno-for-scope -I. -IC:\Tornado\target\h -DCPU=PPC860 -c E:\NIP\source\libxorp\mac.cc
>> >  * E:\NIP\source\libxorp\mac.cc: In function `static bool EtherMac::valid(const class basic_s 
>> >  * tring<char,string_char_traits<char>,__default_alloc_template<true,0> > &)':
>> >  * E:\NIP\source\libxorp\mac.cc:113: Internal compiler error.
>> >  * E:\NIP\source\libxorp\mac.cc:113: Please submit a full bug report to `egcs-bugs@cygnus.com 
>> >  * '.
>> >  * make: *** [mac.o] Error 0x1
>> >  */
>> > 
>> > 
>> > Edrt
>> _______________________________________________
>> Xorp-hackers mailing list
>> Xorp-hackers@icir.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>
>_______________________________________________
>Xorp-hackers mailing list
>Xorp-hackers@icir.org
>http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers

			




From edrt@citiz.net  Tue Dec  2 11:54:05 2003
From: edrt@citiz.net (edrt)
Date: Tue, 2 Dec 2003 19:54:5 +0800
Subject: [Xorp-hackers] compiler brokes at EtherMac::valid
Message-ID: <200312021154.hB2BsNl8019863@wyvern.icir.org>

>On Tue, 2003-12-02 at 11:20, edrt wrote:
>> >>    When porting mac.cc, my compiler broken at EtherMac::valid. 
>> >> Is "buf[s.size() + 1]" definition valid ? Instead, when replace it with fixed size definition the 
>> >> compiler doesn't complains.
>> >>    Is it someting to do with my compiler? My compiler is g++ppc (gcc driver version 
>> >> cygnus-2.7.2-960126 egcs-971225), below is the output of the compiler :
>> >
>> >The variable-length automatic arrays are GCC-ism.
>> >They are used in few places, because they help to make the code a
>> >bit simpler.
>> >
>> >It looks like your compiler is from the gcc family so I guess it
>> >should be able to compile it, but from the compilation error below
>> >the reason it fails is obvious: "Internal compiler error" (i.e., a
>> >compiler bug).
>> >
>> >Nevertheless, variable-length arrays make the code more difficult to
>> >port (as you have noticed already), hence I think we should try to
>> >get rid of them (especially given that I am probably the most
>> >frequent user of variable-length arrays :)
>> >
>> >In other words, your solution of using fixed-size definition is the
>> >right one.
>> >
>> >Thanks,
>> >Pavlin
>> >
>> >P.S. BTW, what OS are you trying to port XORP to? Please don't tell
>> >me it is Windows :)
>> 
>> The target OS is vxworks running on powerpc, using cross-development tools 
>> running on Windows to build and download it to target board.
>> 
>> Thanks
>> Edrt
>> 
>Sounds interesting, can you say any more about what your long term goals
>are ? Copy your reply to xorp-hackers if this is appropriate.
>
>Adam
>Part-time xorp developer
>Full-time PhD
>
Short term goal is port and play with PIM. Later to port the other Xorp component 
to the embedded platform (especially IPC stuff). 
C++ code is more manageable, greatly reduce the time to understand the Xorp internal : )

Edrt

>> 
>> >
>> >> 
>> >> /* 
>> >>  * ccppc -g -mcpu=860 -ansi -nostdinc -DRW_MULTI_THREAD -D_REENTRANT -fvolatile -fno-builtin	
>> >>  * -fno-for-scope -I. -IC:\Tornado\target\h -DCPU=PPC860 -c E:\NIP\source\libxorp\mac.cc
>> >>  * E:\NIP\source\libxorp\mac.cc: In function `static bool EtherMac::valid(const class basic_s 
>> >>  * tring<char,string_char_traits<char>,__default_alloc_template<true,0> > &)':
>> >>  * E:\NIP\source\libxorp\mac.cc:113: Internal compiler error.
>> >>  * E:\NIP\source\libxorp\mac.cc:113: Please submit a full bug report to `egcs-bugs@cygnus.com 
>> >>  * '.
>> >>  * make: *** [mac.o] Error 0x1
>> >>  */
>> >> 
>> >> 
>> >> Edrt
>> 
>> 			
>> 
>> 
>> 
>> _______________________________________________
>> Xorp-hackers mailing list
>> Xorp-hackers@icir.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers

			




From alsharrifws@post.cz  Thu Dec 11 15:54:58 2003
From: alsharrifws@post.cz (Al Sharrif)
Date: Thu, 11 Dec 2003 16:54:58 +0100
Subject: [Xorp-hackers] Reply Soon (Read Do Not Delete)
Message-ID: <200312111554.hBBFrol8047201@wyvern.icir.org>

Partnership Investment
ATTN SIR,
I received encouraging information about you and how trust worthy you are. I
am delighted with such a useful information. I am interested in the
partnership investment program with your corporation or with you in. First permit me to
introduce myself as Al Sharrif of the Polisario Movement of Western
Sahara State in the Democratic Republic of Sahara. Being the chief executive
of my region under our leader Mohamed Abdulaziz . I awarded the contract of
IRRIGATION to a top Portuguese Firm worth several millions of dollars. In
the execution of that project the Portuguese Firm discovered large amount of
gold in one of the contract site. I collaborated with the Portuguese Firm on
a mutual agreement on the proceed of which my share of $65.000,000 =(sixty
five million dollars)has been deposited with a security company in Europe.
As the Governor, I cannot introduce or circulate this funds into the Sahara
banking system considering my provisional duty and considering the fact 

that I earn less than $1,000US dollars monthly. The above situation prompted
my decision to solicit your co-operation to take delivery of this funds into
your custody for my proposed investment as you will be adequately
compensated with $5,000,000 USdollars. I will arrange all necessary
procedures in ensuring a smooth process for the funds to get to you. I will
appreciate you contact me once you receive this mail via my e-mail account
indicating your capability and willingness to enable me to give you more
details of my modus operandi of getting this money to you hitch free. This
matter requires your urgent attention and confidentiality whatever your
decision.
Best Regards,
Albert Sharrif
Western Sahara
Sahara




From alsharrifws@post.cz  Thu Dec 11 15:51:57 2003
From: alsharrifws@post.cz (Al Sharrif)
Date: Thu, 11 Dec 2003 16:51:57 +0100
Subject: [Xorp-hackers] Reply Soon (Read Do Not Delete)
Message-ID: <200312111551.hBBFoxl8047183@wyvern.icir.org>

Partnership Investment
ATTN SIR,
I received encouraging information about you and how trust worthy you are. I
am delighted with such a useful information. I am interested in the
partnership investment program with your corporation or with you in. First permit me to
introduce myself as Al Sharrif of the Polisario Movement of Western
Sahara State in the Democratic Republic of Sahara. Being the chief executive
of my region under our leader Mohamed Abdulaziz . I awarded the contract of
IRRIGATION to a top Portuguese Firm worth several millions of dollars. In
the execution of that project the Portuguese Firm discovered large amount of
gold in one of the contract site. I collaborated with the Portuguese Firm on
a mutual agreement on the proceed of which my share of $65.000,000 =(sixty
five million dollars)has been deposited with a security company in Europe.
As the Governor, I cannot introduce or circulate this funds into the Sahara
banking system considering my provisional duty and considering the fact 

that I earn less than $1,000US dollars monthly. The above situation prompted
my decision to solicit your co-operation to take delivery of this funds into
your custody for my proposed investment as you will be adequately
compensated with $5,000,000 USdollars. I will arrange all necessary
procedures in ensuring a smooth process for the funds to get to you. I will
appreciate you contact me once you receive this mail via my e-mail account
indicating your capability and willingness to enable me to give you more
details of my modus operandi of getting this money to you hitch free. This
matter requires your urgent attention and confidentiality whatever your
decision.
Best Regards,
Albert Sharrif
Western Sahara
Sahara




From M.Handley@cs.ucl.ac.uk  Thu Dec 11 16:03:59 2003
From: M.Handley@cs.ucl.ac.uk (Mark Handley)
Date: Thu, 11 Dec 2003 16:03:59 +0000
Subject: {SPAM?} [Xorp-hackers] Reply Soon (Read Do Not Delete)
In-Reply-To: Your message of "Thu, 11 Dec 2003 16:51:57 +0100."
 <200312111551.hBBFoxl8047183@wyvern.icir.org>
Message-ID: <19362.1071158639@aardvark.cs.ucl.ac.uk>

Sorry about the spam - I've just changed the permissions so this list
is now restricted to subscribers only (all other posts will need admin
approval).

 - Mark

From M.Handley@cs.ucl.ac.uk  Wed Dec 17 11:25:03 2003
From: M.Handley@cs.ucl.ac.uk (Mark Handley)
Date: Wed, 17 Dec 2003 11:25:03 +0000
Subject: [Xorp-hackers] xorp for wireless authentication/access
Message-ID: <72639.1071660303@aardvark.cs.ucl.ac.uk>

Adam and I have been discussing the idea of writing XORP components to
provide access control and authentication for wireless users.  This
would use transparent HTTP redirect to a web page on the router itself
to allow users to authenticate themselves - basically the same method
used by lots of wireless hotspots.

This isn't all that hard to do in principle - the hardest part would
probably be unifying all the various components (firewall, dhcpd,
httpd) under the XORP rtrmgr and configuration files.

But this raises one question which we don't know how to answer: what
should the FEA's API be for firewall functionality?  Comparing what is
available on various platforms (especially FreeBSD and Linux), it
seems that there isn't a whole lot of commonality between iptables and
ipfw2. So creating a common API without dumbing it down to the lowest
common denominator seems difficult.

Does anyone have any thoughts on this?

Cheers,
	Mark

From luigi@iet.unipi.it  Wed Dec 17 17:00:45 2003
From: luigi@iet.unipi.it (Luigi Rizzo)
Date: Wed, 17 Dec 2003 09:00:45 -0800
Subject: [Xorp-hackers] Re: xorp for wireless authentication/access
In-Reply-To: <72639.1071660303@aardvark.cs.ucl.ac.uk>; from M.Handley@cs.ucl.ac.uk on Wed, Dec 17, 2003 at 11:25:03AM +0000
References: <72639.1071660303@aardvark.cs.ucl.ac.uk>
Message-ID: <20031217090045.A61319@xorpc.icir.org>

my opinion on that is that there is not going to be a common API.
Just the way stateless filtering is expressed varies a lot
(some have hash tables, some have maps, some have lists),
not to mention stateful and 'extra stuff' that the firewall can do.
 
However -- it seems that here you have a very specific problem at
hand, so it would be conceivable to provide a few calls:

        redirect_unauthenticated_user()
        open_services_to_this_mac_address(mac_address)
        delete_all_permissions_for_this_mac_address(mac_address)

which are then translated into machine dependent set of calls
to the firewall. And think of a general API only when/if you
will ever need it.

	cheers
	luigi

On Wed, Dec 17, 2003 at 11:25:03AM +0000, Mark Handley wrote:
> 
> Adam and I have been discussing the idea of writing XORP components to
> provide access control and authentication for wireless users.  This
> would use transparent HTTP redirect to a web page on the router itself
> to allow users to authenticate themselves - basically the same method
> used by lots of wireless hotspots.
> 
> This isn't all that hard to do in principle - the hardest part would
> probably be unifying all the various components (firewall, dhcpd,
> httpd) under the XORP rtrmgr and configuration files.
> 
> But this raises one question which we don't know how to answer: what
> should the FEA's API be for firewall functionality?  Comparing what is
> available on various platforms (especially FreeBSD and Linux), it
> seems that there isn't a whole lot of commonality between iptables and
> ipfw2. So creating a common API without dumbing it down to the lowest
> common denominator seems difficult.
> 
> Does anyone have any thoughts on this?
> 
> Cheers,
> 	Mark

From M.Handley@cs.ucl.ac.uk  Wed Dec 17 19:34:41 2003
From: M.Handley@cs.ucl.ac.uk (Mark Handley)
Date: Wed, 17 Dec 2003 19:34:41 +0000
Subject: [Xorp-hackers] Re: xorp for wireless authentication/access
In-Reply-To: Your message of "Wed, 17 Dec 2003 09:00:45 PST."
 <20031217090045.A61319@xorpc.icir.org>
Message-ID: <11427.1071689681@eve.cs.ucl.ac.uk>

>my opinion on that is that there is not going to be a common API.
>Just the way stateless filtering is expressed varies a lot
>(some have hash tables, some have maps, some have lists),
>not to mention stateful and 'extra stuff' that the firewall can do.

That's my concern too.

>However -- it seems that here you have a very specific problem at
>hand, so it would be conceivable to provide a few calls:
>
>        redirect_unauthenticated_user()
>        open_services_to_this_mac_address(mac_address)
>        delete_all_permissions_for_this_mac_address(mac_address)
>
>which are then translated into machine dependent set of calls
>to the firewall. And think of a general API only when/if you
>will ever need it.

This would work for this application.  

But a XORP router *is* going to have to be able to do fairly general
firewalling.  

Perhaps the solution here is to clone Juniper's firewall CLI, map this
into an API to the FEA for the basic firewall functionality, and fix
up everything in the FEA to map this to native calls.  This would give
us basic functionality, but not the bells and whistles.  

For specific functionality like the wireless auth, we could provide
higher-level calls like those above.  

And then if you really need the bells and whistles, provide a bypass
mechanism to access the platform's native interface directly, albeit
non-portably.

Cheers,
	Mark

From kohler@icir.org  Thu Dec 18 17:52:48 2003
From: kohler@icir.org (Eddie Kohler)
Date: Thu, 18 Dec 2003 09:52:48 -0800
Subject: [Xorp-hackers] Re: xorp for wireless authentication/access
In-Reply-To: Message from Mark Handley <M.Handley@cs.ucl.ac.uk>
 of "Wed, 17 Dec 2003 19:34:41 GMT." <11427.1071689681@eve.cs.ucl.ac.uk>
Message-ID: <200312181752.hBIHqmsD010976@coyote.icir.org>

> This would work for this application.  
> 
> But a XORP router *is* going to have to be able to do fairly general
> firewalling.  
> 
> Perhaps the solution here is to clone Juniper's firewall CLI, map this
> into an API to the FEA for the basic firewall functionality, and fix
> up everything in the FEA to map this to native calls.  This would give
> us basic functionality, but not the bells and whistles.  

Oy, I disagree with this approach, except for this:

> And then if you really need the bells and whistles, provide a bypass
> mechanism to access the platform's native interface directly, albeit
> non-portably.

I think the right thing to do now is to incrementally add well-designed
bits to the FEA as we need specific firewall functions. Then any potential
unifying plan would emerge naturally.

E