Get DHCP lease date
 

Hello,
We are having problems with Macs connecting to the work network. One of the questions that our IT dept asked is the lease date and time from the DHCP (ie when was the ip acquired). Something like what you get on Windows with Ipconfig /all. Neither the ifconfig nor the ipconfig getopt commands give any date and time info.

This is to try to figure out why some Macs get 'dropped' from the network (they get valid IP info from the DHCP, but they cannot ping anything not even the router)

Thanks

The lease info is stored in files under /var/db/dhcpclient/leases
So try, e.g.:
sudo more /var/db/dhcpclient/leases/en0

You can also turn on logging for DHCP via the command:
sudo ipconfig setverbose 1
Then look under /var/log and you will see a new log file "com.apple.IPConfiguration.bootp"


But if your Macs aren't able to ping the router, that would seem to be some other problem than a mere DHCP issue.
Try setting it to use a static IP while troubleshooting (thus sidestepping the DHCP issue) and then try to do the ping.

Thanks for the info, but that file does not have the date and time that the lease was obtained. when you run ipconfig /all on windows there is one line that says
Lease Obtained ..... : Thursday, August 24 2006
This is the info that our IT person is looking for.

We had tried static IP but with no immediate success. I'm not sure if it is something on the network or with the OSX clients. Of course IT says it is the Macs. but, they work fine in other locations, where DHCP is used.
The pinging would fail most of the time , ex if I sent 200 pings I might get 2 or 3 replies, or maybe none. The strange thing is that if you left the mac connected for a while, it would eventually be able to have constant communications.

sudo grep -A 1 LeaseStartDate /var/db/dhcpclient/leases/en0

(assuming the network in question is on en0--of course substitute en1, etc. if appropriate.)

Trevor

This info is in that file. As Trevor has pointed out, you can extract the relevant lines with 'grep'
Maybe you were confused by the date & time format. It is using the ISO 8601 standard date/time format. The time is UTC ("Greenwich Time")


The failure with ping would seem to indicate some more fundamental problem with your network.
Perhaps the Macs are connected to a faulty router or are connected via faulty cables.

The fact that there are occasional responses to a ping argues against this being the problem, but that said--what is set in the Macs at System Preferences > Sharing > Firewall tab > Advanced... button?

Trevor

pings with excessive packetloss tend to point to hardware problems.

Use known good cables, check/reboot the switches, make sure to use known good ports.

Just because your IT people have no earthly idea how a Mac works should not influence how they debug what sounds like plain network problems.

I would also reboot the switches, sometimes i run into a similiar problem where all the data drops get link lights but they are actually connecting at such a low speed they don't get assigned IPs nor can i mount network drives, nor can i ping anything

i would have the it dept. reboot your switches and see what happens

in all honesty a windows platform machine and an apple platform machine pretty much work in the same manner. people just chose to not recognize that

I tried the command
sudo grep -A 1 LeaseStartDate /var/db/dhcpclient/leases/en0
but it gives no results. when I do cat /var/db/dhcpclient/leases/en0 I get the following :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>LeaseIPAddress</key>
<string>146.243.135.85</string>
</dict>
</plist>

does it seem that my mac is not recording things properly? I'm running OSX10.3.9 with all the latest security patches.

On the network issue: back a couple of months when the problems started happening, we had tried a bunch of tests : moved mac laptops and desktops to drops that were used by working PCs, switched cables (btw, IT had rewired our area at the beginning of the year and had given out new patch cables for all systems), rebooted macs multiple times. The macs are various G5, G4, G3 desktops and laptops all on some version of 10.3.x As I said, only if one waited a while, the network would start working. People would come and tell me 'thanks for fixing it' ! Once they it got working, I would tell them to not shut down, just leave them going.
Recently I came back from vacation, and my laptop would not connect again. Eventually I created a new location in network preferences, and manually copied the settings on the previous one and that seemed to work. I had a PC pinging my laptop continually and I would switch locations between the 'good' and the 'bad' one. After every 'Apply' I would see that I got the same IP address, but the pinging from the PC would fail when I was on the bad one.
Tried the same method with a desktop, and it worked also. I don't know why.


Thanks again for all your help

It might just be a difference between 10.3 and 10.4 - I'm using 10.4.7

Did you try turning on logging via the command 'sudo ipconfig setverbose 1' as I recommended above?

Probably another difference in OS :
I just tried 'sudo ipconfig setverbose 1' and I get an error. Basically this reply:

usage: ipconfig <command> <args>
where <command> is one of waitall, getifaddr, ifcount, getoption, getpacket, set

With the 'ipconfig set -?' I get:
usage: set <interface name> < BOOTP | MANUAL | DHCP | INFORM | NONE > <method args>

Am I stuck on this problem?

You could try installing Tiger onto an external Firewire drive and then booting one of the troubled Macs from that external drive to see if it has a problem when running Tiger.

But as I said earlier, it would seem like you are concentrating on the wrong thing (DHCP). If your Mac has an IP address (static or otherwise) and none of the other machines on that network segment are using that IP address (check by pinging that IP address from some other machine and then using 'arp -a' and looking at the MAC hardware addresses) then I don't think your problems are DHCP-related.

I note that some people have had problems due to bugs in some versions of some routers. I vaguely recall that this was related to the "spanning-tree" feature.

That is purely an AppleTalk problem, it does not affect TCP/IP and can be solved by setting the ports to "portfast" (cisco) or equivalent, we've had a thread on that some time ago.

Supposing your IT people even know what that is, packet logging (tcpdump, ethereal) could also be helpful.

Ah yes - thanks for refreshing my memory.

It isn't necessary to involve the IT people. You could do the packet logging yourself by installing Ethereal (which runs under X11) via Fink.
But I would first try the experiment of installing Tiger as I recommended above.

First I'd like to thank you all for taking the time and providing all this info. you've been more helpfull than anywhere else, I really appreciate it.

back to the pain,, I don't have a copy of Tiger to try this. Hopefully soon (in my dept speak it means 3-4 months).
I kind of guessed that DHCP might not be the problem, i was trying to comply with the IT group which requested that date/time info. I had heard from someplace else about some issues with cisco switches: I've seen that the recommended settings from cisco is to set ports at 100Mb and full duplex, while macs prefer the ports to be autoconfigured. Also seen the part about "spanning-tree" (did not know that is is purely appletalk). I had given that info to IT, but did not get any response or comment. I'll try again.
Btw, i found a shareware iPNetMonitorX, which does show the lease date and time. I'd prefer if one could get that date info without software. I just hope I don't need to use it again before it's 21 day trial ends :)

Thanks again

You ought to be able to buy a copy of Tiger just for troubleshooting. Any reasonable organization would see that the $129 is pocket change compared to the time being spent.

Does the problem occur right away after a new DHCP lease?
(If so, you can easily supply the date & time info by just looking at your watch!)
In Tiger, there is a button in the Network preferences to request a new DHCP lease. If this isn't there in Panther, then you could still do it manually by just switching to a different "location" then back again.
(Set up a new network "location" in the Network preferences - e.g. it is often useful to have one that has no network connections at all - everything disabled)

You can set the speed and half/full duplex yourself in the network prefpane, but if that is the problem, the symptom is usually a very dead interface, not some packets getting through.

How high up in the corporate foodchain are you ?
Sometimes the only way to get things done is to
• have someone with authority tell the head of IT to stop the circus and get to solve problems instead of creating them or,
• in really desperate cases, get funding for comptetent external consultants to shame them into getting it together

just curious, have you tried just rebooting the switches?

Sorry, I don't have access to the switches. Since we're all in one 'big' network, and the macs are not isolated, I think IT won't reboot them unless they really have to.

Like a flounder, bottom feeder. And since it appears that the problem eventually goes away, it becomes a back burner, (even to me). Now that there seems to be a solution (new "location" see below)..

I don't think it does. I've had at least one case where the user's G5 was working 'normally' for a while, he went away from his desk for half an hour or so, and when he came back, his station could not communicate in the network. I had seen elsewhere mentioned the part about creating a new "location", and that seemed to fix his problem right away. I'm waiting on one user to bring his problematic laptop in to test this again. That solution kind of switches some of the suspicions back on the mac side? Still does not explain the problem though.
Thanks

Well I jinxed that one. Another G5 got dropped from the network AND creating a new "location" did not cure the problem. I saw that he got a new IP address after I created the new location. Switching between the 'bad' and 'new' location did change IP addresses. When I created some more new 'locations', they would get the most recent IP.
So I'm back to square 1. At least this time I wrote down the time that I got the IP address so I can answer IT on that...

Note that it isn't (I think) necessary to create a new location each time the problem occurs. It would seem that what you have found is that switching to a different "location" fixes the problem.
One thing that doing a "location" switch does is get a new DHCP lease.
The fact that requesting a new lease fixes the problem doesn't really throw any suspicion on the problem being on the Mac side.

And you still need to investigate why 'ping' fails when the Mac seems to have a valid IP address. Is there some network component that prohibits pings (or other transmissions) based on a blacklist or whitelist of MAC addresses or something?

I'm not sure I understand - if it didn't fix the problem, then the "new" location could also presumably be described as "bad".

But this gives you something to go on. DHCP servers are normally configured to give the same IP address to the same machine (based on the machine's hardware MAC address). So if switching to a new "location" (which requested a new lease) resulted in a change of IP address, that would seem to indicate that either the DHCP server is malfunctioning (or isn't configured the usual way) or that the previous IP address was not available (since it was found to be in use by some other machine on the network for example).

Check if the old IP address is now in use by some other machine.
(e.g. by pinging it, then looking at the results of 'arp -a')