How to disable "option 50" Raspbian?

[Cubytus]

Hello there,

my RPi is connected to a DHCP LAN, and the modem acts as a DHCP server. Nothing unusual, but I noticed it can't be found using its hostname. However, the raw IP works, and it receives its static DHCP address as assigned.

The modem manufacturer sugests that I disable "option 50" in order to solve the issue, but how do I do that in Raspbian?

[DougieLawson]

Option 50 means you pass a static IP address to the DHCP server and the server acknowledges that you are using that address so it doesn't assign a new address from the pool and doesn't assign that address to another host.

What's in your /etc/dhcpcd.conf?

I'd see if you can reduce the range of addresses in the DHCP pool on your router so that the static address you're assigning to your RPi is not DHCP managed.

On my network every address from xxx.xxx.1.1 to xxx.xxx.1.29 is outside my xxx.xxx.1.30 to xxx.xxx.1.100 DHCP range. All eight of my raspberries get a static address from that block. Addresses above xxx.xxx.1.101 up are also used for servers like my WiFi printer.

[Cubytus]

Hmmm, there's nothing at /etc/dhcpcd.conf.

When you say "Option 50 means you pass a static IP address to the DHCP server", it seems to me it's an unexpected behavior since I expect the DHCP server to assign the static DHCP address to the RPi whenever it's on. Probably the RPi remembers the address it had previously, and suggests it to the DHCP server, and both agree.

In other words, I don't assign a static address to the RPi, the DHCP server is supposed to recognize it's MAC address and tell the RPi what address it should use, just like the other devices on the network, and be reachable using their hostname.

LAN addresses assignment
Here, the Ethernet-linked headless devices receive IPs in the .10 to .19 addresses (including network printer, RPis, network drives, IP cameras)
20 to 29 are Ethernet, full-featured computers and take into account virtual machines that need their own
30 to 39 are Wifi headless devices such as RPis when they have such an adapter connected
40 to 49 are Wifi full-featured computers / phones / tablets.

Easy, as I just have to add 20 to the last number to know the Wifi address when using another connection. All addresses in the .10 to .49 block are static DHCP.

.2 is for the 802.11g-only router
.4 is the IP phone
all others under .10 are freely available for transient computers

[drgeoff]

@Cubytus
It is not a good idea to dispute anything Dougie writes before being sure of the facts.

I suggest you read https://tools.ietf.org/html/rfc2132, particularly section 9.1.

[DougieLawson]

It is not a good idea to dispute anything Dougie writes before being sure of the facts.

Thank you. If I were more narcissistic I'd add that to my forum signature block.

The really hard part of this is trying to trace what's going on between a DHCP client and a DHCP server, you can't start tcpdump on an interface that's not active, as soon as it's active all of the DHCP stuff has been done. I've not looked whether it's possible to run a trace on another interface in promiscuous mode (or whether a RPi supports that mode on its ethernet cabled connection) to see all of my LAN traffic from all stations (which will be a bucket of boring Facebook crud if my wife is online).

Suggesting "just disable 'option 50'" is fatuous and not the way to solve this problem. If the server doesn't support 'option 50' it should be perfectly entitled to simply ignore it.

My Technicolor router handles 'option 50' in the perfect way. If 'option 50' is not set it looks at whether your lease has expired and re-assigns an existing address or assigns a new address (normal DHCP protocol). If it is set, even if the address is part of the DHCP pool (and unused) it assigns that address and marks the pool entry as "static" with no lease time. I've not tested what happens if two stations come in with the same static address.

[drgeoff]

It is not a good idea to dispute anything Dougie writes before being sure of the facts.

Thank you. If I were more narcissistic I'd add that to my forum signature block.

I didn't say or imply that everything Dougie writes is correct.

[Cubytus]

I am just reporting what the modem manufacturer suggested, and I assume he is talking about a debug attempt to check if that would solve the issue at least temporarily, and rightfully pointed at the RPi since it's the only device experiencing the problem (IP OK, hostname resolution doesn't go through). The dump was made on a LAN-connected computer with Wireshark, and Raspbian has stock configuration.

I still have a hard time figuring out how this "option 50" would have any influence on resolving the RPi's hostname. RFC 2132 doesn't mention that.

No device use static IPs, but almost all use static DHCP IP assignment. So how should I disable this option so as to provide a test result to the manufacturer?

[DougieLawson]

You're going to have to ask the manufacturer for more support. Tell him you've got a Debian Jessie system using dhcpcd5.

You could try ripping the hostname stuff out of your /etc/dhcpcd.conf by prefixing it with a # to make it a comment.

[Cubytus]

I asked the manufacturer for support, and sent him the Wireshark dumps as per his request. Now I must perform the debugging steps. There's no such file named /etc/dhcpcd.conf in Raspbian.

If that helps, here are screen captures showing
1- static DHCP assignment rule

image002.png (12.74 KiB) Viewed 2782 times

2- negotiation process.

image001.png (39.63 KiB) Viewed 2782 times

[DougieLawson]

There's no such file named /etc/dhcpcd.conf in Raspbian.

There is if you're running any version of Raspbian built or updated since May 2015.

[Cubytus]

I got:

Code: Select all

cat /etc/debian_version 
7.8

after running apt-get update / apt-get upgrade, and a reboot. But still no such file as /etc/dhcpcd.conf.

[kusti8]

Ok, what's in /etc/network/interfaces?

[Cubytus]

Here is the content of /etc/network/interfaces:

Code: Select all

auto lo

iface lo inet loopback
iface eth0 inet dhcp

allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

[Cubytus]

I ran apt-get update, apt-get upgrade, then reboot, then apt-get dist-upgrade, then reboot again.

lsb_release still displays:

Code: Select all

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 7.8 (wheezy)
Release:	7.8
Codename:	wheezy

Ok, so how would I "disable option 50" for the purpose of this test, knowing this Raspbian is fully updated but doesn't show any file named /etc/dhcpcd.conf? Should I try to update to Jessie first by reflashing the image, in case it's a bug from Wheezy?

[fruit-uk]

Looking at your first post, do you have the Pi listed in /etc/hosts on the other machines?
If it's MS then I have no idea where it might go.

Have you tried dhcpdump? May be easier to read than wireshark logs - not tried though.

[Cubytus]

On this machine, no other devices than localhost are listed, but only the RPi can't be called by its hostname.

I'd like to know why it still shows Debian 7.8 despite all upgrade procedures, and if trying a manual re-flash to 8.0 would solve the issue.

And, how is this "option 50" disabled, for the test I am asked to perform?

[fruit-uk]

Perhaps it depends on what OS you have on other machines. I always try to list all in /etc/hosts on all mine but they are all linux. Been doing it like that for years - may be regarded as bad practice now of course

What install did your Pi start out as?
I believe there were update/upgrade differences from some of the early net-ua installs . I can't remember the specifics but the advice I read was to to do a fresh install - I have a recollection that it was about when Pi2 came out but may have been some other new hardware.

[rpdom]

I'd like to know why it still shows Debian 7.8 despite all upgrade procedures, and if trying a manual re-flash to 8.0 would solve the issue.

Could you show the output of "apt-cache policy"? That will tell us what apt-get is configured to do.

[Cubytus]

@fruit-uk, the other machines are Macs. I haven't tried to reach the Pi on the only Windows here, nor from the Linux virtual machines.

Not sure I understand this one:

What install did your Pi start out as?

It is a regular install of Raspbian, flashed from an image I got from Raspberrypi.org, which is not the one with kernel 4.1, though.

apt-cache policy :

Code: Select all

Archivos de paquetes:
 100 /var/lib/dpkg/status
     release a=now
 500 http://archive.raspberrypi.org/debian/ wheezy/main armhf Packages
     release o=Raspberry Pi Foundation,a=oldstable,n=wheezy,l=Raspberry Pi Foundation,c=main
     origin archive.raspberrypi.org
 500 http://raspberrypi.collabora.com/ wheezy/rpi armhf Packages
     release o=Collabora,n=wheezy,l=Collabora Raspberry Pi graphics enablement,c=rpi
     origin raspberrypi.collabora.com
 500 http://mirrordirector.raspbian.org/raspbian/ wheezy/rpi armhf Packages
     release v=7.0,o=Raspbian,a=oldstable,n=wheezy,l=Raspbian,c=rpi
     origin mirrordirector.raspbian.org
 500 http://mirrordirector.raspbian.org/raspbian/ wheezy/non-free armhf Packages
     release v=7.0,o=Raspbian,a=oldstable,n=wheezy,l=Raspbian,c=non-free
     origin mirrordirector.raspbian.org
 500 http://mirrordirector.raspbian.org/raspbian/ wheezy/contrib armhf Packages
     release v=7.0,o=Raspbian,a=oldstable,n=wheezy,l=Raspbian,c=contrib
     origin mirrordirector.raspbian.org
 500 http://mirrordirector.raspbian.org/raspbian/ wheezy/main armhf Packages
     release v=7.0,o=Raspbian,a=oldstable,n=wheezy,l=Raspbian,c=main
     origin mirrordirector.raspbian.org
Paquetes con pin:

[fruit-uk]

Not sure I understand this one:

Only that some early net-ua installs I did here seemed not to fully upgrade to current versions. That was a long time ago now so maybe it doesn't happen any more.

[Cubytus]

Should I simply reflash from a more recent version, then? I still couldn't perform the test as requested by the tech support, and I can't picture the manufacturer getting a Pi, flashing it and connecting it to a specific modem just for one customer

[fruit-uk]

Since the transition from wheezy to jessie a new install is probably a very good idea - but keep a copy of your data and perhaps keep a copy of /etc too for reference - although jessie /etc differs in places