aboutsummaryrefslogtreecommitdiffstats
path: root/test/test_dhcp.py
AgeCommit message (Collapse)AuthorFilesLines
2018-03-23Drop dhcp pkts w/ hardware address mismatchesDave Barach1-0/+1
Add a few dhcp client rx packet/state counters Temporarily disable the dhcp client unit test, since it trips over the newly-added hardware address check. Change-Id: I7f68607e6ed3d738cba357c3fe76664a99b71cd8 Signed-off-by: Dave Barach <dave@barachs.net>
2018-03-19Scapy upgrade to 2.4.0.rc5Neale Ranns1-1/+2
- many of the patches fd.io applies in test/patches/2.3.3 are now upstreamed in 2.4 - 2.4 adds support for IGMPv3 which is my main motivation for the upgrade Change-Id: If2c0a524e3cba320b4a5d8cd07817c6ea2bf0c5a Signed-off-by: Neale Ranns <nranns@cisco.com>
2018-01-23For DHCP client configuration control the setting of the broadcast flag in theNeale Ranns1-4/+105
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>
2018-01-09test: consolidate the multiple versions of send_and_*Neale Ranns1-7/+0
Change-Id: I7fa7d0ebf73dab8264a2e5ddbd412600d78ead05 Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-11-16Add Support of DHCP VSS Type 0 where VPN-ID is ASCIIJohn Lo1-170/+298
Enhence support of DHCP VSS (Virtual Subnet Selection) to include VSS type 0 where VSS info is a NVT (Network Virtual Terminal) ASCII VPN ID where the ASCII string MUST NOT be terminated with a zero byte. Existing code already support VSS type 1, where VSS information is a RFC 2685 VPN-ID of 7 bytes with 3 bytes OUI and 4 bytes VPN index, and VSS type 255 indicating global VPN. Change-Id: I54edbc447c89a2aacd1cc9fc72bd5ba386037608 Signed-off-by: John Lo <loj@cisco.com>
2017-10-25VPP-1033: Python API support arbitrary sized input parameters.Ole Troan1-1/+2
Dynamically calculate the required buffer size to pack into based on message definition. Also add input parameter length checking. Change-Id: I7633bec596e4833bb328fbf63a65b866c7985de5 Signed-off-by: Ole Troan <ot@cisco.com>
2017-09-11FIB table add/delete APINeale Ranns1-3/+21
part 2; - this adds the code to create an IP and MPLS table via the API. - but the enforcement that the table must be created before it is used is still missing, this is so that CSIT can pass. Change-Id: Id124d884ade6cb7da947225200e3bb193454c555 Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-08-03DHCP Client: receive unicast ACKsNeale Ranns1-21/+71
despite VPP DHCP client setting neither ciaddr nor giaddr and setting the broadcast bit (see RFC 2131 section 4.1) some DHCP servers will still send a unicast DCHPACK. So as not to drop this VPP must have both 1) a receive FIB entry for the OFFERED IP adress and 2) a 'don't drop me because of uRPF' FIB entry for the DHCP server's address. Change-Id: I167d858deb45629318cbdccf5bf67d971730a42f Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-07-18DHCP client option 61 "client_id"Neale Ranns1-2/+32
the existing seeting of client_id to a VPP version number was unused and so overridden Change-Id: If9ebea936336f1fcca8d07e67186c95f8f8f0ccd Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-07-18DHCP client - remove interface address when DHCP de-configuredNeale Ranns1-21/+137
Change-Id: I63c59e3c13859b51999d283774f7783ef0a6a5ed Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-04-19Learn IP6 link-local ND entries from NSs sourced from link-local addressNeale Ranns1-7/+1
Change-Id: I4c3ce4d58df7977490fc94991291422ea1e31ee3 Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-03-07DHCP Multiple Servers (VPP-602, VPP-605)Neale Ranns1-44/+312
Multiple DHCP (4 and/or 6) servers can be added and removed through multiple calls to the 'set dhcp server' API. All 4/6/ discover/solicit messages will then be replicated to all servers in the list. The expectation is that the servers/system is configured in such a way that this is viable. If VSS information is providied for the clinet VRF which also has multiple servers configured, then the same VSS information is sent to each server. Likewise the source address of packets sent to from VPP to each server is the same. Change-Id: I3287cb084c84b3f612b78bc69cfcb5b9c1f8934d Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-03-03Changing the IP table for an interface is an error if the interface already ↵Neale Ranns1-0/+7
has an address configured (VPP-601) Change-Id: I311fc264f73dd3b2b3ce9d7d1c33cd0515b36c4a Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-02-16Consolidate DHCP v4 and V6 implementation. No functional change intendedNeale Ranns1-1/+1
The DHCP proxy and VSS information maintained by VPP is the same for v4 and v6, so we can manage this state using the same code. Packet handling is cleary different, so this is kept separate. Change-Id: I10f10cc1f7f19debcd4c4b099c6de64e56bb0c69 Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-02-21dhcp: multiple additionsNeale Ranns1-82/+84
DHCP additions: 1) DHCPv4 will only relay a message back to the client, if the Option82 information is present. So make this the default. 2) It is no longer possible to select via the API to "insert circuit ID" - since this is now default 3) Remove the version 2 API since it's now the same as version 1. 4) Adding the VSS option is now conditional only on the presence of VSS config (not the 'insert' option in the set API) 5) DHCP proxy dump via API Change-Id: Ia7271ba8c1d4dbf34a02c401d268ccfbb1b74f17 Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-01-27IP Multicast FIB (mfib)Neale Ranns1-16/+0
- IPv[46] mfib tables with support for (*,G/m), (*,G) and (S,G) exact and longest prefix match - Replication represented via a new replicate DPO. - RPF configuration and data-plane checking - data-plane signals sent to listening control planes. The functions of multicast forwarding entries differ from their unicast conterparts, so we introduce a new mfib_table_t and mfib_entry_t objects. However, we re-use the fib_path_list to resolve and build the entry's output list. the fib_path_list provides the service to construct a replicate DPO for multicast. 'make tests' is added to with two new suites; TEST=mfib, this is invocation of the CLI command 'test mfib' which deals with many path add/remove, flag set/unset scenarios, TEST=ip-mcast, data-plane forwarding tests. Updated applications to use the new MIFB functions; - IPv6 NS/RA. - DHCPv6 unit tests for these are undated accordingly. Change-Id: I49ec37b01f1b170335a5697541c8fd30e6d3a961 Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-01-26DHCPv[46] proxy testsNeale Ranns1-0/+739
Change-Id: I6aaf9c602cd515ed9d4416d286f9191d048c1a87 Signed-off-by: Neale Ranns <nranns@cisco.com>