I have some troubles with dhcpd.
Its configured, firewalld ports opened, DHCP client gets all info from server exept default route which makes my server totaly unusable.
It was your choice to change the computer code your posted, by naming the first two bytes to x.x., which they most probably are not.
I have no idea why you did, but such behaviour can hide problem causes. E.g. when you had originaly someting different for x.x. in different places, you configuration would be broken, but nobody here would be able to see such a thing where you (human as you are) may have skipped over again and again.
Also, opening I do not know which firewall ports you opened on the server, but DHCP is not a TCP/IP protocol and does not use TCP or UDP ports.
I am sorry, but the above are only side remarks, it will not help you very much with your problem, that I find as strange as you.
There is no such thing as “TCP/IP protocol”. There is “IP protocol” and there is “TCP protocol”. There is “TCP/IP family of protocols” which when used colloquially often includes UDP, ICMP, ARP and others.
and does not use TCP or UDP ports.
DHCP is using UDP as transport and of course it is using UDP ports 67 (server) and 68 (client).
What is really missing in original post is which network configuration framework is used (wicked or NetworkMaanger).
Sorry fot showing myself so misinformed (thus possibly creating confusion), but I thought Bootp (and thus DHCP) works through ethernet broadcast and connections. As long as the DHCP client does not have an IP address, etc. it can not “talk” IP at all.
Sorry again, but I do not see wh using wicked or NM on the server makes much difference. There seems to be a working NIC because all other data (IP address, netmask and DNS servers) seem to be transported to the client, only the router is not.
Make sure that a semicolon is inserted at the end of each line, because otherwise dhcpd is not started.
But, I see that your dhcpd configuration isn’t suffering from this issue …
On the other hand, you have “option domain-name-servers” and “option routers” within the “subnet” definition – maybe you should move those lines to the section before the “subnet” definition.
I tryed to move those lines - still nothing in “default gateway” at client.
Wicked
Just imagine that “x.x.” is 192.168., i mean, i didnt misspeled it or im not using different subnets everywhere, all config belong to one subnet(doublechecked after ur comment).
there are a lot of ways to configure wicked, so “its configured” does not really say much. If you are using YaST which edits ifcfg files, default route is controlled by DHCLIENT_SET_DEFAULT_ROUTE or DHCLIENT_UPDATE options which can be set either in per-interface ifcfg or globally in dhcp file.
Am I right that you are now talking about the client.
In fact we know nothing about the client other then that it does not set the default router when it uses the openSUSE 15.0 based DHCP server and it does set it when it uses a Debian based DHCP server.
We do not even know the client’s operating system, let alone if it uses ifcfg files.
It seems that, if another DHCP Server in the network (e.g. a Microsoft machine) provides a Classless Static Route (DHCP option 121, rfc3442-classless-static-routes in ISC DHCP) then, the Open Source DHCP Server will not supply and Default Route information …
A solution seems to be: in “/etc/dhcpcd.conf” comment out “option classless_static_routes”.
Default:
# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
Edited:
# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
# option classless_static_routes
On the other hand there’s this:
It must not send a default gateway option when it can’t provide routing to the rest of the world.
In other words, provided that, your DHCP Server is providing the routing to the rest of the world then, it’ll send the Default Gateway information …
Once again, its not a client sided problem, because debian DHCP-Server works fine, there are one another DHCP (WiFi router) behind my VPN, but Debian router not care bout it, clients will be windows machines only (so option classles_static_routes not a solution) and i have one OpenSUSE Leap 15 machine for test reasons, its frustrating that same config within same dhcp server version doesnt work on OpenSUSE Leap 15.
My DHCP Server providing routing, because my static machines (mostly linux/wicked) already works fine and have access to internet.
I tryed 2 failsafe examples from /usr/share/doc/packages/ - doesnt working.
I tryed to start dhcpd without chrootjail - doesnt working.
May not affect the problem you’re trying to solve,
But also noting that you’ve sett your local Domain Name to “local” which is bad, it’s a commonly used namespace used by a number of auto-config networking systems like Avahi.
Not to be overlooked,
Although trying to troubleshoot your manually created dhcpd.conf can be educational,
Practically, you should install yast2-dhcp-server and use it to configure… If it works then you can compare the working with your non-working configurations.
Although it’s possible that you have a client-side problem, if your client is configured as a dhcp client (using either Yast/Wicked or NM), the odds you have any kind of client-side problem is incredibly tiny.