netnice-kernels — a ML for netnice kernel module and its porting

Re: [Netnice-kernels] Re: inetd on OpenBSD

[Takashi O. <ta...@cs...>]

hi,

sorry for the slow reply. i will have a short business trip back to japan
this weekend and have been a bit hectic.

Scott Brumbaugh wrote:
> 
> > but, i have been thinking, in such a case, all the sockets should be
> > "disconnected", since the situation in which sockets are connected to
> > a VIF which is a parent of the process which accommodates the sockets
> > is a violation of the VIF association rule.
> >
> 
> This is not clear to me. In inetd all the sockets are inherited by
> the child but they are closed (disconnected) in the inetd parent.  All
> that I see as being incorrect is that the inherited sockets are not
> linked to the correct VIF in the child process.  I only see this as an
> inetd problem.  Maybe you can explain the error in my understanding as I
> don't see this as a problem in the netnice internals.
> 
> The behavior that I observe in both Linux and FreeBSD is that when a
> process creates sockets, the sockets are attached to a copy of that
> process's associated VIF.  When a new process is created it inherits
> the parents process VIF.  A process can change its associated VIF but
> this will not change the VIF association of any sockets currently in
> existence.  Only new sockets will be connected to the new process VIF.
> 
> If a process wants a socket to be associated with a specific VIF it
> needs to either explicitly set the symlink in Pso_dir or it must first
> attach the VIF as its process specific VIF as a symlink under Pso_list
> and then create the socket.
> 
> Looking at what you wrote, are you saying that when a process does the
> symlink operation in Pso_list that all the sockets under Pso_dir need
> to be reattached as well?

i think yes. all the sockets are connected to VIFs, which are the process-
attached VIF or its descendants. otherwise, it violates the protection rule.
to avoid sudden disconnection, it is programs responsibility, to reconnect
the sockets-VIF association first, before reconnects the process-VIF
association.

> I have added the vifctl perl script to the userspace tools under
> netnice/linux.  The changes consisted of a lookup in /etc/mtab for the
> nnfs mount point, and a lookup in /proc/<pid>/exe for the processes
> executable file name. I have also added code to have inetd create the
> symlinks under the socket fd directories as discussed previously.
> These changes are conditionally deactivated now because they are
> causing crashes when enabled.  I do not know what is wrong at this
> point.

this sounds good. thaks.

> I have also committed bug fix changes to NNFS.  One change is a work
> around that appears to prevent the intermittent crashes that where
> occurring in pvif_lookup.  This change affects the pvif returned from
> the lookup of a TCP socket.  Now a pvif will only be returned when a
> TCP socket is in the ESTABLISHED state.

ah. i have never thought about this issue. Linux may have different
semantics of socket lookup. we will check the BSD part. thanks for
the report.


best,

-- taka

Re: [Netnice-kernels] Re: inetd on OpenBSD

[Scott B. <sco...@ve...>]

Hi,

I have added the vifctl perl script to the userspace tools under
netnice/linux.  The changes consisted of a lookup in /etc/mtab for the
nnfs mount point, and a lookup in /proc/<pid>/exe for the processes
executable file name. I have also added code to have inetd create the
symlinks under the socket fd directories as discussed previously.
These changes are conditionally deactivated now because they are
causing crashes when enabled.  I do not know what is wrong at this
point.

I have also committed bug fix changes to NNFS.  One change is a work
around that appears to prevent the intermittent crashes that where
occurring in pvif_lookup.  This change affects the pvif returned from
the lookup of a TCP socket.  Now a pvif will only be returned when a
TCP socket is in the ESTABLISHED state.

So far the following pieces are functioning in an alpha state
on Linux.

	netnice internals
	nnfs
	inetd
	netnice command
	vifctl



Regards,


Scott Brumbaugh

[Netnice-kernels] Re: inetd on OpenBSD

[Scott B. <sco...@ve...>]

Hi Takashi,

On Sun, 14 Nov 2004, Takashi Okumura wrote:

> hi scott,
> 
> sorry for the slow reply. because nn_create() wraps the created process
> with a VIF before it does an exec call, i think that any sockets created
> after the exec will share the created VIF. the reason because the sockets
> you observed were not sharing the created VIF is probably because, they
> are inherited from the inetd. so, we'll need to reconnect all the sockets,
> probably inside nn_create(), as you suggested...
> 

I think this is easy to fix.

> but, i have been thinking, in such a case, all the sockets should be
> "disconnected", since the situation in which sockets are connected to
> a VIF which is a parent of the process which accommodates the sockets
> is a violation of the VIF association rule.
> 

This is not clear to me. In inetd all the sockets are inherited by
the child but they are closed (disconnected) in the inetd parent.  All
that I see as being incorrect is that the inherited sockets are not
linked to the correct VIF in the child process.  I only see this as an
inetd problem.  Maybe you can explain the error in my understanding as I
don't see this as a problem in the netnice internals.

The behavior that I observe in both Linux and FreeBSD is that when a
process creates sockets, the sockets are attached to a copy of that
process's associated VIF.  When a new process is created it inherits
the parents process VIF.  A process can change its associated VIF but
this will not change the VIF association of any sockets currently in
existence.  Only new sockets will be connected to the new process VIF.

If a process wants a socket to be associated with a specific VIF it
needs to either explicitly set the symlink in Pso_dir or it must first
attach the VIF as its process specific VIF as a symlink under Pso_list
and then create the socket.

Looking at what you wrote, are you saying that when a process does the
symlink operation in Pso_list that all the sockets under Pso_dir need
to be reattached as well?  


> so, it looks like a serious bug, both in the kernel and in the inetd
> implementation. i appreciate your bug report, and would be happy
> if you take care of the linux side of the issue (both in the kernel
> and in the userland).
> 
> best,
> 
> -- taka
> 


Thanks,


Scott Brumbaugh

[Netnice-kernels] Re: inetd on OpenBSD

[Takashi O. <ta...@cs...>]

hi scott,

sorry for the slow reply. because nn_create() wraps the created process
with a VIF before it does an exec call, i think that any sockets created
after the exec will share the created VIF. the reason because the sockets
you observed were not sharing the created VIF is probably because, they
are inherited from the inetd. so, we'll need to reconnect all the sockets,
probably inside nn_create(), as you suggested...

but, i have been thinking, in such a case, all the sockets should be
"disconnected", since the situation in which sockets are connected to
a VIF which is a parent of the process which accommodates the sockets
is a violation of the VIF association rule.

so, it looks like a serious bug, both in the kernel and in the inetd
implementation. i appreciate your bug report, and would be happy
if you take care of the linux side of the issue (both in the kernel
and in the userland).

best,

-- taka

Scott Brumbaugh wrote:
> 
> Hi Takashi,
> 
> I have been implementing inetd on Linux and need an explaination.  I
> have setup an inetd.conf as so:
> 
> # inetd.conf
> telnet  stream  tcp     nowait  root    /usr/sbin/in.telnetd telnetd    @10K/sec
> 
> I start inetd and telnet into the box through eth0 (ethernet).  Inetd creates
> a vif in /nnfs and sets the bandwidth.
> 
> [scottb@tamarack scottb]$ ls -lR /nnfs/network/eth0/inetd_2093/
> /nnfs/network/eth0/inetd_2093/:
> total 0
> -rw-r--r--  1 root root 0 Nov 11 14:16 bandwidth
> -rw-r--r--  1 root root 0 Nov 11 14:16 drops
> -rw-r--r--  1 root root 0 Nov 11 14:16 filter
> -rw-r--r--  1 root root 0 Nov 11 14:16 port
> -rw-r--r--  1 root root 0 Nov 11 14:16 recv
> -rw-r--r--  1 root root 0 Nov 11 14:16 send
> -rw-r--r--  1 root root 0 Nov 11 14:16 type
> -rw-r--r--  1 root root 0 Nov 11 14:16 weight
> 
> It sets the symlink under the Pso_list directory but does not change
> the symlinks under the Pso_dir fd directories, this the same as I
> observe with my FreeBSD ISO version:
> 
> [scottb@tamarack scottb]$ ls -l /nnfs/2093/sockets/
> total 0
> drwxr-xr-x  2 root root 0 Nov 11 14:22 0
> drwxr-xr-x  2 root root 0 Nov 11 14:22 1
> drwxr-xr-x  2 root root 0 Nov 11 14:22 2
> lrwxr-xr-x  1 root root 0 Nov 11 14:22 eth0 -> ../../network/eth0/inetd_2093
> lrwxr-xr-x  1 root root 0 Nov 11 14:22 lo -> ../../network/lo/inetd_2093
> [scottb@tamarack scottb]$ ls -lR /nnfs/2093/sockets/
> /nnfs/2093/sockets/:
> total 0
> drwxr-xr-x  2 root root 0 Nov 11 14:22 0
> drwxr-xr-x  2 root root 0 Nov 11 14:22 1
> drwxr-xr-x  2 root root 0 Nov 11 14:22 2
> lrwxr-xr-x  1 root root 0 Nov 11 14:22 eth0 -> ../../network/eth0/inetd_2093
> lrwxr-xr-x  1 root root 0 Nov 11 14:22 lo -> ../../network/lo/inetd_2093
> 
> /nnfs/2093/sockets/0:
> total 0
> lrwxr-xr-x  1 root root 0 Nov 11 14:22 eth0 -> ../../../network/eth0
> lrwxr-xr-x  1 root root 0 Nov 11 14:22 lo -> ../../../network/lo
> 
> /nnfs/2093/sockets/1:
> total 0
> lrwxr-xr-x  1 root root 0 Nov 11 14:22 eth0 -> ../../../network/eth0
> lrwxr-xr-x  1 root root 0 Nov 11 14:22 lo -> ../../../network/lo
> 
> /nnfs/2093/sockets/2:
> total 0
> lrwxr-xr-x  1 root root 0 Nov 11 14:22 eth0 -> ../../../network/eth0
> lrwxr-xr-x  1 root root 0 Nov 11 14:22 lo -> ../../../network/lo
> 
> Now, the telnet session is running but all data is passing through
> the vifs attached to socket fds 0,1, and 2 which have the default bandwidth
> set:
> 
> [scottb@tamarack scottb]$ cat /nnfs/2093/sockets/0/eth0/bandwidth
> 1032000
> 
> So the bandwidth of the telnet session is not throttled to 10K as I
> think it is supposed to be.  It seems that inetd should also reset the
> symlinks in the socket fd directories.  Now the reason I ask this is
> because it seems that the FreeBSD implementation does the same thing
> which does not seem right.
> 
> I am thinking that I should add the logic into nn_create that will
> set the symlinks under Pso_dir as well as under Pso_list.
> 
> Scott Brumbaugh

Re: [Netnice-kernels] Re: Netnice internals

[Scott B. <sco...@ve...>]

Hi,

I have submitted some changes to the internals to CVS.  I think these
changes fix the problem with running netnice -d.  As far as I can
tell, things seem to be working but there are probably features that
I am overlooking.  

There is still a crash that happens when the interrupt function
(vif_rcv) runs in the context of the swapper process.  This may be
because the pvif memory is paged out at that point.  I am just
guessing here.  This is the only crash that I am experiencing now.



Thanks,


Scott Brumbaugh

Re: [Netnice-kernels] Re: Netnice internals

[Takashi O. <ta...@cs...>]

Scott Brumbaugh wrote:
> 
> I had committed my changes before I got this email.  I put them
> in netnice/linux/src because of this email I received earlier.

sorry, scott. seems like that i was not paying attention to that part.

okay. please keep your code as is, for now. we'll integrate the codes
when we release netnice-2.2 package...

thanks,

-- taka

Re: [Netnice-kernels] Re: Netnice internals

[Scott B. <sco...@ve...>]

On Tue, 9 Nov 2004, Takashi Okumura wrote:

> hi,
> 
> can you work on netnice-common/src/netnice, instead??
> just guard the changes you make with __linux__.
> 
> if you really want to have a separate source code,
> that is okay. but, please justify, beforehand.
> 
> thanks!
> 
> 
> -- taka

Hi,

I had committed my changes before I got this email.  I put them
in netnice/linux/src because of this email I received earlier.

Sho Fujita wrote:

> i agree with taka. netnice command is a good starting point. but it
> seems to use /proc. since netnice for other architectures such as
> freebsd4.9, netbsd, and openbsd are using /proc, copy
> netnice/netnice-common/src/* to netnice/linux/src, then modify them.
> vifctl needs vif_capture.c working, please leave it untill later.


Thanks,


Scott Brumbaugh

Re: [Netnice-kernels] Re: Netnice internals

[Takashi O. <ta...@cs...>]

doesn't your strategy on ksh (overriding of parsing output) work, here?
if we cannot easily modify ksh and bash, is it hard to port
FreeBSD/sh onto OpenBSD and Linux?

i personally prefer the "@xxxMbps" specification...


-- taka

Sho Fujita wrote:
> 
> >>>p.p.s. can you suggest/specify a shell program we need to modify for linux?
> >>>     bash? bsh? ksh?
> >>>
> >>Most Linux systems use bash as the shell.
> >
> >okay. fujita-kun, is bash an easy case? what do we need to do first?
> >any suggestion?
> >
> I have no idea about bash. But to implement @<bandwidth> expression, we
> have to modify the parser of bash. And It will be a difficult task.
> Then, I have a suggestion about the design of bandwidth configuration.
> How about using environment variables? A sample expression follows.
> > BW=10Mbps ftp example.com
> In this approach, we don't have to modify the parser. Moreover, if a
> shell which executes a netnice-enabled script doesn't indeed support
> netnice, It simply excutes the command without bandwidth limitation. We
> can reduce adverse effects of passing @<bandwidth> as a argument to the
> command.

Re: [Netnice-kernels] Re: Netnice internals

[Takashi O. <ta...@cs...>]

hi,

can you work on netnice-common/src/netnice, instead??
just guard the changes you make with __linux__.

if you really want to have a separate source code,
that is okay. but, please justify, beforehand.

thanks!


-- taka

Scott Brumbaugh wrote:
> 
> On Tue, 9 Nov 2004, Takashi Okumura wrote:
> 
> > hi scott,
> >
> > have you committed your changes? i couldn't find them on the CVS.
> >
> 
> I have not committed the changes to the netnice command, I will
> do this today under netnice/linux/src/netnice.  I am currently
> working on the internals attempting to get vif_rm to work.
> 
> Thanks,
> 
> Scott Brumbaugh

Re: [Netnice-kernels] Re: Netnice internals

[Scott B. <sco...@ve...>]

On Tue, 9 Nov 2004, Takashi Okumura wrote:

> hi scott,
> 
> have you committed your changes? i couldn't find them on the CVS.
> 

I have not committed the changes to the netnice command, I will
do this today under netnice/linux/src/netnice.  I am currently 
working on the internals attempting to get vif_rm to work.


Thanks,

Scott Brumbaugh

Re: [Netnice-kernels] Re: Netnice internals

[Sho F. <fu...@wi...>]

Hi,

Takashi Okumura wrote:

>hi,
>
>Scott Brumbaugh wrote:
>  
>
>>>p.s. fujita-kun. does vifctl use vif_capture.c, or NPF?
>>>      
>>>
>
>i talked with fujita-kun and the statement was his mistake. we do not need
>NPF for vifctl. i think it will work on Linux also (but, you'll need to
>modify the mount point hardcorded in the perl script).
>
>  
>
I'm sorry. I took vifctl for vf which needs vif_capture.

>>>p.p.s. can you suggest/specify a shell program we need to modify for linux?
>>>     bash? bsh? ksh?
>>>      
>>>
>>Most Linux systems use bash as the shell.
>>    
>>
>
>okay. fujita-kun, is bash an easy case? what do we need to do first?
>any suggestion?
>
>  
>
I have no idea about bash. But to implement @<bandwidth> expression, we
have to modify the parser of bash. And It will be a difficult task.
Then, I have a suggestion about the design of bandwidth configuration.
How about using environment variables? A sample expression follows.
> BW=10Mbps ftp example.com
In this approach, we don't have to modify the parser. Moreover, if a
shell which executes a netnice-enabled script doesn't indeed support
netnice, It simply excutes the command without bandwidth limitation. We
can reduce adverse effects of passing @<bandwidth> as a argument to the
command.

>actually, we may move the issue onto netnice-developers ML, since there are
>several linux developers, waiting for the kernel module to be ready.
>
>thanks,
>
>-- taka
>
>
>  
>
-- sho

Re: [Netnice-kernels] Re: Netnice internals

[Takashi O. <ta...@cs...>]

hi,

Scott Brumbaugh wrote:
> > p.s. fujita-kun. does vifctl use vif_capture.c, or NPF?

i talked with fujita-kun and the statement was his mistake. we do not need
NPF for vifctl. i think it will work on Linux also (but, you'll need to
modify the mount point hardcorded in the perl script).

> > p.p.s. can you suggest/specify a shell program we need to modify for linux?
> >      bash? bsh? ksh?
> 
> Most Linux systems use bash as the shell.

okay. fujita-kun, is bash an easy case? what do we need to do first?
any suggestion?

actually, we may move the issue onto netnice-developers ML, since there are
several linux developers, waiting for the kernel module to be ready.

thanks,

-- taka

Re: [Netnice-kernels] Re: Netnice internals

[Takashi O. <ta...@cs...>]

hi scott,

have you committed your changes? i couldn't find them on the CVS.

once after we finish stabilizing netnice command, we may CC the
discussions to net...@li..., also,
so that application developers may help us. this is also good
for alpha testing purpose.

today, i had a meeting with such a developer, Pat Myers, who is
working on netnice module for firewall builder, and he agreed that
he'll use Linux/NPF for debugging and for further testing of his
application.

i'll keep you guys updated.

thanks,

-- taka

Scott Brumbaugh wrote:
> 
> Hi,
> 
> I have ported the netnice user program to Linux, looking up the nnfs
> root directory with getmntnent.  I did not need to make any other
> changes.  However, I found that the -d (delete) option is not working.
> I think this is because of a bug in either vif_rm or vif_free.  I have
> been trying to debug these in NNFS.
> 
> Scott B

Re: [Netnice-kernels] Re: Netnice internals

[Scott B. <sco...@ve...>]

Hi,

I have ported the netnice user program to Linux, looking up the nnfs
root directory with getmntnent.  I did not need to make any other
changes.  However, I found that the -d (delete) option is not working.
I think this is because of a bug in either vif_rm or vif_free.  I have
been trying to debug these in NNFS.



Scott B

[Netnice-kernels] Re: Netnice internals

[Scott B. <sco...@ve...>]

On Sun, 7 Nov 2004, Takashi Okumura wrote:

> hi,
> 
> fujita-kun, thanks for your help.
> 
> 
> Sho Fujita wrote:
> > 
> > i agree with taka. netnice command is a good starting point. but it
> > seems to use /proc. since netnice for other architectures such as
> > freebsd4.9, netbsd, and openbsd are using /proc, copy
> > netnice/netnice-common/src/* to netnice/linux/src, then modify them.
> > vifctl needs vif_capture.c working, please leave it untill later.
> 
> i would like to add one more comment here, for scott.
> 
> due to several difficulties we have on procfs implementation, we
> are shifting to the NNFS-based API. FreeBSD5/Netnice supports NNFS,
> as you know, and we'll migrate into NNFS on OpenBSD and NetBSD shortly.
> 
> However, its mount point is controversial. FreeBSD/Netnice uses /proc
> for NNFS, but, we will need to mount NNFS of Linux at /nnfs, which might
> compromise the portability of netnice applications. We may need to think
> about OSs which do not support procfs, such as MacOS X and Windows OS, also.
> 

For the Linux netnice command I was going to read /etc/mtab using
getmntent to make sure that nnfs is mounted and get the mount point.
So the actual mount point for nnfs should not matter.

> 
> -- taka
> 
> p.s. fujita-kun. does vifctl use vif_capture.c, or NPF?
> 
> p.p.s. can you suggest/specify a shell program we need to modify for linux?
>      bash? bsh? ksh?

Most Linux systems use bash as the shell.


Scott B

Re: [Netnice-kernels] Re: Netnice internals

[Sho F. <fu...@wi...>]

i'm going to work on vif_capture first, then npf.

>-- taka
>
>p.s. fujita-kun. does vifctl use vif_capture.c, or NPF?
>
>  
>
-- sho

[Netnice-kernels] Re: Netnice internals

[Takashi O. <ta...@cs...>]

hi,

fujita-kun, thanks for your help.


Sho Fujita wrote:
> 
> > > There does not seem to be a linux branch in CVS for the user programs?
> > > Can you suggest an order for me to work on these, easiest in your
> > > opinion first?
> >
> > Ah... Fujita kun will set up the programs to work on, for you, shortly.
> > I think it is a good idea to start working on netnice command, first.
> > Then, vifctl (a perl script), and inetd (probably, very easy). Then,
> > you may work on the shell implementation. But, since it can be time
> > consuming, please coordinate well with Fujita-kun. He spent (wasted?)
> > so many days on the porting, and so, knows how to address the problem.
>
> i agree with taka. netnice command is a good starting point. but it
> seems to use /proc. since netnice for other architectures such as
> freebsd4.9, netbsd, and openbsd are using /proc, copy
> netnice/netnice-common/src/* to netnice/linux/src, then modify them.
> vifctl needs vif_capture.c working, please leave it untill later.

i would like to add one more comment here, for scott.

due to several difficulties we have on procfs implementation, we
are shifting to the NNFS-based API. FreeBSD5/Netnice supports NNFS,
as you know, and we'll migrate into NNFS on OpenBSD and NetBSD shortly.

However, its mount point is controversial. FreeBSD/Netnice uses /proc
for NNFS, but, we will need to mount NNFS of Linux at /nnfs, which might
compromise the portability of netnice applications. We may need to think
about OSs which do not support procfs, such as MacOS X and Windows OS, also.

Accordingly, we are planning to add OS-independent library layer in
between the applications and the NNFS API, libnetnice. The draft API will
be released soon, and we are planning to modifiy all the netnice
applications in the package by utilizing the library, after that.

But, modifications of the applications we need for the libnetnice utilization
will be fairly minor. so, please first implement the netnice applications,
utilizing the direct NNFS API, for now.

thanks,


-- taka

p.s. fujita-kun. does vifctl use vif_capture.c, or NPF?

p.p.s. can you suggest/specify a shell program we need to modify for linux?
     bash? bsh? ksh?

thanks!

[Netnice-kernels] Re: Netnice internals

[Sho F. <fu...@ho...>]

hi, 

> Fujita-kun, if your time permits, i would be happy if you once checkout
> the Linux code, and test it for him. (i also expect your reply to my
> request on the kernel ML. thx in advance)
ok, i'll try. maybe i can submit a report in a few days.

> > There does not seem to be a linux branch in CVS for the user programs?
> > Can you suggest an order for me to work on these, easiest in your
> > opinion first?
>
> Ah... Fujita kun will set up the programs to work on, for you, shortly.
> I think it is a good idea to start working on netnice command, first.
> Then, vifctl (a perl script), and inetd (probably, very easy). Then,
> you may work on the shell implementation. But, since it can be time
> consuming, please coordinate well with Fujita-kun. He spent (wasted?)
> so many days on the porting, and so, knows how to address the problem.
i agree with taka. netnice command is a good starting point. but it
seems to use /proc. since netnice for other architectures such as
freebsd4.9, netbsd, and openbsd are using /proc, copy
netnice/netnice-common/src/* to netnice/linux/src, then modify them.
vifctl needs vif_capture.c working, please leave it untill later. 

thank you.

--sho 

Re: [Netnice-kernels] Linux/Netnice

[Sho F. <fu...@ho...>]

dear netnice hackers,

i apologize for this late replay. 
> scott, mr. fujita, who has ported FreeBSD/Netnice onto OpenBSD,
> will take care of Netnice Packet Filter, vif_capture.c, and so, please
> coordinate well with him. please note that NPF needs to modify both the
> core and NNFS. btw, for your testing, you may use "netnice" command in
> netnice-2.1/netnice-common/. i think "vifctl" would be also helpful.
i checked out the linux sources and started reading. 

> fujita-kun, if your time perimts, can you create directories for
> linux and put initial files to work on, under netnice-2.1/linux??
> scott will take care of the applications, after he finishes the
> debugging. but, i think it would really help, if you take over
> the setting part. it is also a good idea if you report the latest
> status of your OpenBSD.
i created netnice/linux/{sys,src,etc}.
sys - a patch to the kernel sources will be placed
src - applications which need to be modified for netnice such as sh,
inetd will be placed
etc - scripts which initialize netnice facility will be plased

i updated the wiki page. please check it.
http://www.netnice.org/pukiwiki.php?cmd=edit&page=OpenBSD

regards.

--sho

Re: [Netnice-kernels] Netnice for Linux

[Scott B. <sco...@ve...>]

Hi,

I have made another update to CVS.  This change mostly adds the vif_rm
and vif_free functions which have been missing up to this point.
There is still an intermittent crash occuring in the vif_rcv function
but other than that the system seems to be stabilizing.



Thanks,

Scott Brumbaugh

Re: [Netnice-kernels] Netnice for Linux

[Takashi O. <ta...@cs...>]

hi scott,

thanks for the update.

regarding the configuration and testing issue, i would appreciate if
you update the wiki, also, if your time permits.

	http://www.netnice.org/pukiwiki.php?Linux

if you want/need, you may create more pages, or you may my
note for novice developer to another page.

thanks!


-- taka

Scott Brumbaugh wrote:
> 
> Hi,
> 
> I have committed changes to CVS that provides a minimally working
> netnice implementation on Linux.  I am still experiencing some crashes
> and the internals are still not completely ported (vif_rm and vif_free
> are not being executed).  But I am able to create new vifs and assign
> them to processes using NNFS and then create client/server tcp
> sessions.
> 
> To get these latest changes from cvs do:
> 
>  $ cvs co -r netnice267 Linux
> 
> For compilation configuration I suggest the following.  Select netnice
> kernel support from 'networking support->networking options->netnice
> for linux'.  Select nnfs from 'filesystems->pseudo
> filesystems->netnice filesystem support'.  I also need to disable SMP
> support from 'processor type->symetric multi-processing support'.
> 
> With a kernel built and running, mount the nnfs file system like this
> 
>  # mkdir /nnfs
>  # mount -t nnfs none /nnfs
> 
> Open up the vifs like this
> 
>  # echo 1000K > /nnfs/network/eth0/bandwidth
>  # echo 1000K > /nnfs/network/lo/bandwidth
> 
> Run a tcp session:
> 
>  # telnet somehost.com
> 
> Regards,
> 
> Scott Brumbaugh

[Netnice-kernels] Netnice for Linux

[Scott B. <sco...@ve...>]

Hi,

I have committed changes to CVS that provides a minimally working
netnice implementation on Linux.  I am still experiencing some crashes
and the internals are still not completely ported (vif_rm and vif_free
are not being executed).  But I am able to create new vifs and assign
them to processes using NNFS and then create client/server tcp
sessions.

To get these latest changes from cvs do:

 $ cvs co -r netnice267 Linux

For compilation configuration I suggest the following.  Select netnice
kernel support from 'networking support->networking options->netnice
for linux'.  Select nnfs from 'filesystems->pseudo
filesystems->netnice filesystem support'.  I also need to disable SMP
support from 'processor type->symetric multi-processing support'.


With a kernel built and running, mount the nnfs file system like this

 # mkdir /nnfs
 # mount -t nnfs none /nnfs

Open up the vifs like this

 # echo 1000K > /nnfs/network/eth0/bandwidth
 # echo 1000K > /nnfs/network/lo/bandwidth

Run a tcp session:

 # telnet somehost.com


Regards,


Scott Brumbaugh

RE: [Netnice-kernels] Linux/Netnice

[Scott B. <sco...@ve...>]

On Thu, 4 Nov 2004, kartikey bhatt wrote:

> hi scott,
> 
> have merged your working changes into cvs?
> 
> regards,
> kartikey
> 

Hi Kartikey,

I will commit the changes today as soon as I clean it up some.  I made
just a few changes from the patch that you gave me before.  Vif_rm and
vif_free are still not hooked up.  But, I can run tcp client server
sessions and exercise some control over them through the nnfs file
system.  I am still having some crashes.  Also, I need to disable
netfilter support when compiling the kernel.


Thanks,


Scott Brumbaugh

RE: [Netnice-kernels] Linux/Netnice

[kartikey b. <kar...@ho...>]

hi scott,

have merged your working changes into cvs?

regards,
kartikey


>From: Takashi Okumura <ta...@cs...>
>To: netnice kernels <net...@li...>
>Subject: [Netnice-kernels] Linux/Netnice
>Date: Wed, 03 Nov 2004 19:37:11 -0500
>
>dear netnice hackers,
>
>scott has integrated Kartikey's core module and his NNFS module,
>and has started debugging.
>
>scott, mr. fujita, who has ported FreeBSD/Netnice onto OpenBSD,
>will take care of Netnice Packet Filter, vif_capture.c, and so, please
>coordinate well with him. please note that NPF needs to modify both the
>core and NNFS. btw, for your testing, you may use "netnice" command in
>netnice-2.1/netnice-common/. i think "vifctl" would be also helpful.
>
>fujita-kun, if your time perimts, can you create directories for
>linux and put initial files to work on, under netnice-2.1/linux??
>scott will take care of the applications, after he finishes the
>debugging. but, i think it would really help, if you take over
>the setting part. it is also a good idea if you report the latest
>status of your OpenBSD.
>
>i would suggest you guys use the ML for coordination so that other
>developers may observe your steps.
>
>thanks for your contributions!
>
>
>-- taka
>
>Scott Brumbaugh wrote:
> >
> > I have made a few more small changes to the internals and have
> > eliminated most of the crashes.  The packets are flowing throught the
> > vif_enque and vif_deque functions in both directions.  The crashes
> > seemed to mostly come from dereferencing bad pointers inside of the
> > sk_buffs.  It did take a bit more work to get pvif_lookup working.  It
> > seems to be doing ok now for tcp and udp packets.  I have been able to
> > run an xclient and mount a directory through nfs.
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE
>LinuxWorld Reader's Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
>_______________________________________________
>Netnice-kernels mailing list
>Net...@li...
>https://lists.sourceforge.net/lists/listinfo/netnice-kernels

_________________________________________________________________
Millions of active and validated profiles.  
http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?74 Find your match on 
BharatMatrimony.com

[Netnice-kernels] Linux/Netnice

[Takashi O. <ta...@cs...>]

dear netnice hackers,

scott has integrated Kartikey's core module and his NNFS module,
and has started debugging.

scott, mr. fujita, who has ported FreeBSD/Netnice onto OpenBSD,
will take care of Netnice Packet Filter, vif_capture.c, and so, please
coordinate well with him. please note that NPF needs to modify both the
core and NNFS. btw, for your testing, you may use "netnice" command in
netnice-2.1/netnice-common/. i think "vifctl" would be also helpful.

fujita-kun, if your time perimts, can you create directories for
linux and put initial files to work on, under netnice-2.1/linux??
scott will take care of the applications, after he finishes the
debugging. but, i think it would really help, if you take over
the setting part. it is also a good idea if you report the latest
status of your OpenBSD.

i would suggest you guys use the ML for coordination so that other
developers may observe your steps.

thanks for your contributions!


-- taka

Scott Brumbaugh wrote:
>
> I have made a few more small changes to the internals and have
> eliminated most of the crashes.  The packets are flowing throught the
> vif_enque and vif_deque functions in both directions.  The crashes
> seemed to mostly come from dereferencing bad pointers inside of the
> sk_buffs.  It did take a bit more work to get pvif_lookup working.  It
> seems to be doing ok now for tcp and udp packets.  I have been able to
> run an xclient and mount a directory through nfs.