summaryrefslogtreecommitdiffstats
path: root/src/vpp-api/vom/dhcp_config_cmds.hpp
AgeCommit message (Collapse)AuthorFilesLines
2018-04-27Move VOM to extras/vomDamjan Marion1-172/+0
Change-Id: Iea174f03dfba3bd06024db0f0cc373532300dcae Signed-off-by: Damjan Marion <damarion@cisco.com>
2018-01-23For DHCP client configuration control the setting of the broadcast flag in theNeale Ranns1-1/+7
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-06VOM reshuffleNeale Ranns1-0/+166
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>