On 03/04/2013 04:54 PM, Alan DeKok wrote:

  The point of asking for debug output is to see what the server is doing.

  I'm not sure what the rest of your message means.  The server defaults
to copying the giaddr from the request to the reply.  This is so that
the reply can use the giaddr as the destination IP.  If you use Perl to
update the giaddr to something else... then the reply will be sent there.

I have to do that, this is cable IP network that i am talking about. Real life example.
I am using Cisco CMTS and his primary interface IP as cable-helper/relay IP.

This is by desing.
I am sorry for my bad english but i will try to explain, please bare with me...

This is CM/CPE bundle interface:

interface Bundle1.150
vrf forwarding vrf_name
ip address public_ip 255.255.255.240 secondary
ip address private_ip 255.255.192.0
no ip unreachables
no cable arp
cable source-verify dhcp
cable helper-address radius_ip
end

As you can see CMTS will relay all requests from CM's and CPE's over primary interface address (private_ip/255.255.192.0)
radius will get all requests from that IP. all offers need to go back to that same ip, no matter what giaddr is sent to client.

i have it already working that way with another dhcp server, in production.
also, couple of commercial products that i was testing had exactly the same logic implemented, all offers were sent to relay ip, no matter what was set as giaddr.

Let us say that i have two pools for CPE devices, imaginary:
200.200.200.0/28
200.200.100.0/28

In that case i will have two lines in bundle interface setup:
ip address 200.200.200.1 255.255.255.240 secondary
ip address 200.200.100.1 255.255.255.240 secondary

and this is relay_ip (primary ip address of bundle interface)
ip address 10.10.10.1 255.255.192.0

If dhcp finds free address from first pool (200.200.200.10/28) offer will be somethink like this:

giaddr: 200.200.200.1
yiadd: 200.200.200.10
OPTION: 1 ( 4) Subnet mask 255.255.255.240
...

but offer still needs to be sent to 10.10.10.1, where requests came from in the first place.

I didn't break anything, i have to do it that way.
As far as dhcp server goes, it would be logical for him to return the offer to relay ip. relay will forward it to a client and client will get correct data.
If offer goes to any other address Cisco ASA will drop that packet because it doesn't have it in initiated/established chains...

Next time CPE tries to renew/release address request will come from 10.10.10.1 again...

That is why i said that relay_ip shouldn't be replaced with giaddr.

FR i am using is 2.2.0, latest stable version.

i will try to send debug info tomorrow AM CET...