Age | Commit message (Collapse) | Author | Files | Lines |
|
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>
|
|
logging: allow a client to register a callback handler to recieve log messages
that way the client can maintain a correctly sequenced log
populate: fix the creation of interface and the setting of the handle
stats: the reset promise idea is not defined behaviour.
Use an eanble/disable command pair
Change-Id: I347720bb65df2874c7619e722d593bc863ee2bf1
Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
|
|
Change-Id: I74886c31f8ceba2561679513560cf5ae46757236
Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
|
|
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>
|
|
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>
|