PDA

View Full Version : DHCP - cant get IP, from DHCP server?



bigkm
10th October 2005, 11:40 PM
edit: i accidently wrote bind9 for somestupid reason its ment to be dhcp3 must be the trailing digit.

ok i cant get an ip at work since like last wednesday. I put this here as its more related to command line and i'd rather get answers from fellow unix nuts. :)

At work
i have had an assigned ip (in the dhcp3.conf or whatever) and since the other day i haven't been able to get an ip. (both ethernet and wireless ).every other system on the network gets an ip fine. the weird thing is that it will get the ip if bootP is selected in sysprefs and also get the ip of router and subnet, dns ... when set to dhcp with manual address.

so i took out the assigned address and still nothing,
cleared my arp cache
formated my mac
reinstalled tiger.
changed my mac address.

At Home
i have a cheap router and it gets an ip straight away.

This problem is the same as it was before the format. the strange thing is that it did this(the same as at work) at another location as well . which makes me confused.

what else is there to do. the server at work is debian running dhcp3, and has a log
log looks like this with these settings.


dhcp with manual address


Oct 10 17:18:45 localhost dhcpd: DHCPINFORM from 192.168.1.26 via eth1
Oct 10 17:18:45 localhost dhcpd: DHCPACK to 192.168.1.26


dhcp


Oct 10 17:18:46 localhost dhcpd: DHCPDISCOVER from 00:0d:93:6b:28:6a (jet) via eth1
Oct 10 17:18:47 localhost dhcpd: DHCPOFFER on 192.168.1.245 to 00:0d:93:6b:28:6a (jet) via eth1
Oct 10 17:18:48 localhost dhcpd: DHCPDISCOVER from 00:0d:93:6b:28:6a (jet) via eth1
Oct 10 17:18:48 localhost dhcpd: DHCPOFFER on 192.168.1.245 to 00:0d:93:6b:28:6a (jet) via eth1
Oct 10 17:18:50 localhost dhcpd: DHCPDISCOVER from 00:0d:93:6b:28:6a (jet) via eth1
Oct 10 17:18:50 localhost dhcpd: DHCPOFFER on 192.168.1.245 to 00:0d:93:6b:28:6a (jet) via eth1
Oct 10 17:18:55 localhost dhcpd: DHCPDISCOVER from 00:0d:93:6b:28:6a (jet) via eth1


the server is working and is giving address to many windows boxes and printers and linux boxes.
but my ibook doesn't get anything anymore which has got me scrachting my head.

can anyone help.

Nevets_Anderson
11th October 2005, 07:01 PM
I'm a little confussed

>i have had an assigned ip (in the dhcp3.conf or whatever) and since the other day i haven't been able to get an ip.

And then you talk about DHCP (Dynamic Host Configuration Protocol)

You shouldn't have to do anything at the command line level

Are you using the system prefs? (apple menu system Preferences Network > ethernet see attached graphic)

If you have an assigned ip then you should be manually entering the unique ip address and the router address subnet DNS info etc

If your using dhcp the Mac will find all of that for you .

Hope this helps

bigkm
11th October 2005, 09:38 PM
its confusing as ive tried everything i can think of and am trying to explain this so i don't get people wasting there time with solutions i already tried.


Are you using the system prefs?
yes

i couldn't see a networking forum on appletalk so it got posted in my favourite section.


If you have an assigned ip then you should be manually
i used the wrong word there maybe mac filtering is a better way of explaining what i have tried setting ( and unsetting) on the dhcp server.



If your using dhcp the Mac will find all of that for you
ok now we are getting somewhere, this is the problem (mac wont get one)

The Architect.mac
11th October 2005, 09:42 PM
yeh its definitely at your end, i reckon

Im hesitant to say a couple of Lease renewals as a clean format is the biggest leat renewal i know

when you say changed mac address - are we talking the hardware mac address (didn't think you could) and i guess is that address correctly filtering (ie. thought you changed something you couldn't so you changed the filter address on the server)??

edit - In windows your comp has a trust and when you format that trust needs to be removed and the computer rejoined to the domain to be trusted again. - could there be something similar involved - but why would it stop working in the first place - unless your trust was removed accidentally - sorry windows in me got loose for a second

Hope it works out

bigkm
11th October 2005, 09:52 PM
so you changed the filter address on the server)??

the server gives out addresses to everyone , ive tried commenting it out and restarting dhcp3 and still nothing it had been working for a long time previously.


the reason for the format was a slightly corrupt hdd from dodgy ram that has been dodgy from the day i got it.

bigkm
11th October 2005, 09:54 PM
In windows your comp has a trust and when you format that trust needs to be removed and the computer rejoined to the domain to be trusted again.

that wont be the problem as we don't have any windows servers. only linux.

thanks for sparking ideas.

The Architect.mac
11th October 2005, 09:58 PM
mac hardware address filtering is the ability to allow and disallow computers based on hardcoded individual hardware mac addresses (mac doesn't mean macintosh in this case) usually related to WLAN to stop intruders

ip addresses, subnet masks, gateways and DNS- domain name servers are handed out by dhcp- dynamic host control protocol (i think) servers

i think its a trust issue of some form or your network port is stuffed and the cable is twisted so the 0s are getting through but not the 1s

edit - obviously not trust issue as linux doesn't use trusts hey? bummer

Nevets_Anderson
11th October 2005, 10:07 PM
What's interesting is what has changed? What hapened last wednesday?

Are you running the Debian DHCP box or is your admin doing this? Did she/he do anything to the DHCP box last wednesday?

Another thing to look for is are you for example pluging your ethernet into say a switch that then talks to the router? Has someone done something to the switch settings recently? Have you tried pluging into diffrent parts of the network?

I'd also look at the need for filling out the DHCP Client ID the interesting thing about that is that each must be unique!

If your still having troubles and are comfortable with packet sniffing you might like to run tcpdump or install / run ethereal and see what's going on from that level... (Be warned get permission from your system admin if you do run a packet sniffer some people get very techey when you start running a packet sniffer on a network)

Sorry hope I haven't confused you further!

bigkm
11th October 2005, 10:27 PM
ip addresses, subnet masks, gateways and DNS- domain name servers are handed out by dhcp- dynamic host control protocol (i think) servers
i know this , i've been studing network engineering for bout 2 years. thanks anyway.


I'd also look at the need for filling out the DHCP Client ID
i always do this (ive tested almost every different config that i posibly could think of


Are you running the Debian DHCP box or is your admin doing this? Did she/he do anything to the DHCP box last wednesday?
im like the co-admin. we haven't done anything at all to the server.

there is also a wireless access point that is just a bridge. and that has the same characteristitcs as the ethernet conection.




If your still having troubles and are comfortable with packet sniffing you might like to run tcpdump or install / run ethereal and see what's going on from that level... (Be warned get permission from your system admin if you do run a packet sniffer
brilliant idea. im also going to take my mac mini in tomorrow just to help narrow things down a bit.



people get very techey when you start running a packet sniffer on a network
thats if you let them know :)


the only thing i can think of happening last wednesday is that my mate at tafe was running ettercap (arp poisoning) i've cleard all arp cache and done a format,



Sorry hope I haven't confused you further!
Not at all. :)

bigkm
11th October 2005, 11:04 PM
sweet tested it out and came up with this to try tomorrow.


sudo tcpdump -v udp port 67

Nevets_Anderson
11th October 2005, 11:23 PM
Cool ! let us know how you go

Talking of packet sniffing tcpflow is also nice for this sort of stuff
ethereal (esp the most recent version) is getting very very good although I haven't run it on anything huge of late. Best way to install that is via Fink...

Marc Liyanages tcpflow (http://www.entropy.ch/software/macosx/)

Good luck!

:)

bigkm
11th October 2005, 11:32 PM
i had ethereal installed on pather was quite good.

bigkm
12th October 2005, 10:49 AM
i took the mini in today and its the same as the ibook.
ok here is the weird thing both macs will not get an ip from the linux dhcp server.

yet will get them from anywhere else.

Nevets_Anderson
12th October 2005, 11:23 AM
Did you run a packet trace?

What was going on at that level?

Other thing is have you Googled the version of Debian DHCP server your running?
Patches? Updates? Knowin issues?

internet
12th October 2005, 12:43 PM
how very bizarre, i haven't heard of this happening before..
is the MAC address on the mini and ibook the original standard address?
plug them into the network, make them request an address, then check the arp entries on the DHCP server, see if it is seeing them at all
check dhcpd logs on the dhcp server

bigkm
12th October 2005, 01:59 PM
Originally posted by internet@Oct 12 2005, 12:43 PM



check dhcpd logs on the dhcp server
they are in my original post. (at top).


as for the tcp dump it making the request and getting a reply with a dynamicly assigned ip. but its just not doing anything with them its like my mac's are ignoring the reply.

and we tried updates on the server this morning as well.

purana
12th October 2005, 02:19 PM
I am so lost by thread, but I have one question.

Who is the DHCP server when things dont work on your mac? Do you know what platform the DHCP server is on that is dishing out DHCP.

EDIT: just flicked back appears the problem DHCP server is a Debian box running DHCPD v3 I am guessing.

Anyways, my one and only suggestion to you is to logon to the Debian box that is acting as the DHCP server and as root issue the following command;

route add -host 255.255.255.255 dev eth1

You might need to change the eth1 to reflect the ethernet device to which the dhcpd service is pushing out ip's on. (although from your posts it looks like eth1 according to some previous log pastes you did)

Make this change, and then possibly see if the problem mac picks up the DHCP correctly. If not, then restart the DHCPd server on debian and try again. Should it still not pick up an IP from the server, then I guess I will keep working on it.

Let us know how you go.

Should it work, then you will need to add the route command into one of the startup scripts so that its enabled after every reboot.

Chow

bigkm
12th October 2005, 03:34 PM
i think were getting somewhere now but no luck with that route command.

any other ideas

purana
12th October 2005, 03:54 PM
Give me a break down on the setup...

What version of Debian?
What version of dhcpd on debian? How was it installed via apt-get install? or via source compile?

What modifications have you done to the dhcpd.conf on debian, any chance I can have a copy for a peek? Feel free to contact me for email address?

Nothing else comes to mind at the moment... give me an hour and half to get home. I need to leave work right now.

The problem is only with your mac when obtaining DHCP ip right, its not affecting any other host to which this DHCP server on debian issues IP's right?

Have you made any changes to the problem mac other then those that require the GUI to do them.. ie have you vi'd any files manually..

EDIT: PS I am a debian guy and I have never had any problems with Debian and the DHCP server that ships with it. Especially with dishing out IP's to a mac. It just worked and worked all the time. But given time and more information I reckon it can be solved. Just like most problems.

bigkm
12th October 2005, 03:59 PM
debian sarge 3.1
dhcpd 3.0.3
apt-get (yes)

cant give the dhcpd.conf (yet will need permision for that(verbal))

im mac/ debian person too.


ill have a go at my home debian box to see if that will give me an ip.

purana
12th October 2005, 06:42 PM
If you remove the static DHCP assignment from within your DHCPd.conf and then restart DHCPd does the mac get a normal DHCP ip from the pool.

My guess is its probably a syntax problem on the dhcp server config file, however you cant give me that for confirmation.

So hash out the static mac address rule that gives you a static assignement from dhcp server and see if it works. If it does you have stuffed the static assignment up.

Nevets_Anderson
12th October 2005, 07:01 PM
Ok hows this for an idea

If you have an old dumb hub and a few cables to hook it up try this

take in your mac mini in to work and hook the hub up to the switch

Set the ip address manually on the mini

Turn on tcpdump on the Mini in promiscuous mode - you should get some broardcast packets at least from the network. (dosen't matter what ip address the mini has as it's listening to everything)

Plug in your ibook with what ever dhcp settings you might like to try

See what happns via the mac mini and tcpdump!

Good luck! And keep us informaed!

Nevets

Currawong
12th October 2005, 08:57 PM
This might be useless info:

While in Japan, I was plugging various Macs (running OSX) and an Airport Express into an ADSL modem router. Nothing would pick up an IP address or other info from the hub, unless the hub was restarted each time. I only wish I'd had the time to determine whether it was hardware or firmware (router software) that was the problem.

bigkm
12th October 2005, 10:26 PM
Originally posted by purana@Oct 12 2005, 06:42 PM
If you remove the static DHCP assignment from within your DHCPd.conf and then restart DHCPd does the mac get a normal DHCP ip from the pool.

My guess is its probably a syntax problem on the dhcp server config file, however you cant give me that for confirmation.

So hash out the static mac address rule that gives you a static assignement from dhcp server and see if it works. If it does you have stuffed the static assignment up.
first thing i did was comment that out.

the ip i had assigned was 192.168.1.26
and thats was it was offering.

but when i hashed it out the servers logs showed that it was trying to give me something like 192.168.1.267, so the assignment is not the problem,

there are numerous print servers, ubuntu, debian, win2000, winxp ,
systems on the network all with ip's getting through,

i pluged my ibook into a switch at another location that was running a win 2000 advanced server( this was the dhcp server as well) and it(ibook) got an ip.

im thinking since the mini wouldn't get an ip this is some sort of cross platform debian - OS X , issue.

sfcoy
12th October 2005, 11:07 PM
Here's an idea out of left field (because I've seen it happen).

Make sure there are no other devices on your network that are also trying to hand out DHCP addresses. Could be your Mac's are listening to the wrong one and then getting an address that doesn't work on your network (or an address that someone else already has).

Steve C.

bigkm
13th October 2005, 12:05 AM
we would have a lot more errors, if there was more than one dhcp server.

Nevets_Anderson
13th October 2005, 09:41 AM
i pluged my ibook into a switch at another location that was running a win 2000 advanced server( this was the dhcp server as well) and it(ibook) got an ip.

im thinking since the mini wouldn't get an ip this is some sort of cross platform debian - OS X , issue.

Hmm so it's not the mac ! I'd love to do 2 packet traces 1 where the mac works and runs ok and one where the debian fails - would be very interesting to se whats going on.....

Just a thought as this may be related to a timing issue how is your ethernet configured?
Automatically or manual? Full duplex or half? Standard Jumbo or custom packet size? It may be worth playing around with this setting to see if you can slow / speed things up ....

The plot thickens!

purana
13th October 2005, 09:57 AM
Originally posted by bigkm@Oct 12 2005, 10:26 PM
im thinking since the mini wouldn't get an ip this is some sort of cross platform debian - OS X , issue.
Not likely, as people long before you would of had this problem on the web.

And seeing as I am a debian guy, I've had no problems in the past with my Debian machine dishing out DHCP to my Powerbook, wifes Powerbook, Mac mini or old G3 towers.

Its something in your environment. I am not convinced its the mac, although certainly think something is wrong with the debian setup of DHCPd server.

bigkm
13th October 2005, 10:43 AM
i will post the dhcp dump soon.

sfcoy
13th October 2005, 11:15 PM
Originally posted by bigkm@Oct 13 2005, 12:05 AM
we would have a lot more errors, if there was more than one dhcp server.
Not necessarily. If most machines already have an address, they will keep asking for it and getting it from the original source.

As I mentioned, I've seen this before and it only affected one or two machines out of 40 or so.


Nevertheless, a tcpdump of the dhcp requests will prove this one way or the other.

Steve C.

bigkm
14th October 2005, 12:34 AM
ok this is wat i came up with.

this is the tcp dump at home. will post the next one in about 10 hours.


00:32:22.230742 IP (tos 0x0, ttl 255, id 50861, offset 0, flags [none], length: 328) 0.0.0.0.bootpc > broadcasthost.bootps: BOOTP/DHCP, Request from 00:0d:93:6b:28:6a, length: 300, xid:0x35714796, flags: [none] (0x0000)
Client Ethernet Address: 00:0d:93:6b:28:6a [|bootp]
00:32:22.232448 IP (tos 0x0, ttl 64, id 51558, offset 0, flags [none], length: 341) 192.168.0.1.bootps > broadcasthost.bootpc: BOOTP/DHCP, Reply, length: 313, xid:0x35714796, flags: [none] (0x0000)
Your IP: 192.168.0.26
Server IP: 192.168.0.1
Client Ethernet Address: 00:0d:93:6b:28:6a [|bootp]



from what i can remember the dump i did at work came up with.
Server IP: localhost

i think this might be a good start.
i will post back in the morning.

bigkm
14th October 2005, 10:39 AM
heres the dump fro work it seems to be missing the Server IP , bit.


10:41:01.986521 IP (tos 0x0, ttl 255, id 50905, offset 0, flags [none], length: 328) 0.0.0.0.bootpc > broadcasthost.bootps: BOOTP/DHCP, Request from 00:0d:93:6b:28:6a, length: 300, xid:0x12bac1f5, flags: [none] (0x0000)
Client Ethernet Address: 00:0d:93:6b:28:6a [|bootp]
10:41:04.191569 fe80::20d:93ff:fe6b:286a > ff02::fb: HBH (padn)(rtalert: 0x0000) [icmp6 sum ok] icmp6: multicast listener report max resp delay: 0 addr: ff02::fb [hlim 1] (len 32)
10:41:04.433604 fe80::20d:93ff:fe6b:286a.mdns > ff02::fb.mdns: 0 [5q] [5n][|domain] (len 248, hlim 255)
10:41:04.468912 fe80::20d:93ff:fe6b:286a > ff02::fb: HBH (padn)(rtalert: 0x0000) [icmp6 sum ok] icmp6: multicast listener report max resp delay: 0 addr: ff02::fb [hlim 1] (len 32)
10:41:04.565028 fe80::20d:93ff:fe6b:286a > ff02::2: HBH (padn)(rtalert: 0x0000) [icmp6 sum ok] icmp6: multicast listener done max resp delay: 0 addr: ff02::1:ff6b:286a [hlim 1] (len 32)
10:41:05.950933 IP (tos 0x0, ttl 255, id 50906, offset 0, flags [none], length: 328) 0.0.0.0.bootpc > broadcasthost.bootps: BOOTP/DHCP, Request from 00:0d:93:6b:28:6a, length: 300, xid:0x12bac1f6, flags: [none] (0x0000)
Client Ethernet Address: 00:0d:93:6b:28:6a [|bootp]
10:41:05.951488 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], length: 328) localhost.bootps > 192.168.1.247.bootpc: BOOTP/DHCP, Reply, length: 300, xid:0x12bac1f6, flags: [none] (0x0000)
Your IP: 192.168.1.247
Client Ethernet Address: 00:0d:93:6b:28:6a [|bootp]
10:41:05.954490 fe80::20d:93ff:fe6b:286a > ff02::1:ff6b:286a: HBH (padn)(rtalert: 0x0000) [icmp6 sum ok] icmp6: multicast listener report max resp delay: 0 addr: ff02::1:ff6b:286a [hlim 1] (len 32)
10:41:06.064643 :: > ff02::1:ff6b:286a: [icmp6 sum ok] icmp6: neighbor sol: who has fe80::20d:93ff:fe6b:286a (len 24, hlim 255)
10:41:07.097393 fe80::20d:93ff:fe6b:286a > ff02::2: [icmp6 sum ok] icmp6: router solicitation (src lladdr: 00:0d:93:6b:28:6a) (len 16, hlim 255)
10:41:07.322142 IP (tos 0x0, ttl 255, id 50907, offset 0, flags [none], length: 328) 0.0.0.0.bootpc > broadcasthost.bootps: BOOTP/DHCP, Request from 00:0d:93:6b:28:6a, length: 300, xid:0x12bac1f6, secs:2, flags: [none] (0x0000)
Client Ethernet Address: 00:0d:93:6b:28:6a [|bootp]
10:41:07.322664 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], length: 328) localhost.bootps > 192.168.1.247.bootpc: BOOTP/DHCP, Reply, length: 300, xid:0x12bac1f6, secs:2, flags: [none] (0x0000)
Your IP: 192.168.1.247
Client Ethernet Address: 00:0d:93:6b:28:6a [|bootp]

sfcoy
14th October 2005, 11:40 PM
Originally posted by bigkm@Oct 14 2005, 10:39 AM

10:41:07.322664 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], length: 328) localhost.bootps > 192.168.1.247.bootpc: BOOTP/DHCP, Reply, length: 300, xid:0x12bac1f6, secs:2, flags: [none] (0x0000)
Your IP: 192.168.1.247
Client Ethernet Address: 00:0d:93:6b:28:6a [|bootp]
This indicates to me that your machine is responding to its own dhcp requests (see the "localhost.bootps" and the really quick response time - 0.5ms!).

Are you sure that you're not running a DHCP daemon on your own?

Playing with MacOS X Server maybe?

Steve C.

bigkm
16th October 2005, 12:42 AM
Running client version of Tiger.

did a " ps -aux"

there is no bootpd server running and that ip is showing up in the servers syslog.

sfcoy
16th October 2005, 02:46 AM
Here is what I get on my powerook from my local network:


02:38:36.501496 IP 0.0.0.0.bootpc > broadcasthost.bootps: BOOTP/DHCP, Request from 00:0a:95:f8:8b:88, length: 300
02:38:36.508346 IP orodruin.resolvesw.com.au.bootps > nardol.resolvesw.com.au.bootpc: BOOTP/DHCP, Reply, length: 300


orodruin is the linux box I use for my firewall and local dhcp server, and nardol is the host name of my Powerbook. On a 100Mb network note the response time is in the order of 7ms.

Are you on a 1000Mb network? That would be the only explanation for your 0.5ms response time aside from the machine responding to itself.

If you try the tcpdump again, add the "-n" option so that it displays ip addresses instead of host names.

Finally, you should probably be looking for a "dhcpd" process rather "bootpd".

Edit: Doh! Of course a "netstat -anf inet" will tell us straight away if there is a server listening on port 67 of your Mac.

Steve C.

Nevets_Anderson
16th October 2005, 06:53 PM
Had a quick look at the above

This may be worth a try

Try turning off ip6 in the advanced section of your ethernet set up

Unless your doing some advanced network stuff you don't need it and it's good security practice ... if you don't use it don't turn it on


This is a tcpdump from my power book to an asante router notice no mention of ip6



18:56:27.843898 IP 0.0.0.0.bootpc > broadcasthost.bootps: BOOTP/DHCP, Request from 00:0a:95:99:00:92, length: 300
18:56:27.846958 IP 192.168.123.254.bootps > broadcasthost.bootpc: BOOTP/DHCP, Reply, length: 313
18:56:28.853481 arp who-has 192.168.123.125 tell 0.0.0.0
18:56:29.153686 arp who-has 192.168.123.125 tell 0.0.0.0
18:56:29.456575 arp who-has 192.168.123.125 tell 0.0.0.0
18:56:29.756921 arp who-has 192.168.123.125 tell 0.0.0.0
18:56:30.062580 arp who-has 192.168.123.125 tell 192.168.123.125


Let us know how you go

Nevets

bigkm
17th October 2005, 11:18 AM
ok heres the tcp dump from work
im on the verge of submiting a bug report to apple.

11:21:15.698519 IP (tos 0x0, ttl 255, id 254, offset 0, flags [none], length: 328) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0d:93:6b:28:6a, length: 300, xid:0x44948807, flags: [none]
Client Ethernet Address: 00:0d:93:6b:28:6a [|bootp]
11:21:15.699055 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], length: 328) 127.0.0.1.67 > 192.168.1.26.68: BOOTP/DHCP, Reply, length: 300, xid:0x44948807, flags: [none]
Your IP: 192.168.1.26
Client Ethernet Address: 00:0d:93:6b:28:6a [|bootp]
11:21:16.804659 IP (tos 0x0, ttl 255, id 255, offset 0, flags [none], length: 328) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0d:93:6b:28:6a, length: 300, xid:0x44948807, secs:1, flags: [none]
Client Ethernet Address: 00:0d:93:6b:28:6a [|bootp]
11:21:16.805158 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], length: 328) 127.0.0.1.67 > 192.168.1.26.68: BOOTP/DHCP, Reply, length: 300, xid:0x44948807, secs:1, flags: [none]
Your IP: 192.168.1.26
Client Ethernet Address: 00:0d:93:6b:28:6a [|bootp]


192.168.1.26 is the the specified ip i have for myself set on the server

sfcoy
17th October 2005, 02:13 PM
Can you do a "netstat -anf inet" on your machine?

The 127.0.0.1.67 implies that the address is coming from your computer somehow.

Steve C.

Heidi-Lee
17th October 2005, 04:59 PM
Originally posted by sfcoy@Oct 17 2005, 02:13 PM

The 127.0.0.1.67 implies that the address is coming from your computer somehow.
hehe..

That line means....

127.0.0.1:67 (its not address 127.0.0.1.67 per se)

ie.. port 67 (something is listening) ie. as indicated in the output BOOTP/DHCP etc :)

Expressed as 127.0.0.1.67 (which could be confusing, but it seems this is how its expressed).

bigkm
18th October 2005, 12:48 AM
The 127.0.0.1.67 implies that the address is coming from your computer somehow.

well system preferences says that i can't connect blablabla... and i have a self assigned IP.
IMHO this is where this is coming from.

no one has been able to explain is the reason i can before work plug my ibook in at home and then sleep it and then go straight to work and unsleep it and it not get an ip. but it works perfect if i set to BOOTP(at work) and not dhcp.

zbaron
18th October 2005, 07:53 PM
Well, that response coming from 127.0.0.1 is just *wrong*. The response should come from the IP address of the Debian box that is running DHCPd. Do you have Internet Sharing on per chance?

In fact, if that packet is really coming from the server, then the configuration on the server is sick and needs some attention. I'd say, if this is the case, the Mac is doing the right thing and ignoring a DHCP reply from a loopback address.

Would it be possible to run a tcpdump on the server as well? Something like "tcpdump -n -i eth0 -vvv udp port bootps or udp port bootpc".

Edits: i'll get that command right sooner or later!

bigkm
18th October 2005, 08:03 PM
no internet sharing



let i remind anyone who hasn't read the full post i have formated the iBook and done a complete reinstall
and the problem is the same as it was before the reinstall.

which logic would point that toward the server, but the fact that every other kind of os can get an ip except my two mac's.

zbaron
18th October 2005, 09:07 PM
After a little more thought, it would be impossible for a host to receive a DHCP request on its own loopback address ... so we can forget about that one.

However, without knowing anything about your DHCP server configuration, but after some reading and checking of my own ISC DHCP servers, here are a few things to check.

Can you check in the server configuration (dhcpd.conf) for a "server-identifier" option. If its there and it has 127.0.0.1 after it, get rid of that line or comment it out and restart the DHCP server. If however there is a hostname there you could still get rid of that line. Or, check in /etc/hosts.

I've seen a few Linux distributions do this:


127.0.0.1 localhost localhost.localdomain myname myname.mydomain

Where as it should really be something like:


127.0.0.1 localhost localhost.localdomain
192.168.n.n myname.mydomain myname

It would be better to remove the "server-identifier" if it exists than playing with /etc/hosts. Maybe some other services on the box like resolving to 127.0.0.1. The only reason I can think of for keeping this particular option in the dhcpd.conf file is if the server is multi-homed and only wants to listen for DHCP requests on one of its interfaces (although, there are better ways to acheive that as well).

bigkm
18th October 2005, 09:25 PM
heres the dhcpd.conf
i've substituted domain for our domain name.
and not included a heap of print servers and other pc's mac filters.
ill try that server-identifier thing when i get to work in the mornign


server-identifier blue.domain.com.au;
authoritative;
ddns-update-style interim;
default-lease-time 600;
max-lease-time 7200;
log-facility local7;

subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.51 192.168.1.254;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option domain-name "lan.domain.com.au";
one-lease-per-client on;
default-lease-time 14400;
max-lease-time 14400;
option ip-forwarding off;
option time-offset 10000;
option routers 192.168.1.1;
option domain-name-servers 192.168.1.1;
}


...
//various other filters not included
//iBook setting
host jet {
hardware ethernet 00:0d:93:6b:28:6a;
server-name "jet.lan.domain.com.au";
fixed-address 192.168.1.26;
}

zbaron
18th October 2005, 09:38 PM
Besides the server-identifier, you should remove the "server-name" option from the "host jet" section. The client will be able to build its name by combining the hostname and the domain-name options.

A suitable option to substitute for "server-identifier" would be "server-name".

eg: server-name "blue.domain.com.au";

The "server-name" attribute just sends the provided string as name of the DHCP server to the client in the response, although it should be a properly resolvable hostname.

bigkm
19th October 2005, 10:41 AM
eg: server-name "blue.domain.com.au";
Congratulations and Thank you

that line did the trick.


thank you to anyone else who helped

zbaron
19th October 2005, 12:27 PM
Awesome! Always glad to hear of successful problem resolutions. I guess out of this, we now know that the OS/X dhcp client will discard any responses that appear to come from invalid servers.