DHCP module and external DHCP relay

[Alan DeKok]

Eugene Grosbein wrote:
> The DHCP code does DOES use "client definitions".

  It has one, but it doesn't *use* it for anything.

> There is a comment in src/lib/dhcp.c before the code I'm speaking about:
> 
>         /*
>          *      Create a unique vector from the MAC address and the
>          *      DHCP opcode.  This is a hack for the RADIUS
>          *      infrastructure in the rest of the server.
>          *
>          *      Note: packet->data[2] == 6, which is smaller than
>          *      sizeof(packet->vector)
>          *
>          *      FIXME:  Look for client-identifier in packet,
>          *      and use that, too?
>          */
>         memset(packet->vector, 0, sizeof(packet->vector));
>         memcpy(packet->vector, packet->data + 28, packet->data[2]);
>         packet->vector[packet->data[2]] = packet->code & 0xff;
> 
> This is plain wrong as it's making non-unique "vector"
> when all requests come from the same MAC address of the DHCP relay.

  That field ( CHADDR ) is the MAC address of the client.  Not the relay.

  If the relay is putting it's own MAC into the CHADDR field, then the
relay is broken.  Throw it in the garbage, and get one that works

> 1. New client sends DHCP Discover via DHCP relay with new xid.
> 2. FreeRADIUS has plenty of requests from this DHCP relay and drops the request
> with a note in its log about duplicate request. That's a monent when it fails.

  You're not posting the debug log, as suggested in the FAQ, "man" page,
etc.  That *would* have helped.

  The duplicate detection code uses the XID.  So if the server sees a
duplicate it's because the XID is the same.

  Some of the issue here is that I'm working with v3.  I don't work with
v2 any more, except to fix bugs.

> 3. Client does not sit silent and repeats its request with the same xid
> several times.
> 4. Eventually, the request with noted xid comes in such a moment
> that FreeRAIDUS accepts it without a drop and passes to post_auth().

  I have no idea what that means.

> There are 6 seconds between point 1 and point 4 generally and
> several retransmissions from the DHCP clients with the same xid.

  Which disagrees with your earlier post which said:

Request 14280134 has been waiting in the processing queue for 6 seconds.
 Check that all databases are running properly!
Discarding duplicate request from client dhcp port 67 - ID: 1381353109
due to unfinished request 14280311

  The ONLY reason that message occurs is because your database is slow.

  If the server DROPS the first packet, then the packet CANNOT be
sitting in the processing queue for 6 seconds.  Yet you say your
database is fast.

  Your explanations are in gross disagreement.  One or more of your
assumptions is completely wrong.

> No-no, we are not talking about server "blocking".

  Then why did the server produce the message I quoted above?

  You're changing your story.  It's annoying.

  The server IS blocking.  The server IS NOT dropping duplicates.

  You've posted 2 lines of debug output showing that the server is blocking.

  You've posted ZERO debug output showing that the server is dropping
duplicates.

  Your explanation about the relay putting it's own MAC address into the
CHADDR fields makes ZERO sense.

  Alan DeKok.