Snooping problem - Hardware Code Type 0

startx001 · ‎11-03-2014

Hi all ,

I would like to ask you do you know or did someone meet whit this issue on CMTS 7246VXR IOS : ubr7200-ik9su2-mz.123-23.BC10.bin

Issue is that CMTS sends DHCP packet with Hardware Code Type 0 and it should be 1 , so that huawei router reports this error message.

Line 24887: Sep 11 2014 01:24:47+02:00 DST PG-NPE1 %%01SNOOPING/4/HTYPEERR(l)[342123]:Slot=5,Vcpu=0;The type of hardware address in DHCP packet received from interface GigabitEthernet5/0/1.1001 VLAN 1001 was wrong!

RFC 2131 Dynamic Host Configuration Protocol March 1997

DHCP clarifies the interpretation of the 'siaddr' field as the

address of the server to use in the next step of the client's

bootstrap process. A DHCP server may return its own address in the

'siaddr' field, if the server is prepared to supply the next

bootstrap service (e.g., delivery of an operating system executable

image). A DHCP server always returns its own address in the 'server

identifier' option.

FIELD OCTETS DESCRIPTION

----- ------ -----------

op 1 Message op code / message type.

1 = BOOTREQUEST, 2 = BOOTREPLY

htype 1 Hardware address type, see ARP section in "Assigned

Numbers" RFC; e.g., '1' = 10mb ethernet.

hlen 1 Hardware address length (e.g. '6' for 10mb

ethernet).

Is this already know bug ?

KR

VZ

cperroquin · ‎11-03-2014

I don't see the problem based on RFC2132 or RFC5494.

In RFC2132:

The client identifier MAY consist of type-value pairs similar to the
'htype'/'chaddr' fields defined in [3]. For instance, it MAY consist
of a hardware type and hardware address. In this case the type field
SHOULD be one of the ARP hardware types defined in STD2 [22]. A
hardware type of 0 (zero) should be used when the value field
contains an identifier other than a hardware address (e.g. a fully
qualified domain name).

May be the CMTS is doing a DHCP Inform request with is FQDN in the adresse instead of hardware address.

Could you do packet capture on the DHCP packet?

startx001 · ‎11-05-2014

Debug from CMTS :

*Nov 4 04:33:26.959: DHCPD: forwarding BOOTREPLY to client 0021.27e3.4deb.
*Nov 4 04:33:26.959: DHCPD: validating relay information option.
*Nov 4 04:33:26.959: DHCPD: broadcasting BOOTREPLY to client 0021.27e3.4deb.
*Nov 4 04:33:26.967: DHCPD: cannot load local addresses for Bundle1.1.
*Nov 4 04:33:26.967: DHCPD: cannot load local addresses for Bundle1.1.
*Nov 4 04:33:26.967: DHCPD: cannot load local addresses for Bundle1.1.
*Nov 4 04:33:26.971: DHCPD: setting giaddr to 10.7.0.1.
*Nov 4 04:33:26.971: DHCPD: adding relay information option.
*Nov 4 04:33:26.971: DHCPD: BOOTREQUEST from 0100.1cea.8077.ad forwarded to x.x.x.x.
*Nov 4 04:33:26.975: DHCPD: forwarding BOOTREPLY to client 001c.ea80.77ad.
*Nov 4 04:33:26.975: DHCPD: validating relay information option.
*Nov 4 04:33:26.975: DHCPD: creating ARP entry (10.7.6.153, 001c.ea80.77ad).
*Nov 4 04:33:26.975: DHCPD: unicasting BOOTREPLY to client 001c.ea80.77ad (10.7.6.153).
*Nov 4 04:33:27.031: DHCPD: setting giaddr to 10.7.0.1.
*Nov 4 04:33:27.031: DHCPD: adding relay information option.
*Nov 4 04:33:27.031: DHCPD: BOOTREQUEST from 0100.1cea.7cb5.b2 forwarded to x.x.x.x.
*Nov 4 04:33:27.031: DHCPD: forwarding BOOTREPLY to client 001c.ea7c.b5b2.
*Nov 4 04:33:27.031: DHCPD: validating relay information option.
*Nov 4 04:33:27.031: DHCPD: creating ARP entry (10.7.5.248, 001c.ea7c.b5b2).
*Nov 4 04:33:27.031: DHCPD: unicasting BOOTREPLY to client 001c.ea7c.b5b2 (10.7.5.248).
*Nov 4 04:33:27.039: DHCPD: setting giaddr to 10.7.0.1.
*Nov 4 04:33:27.039: DHCPD: adding relay information option.
*Nov 4 04:33:27.039: DHCPD: BOOTREQUEST from ff26.ec78.5200.0300.01c8.fb26.ec78.52 forwarded to x.x.x.x
*Nov 4 04:33:27.043: DHCPD: forwarding BOOTREPLY to client c8fb.26ec.7852.
*Nov 4 04:33:27.043: DHCPD: validating relay information option.
*Nov 4 04:33:27.043: DHCPD: creating ARP entry (10.7.2.3, c8fb.26ec.7852).
*Nov 4 04:33:27.043: DHCPD: unicasting BOOTREPLY to client c8fb.26ec.7852 (10.7.2.3).
*Nov 4 04:33:27.051: DHCPD: cannot determine client hardware address.
*Nov 4 04:33:27.051: DHCPD: excessive retransmissions from client .
*Nov 4 04:33:27.051: DHCPD: switching to relay address 109.72.96.1.
*Nov 4 04:33:27.051: DHCPD: setting giaddr to 109.72.96.1.
*Nov 4 04:33:27.051: DHCPD: adding relay information option.
*Nov 4 04:33:27.051: DHCPD: BOOTREQUEST from forwarded to x.x.x.x.
*Nov 4 04:33:27.051: DHCPD: invalid opcode (0).
*Nov 4 04:33:27.063: DHCPD: setting giaddr to 10.7.0.1.
*Nov 4 04:33:27.063: DHCPD: adding relay information option.
*Nov 4 04:33:27.063: DHCPD: BOOTREQUEST from 0100.1cea.4a3e.64 forwarded to x.x.x.x.
*Nov 4 04:33:27.067: DHCPD: forwarding BOOTREPLY to client 001c.ea4a.3e64.
*Nov 4 04:33:27.067: DHCPD: validating relay information option.
*Nov 4 04:33:27.067: DHCPD: creating ARP entry (10.7.0.58, 001c.ea4a.3e64).
*Nov 4 04:33:27.067: DHCPD: unicasting BOOTREPLY to client 001c.ea4a.3e64 (10.7.0.58).
*Nov 4 04:33:27.075: DHCPD: setting giaddr to 10.7.0.1.
*Nov 4 04:33:27.075: DHCPD: adding relay information option.
*Nov 4 04:33:27.075: DHCPD: BOOTREQUEST from 0100.1cea.7cbc.3f forwarded to x.x.x.x.
*Nov 4 04:33:27.079: DHCPD: forwarding BOOTREPLY to client 001c.ea7c.bc3f.
*Nov 4 04:33:27.079: DHCPD: validating relay information option.
*Nov 4 04:33:27.079: DHCPD: creating ARP entry (10.7.4.80, 001c.ea7c.bc3f).
*Nov 4 04:33:27.079: DHCPD: unicasting BOOTREPLY to client 001c.ea7c.bc3f (10.7.4.80).
*Nov 4 04:33:27.103: DHCPD: setting giaddr to 10.7.0.1.
*Nov 4 04:33:27.103: DHCPD: adding relay information option.
*Nov 4 04:33:27.103: DHCPD: BOOTREQUEST from 0100.1cea.7cbf.1b forwarded to x.x.x.x

x.x.x.x is the DHCP server.

Is this bug ?

KR

VZ