[openbeosnetteam] Re: Tests plan?

Hi,

> > It seems we may be able to formalize a testing group as well.  Scott
> > and I for sure, and perhaps Waldemar.  If we have a definite set of
> > testers, we can work together to create the test plans and so on.

I would like to help you testing the netstack, but I also have my own task that 
will hopefully be finished soon (at least the basic stuff).

> Based on what's been posted in the past I think that Waldemar is the 
> only one who can exercise the PPP stuff (?).  I, for one, cannot test 
> this because I have an ADSL connection with a static IP address.

You mean that you do not dial-in with username and password. It is like an 
ethernet connection, right?

> I also think we should capture a core dump on Philippe's and Waldemar's 
> brain.  You and I are coming into this cold (which has its advantages), 
> but a quick proverbial "state of the union address" definitely couldn't 
> hurt.

Hey, just ask and we will try to answer (if we can ;).

> > I personally am testing the stack initially by running through each
> > of our available network applications:
> >
> > arp
> > ifconfig
> > ping
> > route
> > traceroute

Yes, that is a good starting point. You will soon see what has to be done.

> How about more abusive things like nmap (or the Be equivalent), ping 
> floods, and multicast?
> 
> Do we have a way to test things like IGMP or PIM?  What about UDP?

I cannot say anything about it.

> In this age where "internet security" seems to be the buzzword du jour, 
> Be lacks anything even remotely resembling stateful packet filtering.  
> Sorry, that's the security freak in me rearing its ugly head.  Is this 
> applicable to R5, or GE stuff?  Nathan, do you have anything to add 
> here?

The next generation netstack will have such features, but not the current one.

> > I am not testing pppconfig, but I think Waldemar is.  I am writing up

Right. ;)

> > Once we get past this first stage, I am will to right up formal test
> > plans so we can dig further into the issues and start changing code...
> 
> Hmmmm...  Seems to me that the "first stage" you propose is an 
> artificial milestone.  After all, the stack and its kith and kin, have 
> been under development for some time now.  I'd rather step back and 
> take in the bigger picture, fix what's broken, and evolve the product 
> (pardon the corporate-speak).

Do not implement new features. Just fix the beast.
If you really want to replace some parts we should design it with a future 
stack in mind.
But the main task is getting the stack working.

> > but what do you all think of this so far?

Sounds okay to me.

Waldemar

Other related posts: