-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cnet-graph: do not forward TCP control packets to chnl_callback #390
cnet-graph: do not forward TCP control packets to chnl_callback #390
Conversation
CNET-Graph will send TCP control packets sometimes e.g. SYN, FIN, ACK, etc. We do not need to notify these packets. Instead, we only notify packets that has user data. For UDP, we notify all. Signed-off-by: Jalal Mostafa <[email protected]>
I am concerned if we restrict some TCP packets from going to the callback the TCP protocol will not be handled correctly by the Kernel stack. It is valid to have zero data TCP packets with flags like when closing or other reasons. The PR is also addressing a traffic generator or DOS attack use case. |
Hi @KeithWiles We need to cover the traffic generator/DOS use cases as you said as they usually have user data of size zero. |
Could you please run the 'graph dot` command and paste one of the text files here. I want to see the graph layout again. Still thinking about this change, but so far I think it maybe OK. |
digraph cndp_tcpecho_graph_1 {
rankdir=LD; bgcolor=mistyrose
label=<<font color='black'>Graph Name: </font><font color='blue' point-size='20'> <b>cndp_tcpecho_graph_1</b></font> <font color='black'><b>(pkt_drop removed)</b></font>>
edge [color=blue, arrowsize=0.6]
node [margin=0.1 fontcolor=black fontsize=16 width=0.8 shape=box color=black style="filled,rounded"]
{"eth_rx-0" [fillcolor=lavender]}->"ptype"
{"eth_tx-0" [fillcolor=cyan]}->"chnl_callback"
{"eth_rx-1" [fillcolor=lavender]}->"ptype"
{"eth_tx-1" [fillcolor=cyan]}->"chnl_callback"
{"ip4_input" [fillcolor=mediumspringgreen]}->{"ip4_forward" "ip4_proto"}
{"ip4_output" [fillcolor=mediumspringgreen]}->{"arp_request" "eth_tx-0" "eth_tx-1"}
{"ip4_forward" [fillcolor=mediumspringgreen]}->{"arp_request" "eth_tx-0" "eth_tx-1"}
{"ip4_proto" [fillcolor=mediumspringgreen]}->{"udp_input" "tcp_input"}
{"udp_input" [fillcolor=cornsilk]}->{"chnl_recv" "punt_kernel"}
{"udp_output" [fillcolor=cornsilk]}->"ip4_output"
{"tcp_input" [fillcolor=lightpink]}->{"chnl_recv" "punt_kernel"}
{"tcp_output" [fillcolor=lightpink]}->"ip4_output"
{"chnl_callback" [fillcolor=lightgrey]}
{"chnl_recv" [fillcolor=yellowgreen]}->"chnl_callback"
{"ptype" [fillcolor=goldenrod]}->{"punt_kernel" "punt_l2_kernel" "ip4_input" "gtpu_input"}
{"arp_request" [fillcolor=mediumspringgreen]}
{"punt_kernel" [fillcolor=coral]}
{"punt_l2_kernel" [fillcolor=coral]}
{"gtpu_input" [fillcolor=lightskyblue]}->"ip4_input"
} |
Thanks for the picture. I was thinking about the PSH and URG flag test, you can have PSH (I believe) without user data and seems like checking only the size is reasonable. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR
Thanks @KeithWiles ! |
CNET-Graph will send TCP control packets sometimes e.g. SYN, FIN, ACK, etc. We do not need to notify these packets. Instead, we only notify packets that have user data. For UDP, we notify all.
Let me know your comments how the decision to forward the packet to chnl_callback can be improved.
Right now I check data length. How about we check
PSH
orURG
flags? If they are set in the tcb, then the packet has user data and we forward tochnl_callback
. I am rethinking it because I am thinking of traffic generators that generate empty segments (where data len is zero), we may still need to get notifications inchnl_callback
for these.