LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)
-   -   ICMP Destination Unreachable (Host administratively prohibited) (https://www.linuxquestions.org/questions/linux-networking-3/icmp-destination-unreachable-host-administratively-prohibited-443493/)

jiml8 05-10-2006 11:10 AM

ICMP Destination Unreachable (Host administratively prohibited)
 
I am trying to remote boot a workstation, having it use PXE to download a linux image and initrd.img from a server.

The server is FC4. The workstation is an X86 box that supports PXE boot.

The server has DHCPD configured like this:
Code:

ddns-update-style ad-hoc;
default-lease-time 32768;
max-lease-time 32768;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.1;
option domain-name-servers 192.168.1.1;
#option domain-name "mydomain.org";

subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.10 192.168.1.100;
  range 192.168.1.150 192.168.1.200;
}
host pxeclient {
  hardware ethernet 00:40:63:DB:9A:8B;
  fixed-address 192.168.1.145;
  option host-name "pxeclient";

  filename "/pxelinux.0";
  next-server 192.168.1.20;
  option root-path "/netboot/pxeclient";
}

I have established a directory /tftpboot which contains a number of files, notably pxelinux.0 which is the boot loader. Permissions on tftpboot were set with chmod -R 777 /tftpboot so it should be world-accessible.

I have tftp running in xinetd, configured like this:
Code:

service tftp
{
        socket_type                = dgram
        protocol                = udp
        wait                        = yes
        user                        = root
        server                        = /usr/sbin/in.tftpd
        server_args                = -s /tftpboot
        disable                        = no
        per_source                = 11
        cps                        = 100 2
        flags                        = IPv4
}

According to Ethereal, when the client boots, it looks to DHCPD for its IP, and is given the specified 192.168.1.145. It then requests TFTP READ /pxelinux.0.

The server sends it an ICMP response that says Destination Unreachable(Host administratively prohibited) Anyone have any idea why?

jiml8 05-12-2006 10:18 AM

No one here has seen this?

jiml8 05-12-2006 06:55 PM

Got it.
Iptables default FC4 configuration killed it.
Disable iptables and bob's your uncle!

BSchindler 05-12-2006 09:32 PM

Funny you post this ... I am just setting up a box to do exactly what you are doing. I have setup remote boot before (about a year and a half ago) but I cannot exactly remember all the details.

But, first, do you have SELinux enabled? If so, you may want to disable while debugging this.

Next, you may want to run DHCPD in the foreground with debugging info to console as in:
$>/usr/sbin/dhcpd -f -d

That's where I would start. I will be working on this more (using FC5) as server and will let you know what I discover.

HTH

jiml8 05-13-2006 01:24 PM

Actually, it is my intent to download an FC5 image to the workstation for installation.

The plan is to remotely boot a bare workstation, then remotely configure it into a standard configuration using dd and previously prepared images of boot block and system, followed by the creation and population of /home directories.

I am not using SELinux.

There is a default PXE boot image provided with FC4, but the initrd.img that is provided with it is non-standard (meaning it isn't a compressed image) and what it apparently does is cause the remotely booted FC4 installation to seek out a disk-based FC4 installation set.

I do not want to do this, so I provided a different initrd.img which wants to do an NFS mount of a root partition that is on the server. It works, but I have not yet provided anything in the /root partition, thus the workstation is going through startup to the point where it changes to /root, then it hangs.

At least, I have it running to that point.

Complicating this is that the systems I am working on are in switzerland and I am in the USA. LOL.

hxcan 07-04-2010 09:56 PM

Quote:

Originally Posted by jiml8 (Post 2242805)
Got it.
Iptables default FC4 configuration killed it.
Disable iptables and bob's your uncle!

Thank you very much.

cwcarlson 06-05-2012 12:35 PM

Thanks for this question/answer
 
I've been beating my head against the wall trying to figure out what happened, and this thread saved me.

I'm running Fedora 15 as my development machine. I've been very diligent to install the updates as they came out (per the automated check). We test our products using pXe-boot Ubuntu machines without disk drives, so I often NFS mount from the Fedora computer.

One day, we were told to shut down computers because the power company was going to be turning power off for a few hours.

When I turned the computer on again, I could no longer NFS mount. There was no indication in either computer to indicate why. The pXe-booted machine would just return "mount.nfs: mount system call failed." There was nothing in dmesg, /var/log/secure or /var/log/messages on the Fedora machine to indicate a connection was even attempted.

When I ran traceroute on port 2049 on the pXe machine, it returned times with "!X". I learned that this indicates "Host administratively prohibited." Well, that was not helpful.

I then ran ethereal (don't ask me how difficult that was to install) on the Fedora machine, and that's when I discovered it was the Fedora machine that was responding to the pXe machine with the ICMP. This sent me to LinuxQuestions.org for help, and that's how I found this thread.

In trying to understand iptables, I have discovered this is a rat-hole I'm not ready to follow. It is extremely complicated. Running iptables-save, I have learned nothing about why iptables suddenly won't allow NFS mounts. I've turned off the firewall for NFS, enabled exports, etc., but the only thing that worked was to disable the service.

I wonder if there is a college course on iptables?

Thanks for resolving this issue for me.

leencangku 04-25-2013 04:07 AM

iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
21 4102 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
118 12808 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 94 packets, 19267 bytes)
pkts bytes target prot opt in out source destination

---------- Post added 04-25-13 at 04:08 AM ----------

Quote:

Originally Posted by cwcarlson (Post 4696160)
I've been beating my head against the wall trying to figure out what happened, and this thread saved me.

I'm running Fedora 15 as my development machine. I've been very diligent to install the updates as they came out (per the automated check). We test our products using pXe-boot Ubuntu machines without disk drives, so I often NFS mount from the Fedora computer.

One day, we were told to shut down computers because the power company was going to be turning power off for a few hours.

When I turned the computer on again, I could no longer NFS mount. There was no indication in either computer to indicate why. The pXe-booted machine would just return "mount.nfs: mount system call failed." There was nothing in dmesg, /var/log/secure or /var/log/messages on the Fedora machine to indicate a connection was even attempted.

When I ran traceroute on port 2049 on the pXe machine, it returned times with "!X". I learned that this indicates "Host administratively prohibited." Well, that was not helpful.

I then ran ethereal (don't ask me how difficult that was to install) on the Fedora machine, and that's when I discovered it was the Fedora machine that was responding to the pXe machine with the ICMP. This sent me to LinuxQuestions.org for help, and that's how I found this thread.

In trying to understand iptables, I have discovered this is a rat-hole I'm not ready to follow. It is extremely complicated. Running iptables-save, I have learned nothing about why iptables suddenly won't allow NFS mounts. I've turned off the firewall for NFS, enabled exports, etc., but the only thing that worked was to disable the service.

I wonder if there is a college course on iptables?

Thanks for resolving this issue for me.



All times are GMT -5. The time now is 03:34 PM.