summaryrefslogtreecommitdiffstats
path: root/src/vpp-api/vom/dhcp_config.cpp
AgeCommit message (Collapse)AuthorFilesLines
2018-04-27Move VOM to extras/vomDamjan Marion1-194/+0
Change-Id: Iea174f03dfba3bd06024db0f0cc373532300dcae Signed-off-by: Damjan Marion <damarion@cisco.com>
2018-04-12Fixes for 'make UNATTENDED=yes CC=clang CXX=clang verify'Neale Ranns1-2/+3
Change-Id: I994649761fe2e66e12ae0e49a84fb1d0a966ddfb Signed-off-by: Neale Ranns <nranns@cisco.com>
2018-01-23For DHCP client configuration control the setting of the broadcast flag in theNeale Ranns1-2/+8
DISCOVER message sent. According to RFC2131: In the case of a client using DHCP for initial configuration (before the client's TCP/IP software has been completely configured), DHCP requires creative use of the client's TCP/IP software and liberal interpretation of RFC 1122. The TCP/IP software SHOULD accept and forward to the IP layer any IP packets delivered to the client's hardware address before the IP address is configured; DHCP servers and BOOTP relay agents may not be able to deliver DHCP messages to clients that cannot accept hardware unicast datagrams before the TCP/IP software is configured. To work around some clients that cannot accept IP unicast datagrams before the TCP/IP software is configured as discussed in the previous paragraph, DHCP uses the 'flags' field [21]. The leftmost bit is defined as the BROADCAST (B) flag. The semantics of this flag are discussed in section 4.1 of this document. The remaining bits of the flags field are reserved for future use. They MUST be set to zero by clients and ignored by servers and relay agents. Figure 2 gives the format of the 'flags' field. this changes means VPP conforms to the: "SHOULD accept and forward to the IP layer any IP packets delivered to the client's hardware address before the IP address is configured" with the caveat that VPP allows DHCP packets destined to the stanard client DHCP port to be delivered. With this enhancement the control-plane is now able to choose the setting of the broadcast flag. Change-Id: Ia4eb2c9bb1e30c29f9192facc645e9533641955a Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-11-24VOM: Additions to allow uses to UT applications that use VOMNeale Ranns1-1/+20
- find object by key - compare objects Change-Id: I36ec8612be9482bcef7ceced2a59f7403f77b3e8 Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
2017-11-06VOM reshuffleNeale Ranns1-6/+7
split the VOM into two halves; a top/front-end and a bottom/backend. Only the backend includes the auto-generated VAPI. This serves two purposes: 1 - improves ompile times for VOM, since the VAPI is included only in the backend. 2 - does not expose VAPI to users of VOM Change-Id: I17b93aeaef10c0eba8612016d9034aca5628d9f7 Signed-off-by: Neale Ranns <neale.ranns@cisco.com> Signed-off-by: Mohsin Kazmi <sykazmi@cisco.com>
2017-11-01VPP Object Model (VOM)Neale Ranns1-0/+167
The VOM is a C++ library for use by clients/agents of VPP for programming state. It uses the binary APIs to do so. Various other common client side functions are also provided. Please see om.hpp for a more detailed description. Change-Id: Ib756bfe99817093815a9e26ccf464aa5583fc523 Signed-off-by: Neale Ranns <neale.ranns@cisco.com> Co-authored-by: Mohsin Kazmi <sykazmi@cisco.com>