Hi Murphy, <div><br></div><div><br></div><div>Thanks for your replying, and now I use wildcard the nw_tos field to avoid the flow match problem.</div><div><br></div><div>But I want to ask why during the connection between OpenFlow switch and POX controller, POX command line usually dump some information like below:</div>
<div><br></div><div>[packet                 ] (dhcp parse) warning DHCP packet data too short to parse header: data len 86</div><div><br></div><div>Is this invoke by the arp broadcast or the other problems?</div><div><br>
</div><div>Thanks again.</div><div><br><br><div class="gmail_quote">2013/5/15 Murphy McCauley <span dir="ltr"><<a href="mailto:murphy.mccauley@gmail.com" target="_blank">murphy.mccauley@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On May 15, 2013, at 2:14 AM, chenli wrote:<br>
<br>
> I did some test again, and it's so strange that the back flow for ssh connection needs the field of nw_tos=16.<br>
<br>
</div>I don't think this is strange.  I believe 16 is the TOS value for minimize delay, which makes sense for ssh, since it's interactive.  The server is likely setting it on purpose.<br>
<div class="im"><br>
> If the field for nw_tos equals to 0, the flow can't match correctly. Just like below<br>
<br>
</div>I'm not clear why this a problem.  If its really troublesome for some reason, you could always wildcard it...<br>
<div class="im"><br>
> And how can I find the flow_mods that correspond to these flows in POX?<br>
<br>
</div>That depends on what application you're running in POX.  If you're using l2_learning, for example, it's wherever the flow_mod is in there.  l2_learning uses ofp_match.from_packet() to create a flow which exactly matches the packet it's given.  This includes the TOS field.  You could just insert a match.nw_tos = None to wildcard it...<br>

<span class="HOEnZb"><font color="#888888"><br>
<br>
-- Murphy</font></span></blockquote></div><br></div>