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 sys/syslog.h
@ #include net/if_hif.h
@ #include netinet6/mip6_var.h
@ #include netinet6/mip6.h
@ #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 sys/syslog.h
@ #include net/if_hif.h
@ #include netinet6/mip6_var.h
@ #include netinet6/mip6.h
@ #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 sys/syslog.h
@ #include net/if_hif.h
@ #include netinet6/mip6_var.h
@ #include netinet6/mip6.h
@ #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
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
