Forum Discussion
deepfried78
Altostratus
AltostratusTrouble with TCP::option set 28
Using my lab VE, running 17.1.1.3, the following iRule returns the following error. I can't seem to find what's wrong with the format. Any help would be very appreciated. For context, I'm trying to b...
Thanks, I think we solved this around the same time. My first problem was that I was mistakenly enabling TCP options in my client TCP profile, but using the SERVER_CONNECTED event. When I enabled TCP options in the server event (by just configuring the virtual server to use the same profile for the server), I stopped getting the error.
Here is the profile config:
ltm profile tcp tcp_opt {
app-service none
tcp-options "{28 first}"
Reading https://clouddocs.f5.com/api/irules/SERVER_CONNECTED.html I found that, for a standard profile, I'd find the options set in the first packet after the TCP 3-way handshake, but if I had used a fastL4 VIP, I would see it in the first syn, as you did.
I also noticed that Wireshark interpreted option 28 as "user timeout", and also see the odd length of "6", but when I converted the 6 hex numbers, I got "28" (the option number), "6" (the size), "192" (first octet of true source IP address), "168" (second octet), third octet, and fourth octet. It worked.
Lucas_Thompson
Employee
Employee
Thanks. Since there doesn't seem to be a good reference doc on this, and this functionality is confusing, and this functionality changed between v13 and v15, it seems like a good puzzle to unravel.
Do you have an example packet capture or RFC or other specification of what data you want this to look like?
I did some quick testing using a simple irule:
when SERVER_INIT {
scan [IP::client_addr] {%d.%d.%d.%d} a b c d
TCP::option set 28 [binary format cccc $a $b $c $d] all
}and a TCP profile like this:
ltm profile tcp tcp_opt { app-service none tcp-options "{28 last}" }NOTE: without the tcp-options section in the TCP profile, SERVER_INIT does not fire. In v14, an enhancement was made so that the TCP option can be injected into the very first server-side SYN packet.
I get this this sort of traffic out of the backend:
The "length 6" part doesn't seem quite right, but I'm not precisely sure what reference standard (RFC, etc) defines what "right" looks like here.
Another note about this:
Be careful with this "tcp-options" setting. It must be formatted in pairs like a TCL list (value space value space) or the parser can't parse it correctly. If this parser fails, it puts the BIG-IP into kind of a "dead" state where the TCP profile is broken. Making a change to the iRule attached to the vip causes the parser to re-read the tcp-options parameter. The log when this happens looks like this (in /var/log/ltm):
Jul 26 11:50:56 west.lab.local warning tmm3[28927]: 01010039:4: Bad tcp options value in profile: Could not parse TCP options settings
Jul 26 11:50:56 west.lab.local err tmm3[28927]: 01010356:3: hudfilter_init: filter 'TCP' init failed.
Jul 26 11:50:56 west.lab.local err tmm3[28927]: 01010008:3: Proxy initialization failed for /Common/user107. Defaulting to DENY.
deepfried78Altostratus
AltostratusThanks, I think we solved this around the same time. My first problem was that I was mistakenly enabling TCP options in my client TCP profile, but using the SERVER_CONNECTED event. When I enabled TCP options in the server event (by just configuring the virtual server to use the same profile for the server), I stopped getting the error.
Here is the profile config:
ltm profile tcp tcp_opt {
app-service none
tcp-options "{28 first}"
Reading https://clouddocs.f5.com/api/irules/SERVER_CONNECTED.html I found that, for a standard profile, I'd find the options set in the first packet after the TCP 3-way handshake, but if I had used a fastL4 VIP, I would see it in the first syn, as you did.
I also noticed that Wireshark interpreted option 28 as "user timeout", and also see the odd length of "6", but when I converted the 6 hex numbers, I got "28" (the option number), "6" (the size), "192" (first octet of true source IP address), "168" (second octet), third octet, and fourth octet. It worked.