open Suse 12.1 dhcpcd dhclient issues

English Network/Internet
#1

I am on a corporate network (run by windows gurus) my network is a 10.10.22.000 netmask 255.255.254.0
I am a Linux people so I am on my own here

Working on testing SuSe 12.1 for potential use by my peers (Suse 11.2 and 11.4 did not have any problem => exact same computer)
Initially installed 64 bit (what I really wanted to test) and had a problem => tried 32 bit same problem

Problem is: when my computer boots (or I do a /etc/init.d/network restart) my eth0 gets an Ip address of 192.168.0.21 (not valid in my network)

If I do a “killall dhpcd” then a “/sbin/dhclient eth0” I get a proper 10.10.23.49 IP address (very reliably and network / internet access are ok)

Now for second problem (symptom) however if I do a “host $(hostname)” my host name is not registered with corporate DNS via DHCP

so
problem 1: dhcpcd gives me a bogus IP address
problem 2: dhclient gives me a good IP address but does not register my hostname with DNS

“yast network” is configured for “traditional method with ifup”

In searching through this forum I find references to sytemd vs sysvinit in this area and since this is a “default” install I see pid 1=systemd
and running /etc/init.d/network shows “redirecting to systemctl”

I have “pretty much” duplicated the settings in “yast2 network => network card” between a SuSe 11.4 system (I have several computes at my desk) and the SuSe 12.1 system

I am pretty sure this is a SuSe 12.1 issue (may or may not be related to systemd init)
but don’t find any “answers” on the forum for this problem:
(I did an “update” to the last versions of everything for 64 bit but 32 bit is running whatever was on the install DVD)

  1. is this a real problem or just me or something I missed during install
  2. is there a known fix for it
  3. what more data do I need to post for someone to know what is happening?
#2

Sounds to me like your machine may appear brand new to the Windows Domain (I assume that’s the case in a “corporate network” run by Windows Admins).

Recommend you ask your Windows Admins to remove your existing machine account (NOT User Account) from the Domain and re-join.

Also, I suspect there may be a rogue DHCP server somewhere in your network. You didn’t install DHCP server services on your machine, did you? If you can verify you didn’t make that kind of mistake yourself, ordinarily the issue would be someone else’ problem, but if you absolutely want to find out where you’re getting your 192.168.x.y address from, you may need to run something like Wireshark to inspect the DHCP packets. Or, this could actually be a “network designed feature” to catch rogue clients… :wink:

HTH,
TS

#3

On 2012-03-01 23:36, tsu2 wrote:
>
> Sounds to me like your machine may appear brand new to the Windows
> Domain (I assume that’s the case in a “corporate network” run by Windows
> Admins).

But the windows dhcp server would give an IP anyway, before joining the
domain (you need an IP to negotiate joining/login_to the domain) - unless
configured to give IPs to certain machines only. Interesting…

Anyway, that different dhcp clients get different address ranges is weird.

> Also, I suspect there may be a rogue DHCP server somewhere in your
> network.

Looking at /var/lib/dhcpcd/dhcpcd-eth0.info it might be possible to
determine the machine. I see an entry in a virtual vmware guest I have
running 12.1:


CLIENTID='01:00:0c:29:6b:70:77'
DHCPCHADDR='00:0c:29:6b:70:77'

and

Elanor:~ # arp -a
? (192.168.74.1) at 00:50:56:c0:00:08 [ether] on eth0
? (192.168.74.2) at 00:50:56:fa:4c:30 [ether] on eth0

Elanor:~ # ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0C:29:6B:70:77  <==
inet addr:192.168.74.131  Bcast:192.168.74.255  Mask:255.255.255.0

So that’s not the dhcp server mac’s. There must be a way to determine the
IP or the MAC of the dhcp server. One is by using wireshark, but I hoped to
find a easier one.

Maybe this:


Elanor:~ # dhcpcd-test eth0
info, eth0: hardware address = 00:0c:29:6b:70:77
info, eth0: broadcasting for a lease
debug, eth0: sending DHCP_DISCOVER with xid 0x5158ef5
debug, eth0: waiting for 10 seconds
debug, eth0: sending DHCP_DISCOVER with xid 0x5158ef5
debug, eth0: got a packet with xid 0x5158ef5
info, eth0: offered 192.168.74.136 from 192.168.74.254
....

I think it means that the server 192.168.74.254 offered me a lease.

The OP can choose which dhcp client to use, so that would solve his current
problem:


/etc/sysconfig/network/dhcp:
DHCLIENT_BIN="dhclient"

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

#4

Try deleting the files in “/var/lib/dhcpcd” and then or at least restart the network.

That’s where dhcpcd keeps its cache.

For “dhclient”, try changing settings – use Yast “/etc/sysconfig” editor to change the dhcp client you are using to “dhclient”. It’s possible that just running “dhclient” from the command line doesn’t do everything it should.

#5

First I am thanking everyone for their input: all together it helped me find the problem

  1. do a cat /var/lib/dhcpcd/dhcpcd-eth0.info
    you get some useful data => the DHCP server was DHCPSID=‘10.10.22.46’ (this is one of my other computers)

  2. that computer was running vmware with the network in NAT mode (according to vmware this should not be giving out IP(s) to external computers)
    (no virtual machine actually up just /etc/init.d/vmware start done; or actually left over from running a virtual machine and shutting it down)

  3. did /etc/init.d/vmware stop (problem with 12.1 dhcpcd still there)

  4. turned off the computer with vmware and “low and behold” the SuSe 12.1 dhcpcd gets its IP from the corporate server and all is well

  5. rebooted the computer with vmware => problem still gone? (will have to see if it comes back when I start a virtual machine)

Summary: something about SuSe 12.1 dhcpcd is allowing it to get to a vmware 4.0 player in a near by computer with network in NAT mode and no virtual machine actually up and running

This is undoubtedly a vmware issue and I can identify it and have a work around => but it is an important discovery since we have dozens of Linux computers running vmware players

I hope the info posted here; which was of great help to me; also helps others…

Since I am “tasked” to be testing SuSe 12.1 for others use I will investigate some of the other suggestions as they may prove useful in increasing my general knowledge and I still don’t completely understand why dhcpcd behaves differently from dhclient but the “default” of dhcpcd is now working for me…

#6

On 2012-03-03 00:06, tbuckeyne wrote:

> 2) that computer was running vmware with the network in NAT mode
> (according to vmware this should not be giving out IP(s) to external
> computers)
> (no virtual machine actually up just /etc/init.d/vmware start
> done)

I heard of a similar thing happening on a school nearby, and they were
using windows all about. It created havoc on the entire school, because
some computers were getting correct IPs, and some incorrect. They had to
find which it was by first removing their own dhcp server, then powering
down the computers in lots till they located a lot that solved the issue,
then invetigated that school room by powering down half of the remaining
computers and booting another (if it got a rogue IP, the rogue dhcp server
was in the remaining computers left on)

In the end, it was a computer running vmware something. What I don’t
remember is if it was the virtualizing software fault, or a virtual machine
running someting with a dhcp server active.

Your place was very lucky that it only affected one computer.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)