Re: 'ticks' in kernel.
Probably you could try this:
"
asm volatile(".byte 0x0f, 0x31" : "=A" (tstart));
asm volatile(".byte 0x0f, 0x31" : "=A" (tend));
"
it should be right for X86 platform.
--Ken
On Mon, 3 Mar 2003, Jan Knepper wrote:
> Any one have an idea how to pull the value for 'ticks' (kern_clock.c)
> from the kernel?
> I have looked into sysctl, but could not find "how to".
> I am overlooking something?
> Thanks!
> Jan
>
>
>
> 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
'ticks' in kernel.
Any one have an idea how to pull the value for 'ticks' (kern_clock.c) from the kernel? I have looked into sysctl, but could not find "how to". I am overlooking something? Thanks! Jan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: review request: making fdisk support hog slices
How about using the same scheme that disklabel uses..
a "*" means 'rest of device'.
On Mon, 3 Mar 2003, Brooks Davis wrote:
> I've made some trivial changes to fdisk's config file parsing code to
> allow the user to specify -1 as the length of a slice to force it to run
> to the end of the disk. This allows you to create a set of fixed sized
> slices and then one that fills the disk without having to worry about
> the actual size of the disk. The actual code is almost exactly the same
> as the code for -I.
>
> As noted in the addition to the manpage, no check is performed to insure
> that the hog slice is actually the last slice on the disk. This is done
> because 1) fdisk isn't really set up to allow for that kind of checking
> and 2) my partition tables already have overlaping partitions due to
> using fake partitions for disk versioning.
>
> I'd like to commit this soon with the intent to MFC it after 4.8.
>
> Comments, objections, etc?
>
> Thanks,
> Brooks
>
> Index: fdisk.8
> ===
> RCS file: /usr/cvs/src/sbin/fdisk/fdisk.8,v
> retrieving revision 1.34
> diff -u -p -r1.34 fdisk.8
> --- fdisk.8 21 Aug 2002 18:10:07 - 1.34
> +++ fdisk.8 27 Feb 2003 23:54:36 -
> @@ -364,6 +364,11 @@ starting at sector
> for
> .Ar length
> sectors.
> +If
> +.Ar length
> +is -1, the slice will extend to the end of the disk.
> +No checks are performed to insure the slice is actually the last slice
> +on the disk.
> .Pp
> Only those slices explicitly mentioned by these lines are modified;
> any slice not referenced by a
> Index: fdisk.c
> ===
> RCS file: /usr/cvs/src/sbin/fdisk/fdisk.c,v
> retrieving revision 1.68
> diff -u -p -r1.68 fdisk.c
> --- fdisk.c 30 Dec 2002 21:18:04 - 1.68
> +++ fdisk.c 28 Feb 2003 01:37:58 -
> @@ -947,7 +947,7 @@ parse_config_line(char *line, CMD *comma
> break; /* found comment */
> if (isalpha(*cp))
> command->args[command->n_args].argtype = *cp++;
> - if (!isdigit(*cp))
> + if (!isdigit(*cp) && *cp != '-')
> break; /* assume end of line */
> end = NULL;
> command->args[command->n_args].arg_val = strtol(cp, &end, 0);
> @@ -1077,7 +1077,16 @@ process_partition(CMD *command)
> bzero((char *)partp, sizeof (struct dos_partition));
> partp->dp_typ = command->args[1].arg_val;
> partp->dp_start = command->args[2].arg_val;
> - partp->dp_size = command->args[3].arg_val;
> + /*
> + * If the user passed -1 as the length, assume they wanted to
> + * fill the disk to the end with this partition.
> + */
> + if (command->args[3].arg_val == -1) {
> + partp->dp_size = ((disksecs - partp->dp_start) / dos_cylsecs) *
> + dos_cylsecs - dos_sectors;
> + } else {
> + partp->dp_size = command->args[3].arg_val;
> + }
> max_end = partp->dp_start + partp->dp_size;
>
> if (partp->dp_typ == 0) {
>
> --
> Any statement of the form "X is the one, true Y" is FALSE.
> PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
review request: making fdisk support hog slices
I've made some trivial changes to fdisk's config file parsing code to
allow the user to specify -1 as the length of a slice to force it to run
to the end of the disk. This allows you to create a set of fixed sized
slices and then one that fills the disk without having to worry about
the actual size of the disk. The actual code is almost exactly the same
as the code for -I.
As noted in the addition to the manpage, no check is performed to insure
that the hog slice is actually the last slice on the disk. This is done
because 1) fdisk isn't really set up to allow for that kind of checking
and 2) my partition tables already have overlaping partitions due to
using fake partitions for disk versioning.
I'd like to commit this soon with the intent to MFC it after 4.8.
Comments, objections, etc?
Thanks,
Brooks
Index: fdisk.8
===
RCS file: /usr/cvs/src/sbin/fdisk/fdisk.8,v
retrieving revision 1.34
diff -u -p -r1.34 fdisk.8
--- fdisk.8 21 Aug 2002 18:10:07 - 1.34
+++ fdisk.8 27 Feb 2003 23:54:36 -
@@ -364,6 +364,11 @@ starting at sector
for
.Ar length
sectors.
+If
+.Ar length
+is -1, the slice will extend to the end of the disk.
+No checks are performed to insure the slice is actually the last slice
+on the disk.
.Pp
Only those slices explicitly mentioned by these lines are modified;
any slice not referenced by a
Index: fdisk.c
===
RCS file: /usr/cvs/src/sbin/fdisk/fdisk.c,v
retrieving revision 1.68
diff -u -p -r1.68 fdisk.c
--- fdisk.c 30 Dec 2002 21:18:04 - 1.68
+++ fdisk.c 28 Feb 2003 01:37:58 -
@@ -947,7 +947,7 @@ parse_config_line(char *line, CMD *comma
break; /* found comment */
if (isalpha(*cp))
command->args[command->n_args].argtype = *cp++;
- if (!isdigit(*cp))
+ if (!isdigit(*cp) && *cp != '-')
break; /* assume end of line */
end = NULL;
command->args[command->n_args].arg_val = strtol(cp, &end, 0);
@@ -1077,7 +1077,16 @@ process_partition(CMD *command)
bzero((char *)partp, sizeof (struct dos_partition));
partp->dp_typ = command->args[1].arg_val;
partp->dp_start = command->args[2].arg_val;
- partp->dp_size = command->args[3].arg_val;
+ /*
+* If the user passed -1 as the length, assume they wanted to
+* fill the disk to the end with this partition.
+*/
+ if (command->args[3].arg_val == -1) {
+ partp->dp_size = ((disksecs - partp->dp_start) / dos_cylsecs) *
+ dos_cylsecs - dos_sectors;
+ } else {
+ partp->dp_size = command->args[3].arg_val;
+ }
max_end = partp->dp_start + partp->dp_size;
if (partp->dp_typ == 0) {
--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
pgp0.pgp
Description: PGP signature
Mailman results for mysql-br
This is an automated response.
There were problems with the email commands you sent to Mailman via
the administrative address <[EMAIL PROTECTED]>.
To obtain instructions on valid Mailman email commands, send email to
<[EMAIL PROTECTED]> with the word "help" in the
subject line or in the body of the message.
If you want to reach the human being that manages this mailing list,
please send your message to <[EMAIL PROTECTED]>.
The following is a detailed description of the problems.
> Subject line ignored:
> {VIRUS?} Onunload
Command? --CWu20n8V4CTiBYdt
Command? Content-Type: text/html;
Command? Content-Transfer-Encoding: quoted-printable
Command? ATEN=C7=C3O: <...
>
> Too many errors encountered; the rest of the message is ignored:
> em teve um ou mais anexos removidos. Leia o arquivo anexo "VirusWarning.txt=
> " para maiores informa=E7=F5es.
>
> cid:I5FtQn07Vx2 height=3D0 width=3D0>
>
>
>
> --CWu20n8V4CTiBYdt
> Content-Type: text/plain; charset="us-ascii"; name="VirusWarning.txt"
> Content-Disposition: attachment; filename="VirusWarning.txt"
> Content-Transfer-Encoding: quoted-printable
>
> Essa =E9 uma mensagem do Servi=E7o de Anti V=EDrus de E-mail
> --
> O anexo original "Here.pif"
> provavelmente estava infectado com v=EDrus e foi substitu=EDdo por essa men=
> sagem
> de aviso.
>
> Por essa raz=E3o, n=E3o mantivemos uma c=F3pia do arquivo infectado, por fa=
> vor
> contate o remetente da mensagem para que ele desinfecte o arquivo
> original e envie uma c=F3pia segura.
>
>
> Em Mon Mar 3 20:29:02 2003 , o Servi=E7o de Anti V=EDrus informou:
>/h23NSW022579/Here.pifFound the W32/[EMAIL PROTECTED] virus !!!
>Shortcuts to MS-Dos programs are very dangerous in email in Here.pif
>
> --=20
> Postmaster
> Lisa - http://lisa.linkway.com.br/
>
> --CWu20n8V4CTiBYdt
>
> Content-Type: application/octet-stream;
> name=tour1-4x2[1].jpg
> Content-Transfer-Encoding: base64
> Content-ID:
>
> /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQY
> GBcUFhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQkJCQwLDBgNDRgyIRwh
> MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wgAR
> CADFAQIDAREAAhEBAxEB/8QAGwAAAgMBAQEABAUCAwYBAAf/xAAZAQADAQEB
> AQIDBAX/2gAMAwEAAhADEfmx0EG1D5ajLozp9CN5xOSazcTYlIBV
> BxMJhIJB0G0WQU4qcHUitRZ4PI0EaDIg5ocrFXQ4xqvWJOnqKXjVPNyrMvsu5ekfo859h5Ou
> 57V6hWYv1GmRnulMcmn1R+BoFQNJZsqgfc7Vbh2Il6FkdY0mWy5zn6ioPCOO+1a9tUmNK5D8
> vYhtzWTt2ca9PM0WF3TRUtNqiWCgdAg2l5IO7dZOIGSL7AiKNgMWfuNFlq4nTNPNNUeHeSyC
> wIs4iACijVEEySiACvtPkqYSRNh5TyNLGXg4qOsBTybzR3PA4m/i9PGyMjJ3nwPrYsJcsAqR
> nk6gPEQA4uhEYCqsGTRgXg3ZoVdgNHNwI43inQATjD64CBFPX56bTPVQL5hrjwX10c89xVWi
> 0xTZ64K8kF5WiZjqJgAKutmgadtWqjp022vPMF8aIM97lUwgAYsnWWe1y4n9Cz3+h5mBZ800
> y8L7Ir9G0R0JmCVj+b68oQr2nQgwCTqb0lTpbQfP0aO40emUZeRx6rVVzLRdCSEjXznbm8j6
> hn0fQIj5NVYO8uBq89dktVIUI1DFCeEvnT3EmnBPgXpwG9pPp1lN7K8XF55LLoGjW8LmWCvF
> aJGq+ca89Ivsme2ilfEbWerPgaDPbSzqABOuJWW0R5C8Et5dA+oZJp04jfjdxuwZrrwJvPDY
> djAdwSFNhiXRJivnNYxqftmelCv4zWays/AxjQqbNVBbYP8ALo5NZ28UmmPQPqGqahPoaudi
> lbhvTXgHU5vHpZjua8EgMSiJOq+e3jc5+xxpXNfD9MwXPhMI0Km2CtFphq8+jyecvFNpj4GF
> Q4GrkiPaR09baDdPIa80eXS0YQ15HUXhwSceDeJTX09WRNfD7yFc+BxGrBXWml159Vj1STyu
> nOtvPwMKh2MJEB7HLqoYwGY128VWe7MC6XgnJ0K0LGYp4kNbl6GZX8c0wpc+CTXmq07mro04
> IKlBHgOqdE0jihR7iOiIzRksBcemzwMZYHkdRWC0WPrImp2ZqNlfzPXmgLoXgQmKwmpOz1qS
> iKaq9FuufdckmWgwPFoynU0okFbm1M4owV4cClHgGDMPGdTsHrnIMZeEg6H2bk1ITsVTT6iA
> VqhxptskXdyL6lNhrRQYNrOpcXeMZyA4cTqc2UEgiEQHEgIheWtNsnMZm87EdD6lh0WDhQtE
> 0THoCqBazqvIHXOCaXn1LuIDJVXTp0cCRxSG9nY8q4JB4BRJyKLz1K1xqyR3M0SDVMbrQYdw
> Wpo3HXn64GuLGQQjw2IqIj8BQyFXlVSUxsloYqJHcHQGBQSNeWlWuOrnTDsR0LKk0CginwCK
> lSAyZDXAKqaM7856PrOI4OwZCLptnOt6ollweAYFBFlw4KyNc6ZXYjoRQdAJqjbgtohkmj83
> WwW1NqQZnHWYNriQQH4JBzPRnluQVeywfBCiWPNhZenntOdDF2I8Gm5zXcleCu11hMirplji
> z8aE1mxOkMX2SL0w3qejHAaTwVTbDHpNVWskFYCErnBlpuqC25laaHOoJ6kXqRTGWRHVVMsa
> LCxMhGe0lzL6n2kMFstRpMw8hbLhh0sZ0uZAKRDiBqLrTubr25irgVNZLZ5X1hYlFJ4nW1Y0
> 2zsO5sZUiylFM2Gu1k3Olm0DosAZPOc+7aNb24hSKkkDXEjbJvh1Xb81zmQTA3n1MQAy5hSJ
> tXjQ6ZvM7izyCgXXJ0UsuXMWuEDQt0mIZHn1ZRsWOQ6RDuVWmTUudZarXIsJBIXyTDUlhbTM
> J0iRNJqVzbL9czCxPyI0oBSFDAVQ8XSkAnXlqcr6HgEcLejna1MWvoicwmHQ+O5aFCLoLaLA
> tokV7CQmK4cg4HQ6FQeCoOD8Gdl57n3NVzHxzReRW+N7ItayQ0cg6H//xAArEAABBAEEAQQC
> AgMBAQACAAEDBAUQERITIRQiMTIjMwYVIDRBJEL/2gAIAQEAAQUCiiKRenJiMOBum3TV
> 5NiiMQZnbSpj5rUVasdqW3XKrYZ1uy3Zbst2XJlj6pXJIaRFKZ0qITS8z/wkoFXoNHyFxJlL
> 9Na0gtH1e7rB3cIzgq/ssSSNNs3A2EpCFgj/AI9a9Pfr1hxstuHH0X/pqbSf1MA13xVTnLj4
> YsJRx1WShmBx9RfxD99OSk9yehDYy0lWjfx2Zo1q+RfGUAtNio7GSkxVaeLIzRF/HKsvWbgp
> oW2lBwLSGdgB7Pu9Qhm4wsTg/qmTz8hA+6acuUjLJ5eS7Uhzo9OJnsZTOZbJGWZly9SUsdl/
> TwHnvy2pf7C/i8i9WSk71r4ZGUbli88tf+xUuQY3lz0r27GRpnHZyAS4xVJXOIx9lkfGnUfK
> Oibt01gT+kXGsSeryTxkCiTaF9UEpxph3XBdaaNV4Oa47IRQxkThR4CTwijeIlkKXT/hjBXH
> kslAcOuXk54oIZJ02PE3t4e1ApIzjdnQWSXWBt8aF8aQBu3S6GB1SpwHIeNNpI8aZKPHQipD
> iqojcyRMnZmVmHpm0x4bRUK3Y/8AJPFfSeMhxNeJuDx8pgl7aM0IG2
RE: Jail seperation patch
Hello, My test settings are as follows: Host system (pacific.lifeafterking.org): 10.0.0.2, 10.0.0.3, 10.0.0.4 Jail (test.lifeafterking.org): 10.0.0.3, 10.0.0.4 I also made a new patch which fixes these issues: 1. Telnetting to 0.0.0.0 in the jail now redirects to the first jail IP. 2. Non-root users outside a jail cannot access any files inside a jail (sysctl controllable) The patch can be downloaded at http://msalem.translator.cx/dist/jail_seperation.v6.patch. Thanks, -- Mooneer Salem GPLTrans: http://www.translator.cx/ lifeafterking.org: http://www.lifeafterking.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Pawel Jakub Dawidek Sent: Thursday, February 27, 2003 7:44 AM To: Mooneer Salem Cc: FreeBSD Hackers Subject: Re: Jail seperation patch On Thu, Feb 27, 2003 at 07:16:15AM -0800, Mooneer Salem wrote: +> Actually, I just gave it blah.lifeafterking.org in /etc/hosts. 10.0.0.4 +> really *is* in the same jail: +> +> %ifconfig +> lnc0: flags=8843 mtu 1500 +> inet 10.0.0.3 netmask 0x broadcast 10.0.0.3 +> inet 10.0.0.4 netmask 0x broadcast 10.0.0.4 +> ether 00:50:56:e0:26:54 +> lo0: flags=8049 mtu 16384 +> %hostname +> test.lifeafterking.org +> % Ehh, so now I know nothing about your test settings. After all problems isn't so trivial. +> As for the hide files code, I found a possible location for it, in +> vfs_subr.c (extattr_check_cred()). I added +> this block to it: [...] IMHO very dirty and not complete. Jail don't have to be chrooted to diferent mount-point, and checks like those should be done between vnodes, not pathnames. In my opinion better way is just create another jail and don't give access to main host for regular users. -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
future of all the jail patches [was: Re: jail statfs patch]
On Mon, 3 Mar 2003, Christian Kratzer wrote: Hi, > > attached is a patch for 5.0/HEAD that adds a fine grained option to > > control what fs stats can be seen from within jails. > > > > I know that there is also a kernel module available but as I already > > had started to work on this I finished it for those people who > > preferr it this way. I think this answer got here by accident but nethertheless it's a good point. > Du solltest denke ich trotzdem einen pr aufmachen damit es dafür eine > art ticket gibt. Das hilft denke ich dass es aufgenommen wird. Christian asks me to file a PR to better get this tracked and perhaps included in mainstream. I had seen lots of jail discussion here the last months but I think there had been few PR submission. What is the overall opinion on this - file PRs ? What about including (at least some) of the (other) jail patches in HEAD ? What about jail-ng ? [ Perhaps take this discussion to -current ? ] -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: jail statfs patch
Moin, On Mon, 3 Mar 2003, Bjoern A. Zeeb wrote: > Hi, > > attached is a patch for 5.0/HEAD that adds a fine grained option to > control what fs stats can be seen from within jails. > > I know that there is also a kernel module available but as I already > had started to work on this I finished it for those people who > preferr it this way. Du solltest Denke ich trotzdem einen pr auchmachen damit es dafür eine art ticket gibt. Das hilft denke ich dass es aufgenommen wird. Grüße ck -- CK Software GmbH Christian Kratzer, Schwarzwaldstr. 31, 71131 Jettingen Email: [EMAIL PROTECTED] Phone: +49 7452 889-135Open Software Solutions, Network Security Fax: +49 7452 889-136FreeBSD spoken here! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
jail statfs patch
Hi,
attached is a patch for 5.0/HEAD that adds a fine grained option to
control what fs stats can be seen from within jails.
I know that there is also a kernel module available but as I already
had started to work on this I finished it for those people who
preferr it this way.
--- description ---
The patch is derived from a private patch done by
Christian Kratzer for RELENG_4 and the public patches
by Oliver Fromme (see kern/47586).
It adds following sysctl option:
security.jail.statfs_restricted
This fine grained option lets you control what and how
filesystem
statistcs are seen from within jails:
security.jail.statfs_restricted=0
this is the old behaviour where you could see everything
from the
whole host.
security.jail.statfs_restricted=1
this is the default for now. It shows only partitions
related to the
jail. If there is no root partition resp. the jail is on a
shared
partition a ``fake'' root with the correct values but a
stripped
f_mntonname will be shown.
security.jail.statfs_restricted=2
this is almost the same as 1 but it will show a ``full
fake'' for a
shared root mount. It will zero out almost all values and
write
jail-specific ``fakes'' to the others.
security.jail.statfs_restricted=3
this is almost the same as 1 but it will not show a shared
root at
all.
security.jail.statfs_restricted>=4
this will not show anything but procfs, devfs, etc. within
the jail.
Be warned that this renders the jail to be almost unusable.
--- /description ---
for some sample output or to download the diff please have look at
http://sources.zabbadoz.net/freebsd/jail.html
PS: I am really happy about all the other people currently annouced
other jail patches. Could you also please update the manpage(s) ? ;-)
--
Greetings
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
56 69 73 69 74 http://www.zabbadoz.net/
--- ./sys/kern/kern_jail.c.orig Mon Feb 3 12:57:06 2003
+++ ./sys/kern/kern_jail.c Tue Feb 4 18:54:55 2003
@@ -49,6 +49,11 @@
&jail_sysvipc_allowed, 0,
"Processes in jail can use System V IPC primitives");
+intjail_statfs_restricted = 1;
+SYSCTL_INT(_security_jail, OID_AUTO, statfs_restricted, CTLFLAG_RW,
+&jail_statfs_restricted, 0,
+"Processes in jail may not see all currently mounted file systems");
+
/*
* MPSAFE
*/
@@ -76,6 +81,9 @@
mtx_init(&pr->pr_mtx, "jail mutex", NULL, MTX_DEF);
pr->pr_securelevel = securelevel;
error = copyinstr(j.hostname, &pr->pr_host, sizeof pr->pr_host, 0);
+ if (error)
+ goto bail;
+ error = copyinstr(j.path, &pr->pr_path, sizeof pr->pr_path, 0);
if (error)
goto bail;
ca.path = j.path;
--- ./sys/kern/vfs_syscalls.c.orig Mon Feb 3 13:12:26 2003
+++ ./sys/kern/vfs_syscalls.c Sun Mar 2 19:31:38 2003
@@ -227,6 +227,10 @@
int error;
struct nameidata nd;
struct statfs sb;
+ int notsu, jrlen;
+
+ if (jail_statfs_restricted >= 4 && jailed(td->td_ucred))
+ return (ENOENT);
NDINIT(&nd, LOOKUP, FOLLOW, UIO_USERSPACE, uap->path, td);
if ((error = namei(&nd)) != 0)
@@ -244,9 +248,47 @@
if (error)
return (error);
sp->f_flags = mp->mnt_flag & MNT_VISFLAGMASK;
- if (suser(td)) {
+ notsu = suser(td);
+ if (notsu || (jail_statfs_restricted && jailed(td->td_ucred))) {
bcopy(sp, &sb, sizeof(sb));
- sb.f_fsid.val[0] = sb.f_fsid.val[1] = 0;
+ if (notsu)
+ sb.f_fsid.val[0] = sb.f_fsid.val[1] = 0;
+
+ if (jail_statfs_restricted && jailed(td->td_ucred)) {
+ jrlen = strlen(td->td_ucred->cr_prison->pr_path);
+
+ if (strlen(mp->mnt_stat.f_mntonname) < jrlen) {
+ switch (jail_statfs_restricted) {
+ case 1:
+ bzero(sb.f_mntonname,
+ sizeof(sb.f_mntonname));
+ *sb.f_mntonname = '/';
+ break;
+ case 2:
+ bzero(&
Re: Fragmentation Avoidance Code
Audsin wrote: > I am currently working in the fragmentation avoidance technique caused by > the overhead introduced by MIP6. I am using FreeBSD 4.4 and Kame Snap. > I have introduced some code in netinet6/ip6_output.c code and > netinet6/in6_pcb.h and netinet/in_pcb.h so that length of the MIP6 > extension header if present is taken into account, when calculation the > ipoptlen() and hence frag is avoided. Below i am pasting the code to which > i have made changes. The lines starting with @ symbol shows the code > introduced by me. Please go thru the code and let me know whether this > takes account of the Extension header length introduced by MIP6. Since, > this is my first research project, i kindly request you to go thru the code > and help me. > I have explained my code under the heading "Implementation" in the last ie. > after the codes > > Please let me know, whether this code will take into account the length > occupied by MIP6 Ext header. If any changes is required pls let me know. > > Thanks and sorry for the disturbance We saw it the first two times you sent it. The patch, as is, is unreadable. It would be much more useful to the list if you were to use "cvs diff" to obtain the diff. If you are not using a checked out source tree from a local copy of the CVS repository to do your developement, then "diff -c" is is good, too (unidiffs are less useful because your version is not likely to match our version, since FreeBSD 4.4 predates some significant stack changes, such as SYN caching, etc.). The most correct place to send this request is the "[EMAIL PROTECTED]" list, not the "[EMAIL PROTECTED]" list. All that in mind, it looks like the code oes what you want, which appears to be avoiding fragmentation in the multicast datagram; however, with the diff being as unreadable as it is, no one is likely to step through the full output code path while holding your diff in their head. As a general observation, I'd like to know (1) Is this what it's supposed to do?, (2) If you are talking about multicast datagrams, how is it that you are getting fragmentation without going over the MTU in the first place, is packet coelescing that's biting you?, (3) What's the performance difference you expect out of doing this? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
lpc problem with LinkSys print servers
Greetings hackers... I have an interesting little problem. I have about 13 customers that are running FreeBSD 4.5 to 4.7 (STABLE), with 3-port LinkSys print servers. Everything seems to be working fine. For the past 3 months one of these customers was reporting printing problems on one of their printers connected to the print server. The other printers are working just fine. This particular printer is a high load printer, printing about 50 to 70 pages at a time. Occasionally, the printer just stops while printing. We have to force a 'lpc restart lsjd1p2' command several times to get the printer to restart again. Since it was only happening to one of the 13 sites, I attributed the problem to hardware... (cable, print server, printer, etc). We have since changed out print servers, printers, cables and everything I could think of, all to no avail... The printer still stops right in the middle of a print job. Just now, another customer has reported the exact same problem. They had a local hard ware tech come out and he updated firmware on the print server, installed a new print server, switched out printers, and replaced cables (both network and parallel). Nothing has changed... The printer still stops while printing large print jobs. I believe that lpr/lpd is not resetting after receiving a Busy/Ready (or Nack/Ack) signal. Has anyone else seen this problem before? Thanks in advance... Peter Elsner -- Peter Elsner <[EMAIL PROTECTED]> Vice President Of Customer Service (And System Administrator) 1835 S. Carrier Parkway Grand Prairie, Texas 75051 (972) 263-2080 - Voice (972) 263-2082 - Fax (972) 489-4838 - Cell Phone (425) 988-8061 - eFax I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say "Daddy, where were you when they took freedom of the press away from the Internet?" -- Mike Godwin Unix IS user friendly... It's just selective about who its friends are. System Administration - It's a dirty job, but somebody said I had to do it. If you receive something that says 'Send this to everyone you know, pretend you don't know me. Standard $500/message proofreading fee applies for UCE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
¦³¾÷·|§AÄ@·N¥h¹Á¸Õ¶Ü??
Title: ¬°¤°»ò¦³¤H·|¤ñ§A¦¨¥\10¿
¥D¦®: ³o©Î³\¬O±z¥¿¦b´M§äªº¾÷·|³á
³o©Î³\¬O±z¥¿¦b§äªº¾÷·|[EMAIL PROTECTED]
¹ï¤£°_¡I¥´ÂZ¤F¡A¦pªG¦]¦¹³y¦¨±zªº§xÂZ¡A½Ðª½±µ§R°£¥»«H¤ÎÂI¿ï¤U¤è¡u¤£·Q¦A¦¬«H¡v¡A§ÚÌ·|±N±zªº¸ê®Æ§R°£¡I
¬°¤°»ò¦³¤H·|¤ñ§A¦¨¥\10¿¡A¦¬¤J¦h100¿¡B¬Æ¦Ü¦h1000¿¡AÃø¹D¥L¦³¤ñ§A¦hÁo©ú³o»ò¦h¶Ü¡H
µª®×ªÖ©w¤£¬Oªº¡I
[EMAIL PROTECTED]
¥L̨쩳°µ¤F¤°»ò¬O§ÚÌ©Ò¤£ª¾¹Dªº¨Æ¡H
¦Ó§Ų́쩳°µ¿ù¤F¤°»ò¡B¤S¿ù¹L¤F¤°»ò¡H
·Q¤£·Qª¾¹D¤H®a«ç»ò°µËªº¡I
§A¬Û«H¡u®É¶¡¡×ª÷¿ú¡v¡BÁÙ¬O¡u®É¶¡¡Öª÷¿ú¡v
Á|¨Ò¡G
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@®É¼Æ¡H
¢·¤p®É¡¯¢²¢µ¢´¤Ñ¡¯¢²¢¯¦~¡×¢·¢¶,¢µ¢¯¢¯¤p®É
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]@[EMAIL PROTECTED]
³o¼Ëªº¦¬¤J¡A¨¬°÷¤TÀ\·Å¹¡¡F¶R¨®¤l¡B©Ð¤l«j±j°÷¥Î¡F§O§Ñ¤F¡AÁÙ¦³¤l¤kªº±Ð¨|¶O¡B¦Û¤vªº¾i¦Ñª÷¡BÁÙ¦³¡y¹Ú·Q¡zµ¥«Ý¹ê²{¡I
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]@¥Í¡H
¤£·Q¦A¦¬«H(Unsubscribe)
¡@
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
¦³¾÷·|§AÄ@·N¥h¹Á¸Õ¶Ü??
Title: ¬°¤°»ò¦³¤H·|¤ñ§A¦¨¥\10¿
¥D¦®: ³o©Î³\¬O±z¥¿¦b´M§äªº¾÷·|³á
³o©Î³\¬O±z¥¿¦b§äªº¾÷·|[EMAIL PROTECTED]
¹ï¤£°_¡I¥´ÂZ¤F¡A¦pªG¦]¦¹³y¦¨±zªº§xÂZ¡A½Ðª½±µ§R°£¥»«H¤ÎÂI¿ï¤U¤è¡u¤£·Q¦A¦¬«H¡v¡A§ÚÌ·|±N±zªº¸ê®Æ§R°£¡I
¬°¤°»ò¦³¤H·|¤ñ§A¦¨¥\10¿¡A¦¬¤J¦h100¿¡B¬Æ¦Ü¦h1000¿¡AÃø¹D¥L¦³¤ñ§A¦hÁo©ú³o»ò¦h¶Ü¡H
µª®×ªÖ©w¤£¬Oªº¡I
[EMAIL PROTECTED]
¥L̨쩳°µ¤F¤°»ò¬O§ÚÌ©Ò¤£ª¾¹Dªº¨Æ¡H
¦Ó§Ų́쩳°µ¿ù¤F¤°»ò¡B¤S¿ù¹L¤F¤°»ò¡H
·Q¤£·Qª¾¹D¤H®a«ç»ò°µËªº¡I
§A¬Û«H¡u®É¶¡¡×ª÷¿ú¡v¡BÁÙ¬O¡u®É¶¡¡Öª÷¿ú¡v
Á|¨Ò¡G
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@®É¼Æ¡H
¢·¤p®É¡¯¢²¢µ¢´¤Ñ¡¯¢²¢¯¦~¡×¢·¢¶,¢µ¢¯¢¯¤p®É
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]@[EMAIL PROTECTED]
³o¼Ëªº¦¬¤J¡A¨¬°÷¤TÀ\·Å¹¡¡F¶R¨®¤l¡B©Ð¤l«j±j°÷¥Î¡F§O§Ñ¤F¡AÁÙ¦³¤l¤kªº±Ð¨|¶O¡B¦Û¤vªº¾i¦Ñª÷¡BÁÙ¦³¡y¹Ú·Q¡zµ¥«Ý¹ê²{¡I
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]@¥Í¡H
¤£·Q¦A¦¬«H(Unsubscribe)
¡@
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Fragmentation Avoidance Code
Respected Sir
I am currently working in the fragmentation avoidance technique caused by
the overhead introduced by MIP6. I am using FreeBSD 4.4 and Kame Snap.
I have introduced some code in netinet6/ip6_output.c code and
netinet6/in6_pcb.h and netinet/in_pcb.h so that length of the MIP6
extension header if present is taken into account, when calculation the
ipoptlen() and hence frag is avoided. Below i am pasting the code to which
i have made changes. The lines starting with @ symbol shows the code
introduced by me. Please go thru the code and let me know whether this
takes account of the Extension header length introduced by MIP6. Since,
this is my first research project, i kindly request you to go thru the code
and help me.
I have explained my code under the heading "Implementation" in the last ie.
after the codes
Please let me know, whether this code will take into account the length
occupied by MIP6 Ext header. If any changes is required pls let me know.
Thanks and sorry for the disturbance
Code
-
netinet6/in6_pcb.h and netinet/in_pcb.h
---
@ #ifdef MIP6
@ #include
@ #include
@ #include
@ #include
@ #endif /* MIP6 */
.
.
.
struct in6pcb (
.
.
.
struct ip6_pktopts *in6p_outputopts; /* IP6 options for outgoing packets */
@ #ifdef MIP6
@ struct mip6_pktopts *mip6_outputopts /* MIP6 options for outgoing
packets */
@ #endif
.
.
.
);
netinet6/ip6_output.c
--
In the last part of netinet6/ip6_output.c I have changed the code and
pasted it under Modified code
Modified Code:
-
/*
* Compute IPv6 and MIP6 extension header length.
*/
#ifdef HAVE_NRL_INPCB
# define in6pcb inpcb
# define in6p_outputoptsinp_outputopts6
#endif
int
ip6_optlen(in6p)
struct in6pcb *in6p;
{
int len;
@ if (!(in6p->in6p_outputopts ||
@ #ifdef MIP6
@ in6p->mip6_outputopts
@ #endif
@ ))
@ return 0;
len = 0;
#define elen(x) \
(((struct ip6_ext *)(x)) ? (((struct ip6_ext *)(x))->ip6e_len + 1) <<
3 : 0)
len += elen(in6p->in6p_outputopts->ip6po_hbh);
if (in6p->in6p_outputopts->ip6po_rthdr)
/* dest1 is valid with rthdr only */
len += elen(in6p->in6p_outputopts->ip6po_dest1);
len += elen(in6p->in6p_outputopts->ip6po_rthdr);
len += elen(in6p->in6p_outputopts->ip6po_dest2);
@ #ifdef MIP6
@ len += elen(in6p->mip6_outputopts->mip6po_rthdr);/* MIP6 Routing Header */
@ len += elen(in6p->mip6_outputopts->mip6po_haddr);/* MIP6 Home Addr
Option */
@ len += elen(in6p->mip6_outputopts->mip6_dest2); /* MIP6 Dest2 Option */
@ #endif
return len;
#undef elen
}
#ifdef HAVE_NRL_INPCB
# undef in6pcb
# undef in6p_outputopts
#endif
Original netinet6/ip6_output.c kame Code
--
/*
* Compute IPv6 extension header length.
*/
#ifdef HAVE_NRL_INPCB
# define in6pcb inpcb
# define in6p_outputoptsinp_outputopts6
#endif
int
ip6_optlen(in6p)
struct in6pcb *in6p;
{
int len;
if (!in6p->in6p_outputopts)
return 0;
len = 0;
#define elen(x) \
(((struct ip6_ext *)(x)) ? (((struct ip6_ext *)(x))->ip6e_len + 1) <<
3 : 0)
len += elen(in6p->in6p_outputopts->ip6po_hbh);
if (in6p->in6p_outputopts->ip6po_rthdr)
/* dest1 is valid with rthdr only */
len += elen(in6p->in6p_outputopts->ip6po_dest1);
len += elen(in6p->in6p_outputopts->ip6po_rthdr);
len += elen(in6p->in6p_outputopts->ip6po_dest2);
return len;
#undef elen
}
#ifdef HAVE_NRL_INPCB
# undef in6pcb
# undef in6p_outputopts
#endif
Implementation
1)netinet6/in6_pcb.h and netinet/in_pcb.h
Create a pointer to struct mip6_pktopts, if MIP6 is defined and name the
pointer as *mip6_outputopts
@ #ifdef MIP6
@ struct mip6_pktopts *mip6_outputopts /* MIP6 options for outgoing
packets */
@ #endif
2) netinet6/ip6_output.c
Modify the code of macro elen(x) present in function ip6_optlen(in6p) in
netinet6/ip6_output.c such that it takes into account, the length occupied
by Mip6 Extension headers
@ #ifdef MIP6
@ len += elen(in6p->mip6_outputopts->mip6po_rthdr);/* MIP6 Routing Header */
@ len += elen(in6p->mip6_outputopts->mip6po_haddr);/* MIP6 Home Addr
Option */
@ len += elen(in6p->mip6_outputopts->mip6_dest2); /* MIP6 Dest2 Option */
@ #endif
Regards
Dev
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Fragmentation Avoidance Code
Respected Sir
I am currently working in the fragmentation avoidance technique caused by
the overhead introduced by MIP6. I am using FreeBSD 4.4 and Kame Snap.
I have introduced some code in netinet6/ip6_output.c code and
netinet6/in6_pcb.h and netinet/in_pcb.h so that length of the MIP6
extension header if present is taken into account, when calculation the
ipoptlen() and hence frag is avoided. Below i am pasting the code to which
i have made changes. The lines starting with @ symbol shows the code
introduced by me. Please go thru the code and let me know whether this
takes account of the Extension header length introduced by MIP6. Since,
this is my first research project, i kindly request you to go thru the code
and help me.
I have explained my code under the heading "Implementation" in the last ie.
after the codes
Please let me know, whether this code will take into account the length
occupied by MIP6 Ext header. If any changes is required pls let me know.
Thanks and sorry for the disturbance
Code
-
netinet6/in6_pcb.h and netinet/in_pcb.h
---
@ #ifdef MIP6
@ #include
@ #include
@ #include
@ #include
@ #endif /* MIP6 */
.
.
.
struct in6pcb (
.
.
.
struct ip6_pktopts *in6p_outputopts; /* IP6 options for outgoing packets */
@ #ifdef MIP6
@ struct mip6_pktopts *mip6_outputopts /* MIP6 options for outgoing
packets */
@ #endif
.
.
.
);
netinet6/ip6_output.c
--
In the last part of netinet6/ip6_output.c I have changed the code and
pasted it under Modified code
Modified Code:
-
/*
* Compute IPv6 and MIP6 extension header length.
*/
#ifdef HAVE_NRL_INPCB
# define in6pcb inpcb
# define in6p_outputoptsinp_outputopts6
#endif
int
ip6_optlen(in6p)
struct in6pcb *in6p;
{
int len;
@ if (!(in6p->in6p_outputopts ||
@ #ifdef MIP6
@ in6p->mip6_outputopts
@ #endif
@ ))
@ return 0;
len = 0;
#define elen(x) \
(((struct ip6_ext *)(x)) ? (((struct ip6_ext *)(x))->ip6e_len + 1) <<
3 : 0)
len += elen(in6p->in6p_outputopts->ip6po_hbh);
if (in6p->in6p_outputopts->ip6po_rthdr)
/* dest1 is valid with rthdr only */
len += elen(in6p->in6p_outputopts->ip6po_dest1);
len += elen(in6p->in6p_outputopts->ip6po_rthdr);
len += elen(in6p->in6p_outputopts->ip6po_dest2);
@ #ifdef MIP6
@ len += elen(in6p->mip6_outputopts->mip6po_rthdr);/* MIP6 Routing Header */
@ len += elen(in6p->mip6_outputopts->mip6po_haddr);/* MIP6 Home Addr
Option */
@ len += elen(in6p->mip6_outputopts->mip6_dest2); /* MIP6 Dest2 Option */
@ #endif
return len;
#undef elen
}
#ifdef HAVE_NRL_INPCB
# undef in6pcb
# undef in6p_outputopts
#endif
Original netinet6/ip6_output.c kame Code
--
/*
* Compute IPv6 extension header length.
*/
#ifdef HAVE_NRL_INPCB
# define in6pcb inpcb
# define in6p_outputoptsinp_outputopts6
#endif
int
ip6_optlen(in6p)
struct in6pcb *in6p;
{
int len;
if (!in6p->in6p_outputopts)
return 0;
len = 0;
#define elen(x) \
(((struct ip6_ext *)(x)) ? (((struct ip6_ext *)(x))->ip6e_len + 1) <<
3 : 0)
len += elen(in6p->in6p_outputopts->ip6po_hbh);
if (in6p->in6p_outputopts->ip6po_rthdr)
/* dest1 is valid with rthdr only */
len += elen(in6p->in6p_outputopts->ip6po_dest1);
len += elen(in6p->in6p_outputopts->ip6po_rthdr);
len += elen(in6p->in6p_outputopts->ip6po_dest2);
return len;
#undef elen
}
#ifdef HAVE_NRL_INPCB
# undef in6pcb
# undef in6p_outputopts
#endif
Implementation
1)netinet6/in6_pcb.h and netinet/in_pcb.h
Create a pointer to struct mip6_pktopts, if MIP6 is defined and name the
pointer as *mip6_outputopts
@ #ifdef MIP6
@ struct mip6_pktopts *mip6_outputopts /* MIP6 options for outgoing
packets */
@ #endif
2) netinet6/ip6_output.c
Modify the code of macro elen(x) present in function ip6_optlen(in6p) in
netinet6/ip6_output.c such that it takes into account, the length occupied
by Mip6 Extension headers
@ #ifdef MIP6
@ len += elen(in6p->mip6_outputopts->mip6po_rthdr);/* MIP6 Routing Header */
@ len += elen(in6p->mip6_outputopts->mip6po_haddr);/* MIP6 Home Addr
Option */
@ len += elen(in6p->mip6_outputopts->mip6_dest2); /* MIP6 Dest2 Option */
@ #endif
Regards
Dev
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Fragmentation Avoidance Code
Respected Sir
I am currently working in the fragmentation avoidance technique caused by
the overhead introduced by MIP6. I am using FreeBSD 4.4 and Kame Snap.
I have introduced some code in netinet6/ip6_output.c code and
netinet6/in6_pcb.h and netinet/in_pcb.h so that length of the MIP6
extension header if present is taken into account, when calculation the
ipoptlen() and hence frag is avoided. Below i am pasting the code to which
i have made changes. The lines starting with @ symbol shows the code
introduced by me. Please go thru the code and let me know whether this
takes account of the Extension header length introduced by MIP6. Since,
this is my first research project, i kindly request you to go thru the code
and help me.
I have explained my code under the heading "Implementation" in the last ie.
after the codes
Please let me know, whether this code will take into account the length
occupied by MIP6 Ext header. If any changes is required pls let me know.
Thanks and sorry for the disturbance
Code
-
netinet6/in6_pcb.h and netinet/in_pcb.h
---
@ #ifdef MIP6
@ #include
@ #include
@ #include
@ #include
@ #endif /* MIP6 */
.
.
.
struct in6pcb (
.
.
.
struct ip6_pktopts *in6p_outputopts; /* IP6 options for outgoing packets */
@ #ifdef MIP6
@ struct mip6_pktopts *mip6_outputopts /* MIP6 options for outgoing
packets */
@ #endif
.
.
.
);
netinet6/ip6_output.c
--
In the last part of netinet6/ip6_output.c I have changed the code and
pasted it under Modified code
Modified Code:
-
/*
* Compute IPv6 and MIP6 extension header length.
*/
#ifdef HAVE_NRL_INPCB
# define in6pcb inpcb
# define in6p_outputoptsinp_outputopts6
#endif
int
ip6_optlen(in6p)
struct in6pcb *in6p;
{
int len;
@ if (!(in6p->in6p_outputopts ||
@ #ifdef MIP6
@ in6p->mip6_outputopts
@ #endif
@ ))
@ return 0;
len = 0;
#define elen(x) \
(((struct ip6_ext *)(x)) ? (((struct ip6_ext *)(x))->ip6e_len + 1) <<
3 : 0)
len += elen(in6p->in6p_outputopts->ip6po_hbh);
if (in6p->in6p_outputopts->ip6po_rthdr)
/* dest1 is valid with rthdr only */
len += elen(in6p->in6p_outputopts->ip6po_dest1);
len += elen(in6p->in6p_outputopts->ip6po_rthdr);
len += elen(in6p->in6p_outputopts->ip6po_dest2);
@ #ifdef MIP6
@ len += elen(in6p->mip6_outputopts->mip6po_rthdr);/* MIP6 Routing Header */
@ len += elen(in6p->mip6_outputopts->mip6po_haddr);/* MIP6 Home Addr
Option */
@ len += elen(in6p->mip6_outputopts->mip6_dest2); /* MIP6 Dest2 Option */
@ #endif
return len;
#undef elen
}
#ifdef HAVE_NRL_INPCB
# undef in6pcb
# undef in6p_outputopts
#endif
Original netinet6/ip6_output.c kame Code
--
/*
* Compute IPv6 extension header length.
*/
#ifdef HAVE_NRL_INPCB
# define in6pcb inpcb
# define in6p_outputoptsinp_outputopts6
#endif
int
ip6_optlen(in6p)
struct in6pcb *in6p;
{
int len;
if (!in6p->in6p_outputopts)
return 0;
len = 0;
#define elen(x) \
(((struct ip6_ext *)(x)) ? (((struct ip6_ext *)(x))->ip6e_len + 1) <<
3 : 0)
len += elen(in6p->in6p_outputopts->ip6po_hbh);
if (in6p->in6p_outputopts->ip6po_rthdr)
/* dest1 is valid with rthdr only */
len += elen(in6p->in6p_outputopts->ip6po_dest1);
len += elen(in6p->in6p_outputopts->ip6po_rthdr);
len += elen(in6p->in6p_outputopts->ip6po_dest2);
return len;
#undef elen
}
#ifdef HAVE_NRL_INPCB
# undef in6pcb
# undef in6p_outputopts
#endif
Implementation
1)netinet6/in6_pcb.h and netinet/in_pcb.h
Create a pointer to struct mip6_pktopts, if MIP6 is defined and name the
pointer as *mip6_outputopts
@ #ifdef MIP6
@ struct mip6_pktopts *mip6_outputopts /* MIP6 options for outgoing
packets */
@ #endif
2) netinet6/ip6_output.c
Modify the code of macro elen(x) present in function ip6_optlen(in6p) in
netinet6/ip6_output.c such that it takes into account, the length occupied
by Mip6 Extension headers
@ #ifdef MIP6
@ len += elen(in6p->mip6_outputopts->mip6po_rthdr);/* MIP6 Routing Header */
@ len += elen(in6p->mip6_outputopts->mip6po_haddr);/* MIP6 Home Addr
Option */
@ len += elen(in6p->mip6_outputopts->mip6_dest2); /* MIP6 Dest2 Option */
@ #endif
Regards
Dev
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
