Streaming IS Shai Shabat Feb 2014 OSI Layers
Description: Streaming IS Shai Shabat Feb 2014 OSI Layers Introduction Data Application Network Process to Application Data Presentation Data Representation and Encryption Data Session Inter-host Communication Segments Transport End-to-End Connections
Related Topics
Download Presentation
"Streaming IS Shai Shabat Feb 2014 OSI Layers" is the property of its rightful owner. Permission is granted to download and print the materials on this website for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Presentation Transcript
slide1. Streaming IS Shai Shabat
Feb 2014<br>
slide2. OSI Layers Introduction Data Application
Network Process to
Application Data Presentation
Data Representation
and Encryption Data Session
Inter-host Communication Segments Transport
End-to-End Connections
and Reliability Packets Network
Path Determination
And IP (Logical Addressing) Frames Data Link
MAC and LLC
(Physical addressing) Bits Physical
Media, Signal, and
Binary Transmission OSI Model Applications SSL Streaming
(Active/
Passive) Firewall
(Attachment/
Chain modules)<br>
slide3. Streaming background Connect between the firewall and the application.
Assemble frames / packets into data.
Handle retransmissions
Handle re-ordering
Handle protocol related attacks.<br>
slide4. Streaming mechanism PSL – Passive Streaming Layer passive streaming follow the streaming requests without interfering with the connection. (there are some exceptions: hold, injection, replace data).
CPAS – Check Point Active Streaming active streaming allow the changing of data, we play the role of “man in the middle”.<br>
slide5. Streaming Applications<br>
slide6. Passive inspection traffic flow Gateway Stateful
Inspection S SA A Client Server<br>
slide7. PSL Passive Streaming Layer<br>
slide8. Passive Streaming – General overview PSL maintain the connection as it is, it allow the security application to examine the connection without interfere with the connection itself.
When a packet arrive to the gateway, PSL send the packet to the security application for examination, the application will return drop, accept or continue examining the connection.
Because PSL is taking care of any retransmissions and/or out-of-order packets, the security application to will examine each packet only once, and in the correct order.<br>
slide9. Passive Streaming – General overview PSL provides TCP stream protection, for example:
Retransmission with different data.
TCP connection without a proper handshake.
Future ACK
Etc.
PSL allows to hold the connection by manipulating the retransmission mechanism.
PSL allow sending segment injection (changing the packet) but only if this follow the closing of the connection. – this is the only change PSL allows to send.<br>
slide10. Passive Streaming Passive Streaming does a non-intrusive TCP Streaming for a given connection.
Passive Streaming goes over all the TCP/IP packets in a single connection and builds a stream according to the TCP sequences.
If the segments are not ordered, a re-ordering will be done automatically by using a queue inside the Passive Streaming engine.
Old packets are stored in the queue for security validation. This is used to validate retransmissions of already validated segments.
For example - A hacker can attempt to send malicious data after it has been validated by the AI Application. A sophisticated attack can be sending valid segments with low TTL which will make sure it will pass the GW but will be dropped/not-received by the server. Then, the segments will be “retransmitted”, this time with malicious data and they won’t be inspected again by the GW’s streaming applications (because they inspect every segment in order and only once).<br>
slide11. Passive Streaming Incoming
Packets Passive
Queue 1 Application
Inspection 1 2 Outgoing
Packets 1 2 3 It’s important that before any part of the stream reaches the client/server application it is first inspected by the AI security applications.<br>
slide12. Segment Injection (a.k.a. Send Error Page) PSL allow the application to terminate a connection with an error page, this allow the client to get a feedback as to why the connection was close.
There are two ways to send segment injection:
Server timeout injection – the injection will be sent after the server reach a timeout, this allow us to prevent a state where the injection is combine with some data from the server and this create an attack.
Partial segment injection – we allow to send the injection without the server timeout, the application itself need to allow this.<br>
slide13. Segment Injection Flow Normal TCP
Flow Security
violation Half-Close Inject
Error Page Server Idle
timeout End client
connection Client Idle
timeout Re-Transmission Pass All S2C traffic (wait for timeout).
Strip ACK replies from C2S traffic. Normal TCP inspection Inject error page to client.
Send Reset to server.
Wait for ACK replies from C2S traffic. End connection gracefully (send FIN).<br>
slide14. PSL hold PSL hold API is used by application in order to hold TCP stream
The implementation exploits TCP retransmission mechanism – the held packet and the following retransmissions are stripped, this will cause the server to wait for retransmission of this packet.
Pros: holding the stream with minimal interference in TCP traffic and with minimum memory consumption.
Cons: the hold time is limited and it depends on specific implementation of TCP stack<br>
slide15. PSL gradual hold Enhancement of PSL hold mechanism which improves hold time
In addition to stripping the packet, before reaching the timeout (4 retransmissions) we will send one byte of data and start the process all over again.
Pros: longer hold time then the regular hold
Cons: depends on specific implementation of TCP stack and target application (application timeout, reconstruction using the partial data)<br>
slide16. TCP Streaming – debugs To enable PSL debugs – fw ctl zdebug + tcpstr
PSL does not stat what application requested a drop, instead it stat what parser requested it, this because PSL does not know all the application, it transfer the application to the parser (like WS) and he transfer it to the application.
“psl_process_list: processing astream ffffc2005b93aaf0, packet ffffc20040b82030, seq 1233369950, offset 0, fus 1233369950” “psl_process_data: packet_data=ffffc20040b820e4, packet_data_len=1448;” “psl_process_data: calling data processing function app 9[ASPII_MT];” “psl_process_data: processing function for app 9[ASPII_MT] returned OK_CONTINUE” this debug tell us that when we started and when we are done with PSL examination of the packet and now we send the packet to the applications for testing, we sent it to parser ASPII_MT, and he return continue.
Astream represent the entire connection, all packet from the same connection will have the same astream pointer.<br>
slide17. CPAS Check Point Active Streaming<br>
slide18. Active Streaming High-level Introduction Security Application
Inspection Client TCP Stack Server TCP Stack Connection
termination SYN SYN
ACK ACK SYN SYN
ACK ACK data ack data ack Client Active
Streaming Server CPAS (connection table) CPAS 3rd party (connection table) Client server Client GW
GW server<br>
slide19. Active Streaming – General overview CPAS breaks the connection into two parts using our own stack – this mean, we are responsible for all the stack work (dealing with options, retransmissions, timers etc.)
An application is register to CPAS when a connection start and supply callbacks for event handler and read handler.
On each packet, CPAS send the application the packet data (with cpas_read), allow the application to change the data as it like, and send the data forward (with cpas_write)<br>
slide20. CPAS Connection diagram Client Server Client->
Server’ Client’->
Server Application
Inspection (Client) Application
Inspection (Server) Applications interact with CPAS using the following functions:
cpas_pass_data – which passes data between hconns (half-conn)
cpas_write – which writes data onto the TCP stream
cpas_skip – which skips the next x bytes Server HCONN Client HCONN<br>
slide21. Active Streaming – step by step Application register for CPAS – the application give callbacks functions for CPAS.
Client send SYN, CPAS send the packet to the application to decide if it want to work on this connection or not – If not, packet will continue as if no CPAS.
CPAS register the connection internally and produce SYN-ACK packet to the client.
Once the ACK from the Client is received CPAS will open a connection with the Server side.
For each packet arrive (for either side), CPAS will send the packet to the application, drop the original and replay with an ACK. If the application want it can pass the packet to the other side (server/client).<br>
slide22. CPAS connection flow Upon receiving a connection from a client to some server, the FW answers the client as if it were the server itself.
The client, unaware of this, communicates as it would normally with the FW.
The FW in turn (upon CPAS user’s request), connects to the server as if it were the client, and passes the information from the client to the server and vice versa.
This “passing of data” is, inspected and manipulated as needed.<br>
slide23. Active Streaming – chain module CPAS have two entry point in the firewall, one on the inbound and one on the outbound.
CPAS is the last chain module in the inbound – this because CPAS drops the original packet to prevent it from passing to the other side of the connection.
CPAS is the first chain module in the outbound – this is because CPAS creates the packet and send it to the other side of the connection, in order for all the chain modules to see the new packet we need CPAS to be first.
CPAS have another chain entry called CPAS VM – this is for packets that are meant for the gateway itself.<br>
slide24. Active Streaming – tables cpas_cookie_hash_tab_id – store for each packet that CPAS send its cookie hash (help identify packet that was sent by CPAS or sent by the client/server).
CPTLS_SERVER_CN_CACHE_TABLE_ID – SSL server connection.
pop3d_clients_id – hold all the pop3 connections.
cpas_pmtu_table_id – hold the mss value for connection
cpas_pending_kbuf_db_tab_id – register all the pending kbuf<br>
slide25. Active Streaming – IPV6 The different between IPV6 and IPV4 is hidden from the application, the application receive the data buffer and send it back (with or without changes), CPAS will build the packet according to the IP version we are in.<br>
slide26. Active Streaming – SecureXL As for now, CPAS doesn't support accelerated traffic, this mean that each CPAS packet will be F2F.
Since all the packet will pass SecureXL do_outbound (even if they were F2F) we need to offload the connection to SecureXL.
The offload is done on the outbound, without CPAS, the offload will occur when the SYN packet leave to the server, because CPAS break the connection, the first outbound will occur on the SYN-ACK that is sent to the Client.<br>
slide27. Active Streaming – https With PSL, connection that is encrypted with SSL (TLS) was not supported, the reason for this is that the encryption keys are known only to the Client and Server since they are the one that initiated the connection (preformed the SSL handshake), because of this we couldn’t get the data out of the packet and the application couldn’t scan it for malicious information.
CPAS plays the rule of “man in the middle”, because of this, it can intercept the SSL handshake and change the keys so he will be able to understand the encryption.
The Client preform an SSL handshake with the gateway (thinking it is the Server) while the Server preform SSL handshake with the gateway (thinking he is the Client). The gateway have both keys and he’s able to open the encryption, check the packet and re-encrypt the packet with the corresponding keys.<br>
slide28. Active Streaming – https cont. In order to encrypt / decrypt the SSL connection, CPAS add another layer before the application queue.
The new layer will send the packet to the SSL engine for decryption/encryption and then resume the normal flow.
When the CPTLS engine load he register an hook with CPAS for each side that have SSL enable.<br>
slide29. Active Streaming – https cont. step by step Packets of SSL handshake are passed to the SSL engine to exchange keys.
When the connection and the SSL handshake is fully established, an hook will be register for this connection to handle the decrypt / encrypt of the packets.
When a packet arrive to CPAS, a trap will be sent and the SSL engine will receive the encrypted packet, decode the packet and return it to CPAS.
The packet will enter the receive queue and the application will be able to work on it, once he done he will send it to the write queue.
The packet will pass to the SSL engine for encryption and pass to the other side (Client, Server).<br>
slide30. CPAS Hook API Architecture RX CPAS HCONN Application Hook RX TX HCONN TX Legend: CPAS App API CPAS Hook API TCP Queue Application Queue Hook Client Server Hook Queue Hook Queue Hook Queue Hook Queue App Queue App Queue App Queue App Queue<br>
slide31. Active Streaming – clusterXL CPAS does not synchronize connection between cluster members. If a failover occur and the connection was handled by CPAS then the connection will terminate. This is done because syncing the CPAS information will be to much data to sync (we will have to sync all the stack information in addition to CPAS internal information).
The only exception is VOIP connection.
When a connection start, CPAS will check if it needs to sync the connection (if we are in HA and VOIP connection), if so it will sync the connection information so the other member will be able to resume in case of fail over. We can sync the VOIP connection because it’s a lite connection that doesn't keep much information on the stack.<br>
slide32. Active Streaming – debugs To enable CPAS debugs – fw ctl zdebug –m CPAS + <flag>
CPAS flags: error, warning, tcp, api, glue, events, conns, pkts, timer, tcpinfo, http, ftp, skinny, notify, sync, icmp. Flags meaning (the important ones) : tcp – information regarding the tcp_input and tcp_output function (the function that in-charge of sending and receiving packets) . Events – information regarding events (closing connection, timeout, established etc.). Timer – information regarding the timers. CPAS timers are in-charge of retransmissions, keep alive, and background handling of the TCP stack. Tcpinfo – information regarding the connection – this debug print for each packet the entire PCB struct, this struct contain all the connection information (state, rtt, mss etc.) pkt – information regarding the packet (split, alloc, send, chop, etc.)<br>
slide33. Active Streaming – debugs cont. When first handling a environment with CPAS enable, make sure that CPAS is really enable, the easy way to do it is with: fw ctl zdebug –m CPAS + tcp if a packet is passed and CPAS is working on it we will see the information.
If CPAS is enable on a connection and another application is trying to work on this connection with PSL, PSL will turn into detect mode – no injection will be made to this connection by PSL.
All CPAS drops will be visible in “fw ctl zdebug + drop” except the regular drops CPAS does for each packet (after it done working with it and send the response).
If there is a problem with the TCP structure then you need to turn on the “fw ctl zdebug –m CPAS + tcp” debug, this will give you all the information about the tcp building.<br>
slide34. Active Streaming – debugs cont. - tcpinfo<br>
slide35. Active Streaming – debugs cont. When the environment is full with connections, you can identify a single connection you want (both client side and server side) by adding the tcpinfo flag, finding the problematic debug, go to the tcpinfo related to this CPU and find the pcb pointer search for the pointer in the debug and you will find the information you need.
The tcpinfo (pcb dump) is called every time a packet arrive to tcp_input or tcp_output function (send or receive).<br>
slide36. Questions?<br>
Feb 2014<br>
slide2. OSI Layers Introduction Data Application
Network Process to
Application Data Presentation
Data Representation
and Encryption Data Session
Inter-host Communication Segments Transport
End-to-End Connections
and Reliability Packets Network
Path Determination
And IP (Logical Addressing) Frames Data Link
MAC and LLC
(Physical addressing) Bits Physical
Media, Signal, and
Binary Transmission OSI Model Applications SSL Streaming
(Active/
Passive) Firewall
(Attachment/
Chain modules)<br>
slide3. Streaming background Connect between the firewall and the application.
Assemble frames / packets into data.
Handle retransmissions
Handle re-ordering
Handle protocol related attacks.<br>
slide4. Streaming mechanism PSL – Passive Streaming Layer passive streaming follow the streaming requests without interfering with the connection. (there are some exceptions: hold, injection, replace data).
CPAS – Check Point Active Streaming active streaming allow the changing of data, we play the role of “man in the middle”.<br>
slide5. Streaming Applications<br>
slide6. Passive inspection traffic flow Gateway Stateful
Inspection S SA A Client Server<br>
slide7. PSL Passive Streaming Layer<br>
slide8. Passive Streaming – General overview PSL maintain the connection as it is, it allow the security application to examine the connection without interfere with the connection itself.
When a packet arrive to the gateway, PSL send the packet to the security application for examination, the application will return drop, accept or continue examining the connection.
Because PSL is taking care of any retransmissions and/or out-of-order packets, the security application to will examine each packet only once, and in the correct order.<br>
slide9. Passive Streaming – General overview PSL provides TCP stream protection, for example:
Retransmission with different data.
TCP connection without a proper handshake.
Future ACK
Etc.
PSL allows to hold the connection by manipulating the retransmission mechanism.
PSL allow sending segment injection (changing the packet) but only if this follow the closing of the connection. – this is the only change PSL allows to send.<br>
slide10. Passive Streaming Passive Streaming does a non-intrusive TCP Streaming for a given connection.
Passive Streaming goes over all the TCP/IP packets in a single connection and builds a stream according to the TCP sequences.
If the segments are not ordered, a re-ordering will be done automatically by using a queue inside the Passive Streaming engine.
Old packets are stored in the queue for security validation. This is used to validate retransmissions of already validated segments.
For example - A hacker can attempt to send malicious data after it has been validated by the AI Application. A sophisticated attack can be sending valid segments with low TTL which will make sure it will pass the GW but will be dropped/not-received by the server. Then, the segments will be “retransmitted”, this time with malicious data and they won’t be inspected again by the GW’s streaming applications (because they inspect every segment in order and only once).<br>
slide11. Passive Streaming Incoming
Packets Passive
Queue 1 Application
Inspection 1 2 Outgoing
Packets 1 2 3 It’s important that before any part of the stream reaches the client/server application it is first inspected by the AI security applications.<br>
slide12. Segment Injection (a.k.a. Send Error Page) PSL allow the application to terminate a connection with an error page, this allow the client to get a feedback as to why the connection was close.
There are two ways to send segment injection:
Server timeout injection – the injection will be sent after the server reach a timeout, this allow us to prevent a state where the injection is combine with some data from the server and this create an attack.
Partial segment injection – we allow to send the injection without the server timeout, the application itself need to allow this.<br>
slide13. Segment Injection Flow Normal TCP
Flow Security
violation Half-Close Inject
Error Page Server Idle
timeout End client
connection Client Idle
timeout Re-Transmission Pass All S2C traffic (wait for timeout).
Strip ACK replies from C2S traffic. Normal TCP inspection Inject error page to client.
Send Reset to server.
Wait for ACK replies from C2S traffic. End connection gracefully (send FIN).<br>
slide14. PSL hold PSL hold API is used by application in order to hold TCP stream
The implementation exploits TCP retransmission mechanism – the held packet and the following retransmissions are stripped, this will cause the server to wait for retransmission of this packet.
Pros: holding the stream with minimal interference in TCP traffic and with minimum memory consumption.
Cons: the hold time is limited and it depends on specific implementation of TCP stack<br>
slide15. PSL gradual hold Enhancement of PSL hold mechanism which improves hold time
In addition to stripping the packet, before reaching the timeout (4 retransmissions) we will send one byte of data and start the process all over again.
Pros: longer hold time then the regular hold
Cons: depends on specific implementation of TCP stack and target application (application timeout, reconstruction using the partial data)<br>
slide16. TCP Streaming – debugs To enable PSL debugs – fw ctl zdebug + tcpstr
PSL does not stat what application requested a drop, instead it stat what parser requested it, this because PSL does not know all the application, it transfer the application to the parser (like WS) and he transfer it to the application.
“psl_process_list: processing astream ffffc2005b93aaf0, packet ffffc20040b82030, seq 1233369950, offset 0, fus 1233369950” “psl_process_data: packet_data=ffffc20040b820e4, packet_data_len=1448;” “psl_process_data: calling data processing function app 9[ASPII_MT];” “psl_process_data: processing function for app 9[ASPII_MT] returned OK_CONTINUE” this debug tell us that when we started and when we are done with PSL examination of the packet and now we send the packet to the applications for testing, we sent it to parser ASPII_MT, and he return continue.
Astream represent the entire connection, all packet from the same connection will have the same astream pointer.<br>
slide17. CPAS Check Point Active Streaming<br>
slide18. Active Streaming High-level Introduction Security Application
Inspection Client TCP Stack Server TCP Stack Connection
termination SYN SYN
ACK ACK SYN SYN
ACK ACK data ack data ack Client Active
Streaming Server CPAS (connection table) CPAS 3rd party (connection table) Client server Client GW
GW server<br>
slide19. Active Streaming – General overview CPAS breaks the connection into two parts using our own stack – this mean, we are responsible for all the stack work (dealing with options, retransmissions, timers etc.)
An application is register to CPAS when a connection start and supply callbacks for event handler and read handler.
On each packet, CPAS send the application the packet data (with cpas_read), allow the application to change the data as it like, and send the data forward (with cpas_write)<br>
slide20. CPAS Connection diagram Client Server Client->
Server’ Client’->
Server Application
Inspection (Client) Application
Inspection (Server) Applications interact with CPAS using the following functions:
cpas_pass_data – which passes data between hconns (half-conn)
cpas_write – which writes data onto the TCP stream
cpas_skip – which skips the next x bytes Server HCONN Client HCONN<br>
slide21. Active Streaming – step by step Application register for CPAS – the application give callbacks functions for CPAS.
Client send SYN, CPAS send the packet to the application to decide if it want to work on this connection or not – If not, packet will continue as if no CPAS.
CPAS register the connection internally and produce SYN-ACK packet to the client.
Once the ACK from the Client is received CPAS will open a connection with the Server side.
For each packet arrive (for either side), CPAS will send the packet to the application, drop the original and replay with an ACK. If the application want it can pass the packet to the other side (server/client).<br>
slide22. CPAS connection flow Upon receiving a connection from a client to some server, the FW answers the client as if it were the server itself.
The client, unaware of this, communicates as it would normally with the FW.
The FW in turn (upon CPAS user’s request), connects to the server as if it were the client, and passes the information from the client to the server and vice versa.
This “passing of data” is, inspected and manipulated as needed.<br>
slide23. Active Streaming – chain module CPAS have two entry point in the firewall, one on the inbound and one on the outbound.
CPAS is the last chain module in the inbound – this because CPAS drops the original packet to prevent it from passing to the other side of the connection.
CPAS is the first chain module in the outbound – this is because CPAS creates the packet and send it to the other side of the connection, in order for all the chain modules to see the new packet we need CPAS to be first.
CPAS have another chain entry called CPAS VM – this is for packets that are meant for the gateway itself.<br>
slide24. Active Streaming – tables cpas_cookie_hash_tab_id – store for each packet that CPAS send its cookie hash (help identify packet that was sent by CPAS or sent by the client/server).
CPTLS_SERVER_CN_CACHE_TABLE_ID – SSL server connection.
pop3d_clients_id – hold all the pop3 connections.
cpas_pmtu_table_id – hold the mss value for connection
cpas_pending_kbuf_db_tab_id – register all the pending kbuf<br>
slide25. Active Streaming – IPV6 The different between IPV6 and IPV4 is hidden from the application, the application receive the data buffer and send it back (with or without changes), CPAS will build the packet according to the IP version we are in.<br>
slide26. Active Streaming – SecureXL As for now, CPAS doesn't support accelerated traffic, this mean that each CPAS packet will be F2F.
Since all the packet will pass SecureXL do_outbound (even if they were F2F) we need to offload the connection to SecureXL.
The offload is done on the outbound, without CPAS, the offload will occur when the SYN packet leave to the server, because CPAS break the connection, the first outbound will occur on the SYN-ACK that is sent to the Client.<br>
slide27. Active Streaming – https With PSL, connection that is encrypted with SSL (TLS) was not supported, the reason for this is that the encryption keys are known only to the Client and Server since they are the one that initiated the connection (preformed the SSL handshake), because of this we couldn’t get the data out of the packet and the application couldn’t scan it for malicious information.
CPAS plays the rule of “man in the middle”, because of this, it can intercept the SSL handshake and change the keys so he will be able to understand the encryption.
The Client preform an SSL handshake with the gateway (thinking it is the Server) while the Server preform SSL handshake with the gateway (thinking he is the Client). The gateway have both keys and he’s able to open the encryption, check the packet and re-encrypt the packet with the corresponding keys.<br>
slide28. Active Streaming – https cont. In order to encrypt / decrypt the SSL connection, CPAS add another layer before the application queue.
The new layer will send the packet to the SSL engine for decryption/encryption and then resume the normal flow.
When the CPTLS engine load he register an hook with CPAS for each side that have SSL enable.<br>
slide29. Active Streaming – https cont. step by step Packets of SSL handshake are passed to the SSL engine to exchange keys.
When the connection and the SSL handshake is fully established, an hook will be register for this connection to handle the decrypt / encrypt of the packets.
When a packet arrive to CPAS, a trap will be sent and the SSL engine will receive the encrypted packet, decode the packet and return it to CPAS.
The packet will enter the receive queue and the application will be able to work on it, once he done he will send it to the write queue.
The packet will pass to the SSL engine for encryption and pass to the other side (Client, Server).<br>
slide30. CPAS Hook API Architecture RX CPAS HCONN Application Hook RX TX HCONN TX Legend: CPAS App API CPAS Hook API TCP Queue Application Queue Hook Client Server Hook Queue Hook Queue Hook Queue Hook Queue App Queue App Queue App Queue App Queue<br>
slide31. Active Streaming – clusterXL CPAS does not synchronize connection between cluster members. If a failover occur and the connection was handled by CPAS then the connection will terminate. This is done because syncing the CPAS information will be to much data to sync (we will have to sync all the stack information in addition to CPAS internal information).
The only exception is VOIP connection.
When a connection start, CPAS will check if it needs to sync the connection (if we are in HA and VOIP connection), if so it will sync the connection information so the other member will be able to resume in case of fail over. We can sync the VOIP connection because it’s a lite connection that doesn't keep much information on the stack.<br>
slide32. Active Streaming – debugs To enable CPAS debugs – fw ctl zdebug –m CPAS + <flag>
CPAS flags: error, warning, tcp, api, glue, events, conns, pkts, timer, tcpinfo, http, ftp, skinny, notify, sync, icmp. Flags meaning (the important ones) : tcp – information regarding the tcp_input and tcp_output function (the function that in-charge of sending and receiving packets) . Events – information regarding events (closing connection, timeout, established etc.). Timer – information regarding the timers. CPAS timers are in-charge of retransmissions, keep alive, and background handling of the TCP stack. Tcpinfo – information regarding the connection – this debug print for each packet the entire PCB struct, this struct contain all the connection information (state, rtt, mss etc.) pkt – information regarding the packet (split, alloc, send, chop, etc.)<br>
slide33. Active Streaming – debugs cont. When first handling a environment with CPAS enable, make sure that CPAS is really enable, the easy way to do it is with: fw ctl zdebug –m CPAS + tcp if a packet is passed and CPAS is working on it we will see the information.
If CPAS is enable on a connection and another application is trying to work on this connection with PSL, PSL will turn into detect mode – no injection will be made to this connection by PSL.
All CPAS drops will be visible in “fw ctl zdebug + drop” except the regular drops CPAS does for each packet (after it done working with it and send the response).
If there is a problem with the TCP structure then you need to turn on the “fw ctl zdebug –m CPAS + tcp” debug, this will give you all the information about the tcp building.<br>
slide34. Active Streaming – debugs cont. - tcpinfo<br>
slide35. Active Streaming – debugs cont. When the environment is full with connections, you can identify a single connection you want (both client side and server side) by adding the tcpinfo flag, finding the problematic debug, go to the tcpinfo related to this CPU and find the pcb pointer search for the pointer in the debug and you will find the information you need.
The tcpinfo (pcb dump) is called every time a packet arrive to tcp_input or tcp_output function (send or receive).<br>
slide36. Questions?<br>