Forum Discussion
Piotr_Lewandows
Apr 17, 2016Altostratus
CLIENT_ACCEPTED, SERVER_ACCEPTED and TCP::collect
Hi, That is probably obvious but I can't really figure out how TCP::collect is working depending on where it was enabled. When CLIENT_ACCEPTED is triggered it means three-way handshake was fi...
dragonflymr
Apr 18, 2016Cirrostratus
Hi,
I was thinking about this a bit and I wonder if I am on the right track:
- First of all I assume that both CLIENT_ACCEPTED and SERVER_CONNECTED events are active only when first packet after 3WHS arrives. After processing this packet events are no more active - correct?
- Second - it is not important if this first packet is coming from client to pool member or from pool member to client (for both clientside and serverside). As in above example first packet processed will be from pool member (SMTP server) to client - correct?
- To collect more packets than first one it's necessary to place TCP::release, then TCP::collect in CLIENT_DATA or SERVER_DATA, so first processed packet is released to client or pool member and next packet will be collected - correct?
Now starts part in the example code I do not understand. Assuming that starttls transaction looks like below (based on Wikipedia):
- S:
- C:
- S: 220 mail.example.org ESMTP service ready
- C: EHLO client.example.org
- S: 250-mail.example.org offers a warm hug of welcome
- S: 250 STARTTLS
- C: STARTTLS
- S: 220 Go ahead
- C:
- C & S:
- C & S:
- C: EHLO client.example.org[3]
My interpretation (starting from point 2):
- 3WHS finished on clientside, CLIENT_ACCEPTED triggered. No data from the client but 3WHS on serverside performed as well (assuming Standard VS with just TCP profile). TCP::collect started on serverside
-
Pool member (SMTP server) sends 220... SERVER_DATA triggered. $ehlo is 0, TCP::pyload do not contain "starttls"
- Packet released to client - because TCP::collect not jet started it's delivered to client without being captured by TCP::collect (not jet active on clientside) - is that correct?
- TCP::collect enabled on clientside - so next packet from client to VIP will be placed in the buffer
-
Client sends EHLO...
- CLIENT_DATA triggered
- $ehlo set to 1
- Collect on serverside enabled
- Packet released to serverside - will this packet be captured, or only next one. I assume this packet will be collected - correct?
- Collection on the clientside resumed for next packet
- Seems that 250-mail.example.org... is skipped here?
-
SERVER_DATA is triggered again:
- if returns true - $ehlo = 1, no starttls in payload
- No I am lost - from Wikipedia example it's pool member that should send "250 STARTTLS" but it seems that we are replacing content of the packet going from client to pool member "TCP::payload replace 0 0 "250-STARTTLS\r\n"" - or I am totally wrong here?
- Modified packet is released to the pool member
- Again collection on the clientside is enabled
-
Assuming that for some reason I am wrong here, previous packet is send to the client not pool member, so client is now replying with "starttls"
- CLIENT_DATA triggered again
- Now elseif is true so TCP::respond is send to the client with "220 Ready to..."
- Payload of the packet going to pool member is emptied
- Packet is released
- SSL on VS is re enabled
- There is no more TCP::collect for serverside so packet is delivered directly to pool member - no SERVER_DATA triggered
- Client is starting SSL handshake with VS, after finishing following data packets (decrypted) are delivered to pool member without further processing by iRule.
I think I am pretty close to the truth here but still have filling that I am missing something :-(
Piotr
Recent Discussions
Related Content
DevCentral Quicklinks
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
Discover DevCentral Connects