RE: Preventing zombies to occure
I have some ideas to improve fork()-ing and getting rid of
zombie processes.
This things mentioned here are proposed of a man that do
not know very well
(author means 'the depths' of) BSD kernel source although
he have some ex-
pirience with it (mainly in reading it :-).
By definition zombie is a process entry in proc table that
wasn't released
by wait*() called form the parent's code. So all we need to
do is to ensure
that parent will call wait*() as many times as it called
fork(). This meth-
od have some advantages but it has some disadvantages too.
First of all,
we
provide programmers all users with full out-of-zombies
enviroment where
everything created will be destroyed in the right way.
Second, proposed
me-
thod is easy to include in current source with minnor modifications.
[snip]
If a parent that has zombie children exits the kernel will attach them
to init (I haven't checked, but this is the common unix solution).
init will be calling waitpid to clear zombies automagically.
So this sorta already happens. :)
two ways:
first:
something like
SIGCHLD_handler(int)
{
while (waitpid(-1, NULL, 0))
;
}
you need to handle SIGCHLD, otherwise you will have zombies.
second:
use SA_NOCLDWAID flag in sigaction(2)
in this case ``init'' will be responsible for zombie process
thanks,
emax
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
RE: makeLINT.pl - Bug or am I just stupid
[frederik@server conf]$ sh makeLINT.pl =0: not found makeLINT.pl: 5: Syntax error: redirection unexpected [frederik@server conf]$ try: perl makeLINT.pl NOTES thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: vmware ...
im trying to 'install' vmware, and im missing if_tap.ko, can someone point me in the right direction? the tap (if_tap.ko) driver is part of -current and RELENG_4. it was not included in 4.1-RC. should you need to use it, please, download sources from -current or RELENG_4 and compile it. i hope it will be included in the next release. thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: How to generate a core dump explicily
man abort I would like to generate a core dump 'explicitly' in my program. How can that be done ? thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: kerneld for FreeBSD
well, i've heard both negative and positive replies. so, i've just open ``kerneld'' project on sourceforge.net anyone who is interested, please, make your suggestions and wishes. just drop me an e-mail at [EMAIL PROTECTED] i'll be more than happy to hear from you. i'll try put working prototype on sourceforge.net CVS tonight. thanks everybody, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: kerneld for FreeBSD
[...] This is, IMO, a good idea. I certainly don't want some smartass daemon unloading a module just because it thinks it should. 8) another option in config file? something like ``do_not_unload''? No. Modules shouldn't be unloaded automatically. but why? :-) what is wrong with that? it would be so nice to have small GENERIC kernel and bunch of modules. kernel will start, identify all hardware (pci/pnp) and than load appropriate modules. the only problem here is old hardware :( [...] i do not agree :-) code wants device driver/interface/filesystem/. code should not care about module name. of course it is better to have name convension, but i think this is not the case. :-) This is debatable; mount, for example, knows the name of its plugins. So does PAM. Kernel modules are just plugins that go somewhere else. let say i'm a third party vendor. i developed new hardware and driver for FreeBSD (of course KLD module). i do not want to give my source code to anybody. so you have the following options: 1) go ahead and try to convince me to use the same name convention 2) just ignore this hardware/driver/vendor 3) wait until somebody writes an ``open source'' driver 4) try do something to make in work (could be as easy as rename) 5) ??? thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: kerneld for FreeBSD
On Sun 2000-06-04 (23:06), Coleman Kane wrote: Look through /modules... I'm still having problems working out what this will do. Can you explain the differences between the current way of doing things, and what your stuff will conceptually do? i will try :-) please do not beat me :-) 1) right now we have several places in kernel/user space where we load KLD. if we need add dynamic module loading in some new place we will have to duplicate all code 2) kernel/user space does not unload modules, unless you unload it manually 3) we can not configure which module should be loaded. it is hardcoded so, when i started to code ``kerneld'', i was thinking about 1) one simple interface to load all modules from kernel 2) ability to determine which module can be unloaded and unload it 3) flexible configuration file and, yes, Linux guys have abandoned ``kerneld'', but they do not need it :-) look for KERND define in new Linux kernel. the way they load kernel module is 1) create new kernel thread 2) run /sbin/depmod (or something like this) in the thread 3) wait for thread finished and check for result it does not look like kernel code, indeed :) looks like daemon code :) thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: kerneld for FreeBSD
[...] 1) right now we have several places in kernel/user space where we load KLD. if we need add dynamic module loading in some new place we will have to duplicate all code This isn't necessarily bad, as it is this code which determines the criteria for loading a module. I'm not entirely keen on having this ifconfig(8) uses kldfirstmod(2), kldnext(2) etc. to check if the required interface module in the memory or not. all mount_???(8) utilities use getvfsbyname(3), vfsisloadable(3) and vfsload(3) interface, which makes kernel code useless (kernel will never execute this code). thrown away; especially since all you'd be doing would be replacing it with code which would invoke the kernel daemon. 2) kernel/user space does not unload modules, unless you unload it manually This is, IMO, a good idea. I certainly don't want some smartass daemon unloading a module just because it thinks it should. 8) 3) we can not configure which module should be loaded. it is hardcoded Since the code knows what it wants, this isn't necessarily a bad thing either. In most cases, part of the module name is actually parametric, eg. in the ifconfig(8) case, so this isn't as much of a problem as it sounds. Basically, I think that the current practice of demand-loading modules from inside the kernel is the way to go. There are a couple of cases where pushing them in from the outside (ifconfig, usb, pccard) works, but in each case these already have tools suited to the job. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: kerneld for FreeBSD
sorry, hit wrong key... :) in addition to my previous message... 2) kernel/user space does not unload modules, unless you unload it manually This is, IMO, a good idea. I certainly don't want some smartass daemon unloading a module just because it thinks it should. 8) another option in config file? something like ``do_not_unload''? 3) we can not configure which module should be loaded. it is hardcoded Since the code knows what it wants, this isn't necessarily a bad thing either. In most cases, part of the module name is actually parametric, eg. in the ifconfig(8) case, so this isn't as much of a problem as it sounds. i do not agree :-) code wants device driver/interface/filesystem/. code should not care about module name. of course it is better to have name convension, but i think this is not the case. :-) thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: kerneld for FreeBSD
Mike Smith wrote: [...] This is, IMO, a good idea. I certainly don't want some smartass daemon unloading a module just because it thinks it should. 8) [...] I have no faith at all any metric other than one determined by the module itself to indicate "unuse", and if a module wants to unload itself due to so you point is that we could put a "use/unuse" logic inside each of kernel module. is that correct? even if different kernel modules implement device drivers for the same class of hardware? network interfaces (cards) for example. i would say if interface is marked as ``down'', has no IP, has no references in routing table/firewall, it could be considered as ``gone''. another problem here is that you can use the same module/device right after you have unloaded it. that is a different kind of problem. and, IMHO, it should be solved at configuration level. or even in module itself. for example PSEUDO_DEVICE modules. as far as i know they can not be unloaded. as far as i know sun solaris is able to load/unload dynamicaly kernel modules. and module itself does not perform any attempts to verify its "use/unuse". "unuse", it can already do so. I don't want or need a daemon to do this. thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: kerneld for -current
is there any interest in ``kerneld'' (a-la Linux) for FreeBSD? i've got some working prototype Could you summerize what it offers and does? from RedHat documentation: quote Red Hat Linux includes kerneld, the Kernel Daemon, which automatically loads some software and hardware support into memory as it is needed, and unloads it when it is no longer being used. /quote thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: stupid FS questions
i know that :) i guess my questions were
1) why the same piece of code duplicated in all ``mount_xxx'' utilities?
2) if we are loading fs kernel module from ``mount_xxx'' why
we have to do it again in kernel?
if i'm not missing anything, by the time we reach ``mount''
function, fs module will be in the memory and this code will
never be executed.
thanks,
emax
I believe that it is used to dynamic load filesystem modules.
Please read
the following pages to understand what is a kernel module:
http://thc.inferno.tusculum.edu/files/thc/bsdkern.html
i've been looking at ``mount_xxx'' code and have noticed
"strange" thing.
all ``mount_xxx'' utilities have common part of code, like
error = getvfsbyname("xxx", vfc);
if (error vfsisloadable("xxx")) {
if (vfsload("xxx"))
err(EX_OSERR, "vfsload(xxx)");
endvfsent();/* flush cache */
error = getvfsbyname("xxx", vfc);
}
if (error)
errx(1, "xxx filesystem is not available");
if (mount(vfc.vfc_name, dir, mntflags, args) 0)
err(1, NULL);
1) what is the reason for this? why can't move this code to
``mount''?
2) what is the purpose of the following code in
``/sys/kern/vfs_syscalls.c''?
...
for (vfsp = vfsconf; vfsp; vfsp = vfsp-vfc_next)
if (!strcmp(vfsp-vfc_name, fstypename))
break;
if (vfsp == NULL) {
linker_file_t lf;
/* Refuse to load modules if securelevel raised */
if (securelevel 0) {
vput(vp);
return EPERM;
}
/* Only load modules for root (very important!) */
if ((error = suser(p)) != 0) {
vput(vp);
return error;
}
error = linker_load_file(fstypename, lf);
if (error || lf == NULL) {
vput(vp);
if (lf == NULL)
error = ENODEV;
return error;
}
...
from my understanding this is done to load FS module.
or did i miss someting?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
kerneld for -current
Hello All, is there any interest in ``kerneld'' (a-la Linux) for FreeBSD? i've got some working prototype at http://home.earthlink.net/~evmax/kerneld.tar.gz so far, i've got it working on -current for char devices and network interfaces. file systems are currently in progress. if there is no interest - i'll paint it in green and throw it away :) thanks, emax p.s. yes, i do know that ifconfig is able to load modules and file system modules can be loaded by kernel. but may be better to have one interface? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
stupid FS questions
Hello All,
i've been looking at ``mount_xxx'' code and have noticed "strange" thing.
all ``mount_xxx'' utilities have common part of code, like
error = getvfsbyname("xxx", vfc);
if (error vfsisloadable("xxx")) {
if (vfsload("xxx"))
err(EX_OSERR, "vfsload(xxx)");
endvfsent();/* flush cache */
error = getvfsbyname("xxx", vfc);
}
if (error)
errx(1, "xxx filesystem is not available");
if (mount(vfc.vfc_name, dir, mntflags, args) 0)
err(1, NULL);
1) what is the reason for this? why can't move this code to ``mount''?
2) what is the purpose of the following code in
``/sys/kern/vfs_syscalls.c''?
...
for (vfsp = vfsconf; vfsp; vfsp = vfsp-vfc_next)
if (!strcmp(vfsp-vfc_name, fstypename))
break;
if (vfsp == NULL) {
linker_file_t lf;
/* Refuse to load modules if securelevel raised */
if (securelevel 0) {
vput(vp);
return EPERM;
}
/* Only load modules for root (very important!) */
if ((error = suser(p)) != 0) {
vput(vp);
return error;
}
error = linker_load_file(fstypename, lf);
if (error || lf == NULL) {
vput(vp);
if (lf == NULL)
error = ENODEV;
return error;
}
...
from my understanding this is done to load FS module.
or did i miss someting?
thanks,
emax
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
RE: Is traditional unixes kernel really stable ?
[...] Worse yet: What about hardware buggy devices? This could case the entiry system to crash, isn't it ? Yes, incorrectly programmed hardware either by firmware (on chip/board) or by drivers can cause crashes and hardware damage. [...] This design, would not let a system crash due to device drivers problems or even bad hardware desgin. What all you think about that ? only one :-) performance :-) context switch is a slow operation. Thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Is traditional unixes kernel really stable ?
[...] only one :-) performance :-) context switch is a slow operation. Excuse me gentleman, who said that ? Well, Intel does :) Take time to visit this site: http://www.qnx.com/iat/download/index.html I know this OS. It looks great. Perhaps, it is a good choice for embeded OS. A good OS design could help to reduce context switch overhead. Just to give you some examples of context switching overhead, please take a look at http://www.atnf.csiro.au/~rgooch/benchmarks/linux-scheduler.html Thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Pthread blocking I/O
[...] What's the reason for locking the file descriptors for *all* system calls? especially those I mentioned? Where is pthread_cancel() ? are you using -stable (3.x)? there is no ``pthread_cancel'' in -stable. use -current. or - use other threads library - use non-blocking read - use select/poll with timeout man pthread and see /usr/src/lib/libc_r/uthread for details. thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Pthread blocking I/O
[...] are you using -stable (3.x)? there is no ``pthread_cancel'' in -stable. use -current. Bt!!! Wrong! uname -a FreeBSD server.baldwin.cx 3.4-STABLE FreeBSD 3.4-STABLE #6: Sun Feb 20 20:24:19 EST 2000 [EMAIL PROTECTED]:/usr/source/src/sys/compile/SERVER i386 man -k pthread_cancel pthread_cancel(3) - cancel execution of a thread nm /usr/lib/libc_r.so | grep pthread_cancel 00078524 T pthread_cancel xxx:/usr/home/xxx uname -a FreeBSD xxx.xxx.ru 3.4-STABLE FreeBSD 3.4-STABLE #4: Mon Jan 3 16:01:58 EST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/xxx i386 xxx:/usr/home/xxx man -k pthread_cancel pthread_cancel: nothing appropriate xxx:/usr/home/xxx xxx:/usr/home/xxx nm /usr/lib/libc_r.so | grep pthread_cancel xxx:/usr/home/xxx You do need a fairly recent -stable, but it's in there. :) indeed :-) thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Shell Code... (fwd)
hello all,
in case if still need it :)
here is good skeleton for shell code :-) i DO NOT want to put
REAL shell code here. just do ``x/32bx main'' and you will
see what you want. :)
i'm too lazy to write in assebmler and hate ATT syntax :)
-- cut here -
char*cmd = "/bin/sh";
char*arg[] = { "sh", 0 };
void
main(void)
{
/* execve(cmd, argv, env) */
/* pass ``env'' == NULL */
__asm__("xorl %eax,%eax\n");
__asm__("push %eax");
/* pass ``argv[]'' */
__asm__("push $arg\n");
/* pass ``cmd'' */
__asm__("movl $cmd,%edx\n");
__asm__("movl (%edx),%eax\n");
__asm__("push %eax\n");
/* simulate ``libc call execve'' */
__asm__("push %ecx\n");
/* system call */
__asm__("xorl %eax,%eax\n");
__asm__("movb $0x3b,%al\n");
__asm__("int$0x80\n");
}
- end cut --
thanks
emax
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
RE: NETGRAPH patches (proposal) CONT.
On Tue, Feb 22, 2000 at 09:02:43PM -0800, Archie Cobbs wrote: It's because all packets sent by this node should have the node's address. If you don't have it then PPPoE cannot send a packet "FROM" thia node, as it has no idea of what this node's address is. So.. we can have two hooks, one that sets the host address and one that doesn't.. :-) In that case can we have one that also sets the destination address via arp? i added new control message for ``ngether_node''. i called it NGEF_RAW_MODE. now you can set it to on/off by using NgSendMsg. ``ngether_rcvdata'' will not update ``ether_shost'' if it set to on. otherwise it will. patches available at http://home.earthlink.net/~evmax/ng.tar.gz these are against -current cvsup'ed this sunday around 8:30pm EST. it also includes small test program based ion ``nghook''. Thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: NETGRAPH patches (proposal)
From: Archie Cobbs [mailto:[EMAIL PROTECTED]] Julian Elischer writes: It's because all packets sent by this node should have the node's address. If you don't have it then PPPoE cannot send a packet "FROM" thia node, as it has no idea of what this node's address is. So.. we can have two hooks, one that sets the host address and one that doesn't.. :-) In that case can we have one that also sets the destination address via arp? Now I think you are talking a separate node that implements such a protocol. Right.. ARP is an IP-specific protocol. Ethernet nodes should have no specific knowledge of ARP. [...] This brings up another point.. to really do this correctly we would also need a 802.3/802.2 node type that decoded Ethertypes and SNAP headers. It would have a "downstream" hook that connected to the Ethernet node and also hooks for "ip", "arp", "appletalk", "aarp" (AppleTalk's ARP), "ipx", "ipv6", etc. Also, it could suport generic Ethertype hooks having names of the form "0x". Probably the raw Ethernet node type should not even know about 802.3 (the standard 14 byte Ethernet header and the 60 byte minimum packet length).. i think that ethernet driver should be just raw ethernet node. it should not have any specific knowledge about upper levels. these raw nodes connected to another node that will perform the same functionality as ``ether_input'' does. i.e. it will decode type and send data to the appropriate hook. if the hook is connected - fine, we got data and put it to the protocol stack. if not - just drop. so we are really control the system. if we need specific protocol in the stack just load specific node and connect it to the hook. we can use simple name convention for the hooks (like "ether_0xNNN" where NNN is type) and in this case we do not have to change ``ether_input'' node. this looks more and more like STREAMS :). but NETGRAPH do not put data in the ``envelope'' like STREAMS does. the only thing that bothers me... how we can marry existing functionality and NETGRAPH? i vote for NETGRAPH :) it is c00l :) i just like the idea of connecting raw ethernet device driver with tty level :) thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: NETGRAPH patches (proposal)
Here is the description. ng_ether node has two hooks ``divert'' and ``orphan''. It is possible to connect to the one of the hooks and intercept row Ethernet frames. But there is no clean way to intercept frame, do something and return it back to kernel. This patch provides additional hook ``divertin'' (mmm... name is not good, i think) for each ng_ether node. Implementation issues This will not work for ``orphan'' frames. Since kernel drops it anyway, i decided to leave it as it is. But is is possible to intercept ``orphan'' packets, change it, and write back to ``divertin''. The "divertin" hook is a useful idea.. after 4.0-REL we can check something in based on your patches... ok. i just have a dumb question. what is the big deal with updating ether_shost in ethernet header in ngether_rcvdata. since we are passing raw ethernet frame, why should we update ether_shost? wouldn't it be nice to make it optional? just another control message? Thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
raw socket, bpf, netgraph, etc
Hello All, Is it possible to get access to link layer (AF_LINK) via raw socket? kind of Linux SOCK_PACKET. It seems to me that it is not. (hope I wrong :) I can access raw IP via socket(AF_INET, SOCK_RAW, IPPROTO_RAW) and event get access to IP header with setsockopt. But not AF_LINK :( On the other hand is bpf. but here is the small problem. i have interface with bpf attached to it. when i write to /dev/bpf i got the same packet back. kind of loop. the only solution is to filter these packets. but there is no way to find out which packet i wrote, and which is received from outside. i was thinking about netgraph. would't it be nice to have netgraph interface in each network driver? Any ideas? Thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
BPF bug or not?
All, I've just found that read from /dev/bpfX never return EAGAIN/EWOULDBLOCK. It means that when you do a non blocking read and there is no data you will always get 0. Does it suppose work this way? A non blocking read from pipe return EAGAIN/EWOULDBLOCK if there is no data and pipe was opened as O_RDWR, and 0 when pipe was opened as O_RDONLY. Thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Ethernet TAP driver v0.2 released
Hello All! I've released Ethernet TAP driver v0.2 for FreeBSD It provides a virtual Ethernet interface to the system. It also provides packet reception and transmission for user-space programs. It can be viewed as a simple Ethernet device, which instead of receiving packets from a physical medium, receives them from a user-space program and instead of sending packets via physical media, writes them to the user-space program. Changes since v 0.1 - FreeBSD kernel Ethernet bridging (by Luigi Rizzo) support added. This feature seems to be working, but it needs more testing. I've tested it with VTUN (http://vtun.netpedia.net). I had two Linux boxes connected with the same FreeBSD box with VTUN. The FreeBSD box was an Ethernet bridge. So all three boxes were on the same virtual Ethernet network. Thanks to Maxim Krasnyansky. DUMMYNET should be working also, but I did not test it. - Removig address from tapX interface when tapX device is closed It has been added in v 0.1a, but I did not announce it here The driver can be found at http://vtun.netpedia.net/tun/tap-0.2-freebsd.tar.gz -- Folks, what do you think about smart user-space Ethernet bridge? Anyone needs it? Thanks, eMax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Smart user-space Ethernet bridge
i agree, but ... we have user space ppp, with all kind of useful things like filter etc. it is slower than kernel ppp, but everybody keep using it. so may be we can build a kind of "smart" bridge. it will touch only specific interfaces, collect information about route to specific MAC's etc. thanks, emax I've released Ethernet TAP driver v0.2 for FreeBSD ... Folks, what do you think about smart user-space Ethernet bridge? Anyone needs it? i think performance is a big problem here (same as in the case of user-space natd, but worse because a bridge touches all packets). You have too many data copies. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Ethernet TAP device driver released
Hello All, It is time for new release :) The beta version of Ethernet TAP device driver for FreeBSD is released. I've written this device driver for VTUN (http://vtun.netpedia.net) software package. It is possible the coolest software to make tunnels over TCP/IP networks. For more details please see author's page. The TAP device driver is like TUN device driver, but it works with Ethernet packets. It allows to capture Ethernet packets and feed them to user space and vice versa. The driver can be found at http://vtun.netpedia.net/tun/tap-0.1-freebsd.tar.gz. I've tested it with VTUN on my FreeBSD 3.2-RELEASE. It seems to me it works just fine. I'd like to ask to help me in testing and give some feed back. Thank you very much, Best regards, eMax. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Ethernet TAP device driver released
Hello Mike, It seems to me bfp can bind to EXISTING interface. I.e. you have to have phisical interface. (if I wrong, correct me :) This driver will create a VIRTUAL Ethernet interface "tapX" with random MAC address etc. You can attach bpf to this interface. In other words you can connect computer to Ethernet network without having Ethernet card. All you need is just ANY type of connection. I was using ppp to connect to remote server with VTUN and DID HAVE ETHERNET network. BTW, what the difference between TUN and BPF :-) Regards, eMax. -Original Message- From: Mike Smith [mailto:[EMAIL PROTECTED]] Sent: Monday, November 01, 1999 12:54 PM To: Yevmenkin, Maksim N, CSCIO Cc: [EMAIL PROTECTED] Subject: Re: Ethernet TAP device driver released The beta version of Ethernet TAP device driver for FreeBSD is released. This looks like BPF, only much less smart. Why reinvent the wheel? -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: VTun...
Hi, [...] I notice that you support traffic shaping. I was wondering if you plan to offer support for slower than 8KBytes / sec (64Kbits/s). Everything should be there ;) What I'd like to be able to do, is create some tunnels to my end points, and then using the firewall / routing software, do policy routing. (ie: telnet goes over this tunnel, and is traffic shaped to 1KByte/s, while web traffic goes over another tunnel, and is allocated the remainder of the available bandwidth.) In this way, I'd be able to guarantee a certain amount of BW to core services such as telnet, without letting things like SMTP or web impact on services... Yes, you can do it. I think Max is going to release new version of VTUN very soon. Best regards, eMax. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
TTY driver for SBNI-12x cards
Hello All, I have released beta version of the TTY driver for SBNI-12x cards for FreeBSD 3.2, 3.3 The SBNI-12x card is a short range modem. It is allow to get up to 2MB speed over plain couple of wires. Great for ISP and as "last mile" solution. For more information about the card, please visit http://www.granch.ru. ( russian only :( ) It seems to me it is working just fine. I have tested it using both FreeBSD to FreeBSD, and FreeBSD to Linux modes. The driver can be found at http://gs.inettech.com.my/gs-1.0.1a-freebsd.tar.gz The GS drivers home page is http://gs.inettech.com.my Thanks, eMax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
