Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 2 subscribers
  • Views 3380 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Curious DHCP behavior

SalishSwede
I'm moving a machine from one network to another and finding that the Astaro DHCP server sees that the machine is in different networks but it assigns it the same ip address no matter what network it's in.  This is not helpful.

[FONT=monospace]2013:10:11-16:53:13 wahine dhcpd: DHCPOFFER on 10.1.10.1 to 00:0c:29:bf:76:b7 (aardvark) via eth0 [/FONT]
[FONT=monospace]2013:10:11-16:53:13 wahine dhcpd: DHCPOFFER on 172.16.1.10 to 00:0c:29:bf:76:b7 (aardvark) via eth3 [/FONT]
[FONT=monospace]2013:10:11-16:53:13 wahine dhcpd: DHCPOFFER on 10.3.10.1 to 00:0c:29:bf:76:b7 (aardvark) via eth2 [/FONT]
[FONT=monospace]2013:10:11-16:53:13  wahine dhcpd: if aardvark.ravennasprings.com IN A rrset doesn't exist  add aardvark.ravennasprings.com 43200 IN A 10.1.10.1: timed out. [/FONT]
[FONT=monospace]2013:10:11-16:53:13 wahine dhcpd: DHCPREQUEST for 10.1.10.1 (10.1.1.2) from 00:0c:29:bf:76:b7 (aardvark) via eth0 [/FONT]
[FONT=monospace]2013:10:11-16:53:13 wahine dhcpd: DHCPACK on 10.1.10.1 to 00:0c:29:bf:76:b7 (aardvark) via eth0 [/FONT]
[FONT=monospace]2013:10:11-16:53:13  wahine dhcpd: DHCPREQUEST for 10.1.10.1 (10.1.1.2) from  00:0c:29:bf:76:b7 (aardvark) via eth3: wrong network. [/FONT]
[FONT=monospace]2013:10:11-16:53:13 wahine dhcpd: DHCPNAK on 10.1.10.1 to 00:0c:29:bf:76:b7 via eth3 [/FONT]
[FONT=monospace]2013:10:11-16:53:13  wahine dhcpd: DHCPREQUEST for 10.1.10.1 (10.1.1.2) from  00:0c:29:bf:76:b7 (aardvark) via eth2: wrong network. [/FONT]
[FONT=monospace]2013:10:11-16:53:13 wahine dhcpd: DHCPNAK on 10.1.10.1 to 00:0c:29:bf:76:b7 via eth2 [/FONT]
[FONT=monospace]2013:10:11-16:53:13  wahine dhcpd: DHCPREQUEST for 10.1.10.1 (10.1.1.2) from  00:0c:29:bf:76:b7 (aardvark) via eth4: wrong network. [/FONT]
[FONT=monospace]2013:10:11-16:53:13 wahine dhcpd: DHCPNAK on 10.1.10.1 to 00:0c:29:bf:76:b7 via eth4 [/FONT]


Can anyone think of a solution.  I don't want to manually change network addresses [that's what DHCP is for] and I'd rather not generate static entries for all my machines that travel.

Thoughts?

Thanks.


This thread was automatically locked due to age.
Parents
  • 0
    Hi, Derrick, and welcome to the User BB!

    EDIT: It's definitely Sophos, as it has started handing this same address to android phones as well.

    I don't see anything wrong in the log lines you showed us.  192.168.2.176 is the only IP offered by the UTM to 2c[:D]0:5a:79:1b:75.  All of the other lines are 2c[:D]0:5a:79:1b:75 asking for an IP that's not valid on eth0 and the UTM refusing.  If 192.168.2.176 is not associated to a MAC in the lease table, it can be assigned to another client.

    Cheers - Bob
Reply
  • 0
    Hi, Derrick, and welcome to the User BB!

    EDIT: It's definitely Sophos, as it has started handing this same address to android phones as well.

    I don't see anything wrong in the log lines you showed us.  192.168.2.176 is the only IP offered by the UTM to 2c[:D]0:5a:79:1b:75.  All of the other lines are 2c[:D]0:5a:79:1b:75 asking for an IP that's not valid on eth0 and the UTM refusing.  If 192.168.2.176 is not associated to a MAC in the lease table, it can be assigned to another client.

    Cheers - Bob
Children
  • 0 in reply to BAlfson
    Found the problem.

    There was a Sprint AirRave connected to the network via it's lan port instead of it's wan port.

    The AirRave has a built in DHCP server that hands out addresses in the 192.168.17.x range. 
    I switched the DHCP server from Sophos to a windows 2012 vm while trying to figure all of this out, and I'm a little surprised that windows didn't pick up on the co-existing server and disable itself, which would have instantly given me the indication that there was another one on the network.

    At any rate, everything seems to be chugging along fine now. Thank you for the assistance.