OpenBSD src changes summary for 2016-02-21 ==========================================
gnu usr.bin/skeyinit usr.sbin/eigrpd usr.sbin/smtpd usr.sbin/tcpdump == gnu =============================================================== 01/03 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu gnu ~ gcc/gcc/config/alpha/alpha.c > In alpha_expand_block_clear(), cope with the offset being negative; > this can happen due to the frame layout change introduced in order to > support the stack protector. Fix from miod. > Bug originally observed by jca and condensed to a 3-liner by myself, > basically local [] arrays being initialized with shorter strings. > (deraadt@) == usr.bin =========================================================== 02/03 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin skeyinit ~ skeyinit.c > Fix skeyinit -E by hoisting argument parsing and the call to enable_db() > above the calls to pledge(): /etc/skey wants to have its sticky bit. > ok deraadt@ (tb@) == usr.sbin ========================================================== 03/03 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin eigrpd ~ kroute.c > Filter our RTM_GET messages which are not from us. > Pulled from ospfd. Original author: claudio@ (renato@) ~ tlv.c > Make eigrpd work against newer IOS routers. > Different versions of IOS can use a different number of bytes to encode > the same IPv6 prefix inside route TLVs. This sucks but we have to deal > with it. Instead of calculating the number of bytes based on the value > of the prefixlen field, let's get this number by subtracting the size > of all other fields from the total size of the TLV. It works because > all the other fields have a fixed length. > For reference, the EIGRP draft says that length of the prefix field > should be obtained according to this function: > ((Bit Count - 1) / 8) + 1 > But older IOS versions use this for IPv6 (obtained through reverse > engineering): > ((Bit Count == 128) ? 16 : ((Bit Count / 8) + 1)) > Now, the new IOS-XR apparently uses the first formula for both IPv4 and > IPv6. With this patch, eigrpd will work against both older and newer > versions of IOS. (renato@) ~ packet.c > Add scope id only for unicast IPv6 packets. (renato@) ~ eigrpd.c ~ eigrpd.h ~ eigrpe.h ~ interface.c ~ kroute.c ~ packet.c ~ parse.y ~ rde_dual.c ~ tlv.c ~ util.c > Several minor tweaks. (renato@) ~ kroute.c ~ neighbor.c ~ rde_dual.c ~ util.c > Extend eigrp_addrcmp() and use it in more places. > The idea is to remove unnecessary code duplication throughout the code. > (renato@) ~ eigrpd.h ~ kroute.c ~ packet.c ~ parse.y ~ tlv.c ~ util.c > Introduce the bad_addr() family of functions. > These functions improve code reusability as there's no more need to > check for all possible "bad" addresses in several different places. > Besides that, this patch introduce additional checks in the code. (renato@) ~ eigrpd.c ~ eigrpe.c ~ interface.c ~ kroute.c ~ log.c ~ neighbor.c ~ packet.c ~ parse.y ~ rde.c ~ rde_dual.c ~ rtp.c ~ tlv.c > Copy structs by assignment instead of memcpy. > Copying by straight assignment is shorter, easier to read and has a > higher level of abstraction. We'll only avoid it when copying from an > unaligned source (e.g., network buffers). (renato@) ~ tlv.c > Simplify the handling of the sequence tlv. > The C standard says: "A pointer to a union object, suitably converted, > points to each of its members". > This means that we can use the same code to process both v4 and v6 > addresses. (renato@) ~ eigrpe.c ~ eigrpe.h ~ interface.c ~ kroute.c ~ parse.y ~ rde_dual.c > Move some functions around and rename a few variables and functions. > The sooner we do these changes the better. This rearrangement will make > the code easier to read. (renato@) ~ rde_dual.c > Skip redistributed routes when updating the FIB. (renato@) smtpd ~ smtpd.h > bump version (gilles@) tcpdump ~ print-802_11.c > Make tcpdump show details of beacon country elements in verbose mode only. > ok sthen@ (stsp@) =============================================================================== _______________________________________________ odc mailing list [email protected] http://www.squish.net/mailman/listinfo/odc
