Forum Discussion

Alan_Sha's avatar
Alan_Sha
Icon for Nimbostratus rankNimbostratus
Sep 07, 2005

Unexpected TCL error from the return statement

When the "return" statement (without argument) is called within a USER_RESPONSE event, it will generate a TCL error in the Big IP system log, i.e.

 

 

Sep 7 14:31:07 tmm tmm[15951]: 01220001:3: TCL error: Rule split_connection_test -

 

 

I don't understand what exactly the error is. The log doesn't seem to give me anything meaningful. However, this error doesn't stop the execuation of the iRule or cause any other unexpected behavior. I am wondering whether this is a bug or my misuse of "return" statement. If it is a bug, should I open a support ticket?

 

 

Thx

4 Replies

  • unRuleY_95363's avatar
    unRuleY_95363
    Historic F5 Account
    I will look into it... Thanks. If I discover it is a bug, you won't need to open a support case as I'll directly make a CR for it.

     

     

    And to answer your question, using return should work just fine.

     

     

    However, I would like to see your complete rule to see if it is somehow something other than the return statement. Can you send it to me?

     

    Thanks!
  • Thanks for your reply!

     

     

    I changed my iRule and this time a different error occurred (also appear to be caused by the return statement). I am trying to get the "trace" and send that to you along with the iRule.
  • unRuleY_95363's avatar
    unRuleY_95363
    Historic F5 Account
    Man, that is one narly rule. I've been trying to determine if somehow the rule through the triggering of the USER_RESPONSE event is causing the problem.

     

     

    I just wanted to let you know, I'm still trying to figure it out in my spare time...

     

  • Thanks for your work on this!

     

     

    I have been trying to narrow down the pieces that might be causing the problem too. Somehow I am feeling that the problem is an outcome of some kind of "memory leak". As you can see from my "monster" iRule, there are codes that are modifying the TCP payload before it is sent to the desitination (e.g. insert 50 bytes to the beginning of the original payload before it is sent out.). I am not sure whether that might be causing the problem.