Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Tried Hakcenters suggestion of adding the line DHCPARG=eth0 in to dhcpd.conf (a redhat fix for the same problem apparently, thx hakcenter).
Had a modicum of success in that the subnet dec issue went away and was replaced by a subnet not in the 192.168.1.2 - 192.168.1.60 range. Problem is that when I change it to be in the same range, the subnet dec issue comes back.
I have very little hair left now...........................
I'd remove the aforementioned "Red Hat hack" (I've been running ISC's DHCPd on Red Hat for eight years, and I never heard of that before).
But the main problem is you've got at least two interfaces and you've only defined one of them in your DHCP config. You have to tell the DHCPd what to do with all your interfaces, even if the configuration is "do nothing for this interface".
Post the output from "ifcfg" and we'll see what's up.
Incidentally, IMnsvHO, your global options should be before subnet declarations, not after. Also, supplying any value whatsoever for netbios-scope is usually a prelude to disaster.
I tried putting in a second subnet declaration to see what would happen but still got the same error. (I probably screwed it up tho)
As for the order of text in the dhcpd.conf file, thats the way Yast writes it. I have modified myself several times manually but if I run Yast later it just rewrites in the opposite order.
I should add what I am trying to achieve here. Basically to replace my windows LAN with a LINUX LAN.
ETH0 faces my ISP, receives its IP via DHCP from the ISP. The ip shown in the ifconfig is a result of the linux box being connected to my windows LAN.
When the Linux is connect to the ISP, the IP issued is always 212.4.74.xxx, default gateway is 188.8.131.52, subnet is 255.255.255.0.
I would like to share the internet connection via ETH1 (in the same manner that you can with windows) via DHCP to 3 other linux boxes + 1 windows box, but present only the IP from eth0 (ip masq?) but at this stage i would be happy just to be able get everything talking to each other and web access from each machine.
Ah, I see. I don't know how windows does that sort of thing, I only use it for desktop stuff and run linux in server/infrastructure roles.
You can get everything you want very easily with smoothwall. Download a CD from www.smoothwall.org and run it on an old 486 or similar junker. I run mine on an old industrial PC (basically a very small, low-power-draw p-233 with a solid-state 80 MB hard drive and no fans). It runs transparent squid, the Snort intrusion detection system, firewalling, address masquerading, DNS caching, DHCP etc. etc. etc. and it took about twenty minutes to set the whole thing up.
But, assuming you want to keep going with ISC DHCPd, I'll continue... I looked at the dhcpd.conf man page, and it specifically says that the global options need to go before the subnet declarations. So YAST seems to be buggy, better not use YAST for this.
Also it says "For every subnet which will be served, and for every subnet to which the dhcp server is connected, there must be one subnet declaration, which tells dhcpd how to recognize that an address is on that subnet. A subnet declaration is required for each subnet even if no addresses will be dynamically allocated on that subnet."
Now, I know from experience that I don't have to declare loopback. But, you've got a whole bunch of interfaces lit up on your machine and they are going to need to be declared to DHCPd. For instance, you've got three IPv6 interfaces and two IPv4 interfaces. Since you've only got two physical network cards, this is going to require that the subnet declarations for some of these networks be enclosed in shared-network declarations.
Why are you running IPv6? Is this a requirement? It's going to make your machine configuration significantly more difficult for nearly everything that has anything to do with the network (firewalling and masqerading, for example).
As far as I know (and I am by no means an expert on this) but windows does some sort of autoconfig in a very basic, convoluted DHCPd mated with iptables fashion. not that it matters now as I have come to the decision that DHCPd is not only a complete pain in the rear, but also inadequate for what I want to do. Although security is not an immediate issue, when the time comes DHCPd will not give me any real diversity.
I tried declaring subnets for both NIC's and got the same error for each card (no subnet declaration) I think I agree that the suse Yast is doing something strange when it writes the conf file.
in answer to the IPv6 question, it is the default IPver that suse runs. Its supposed to be backwards compatable to IPv4 so there should be no real issues there.
As for smoothwall, I think that i will give it a try. I have webmin which has a neat GUI for smoothwall so I will give it a go and see if i can preserve what remains of my hair. are there any tips or "traps for new players" that I should be aware of??
For the moment though I am now have NIC issues (it just gets better and better!!) for some bizarre reason my Linux box can no longer get an IP via DHCP from my ISP. first I thought it was the NIC, but having replaced both the NIC and trying to connect with a completely different machine as well i still get no joy. Windows box is fine when I connect it. Linux box/s wont work. I had exactly the opposite problem last night in that the windows box couldnt connect but the Linux box/s could. I have a horrible feeling that when my ISP issues a DHCP lease, the lease is valid only for the NIC it gets issued to for the duration of the lease. Anyone heard of this sort of thing or got any thoughts??
By the way, i can ask for a IP lease renew in windows with ipconfig /renew without having to stop and start the NIC interface, is there a similar command for linux or is ifdown and ifup the only option?
RHELL, Eth1 was intentionally configed as 192.168.1.1 It was going to be the static IP for DHCPd server.
dhcpd looks at the subnets to work out which interfaces to work on.
You have told dhcpd to use subnet 192.168.1.0 netmask 255.255.255.0
If eth1 has the address 192.168.1.1 then that is not in the subnet
you have told dhcpd to use.
Your router address should be within the subnet you are giving to clients.
Use 192.168.0.1 instead.
>You have to tell the DHCPd what to do with all your interfaces,
>even if the configuration is "do nothing for this interface".
No you don't. If you don't want to use dhcp on an interface you can
not configure it for that interface and ignore the message about
no subnet declaration.
>As far as I know (and I am by no means an expert on this) but
>windows does some sort of autoconfig in a very basic, convoluted
>DHCPd mated with iptables fashion.
No, if you leave windows set to "automatically obtain an ip address"
it does uses DHCP to try to get one.
>By the way, i can ask for a IP lease renew in windows with
>ipconfig /renew without having to stop and start the NIC interface,
>is there a similar command for linux or is ifdown and ifup the only option?
Read the man page for whatever dhcp client redhat uses.
So, you don't have any interfaces on the subnet you've told the DHCP daemon to distribute addresses for. Looks like a subtle typographical error to me... I didn't spot it in the ifconfig and that's exactly the bug I was looking for!
About the capabilities of the ISC DHCPd:
It's unlikely that the software is "not adequate" for your uses; as the reference implementation of the protocol it is capable of doing anything that the protocol can do. This is far more than the Windows or Novell dhcp servers can do, and consequently those tools have simpler interfaces and are useable with less planning and research. If you need to do something that the ISC DHCPd can't do, you don't need DHCP, you need something else.
And finally, about the IPv6:
The Internet runs on IPv4 (Internet Protocol Version Four). You are unlikely to be communicating with anyone using any other protocol. IPv5 (streams internet) was a failure for all practical purposes. IPv6 is a new version that includes optional enhanced security and quality of service features as well as a vastly increased address space. In the year 2040, you will probably need IPv6 although some people say you'll never ever need it.
Although IPv6 is, technically, in some senses, "backwards compatible" with IPv4, you cannot communicate with your ISP via IPv6. You are running multiple separate protocol stacks (three, actually, since you've got an encapsulation layer as well as both IPv4 and IPv6 running) and that is wasting resources and providing additional security hazards as well as significantly complicating the configuration of your system. You should get rid of it. Think of it as a can opener attached to your washing machine - every time you use the washer, the can opener is running, even though you don't need to open any cans, and the rotating machinery wastes power and presents a minor hazard to anyone using the washroom.
Distribution: Just about anything... so long as it is Debain based.
You're post is informative but wrong.
192.168.1.1 is absolutely on the network 192.168.1.0 255.255.255.0. That's what the subnet mask tells us. the network part of the IP address is 192.168.1 and the nodes on that address are 1-254 (255 is the broadcast).
An address of 192.168.0.1 255.255.255.0 has a network address of 192.168.0; therefore, it is not on the same subnet as the 192.168.1.1 address.
Regarding not declaring an interface in dhcpd.conf:
If you read the man page (man dhcpd.conf) you will find this:
"For every subnet which will be served, and for every subnet to which
the dhcp server is connected, there must be one subnet declaration,
which tells dhcpd how to recognize that an address is on that subnet.
A subnet declaration is required for each subnet even if no addresses
will be dynamically allocated on that subnet."
It's quite clear that the designers of dhcpd want a mention of each interface. I know on my server if I do not have a info on each interfacd dhcpd bombs.
I accidentally typed the right ip address instead of the incorrect one that Hunza
Let me try that again.
You have told dhcpd to use subnet 192.168.1.0 netmask 255.255.255.0
If eth1 has the address 184.108.40.206 then that is not in the subnet
you have told dhcpd to use.
Use 192.168.1.1 instead
>192.168.1.1 is absolutely on the network
You are correct.
>I know on my server if I do not have a info on each
>interfacd dhcpd bombs.
Works for me. I fail to see why I should tell dhcpd about a subnet that it has
nothing to do with. The abstraction between the hardware interface, ethernet
transport, routing and ip host levels are a fundamental part of networking.
That's a difference of opinion between me and the people who created the software.
>It's quite clear that the designers of dhcpd want a mention of each interface.
I accept that but I see no practical reason for it.
I had hoped to be posting a solution to this issue by now, however the saga continues.
We had a Suse guru here from one of Suse's support partners last Monday, spent the whole day here and even he couldnt fix it!!
Basically the prob remains the same. We can see the ISP and get an IP via DHCP. The machines on the LAN are all static IP and can see each other. The issue is the routing between the two NICs in the gateway box. They simply cannot (or will not) route between themselves. We got it sort of working using squid but for web content only, couldnt get email to work through the squid proxy.
Anyway, the Suse man has taken the issue up with Suse and hopefully they will come up with an answer. For the time being I am still using the WINXP box as a gateway, but I will continue to bang away at this myself.
Watch this space for the solution from SUSe (if they can work it out!!)