On Wed, Jul 05, 2017 at 03:23:34PM +0300, Kapetanakis Giannis wrote: > Yes this patch seems to solve my problem. > > My test client which previously didn't get an IP, got one immediately. > > I'd like to point out however that some clients on some vlans-carp > did manage to get an IP (without the patch). > > Since all my dhcrelays run on carp, why did it work for some of them and > didn't fail on all of them? >
Using carp with htype 0 was a bug, and some cases in the code path probably didn't check for it. But it doesn't matter that much with the fix. So the issues are all gone now? OK? (anyone?) Reyk > thanks :) > > Giannis > > > > On 05/07/17 15:12, Reyk Floeter wrote: > > Hi, > > > > On Wed, Jul 05, 2017 at 12:33:31PM +0300, Kapetanakis Giannis wrote: > >>> Synopsis: relayctl stopped relaying > >>> Category: system > >>> Environment: > >> System : OpenBSD 6.1 > >> Details : OpenBSD 6.1-current (GENERIC.MP) #80: Mon Jul 3 14:23:11 > >> MDT 2017 > >> > >> [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP > >> > >> Architecture: OpenBSD.amd64 > >> Machine : amd64 > >>> Description: > >> > >> patch http://marc.info/?l=openbsd-cvs&m=149140326301074&w=2 > >> seems to create a problem in my dhcrelay setup > >> bpf.c,v 1.17 > >> packet.c,v 1.13 > >> dhcpd.h,v 1.22 > >> > >> Using the log-patch from Reyk > >> I have these errors: > >> Jul 5 11:53:09 dhcrelay[68565]: decode_hw_header:229: invalid htype 0 > >> Jul 5 11:53:09 dhcrelay[68565]: receive_packet:457: decode_hw_header > >> failed, len 364 > >> Jul 5 11:53:10 dhcrelay[68565]: decode_hw_header:229: invalid htype 0 > >> Jul 5 11:53:10 dhcrelay[68565]: receive_packet:457: decode_hw_header > >> failed, len 364 > >> > >> # client - OBSD > >> # dhclient -d vio1 > >> DHCPDISCOVER on vio1 - interval 1 > >> DHCPDISCOVER on vio1 - interval 2 > >> DHCPDISCOVER on vio1 - interval 3 > >> DHCPDISCOVER on vio1 - interval 6 > >> DHCPDISCOVER on vio1 - interval 10 > >> > >> # dhcrelay runs on carp interface on top of vlan > >> trunk1 (lacp) - vlans - carp - dhcrelay > >> ./dhcrelay -d -i carp8 dhcp_server1 dhcp_server2 > >> both dhcp servers are on carp. I send packets on their real IP not the > >> carped one. > >> reply comes from > >> > >> vlan8: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 > >> lladdr 00:1b:21:95:2d:eb > >> description: TEST_VLAN > >> index 37 priority 0 llprio 3 > >> encap: vnetid 8 parent trunk1 > >> groups: vlan internal > >> media: Ethernet autoselect > >> status: active > >> carp8: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > >> lladdr 00:00:5e:00:01:08 > >> description: TEST > >> index 65 priority 15 llprio 3 > >> carp: MASTER carpdev vlan8 vhid 8 advbase 1 advskew 0 > >> groups: carp > >> status: master > >> inet 10.1.100.1 netmask 0xffffff00 broadcast 10.1.100.255 > >> > >> # tcpdump on vlan8 (internal-clients) > >> 11:59:09.156292 00:1a:4a:3c:44:2c ff:ff:ff:ff:ff:ff 0800 342: 0.0.0.0.68 > > >> 255.255.255.255.67: xid:0xd9a18eba [|bootp] [tos 0x10] > >> 11:59:10.161023 00:1a:4a:3c:44:2c ff:ff:ff:ff:ff:ff 0800 342: 0.0.0.0.68 > > >> 255.255.255.255.67: xid:0xd9a18eba secs:1 [|bootp] [tos 0x10] > >> 11:59:12.171069 00:1a:4a:3c:44:2c ff:ff:ff:ff:ff:ff 0800 342: 0.0.0.0.68 > > >> 255.255.255.255.67: xid:0xd9a18eba secs:3 [|bootp] [tos 0x10] > >> 11:59:15.181119 00:1a:4a:3c:44:2c ff:ff:ff:ff:ff:ff 0800 342: 0.0.0.0.68 > > >> 255.255.255.255.67: xid:0xd9a18eba secs:6 [|bootp] [tos 0x10] > >> 11:59:21.191020 00:1a:4a:3c:44:2c ff:ff:ff:ff:ff:ff 0800 342: 0.0.0.0.68 > > >> 255.255.255.255.67: xid:0xd9a18eba secs:12 [|bootp] [tos 0x10] > >> > >> # tcpdump on external trunk0 (relay to dhcp server) > >> 11:59:10.161869 70:81:05:5c:a7:ff 00:1b:21:95:2d:e9 0800 342: > >> dhcp_server2.67 > 10.1.100.1.67: (reply) hops:1 xid:0xd9a18eba > >> Y:10.1.100.182 G:10.1.100.1 ether 00:1a:4a:3c:44:2c [|bootp] > >> 11:59:12.171900 70:81:05:5c:a7:ff 00:1b:21:95:2d:e9 0800 342: > >> dhcp_server2.67 > 10.1.100.1.67: (reply) hops:1 xid:0xd9a18eba secs:3 > >> Y:10.1.100.182 G:10.1.100.1 ether 00:1a:4a:3c:44:2c [|bootp] > >> 11:59:15.181986 70:81:05:5c:a7:ff 00:1b:21:95:2d:e9 0800 342: > >> dhcp_server2.67 > 10.1.100.1.67: (reply) hops:1 xid:0xd9a18eba secs:6 > >> Y:10.1.100.182 G:10.1.100.1 ether 00:1a:4a:3c:44:2c [|bootp] > >> 11:59:16.185594 70:81:05:5c:a7:ff 00:1b:21:95:2d:e9 0800 342: > >> dhcp_server1.67 > 10.1.100.1.67: (reply) hops:1 xid:0xd9a18eba secs:6 > >> Y:10.1.100.181 G:10.1.100.1 ether 00:1a:4a:3c:44:2c [|bootp] > >> 11:59:21.191473 70:81:05:5c:a7:ff 00:1b:21:95:2d:e9 0800 342: > >> dhcp_server1.67 > 10.1.100.1.67: (reply) hops:1 xid:0xd9a18eba secs:12 > >> Y:10.1.100.181 G:10.1.100.1 ether 00:1a:4a:3c:44:2c [|bootp] > >> 11:59:21.191968 70:81:05:5c:a7:ff 00:1b:21:95:2d:e9 0800 342: > >> dhcp_server2.67 > 10.1.100.1.67: (reply) hops:1 xid:0xd9a18eba secs:12 > >> Y:10.1.100.182 G:10.1.100.1 ether 00:1a:4a:3c:44:2c [|bootp] > >> > >> # dhcp_server1 > >> Jul 5 11:59:09 dhcpd: DHCPDISCOVER from 00:1a:4a:3c:44:2c via 10.1.100.1: > >> load balance to peer failover-net > >> Jul 5 11:59:15 dhcpd: DHCPDISCOVER from 00:1a:4a:3c:44:2c via 10.1.100.1 > >> Jul 5 11:59:16 dhcpd: DHCPOFFER on 10.1.100.181 to 00:1a:4a:3c:44:2c via > >> 10.1.100.1 > >> Jul 5 11:59:21 dhcpd: DHCPDISCOVER from 00:1a:4a:3c:44:2c via 10.1.100.1 > >> Jul 5 11:59:21 dhcpd: DHCPOFFER on 10.1.100.181 to 00:1a:4a:3c:44:2c via > >> 10.1.100.1 > >> > >> # dhcp_server2 > >> Jul 5 11:59:09 dhcpd: DHCPDISCOVER from 00:1a:4a:3c:44:2c via 10.1.100.1 > >> Jul 5 11:59:10 dhcpd: DHCPOFFER on 10.1.100.182 to 00:1a:4a:3c:44:2c via > >> 10.1.100.1 > >> Jul 5 11:59:12 dhcpd: DHCPDISCOVER from 00:1a:4a:3c:44:2c via 10.1.100.1 > >> Jul 5 11:59:12 dhcpd: DHCPOFFER on 10.1.100.182 to 00:1a:4a:3c:44:2c via > >> 10.1.100.1 > >> Jul 5 11:59:15 dhcpd: DHCPDISCOVER from 00:1a:4a:3c:44:2c via 10.1.100.1 > >> Jul 5 11:59:15 dhcpd: DHCPOFFER on 10.1.100.182 to 00:1a:4a:3c:44:2c via > >> 10.1.100.1 > >> Jul 5 11:59:21 dhcpd: DHCPDISCOVER from 00:1a:4a:3c:44:2c via 10.1.100.1 > >> Jul 5 11:59:21 dhcpd: DHCPOFFER on 10.1.100.182 to 00:1a:4a:3c:44:2c via > >> 10.1.100.1 > >> > >>> How-To-Repeat: > >> ./dhcrelay -d -i carp8 dhcp_server1 dhcp_server2 > >> > > > > Thanks. > > > > There is HTYPE - the DHCP interface hardware type - and IFT, the > > interface type as reported by the kernel. > > > > carp(4) is an Ethernet-style interface with IFT_CARP that can be used > > as HTYPE_ETHER by dhcrelay, but the code failed to recognize the > > special case and left the htype as 0 (unitialized). Unfortunately, > > there is nothing like an "interface class" that indicates that carp(4) > > is (mostly) compatible to IFT_ETHER. > > > > So the solution is to either add CARP to a whitelist of supported > > interfaces (see below) or to handle all interfaces except enc(4) as > > HTYPE_ETHER by default (the old "we don't care" approach). > > > > Does this fix your problem? > > > > btw. I've also committed a fix to keep logging to stderr with -d. > > > > Reyk > > > > Index: usr.sbin/dhcrelay/dispatch.c > > =================================================================== > > RCS file: /cvs/src/usr.sbin/dhcrelay/dispatch.c,v > > retrieving revision 1.21 > > diff -u -p -u -p -r1.21 dispatch.c > > --- usr.sbin/dhcrelay/dispatch.c 4 Apr 2017 15:52:12 -0000 1.21 > > +++ usr.sbin/dhcrelay/dispatch.c 5 Jul 2017 11:57:41 -0000 > > @@ -137,18 +137,19 @@ setup_iflist(void) > > sdl = (struct sockaddr_dl *)ifa->ifa_addr; > > ifi = (struct if_data *)ifa->ifa_data; > > > > - /* Skip non ethernet interfaces. */ > > + /* Skip unsupported interfaces. */ > > if (ifi->ifi_type != IFT_ETHER && > > - ifi->ifi_type != IFT_ENC) { > > + ifi->ifi_type != IFT_ENC && > > + ifi->ifi_type != IFT_CARP) { > > TAILQ_REMOVE(&intflist, intf, entry); > > free(intf); > > continue; > > } > > > > - if (ifi->ifi_type == IFT_ETHER) > > - intf->hw_address.htype = HTYPE_ETHER; > > - else > > + if (ifi->ifi_type == IFT_ENC) > > intf->hw_address.htype = HTYPE_IPSEC_TUNNEL; > > + else > > + intf->hw_address.htype = HTYPE_ETHER; > > > > intf->index = sdl->sdl_index; > > intf->hw_address.hlen = sdl->sdl_alen; > > > --
