Linux interfaces situation

Status
Not open for further replies.
B

BearZDefect

Joined
Aug 15, 2005
Messages
2,329
Location
Lexington, KY
I have a situation I don't understand yet, hope the Linux gurus here can help.

On Ubuntu Server 10.04 LTS recently installed on a dedicated machine (no other OS) with multiple network adapters the content of /etc/network/interfaces is:

Code:


auto lo

iface lo inet loopback



allow-hotplug eth0 eth1 eth2



iface eth0 inet static

address 192.168.0.60

netmask 255.255.254.0

auto eth0



iface eth1 inet static

address 192.168.0.61

netmask 255.255.254.0

gateway 192.168.0.1

network 192.168.0.0

auto eth1



iface eth2 inet static

address 192.168.0.62

netmask 255.255.254.0

auto eth2



That netmask isn't a typo, but I don't see why 9-bits should cause problems.

ONLY eth1 is plugged in. The others will eventually be plugged into separate switches and more info added to their interfaces sections.

When all interfaces are 'up' there is no communication via eth1 to or from any other hosts on the LAN. However, it can communicate to the Internet, and hosts outside on the Internet can initiate and communcate with it.

If only eth1 is up, with eth0 and eth2 down, it works as expected.

The hardware and drivers seem to work fine. No iptables have been set up.

What have I missed or violated? Is it forbidden to have multiple interfaces in the same subnet?

TIA!
 
Another question not directly related:

nmap from a host on the LAN shows port 21 open on this machine. However, netstat does not indicate anything listening on port 21, and there doesn't appear to be a ftp server running.

So, why does nmap find port 21 open?
 
What are you trying to accomplish? I am assuming you want more throughput.

I would bond them together and assign multiple IPs to the bonded interface; We have this @ work on our mail server, but I didn't implement it. Some of our machines have 5 IPs to each gig interface.
 
Last edited:
Originally Posted By: BearZDefect
Another question not directly related:

nmap from a host on the LAN shows port 21 open on this machine. However, netstat does not indicate anything listening on port 21, and there doesn't appear to be a ftp server running.

So, why does nmap find port 21 open?


FTP might be kicked off by xinetd. (the super daemon) xinetd listens on many ports and transfers control to the daemon that is responsible for servicing that port, in this case ftpd. Xinetd in configurable to implement access control prior to kicking off (or not kicking off) the associated service.

Note:I'm using desktop so I can't really look @ a server setup. Must get one running on virtualbox i guess
 
Last edited:
allow-hotplug.

What he is trying to do is known as lagg on BSD systems. Make sure eth0, eth1, ethX are all DOWN and use:

iface *lo* inet loopback

lo is an alias for the LIST of available interfaces which from the allow-hotplug interface the first available and operational interface in the list.

By the way, 1-bit is pulled for the loobpack *lo* interface...that interface will eventually have something that is SANE looking like a /24 subnet mask (255.255.255.0).
 
Probably an issue with having all of them on the same subnet and only one of them plugged into a switch. The IP stack is probably going to choose the first interface in it's list of interfaces.

I don't know if linux has this command (I'm working from a Solaris knowledge base) What does netstat -rn give you? It should tell you which interface it wants to use for which network. I.E. which interface is listed as the first route to the 192.168.0.0 network?

If you run ifconfig -a does it have the same netmask, etc for each of the interfaces?

I'd like to see the output of both of those commands before I speculate further.
 
Originally Posted By: simple_gifts
Originally Posted By: BearZDefect
Another question not directly related:

nmap from a host on the LAN shows port 21 open on this machine. However, netstat does not indicate anything listening on port 21, and there doesn't appear to be a ftp server running.

So, why does nmap find port 21 open?


FTP might be kicked off by xinetd. (the super daemon) xinetd listens on many ports and transfers control to the daemon that is responsible for servicing that port, in this case ftpd. Xinetd in configurable to implement access control prior to kicking off (or not kicking off) the associated service.

Note:I'm using desktop so I can't really look @ a server setup. Must get one running on virtualbox i guess


Correct! inetd (super daemon think Wile E Coyote) and it's related cousins listen on a bunch of ports and spawn services on demand.
 
Thank your for all the helpful replies!

Changing the netmask to 255.255.255.0 made no difference.

I will work with the info you have all provided.

simple_gifts, I'll look further into bonding if the owner requests it.

javacontour, netstat -rn gives me a helpful hint about the situation, I hadn't been using it with those options.

netstat -tan shows nobody listening on port 21, or any unexpected port for that matter. I'll have to look into configuring inetd. Can inetd be safely disabled, is it necessary if the desired services are running on their own?
 
On inetd (xinetd, etc) you MAY be able to shut it down. However, the better solution is to simply disable the services you don't want running. It's hard to say how many services are used internally through the loopback network 127.0.0.1

You would have to experiment with running the services and their own, and how you will handle or detect if a service crashes.

I.E. can init monitor the services you want, respawn them, etc. (Linux has init, right?)
 
The problem is that it doesn't know which interface to use for outgoing packets...as they are all listed in the routing table. (Actually I believe it just chooses the first one listed for outgoing packets).

You could add a specific route for eth1 which points to the subnet (with a higher priority) or delete the routes for eth0 and eth2.

When the routes are set up correctly, it will use eth1 for outgoing packets to any destination IP on the subnet.
 
brianl, thanks for the explanation and routing suggestion. My observation, using netstat -rn confirms what you and javacontour wrote. I only had to 'down' eth0 for eth1 to start working on the subnet.

javacontour, simple_gifts, I don't see a process inetd or xinetd running on this machine, and if I try to connect to it from a Windows machine on the subnet I get a quick:

Code:
Connected to 192.168.0.xx

Connection closed by remote host.


No ftp service was requested during setup.
I've seen the same oddity on a Debian 5.x server.

If it's of any use, I can post a process list from ps.
 
I don't have a windows box running to check to see how the Windows client works.

What happens if you run ftp 0 from the Ubuntu box? Does it say connection refused or does it give you a connection then connection closed?

BTW, 0 is treated as networking to yourself. It's a lot easier than typing out the IP or loopback address. It's a nice to know shortcut for networking to yourself.
 
Check your /etc/hosts.allow and /etc/hosts.deny

Based on what you saw with the Windows machine, it seems like tcp wrappers may be denying the connection, which is why it connected and then closed.

If it were firewalled, it would not have connected at all...and if inet.d weren't running, the connection would have been refused.
 
javacontour,

Thank you for the 0 shortcut for localhost / 127.0.0.1

"ftp 0" on the machine itself yields:

Code:
ftp: connect: Connection refused



brianl,

hosts.allow and hosts.deny contain only comments.
 
I suspect ftpd is not running, nor being spawned by xinetd.

I suspect the Windows FTP client takes a short cut and doesn't distinguish between connecting and being disconnected and never connecting.

I'd try hitting your linux box with a non-windows FTP client from another machine to confirm you get a connection refused.

I don't have a Windows box running here to test that behavior. I don't use a Windows FTP client very often to know what it does.
 
If the error comes back right away, the connection was refused (or tcp wrappers intercepted and closed the connection, but if there's nothing in those two files, tcp wrappers is not likely a factor in this).

If it takes a while, the connection is likely firewalled.
 
Thanks for the further replies.

Quote:
do a ps -ef | grep inetd

Nothing like inetd reported by ps.

Quote:
I'd try hitting your linux box with a non-windows FTP client from another machine to confirm you get a connection refused.

I didn't take Windows ftp at face value, but nmap running on Windows also reports port 21 open.

Following your suggestion, I tried to ftp to this machine from another Linux machine. It took a couple of minutes, then finally reported:

Code:
ftp: connect: Connection timed out


Maybe I'm on a wild goose chase here.
21.gif
 
Maybe your ftp port is firewalled AND inetd isn't running (but needs to be).

What if you telnet to port 21? Try it from both Linux machines.

telnet 127.0.0.1 21


What does it do?
 
debian:~# ps -ef | grep inet
root 2675 1 0 Feb11 ? 00:00:00 /usr/sbin/inetd

Try manually starting it:

/usr/sbin/inetd

see if that changes anything.
 
Status
Not open for further replies.

Similar threads

OVERKILL
  • Locked
Router review - Cisco ASA 5506W-X w/FirePOWER
Replies
8
Views
7K
Rand
S
  • Locked
Kicking the Microsoft Habit
Replies
15
Views
4K
ToyotaNSaturn
Back
Top Bottom