|
||||||||
|
|
#1
|
|
Hi All,
I am familiar with setting the well known TCP options by way of setsockopt(), but how about setting arbitrary options in the 44 bytes available for the options in the TCP header? Is there a function call I can use to insert say : <my_option_int><my_option_len_int><my_option_dat a> into the TCP header? and have the stack take care of the rest (checksum etc). I know i can consrtuct the iphdr and tcphdr myself and tell the kernel the headers are included, but if i do that, I will now be responsible for completing the TCP handshake & for some work that I'd like the stack to take care of. Is is there an API call to insert such TCP options? or do i really need to get into the kernel now. thanks, grant. grant_holler@yahoo.com |
|
#2
|
|||
|
|||
|
Hi,
I think you ca use "sysctl" and modify these options. thanks, sunil (E-Mail Removed) wrote: > Hi All, > > I am familiar with setting the well known TCP options by way of > setsockopt(), but how about setting arbitrary options in the 44 bytes > available for the options in the TCP header? Is there a function call I > can use to insert say : > > <my_option_int><my_option_len_int><my_option_dat a> into the TCP header? > and have the stack take care of the rest (checksum etc). > > I know i can consrtuct the iphdr and tcphdr myself and tell the kernel > the headers are included, but if i do that, I will now be responsible > for completing the TCP handshake & for some work that I'd like the > stack to take care of. > > Is is there an API call to insert such TCP options? or do i really need > to get into the kernel now. > > thanks, > > grant. |
|
#3
|
|||
|
|||
|
thanks sunil. I took a look at sysctl, but it seems sysctl currently
(i'm working with linux 2.4.24 kernel) will only let you set the known tcp options listed in the tcp 7 manpage. what i'd really like to do is set a custom (non documented TCP option). So, for example, tell the kernel, "here's put these 8 bytes into the TCP header as options and carry on as usual". is there a way to write custom TCP options? thanks, grant. (E-Mail Removed) wrote: > Hi, > > I think you ca use "sysctl" and modify these options. > > thanks, > sunil > (E-Mail Removed) wrote: > > Hi All, > > > > I am familiar with setting the well known TCP options by way of > > setsockopt(), but how about setting arbitrary options in the 44 bytes > > available for the options in the TCP header? Is there a function call I > > can use to insert say : > > > > <my_option_int><my_option_len_int><my_option_dat a> into the TCP header? > > and have the stack take care of the rest (checksum etc). > > > > I know i can consrtuct the iphdr and tcphdr myself and tell the kernel > > the headers are included, but if i do that, I will now be responsible > > for completing the TCP handshake & for some work that I'd like the > > stack to take care of. > > > > Is is there an API call to insert such TCP options? or do i really need > > to get into the kernel now. > > > > thanks, > > > > grant. |
|
#4
|
|||
|
|||
|
(E-Mail Removed) wrote:
> Hi All, > > I am familiar with setting the well known TCP options by way of > setsockopt(), but how about setting arbitrary options in the 44 bytes > available for the options in the TCP header? Is there a function call I > can use to insert say : > > <my_option_int><my_option_len_int><my_option_dat a> into the TCP header? > and have the stack take care of the rest (checksum etc). > > I know i can consrtuct the iphdr and tcphdr myself and tell the kernel > the headers are included, but if i do that, I will now be responsible > for completing the TCP handshake & for some work that I'd like the > stack to take care of. > > Is is there an API call to insert such TCP options? or do i really need > to get into the kernel now. > > thanks, > > grant. Hi Grant, I think only way to support custom TCP option is the get your hands dirty with kernel code. The other way, as you suggested, is to use SOCK_RAW i.e raw socket But in case of raw sockets you have to do TCP handshake/shutdown. Even if setsockopt() API provided a way to set custom TCP option, how will you make the peer TCP understand that option. Peer TCP will just ignore the option which it does not understand. I believe, you will have to extend kernel TCP/IP stack to support your option. It might help if you post your motivation for having custom TCP option. Why do you really want it ? Thanks, Tejas Kokje |
|
#5
|
|||
|
|||
|
thanks tejas. I had a feeling i may need to get into the kernel for
this, but i just wanted to pass it by the folks in this newgroup to make sure there wasn't an existing way of doing it in the standard 2.4 kernel. thanks for the info. I'll dive into the kernel, then ![]() grant. Tejas Kokje wrote: > (E-Mail Removed) wrote: > > Hi All, > > > > I am familiar with setting the well known TCP options by way of > > setsockopt(), but how about setting arbitrary options in the 44 bytes > > available for the options in the TCP header? Is there a function call I > > can use to insert say : > > > > <my_option_int><my_option_len_int><my_option_dat a> into the TCP header? > > and have the stack take care of the rest (checksum etc). > > > > I know i can consrtuct the iphdr and tcphdr myself and tell the kernel > > the headers are included, but if i do that, I will now be responsible > > for completing the TCP handshake & for some work that I'd like the > > stack to take care of. > > > > Is is there an API call to insert such TCP options? or do i really need > > to get into the kernel now. > > > > thanks, > > > > grant. > > Hi Grant, > > I think only way to support custom TCP option is the get your hands > dirty with kernel code. The other way, as you suggested, is to use > SOCK_RAW i.e raw socket But in case of raw sockets you have to do TCP > handshake/shutdown. > > Even if setsockopt() API provided a way to set custom TCP option, how > will you make the peer TCP understand that option. Peer TCP will just > ignore the option which it does not understand. > > I believe, you will have to extend kernel TCP/IP stack to support your > option. It might help if you post your motivation for having custom TCP > option. Why do you really want it ? > > Thanks, > Tejas Kokje |
|
#6
|
|||
|
|||
|
> I believe, you will have to extend kernel TCP/IP stack to support
> your option. It might help if you post your motivation for having > custom TCP option. Why do you really want it ? Indeed, that would be good to know. Those custom TCP options are unlikely to pass any firewalls. The remote TCP stack would also have to understand the options and/or have a way to pass them to the user. If the applications on both sides are the things generating and consuming the options, then ostensibly the applications could just send the information contained in the options in the application-level data stream. The TCP options fields were meant only to communicate information between peer TCP instances, they weren't meant as an additional communication channel between TCP users. rick jones -- portable adj, code that compiles under more than one compiler these opinions are mine, all mine; HP might not want them anyway... ![]() feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... |
![]() |
| Tags |
| custom, header, options, setting, tcp |
| Thread Tools | |
| Display Modes | |
|
|