summaryrefslogtreecommitdiffhomepage
AgeCommit message (Collapse)Author
2019-04-07nclient6: small fixesChristopher Koch
- RapidCommit solicits wait for Reply messages, not Advertise. - Default recipient should be all relay agents and servers, not just servers. - Make New() and NewWithConn() interface same as in nclient4. Signed-off-by: Christopher Koch <chrisko@google.com>
2019-04-07nclient4: simplify New interfaceChristopher Koch
Signed-off-by: Christopher Koch <chrisko@google.com>
2019-04-04client6: new async DHCPv6 client like #250.Christopher Koch
- Race-condition-averse. - Supports multiple concurrent requests. - Tested. - Requires a fully compatible net.PacketConn. Signed-off-by: Christopher Koch <chrisko@google.com>
2019-04-04dhcpv4: add RFC3442 route optionsChristopher Koch
Signed-off-by: Christopher Koch <chrisko@google.com>
2019-04-03Use cancellable crypto RNG from u-rootAndrea Barberio
Fixes #246 Signed-off-by: Andrea Barberio <insomniac@slackware.it>
2019-04-03Allow 0xFF padding in 'End' option (#265)Alexander Tischenko
After investigation on DHCP relaying with BDCOM P3608 GPON OLT switches, i found that 'End' option is not always padded with 0x00, but for some packets is padded by the same 0xFF (End) option. DHCPv4 fails to parse such type of packets and throws an "Invalid options" error. But Wireshark says that all is just fine with 0xFF padding. This commit allows to use 0xFF/0x00 End option padding instead of strict 0x00. This allows BDCOM switches relaying mechanism to work with package.
2019-04-03Modifying the writeIP function to always write IPv4 in 4 byte long format.Akshay Navale
2019-03-29server4 test: pick ports > 32kChris K
2019-03-29dhcpv4: pad v4 messages to a 300 byte minimumChristopher Koch
Certain older DHCP servers and relay agents follow the RFC 951 BOOTP standard in which BOOTP/DHCP messages have a 300 byte minimum length. Signed-off-by: Christopher Koch <chrisko@google.com>
2019-03-29update README: add u-rootPablo Mazzini
2019-03-27client4: add a new DHCPv4 client.Christopher Koch
- Able to send UDP packets before interface is configured. - Able to use any net.PacketConn. - RFC2131-compliant retransmission logic. - Tests. - Race-condition-averse. Previous clients (both mine and the ones here) are prone to race condition errors. Having one and only one place that calls receive on the socket "continuously" without having to coordinate hand-offs makes the logic way easier to follow, and allows for multiple requests in flux at a time. Signed-off-by: Christopher Koch <chrisko@google.com>
2019-03-14client: simulate relay (#259)Pablo Mazzini
2019-03-13Add partial (client) binding support for BSD (#260)Dmitri Goutnik
2019-03-13Adding CircuitId parsing logic into dhcpv4 lib (#255)Akshay Navale
2019-03-13[dhcpv4] simplify userclass handling (#249)Pablo Mazzini
2019-03-11dhcpv6: standardize GetInnerMessageChristopher Koch
2019-03-11dhcpv6: remove setters and getters.Christopher Koch
- Make members directly accessible.
2019-03-11dhcpv6: add explicit unmarshaling functions.Christopher Koch
2019-03-11dhcpv6: rename stuttering types.Christopher Koch
dhcpv6.DHCPv6Message -> dhcpv6.Message dhcpv6.DHCPv6Relay -> dhcpv6.RelayMessage
2019-03-07Allow Unknown OperState of the link interface (#254)Łukasz Siudut
* Allow Unknowo OperState of the link interface We hig a bug when Netconf library was failing to bring interface up despite the fact that it was actually up. It turned out that it's oper state was not set to UP, what is expected by the library. According to kernel documentation it is ok proceed if interface state is Up or Unknown: ``` Interface is in RFC2863 operational state UP or UNKNOWN. This is for backward compatibility, routing daemons, dhcp clients can use this flag to determine whether they should use the interface. ``` Also, resaon why operational state may remain Unknown: ``` IF_OPER_UNKNOWN (0): Interface is in unknown state, neither driver nor userspace has set operational state. Interface must be considered for user data as setting operational state has not been implemented in every driver. ``` I modified our code to try DHCP transaction even if `IfUp` failed, but the OperState was equal to Unknown - it worked perfectly. * Skip rt7 test also with go 1.10 and 1.11 As per request from @pmazzini.
2019-01-28update bsdpPablo Mazzini
2019-01-28update bsdpPablo Mazzini
2019-01-28update bsdpPablo Mazzini
2019-01-28[dhcpv4] move default to main directoryPablo Mazzini
2019-01-28Created examples directory and adjusted READMEAndrea Barberio
2019-01-28dhcpv4: moved client into dhcpv4/client4Andrea Barberio
2019-01-28dhcpv6: moved client into dhcpv6/client6Andrea Barberio
2019-01-26dhcpv6: remove unnecessary Length functionChristopher Koch
2019-01-26dhcpv6: move option code and length marshaling to Options.ToBytes.Christopher Koch
2019-01-26dhcpv6: easier option parsingChristopher Koch
- move option parsing to uio buffer library. - move option code and length reading into FromBytes rather than implementing it in each OptionParser.
2019-01-26dhcpv6: use uio buffer in DHCPv6 message parsingChristopher Koch
2019-01-26dhcpv6: move option code types; add Stringer.Christopher Koch
2019-01-26dhcpv6: introduce TransactionID typeChristopher Koch
2019-01-26dhcpv6: clean up MessageTypeChristopher Koch
- print unknown message type numbers. - unexport unneeded map of strings.
2019-01-26dhcpv6: introduce options type.Christopher Koch
2019-01-25[async] re-add modifiers to Send method (#239)Pablo Mazzini
2019-01-24Update CONTRIBUTORS.mdinsomniac
2019-01-24dhcpv4: getters instead of gettersChristopher Koch
From: r := GetRouter(d.Options) To: r := d.Router()
2019-01-24dhcpv4: nicer API for option parsing.Christopher Koch
From: r := d.GetOneOption(OptionRouter).(*OptRouter).Routers d.UpdateOption(&OptRouter{Routers: []net.IP{net.IP{192, 168, 0, 1}}}) To: r := GetRouter(d.Options) d.UpdateOption(OptRouter(net.IP{192, 168, 0, 1}, ...))
2019-01-20dhcpv4: fix TransactionID in SummaryChristopher Koch
2019-01-20dhcpv4: add Stringer for XIDChristopher Koch
2019-01-19dhcpv4: consolidate all IP options into one file.Christopher Koch
2019-01-19dhcpv4: consolidate string options into one file.Christopher Koch
2019-01-19dhcpv4: build more packets with modifiersChristopher Koch
Also drop unnecessary return value of Modifier.
2019-01-19dhcpv6: added Duid.EqualAndrea Barberio
2019-01-15dhcpv4: add option code list type for simpler modifiers.Christopher Koch
2019-01-15dhcpv4: print values of unknown types in stringifiers.Christopher Koch
2019-01-15dhcpv4: conform to RFC 2131 with respect to options.Christopher Koch
Removes AddOption and GetOption. RFC 2131 specifies that options may only appear once (Section 4.1). If an option does appear more than once, its byte values must be concatenated. RFC 3396 further specifies that to send options longer than 255 bytes, one option may be split into multiple option codes, which must be concatenated back together by the receiver. Both of these are concerned with the byte representation of options. Fact is, based on both RFCs one can say that an option may only appear once, but may be composed of multiple values. Because an option may appear only once logically in any case, we remove the AddOption and GetOption functions and leave only UpdateOption and GetOneOption. Also remove all additions & checks of the End option - the marshaling and unmarshaling code is exclusively responsible for that now.
2019-01-14bsdp: simplify version type.Christopher Koch
2019-01-14dhcpv4: thoroughly fix type docs. Refer to RFCs.Christopher Koch
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-20 09:03:30 +0000