[strongSwan] DHCP plugin + freeradius - strange behavior when no proposals

Tobias Brunner tobias at strongswan.org
Tue Oct 16 12:16:59 CEST 2018

> only something like (I have had no debug):
> 2018-10-14T19:27:57.322435+02:00 alfa charon-systemd[6721]: sending DHCP DISCOVER to
> 2018-10-14T19:27:57.322643+02:00 alfa charon-systemd[6721]: received DHCP OFFER %any from
> 2018-10-14T19:27:57.324271+02:00 alfa charon-systemd: 13[IKE] peer requested virtual IP %any
> 2018-10-14T19:27:57.324465+02:00 alfa charon-systemd: 13[CFG] sending DHCP DISCOVER to
> 2018-10-14T19:27:57.324653+02:00 alfa charon-systemd: 06[CFG] received DHCP OFFER %any from
> 2018-10-14T19:27:57.325632+02:00 alfa charon-systemd[6721]: sending DHCP REQUEST for %any to
> 2018-10-14T19:27:57.325731+02:00 alfa charon-systemd: 13[CFG] sending DHCP REQUEST for %any to
> 2018-10-14T19:27:57.325846+02:00 alfa charon-systemd[6721]: sending DHCP REQUEST for %any to
> 2018-10-14T19:27:57.326035+02:00 alfa charon-systemd: 13[CFG] sending DHCP REQUEST for %any to
> 2018-10-14T19:27:57.332313+02:00 alfa charon-systemd[6721]: received DHCP ACK for %any
> 2018-10-14T19:27:57.334059+02:00 alfa charon-systemd: 12[CFG] received DHCP ACK for %any

Where do you see a loop here?  (The duplicate messages are due to your
logging settings, syslog plus journald.)  But as said, the offer with should probably just be ignored (I pushed a fix for that to the
dhcp-ignore-anyaddr branch [1], the client will just time out and
retransmit the DHCPDISCOVER).

>>> when there is no proposals? should it send any answer?
>> No, why should it send an offer if it has no addresses to offer?
> I was afraid I overlooked something when read DHCP spec. (And there is
> DHCP message informs relay that this server cannot serve request)

RFC 2131 does not explicitly say so in section 4.3.1, but my
understanding is that a server should not send a reply if it doesn't
assign an address to a client (also see section 4.2 where it explicitly
refers to not responding to DHCPDISCOVER, not just not allocating an
address).  The table in section 4.3.1 also says 'yiaddr' is set to the
IP address that's offered to the client, which is clearly not.
And the text after the table indicates that a DHCPOFFER should only be
constructed if an address has been determined.  I also haven't found any
text that would change the behavior if a relay agent is involved.

But still, since there is no negative DHCPOFFER (unlike DHCPNAK as
response to DHCPREQUEST) it's not clear if maybe a response with
could be considered a negative offer (or if its just a bug on the
server's part and it really shouldn't reply at all).

> So I can safely keep my freeradius config?

What doubts do you have?



More information about the Users mailing list