Forum Discussion

Parke_Cummins_1's avatar
Parke_Cummins_1
Icon for Nimbostratus rankNimbostratus
Apr 28, 2010

where's the tcp payload?

I don't get it. Why can't I log tcp payload when the following irules are defined?

 

 

when CLIENT_ACCEPTED {

 

log local0. "client accepted from [IP::client_addr] on port [TCP::client_port]."

 

TCP::collect

 

}

 

when SERVER_CONNECTED {

 

log local0. "Server [IP::server_addr] connected on port [TCP::server_port]."

 

TCP::collect

 

}

 

when CLIENT_DATA {

 

set encodingSystem [encoding system]

 

log local0. "encoding is $encodingSystem. "

 

log local0. "encoding is [encoding system]. "

 

 

set paylen [TCP::payload length]

 

set payload [TCP::payload]

 

set clientPort [TCP::client_port]

 

set clientAddress [IP::client_addr]

 

log local0. "TCP (length)payload from ($clientAddress:$clientPort) = ($paylen)$payload"

 

set payload [UDP::payload]

 

log local0. "UDP payload: $payload"

 

TCP::release

 

TCP::collect

 

}

 

when LB_SELECTED {

 

set paylen [TCP::payload length]

 

set payload [TCP::payload]

 

set lbServer [LB::server addr]

 

log local0. "Selected $lbServer. TCP (length)payload is ($paylen)$payload"

 

STREAM::disable

 

set server={LB::server name}

 

STREAM::expression {@POOL1 @I @}

 

STREAM::enable

 

TCP::release

 

TCP::collect

 

}

 

This section only logs matches, and should be removed before using the rule in production.

 

when STREAM_MATCHED {

 

log local0. "Matched: [STREAM::match]"

 

TCP::release

 

TCP::collect

 

}

 

 

These are the only log entries that are generated (sorted in descending time sequence).

 

 

Wed Apr 28 04:43:57 EDT 2010 info local/tmm tmm[5293] Rule replaceVirtualHostName : Selected 10.99.12.223. TCP (length)payload is (0)

 

Wed Apr 28 04:42:57 EDT 2010 info local/tmm tmm[5293] Rule replaceVirtualHostName : client accepted from 10.99.12.40 on port 3485.

 

 

I can't even get irules to fire for the client_data event. Ultimately, i need to intercept and replace a string in the client request after a pooled server is selected and before it is sent to the server. For now, i just want to see the payload to confirm the expected standard conversation.

 

 

Secondly, why does an entire minute expire before the lb_selected event is fired? Is that because i am using the virtual edition?

 

 

I am a novice at this, and so i am hoping someone can tell me that i am doing something basically stupid!

 

 

Thanks,

 

 

Parke Cummins

 

3 Replies

  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    I've had a quick look using vLTM. And the CLIENT_DATA event fires just fine... When I test from the command line... And assuming there's an EOL sent...

     

     

    If your data is purely binary though, I think the problem you're running into is the lack of parameter to the TCP::collect command. The VS will be sitting there waiting for more data, because you haven't told it how much to collect before firing the CLIENT_DATA event.

     

     

    That'll also be the reason I think that the LB_SELECTED is taking 60 seconds to fire... You're having to hit a timeout before the process proceeds...

     

     

    H
  • Sorry for the delay in reading your response. thanks for that input. I did try specifying a byte count with the tcp:collect at some point, but i don't remember the state of the surrounding iRules; so i think there's merit in trying your suggestion again without changing much else. I'll repost with results.

     

     

    Thanks,

     

    parke
  • unRuleY_95363's avatar
    unRuleY_95363
    Historic F5 Account
    Once you call TCP::release (which you are doing initially in the CLIENT_DATA event), the data is released from TCP and no longer available via the TCP::payload command unless new data has arrived and the CLIENT_DATA event has not had a chance to trigger yet (eg: you are evaluating the LB_SELECTED).

     

     

    I'm very curious why you want to access the TCP payload from the LB_SELECTED event in the first place... In the sample you posted, you do have the data saved off in a variable.

     

     

    I am looking into the best way to release just the held connection initiation but continue to hold any data (which is what I think you are wanting).