[dhcp_relay] Set Broadcast flag for all test packets#1030
[dhcp_relay] Set Broadcast flag for all test packets#1030jleveque merged 2 commits intosonic-net:masterfrom
Conversation
|
We have not experienced failures with the current packet creation. Can you please paste output from a failed test run? |
As below is test failed log, BTW , I used sonic is 201811 branch, and testbed is master branch. What version do you test?
TASK [test : debug] ************************************************************ |
|
For the future, I suggest synchronizing the branches of your repos (e.g., if your image is built from the 201811 branch of sonic-buildimage, you should test it using the 201811 branch of sonic-mgmt). Nonetheless, I was able to reproduce this behavior using 201811 branches in both repos, but only when using an older image, not a newer image. Can you tell me what the commit ids of your sonic-buildimage and sonic-mgmt repos are? |
|
Thanks for your suggestion. According to my understanding about the work process of dhcp relay, If the “Broadcast Flag” value in the message is 0, the relay agent replaces the value with the IP address (Your IP field: 192.168.0.2) for unicasting. However, if the “Broadcast Flag” value is 1, the relay agent replaces it with the broadcast IP address (255.255.255.255) for broadcasting. right? |
|
Your understanding appears correct. If the client sets the "broadcast flag" to 1 in the DISCOVER packet, the relay agent should send the replies back as broadcasts, otherwise, the agent should send them back as unicast. Is your claim that the latest DHCP realay agent code is always sending broadcast, even if the broadcast flag isn't set? That's what it looks like to me, just wanted to confirm. |
|
Yes |
|
That sounds like a bug, but I'm not sure how any changes I made would have had this side effect. I'll have to look into it further. Can you provide me with the commit from the 201811 branch that you built the image that is failing the test? |
|
OK. So after some investigation, I found that with my recent changes to the relay agent, in order to support directed broadcasts, I switched the agent over to use linux sockets. The implementation of the agent when using sockets will never send replies back to the client unicast--even if the broadcast flag is not set--due to this function in socket.c: Therefore, this test should now only test with the broadcast flag set. Thus, your PR is the correct fix. However, for the sake of completeness, can you also set the broadcast bit when forming the DISCOVER and REQUEST packets? The full diff should look like this: |
Add set broadcast flags for Discover & Request
|
OK,I have modify it,Please check. Thank you! |


Description of PR
The expected offer& ack package is broadcast
But get the package is Unicast.
So,we need to set Broadcast flag for dhcp offer&ack,
Summary:
Fixes # (issue)
dhcp relay test failed because verified packet not correct.
Type of change
Approach
How did you do it?
Modify file dhcp_relay_test.py
Add “set_broadcast_bit=True” in create_dhcp_offer_packet and create_dhcp_ack_packet
Set “flags=0x8000” in create_dhcp_offer_relayed_packet and create_dhcp_ack_relayed_packet
How did you verify/test it?
testbed dhcp_relay test
PLAY RECAP *********************************************************************
cel-e1031-01 : ok=58 changed=10 unreachable=0 failed=0
Wednesday 24 July 2019 09:41:45 +0000 (0:00:00.033) 0:00:30.786 ********
TASK: test : command ---------------------------------------------------- 4.53s
TASK: test : gather system version information -------------------------- 2.49s
TASK: setup ------------------------------------------------------------- 1.72s
TASK: test : Copy tests to the PTF container ---------------------------- 1.67s
TASK: test : Get interface facts ---------------------------------------- 1.47s
TASK: test : Get interface facts ---------------------------------------- 1.43s
TASK: test : set_fact --------------------------------------------------- 1.28s
TASK: test : Get process information in syncd docker -------------------- 1.24s
TASK: test : Get process information in syncd docker -------------------- 1.11s
TASK: test : Verify port channel interfaces are up correctly ------------ 0.98s
TASK: test : validate all interfaces are up after test ------------------ 0.82s
TASK: test : Fetch result files from switch to ansible machine ---------- 0.65s
TASK: test : Verify port channel interfaces are up correctly ------------ 0.64s
TASK: test : Gather minigraph facts about the device -------------------- 0.64s
TASK: test : debug ------------------------------------------------------ 0.60s
TASK: test : Gather minigraph facts about the device -------------------- 0.58s
TASK: test : Gathering minigraph facts about the device ----------------- 0.57s
TASK: test : Get orchagent process information -------------------------- 0.52s
TASK: test : validate all interfaces are up ----------------------------- 0.49s
TASK: test : Get orchagent process information -------------------------- 0.49s
Any platform specific information?
cel_e1031&cel_seastone devices
Supported testbed topology if it's a new test case?
Documentation