[aaronjwood]

Hello all,

I am having a problem remote diskless booting via PXE from remote subnets. The Debian etch/LTSP/DHCP servers are all running on the same box located at 10.0.1.4 on our corporate office network (10.0.1.x structure). I have no problem booting a diskless thinclient via pxe when on the 10.0.1.x subnet. However, if I try to boot from a different subnet it seems like tftpd is failing.

The two networks are connected via a VPN tunnel and both networks can ping clients on each network. The remote subnet is 192.168.50.x structure and like I said, I can ping the Debain server at 10.0.1.4 from a 192.168.50.35 computer and vice versa.

When I boot from the remote subnet the tcpdump and syslog show that I get an IP from the DHCP server and then shows a RRQ for the pcelinux.0 file. However, I get no further. Any Ideas? The tcpdump and my dhcpd.conf are below. Any help is greatly appreciated.

=== BEGIN TCPDUMP OF IN/OUT to remote IP ===

07:14:10.590247 IP (tos 0x0, ttl 18, id 2, offset 0, flags none, proto: UDP (17), length: 65) 192.168.50.40.2070 > 10.0.1.4.69: [udp sum ok] 37 RRQ "ltsp/i386/pxelinux.0" octet tsize 0
07:14:10.591507 IP (tos 0x0, ttl 64, id 14319, offset 0, flags none, proto: UDP (17), length: 42) 10.0.1.4.32800 > 192.168.50.40.2070: [udp sum ok] UDP, length 14
07:14:10.696245 IP (tos 0x0, ttl 18, id 3, offset 0, flags none, proto: UDP (17), length: 45) 192.168.50.40.2070 > 10.0.1.4.32800: [udp sum ok] UDP, length 17
07:14:10.704886 IP (tos 0x0, ttl 18, id 4, offset 0, flags none, proto: UDP (17), length: 70) 192.168.50.40.2071 > 10.0.1.4.69: [udp sum ok] 42 RRQ "ltsp/i386/pxelinux.0" octet blksize 1456
07:14:10.705973 IP (tos 0x0, ttl 64, id 14320, offset 0, flags none, proto: UDP (17), length: 43) 10.0.1.4.32800 > 192.168.50.40.2071: [udp sum ok] UDP, length 15
07:14:10.817519 IP (tos 0x0, ttl 18, id 5, offset 0, flags none, proto: UDP (17), length: 32) 192.168.50.40.2071 > 10.0.1.4.32800: [udp sum ok] UDP, length 4
07:14:10.817708 IP (tos 0x0, ttl 64, id 14321, offset 0, flags none, proto: UDP (17), length: 1488) 10.0.1.4.32800 > 192.168.50.40.2071: UDP, length 1460
07:14:11.821026 IP (tos 0x0, ttl 64, id 14322, offset 0, flags none, proto: UDP (17), length: 1488) 10.0.1.4.32800 > 192.168.50.40.2071: UDP, length 1460
07:14:13.820957 IP (tos 0x0, ttl 64, id 14323, offset 0, flags none, proto: UDP (17), length: 1488) 10.0.1.4.32800 > 192.168.50.40.2071: UDP, length 1460
07:14:17.820813 IP (tos 0x0, ttl 64, id 14324, offset 0, flags none, proto: UDP (17), length: 1488) 10.0.1.4.32800 > 192.168.50.40.2071: UDP, length 1460
07:14:25.820555 IP (tos 0x0, ttl 64, id 14325, offset 0, flags none, proto: UDP (17), length: 1488) 10.0.1.4.32800 > 192.168.50.40.2071: UDP, length 1460
07:14:41.820005 IP (tos 0x0, ttl 64, id 14326, offset 0, flags none, proto: UDP (17), length: 1488) 10.0.1.4.32800 > 192.168.50.40.2071: UDP, length 1460
07:14:46.704245 IP (tos 0x0, ttl 18, id 6, offset 0, flags none, proto: UDP (17), length: 70) 192.168.50.40.2072 > 10.0.1.4.69: [udp sum ok] 42 ACK block 0
07:15:58.662417 IP (tos 0x0, ttl 18, id 7, offset 0, flags none, proto: UDP (17), length: 70) 192.168.50.40.2073 > 10.0.1.4.69: [udp sum ok] 42 ACK block 0

process gets no farther than this

=== END DUMP ===

=== BEGIN dhcpd.conf ===

ddns-update-style none;

# option definitions common to all supported networks...
option domain-name "ajwhome";
option domain-name-servers 10.0.1.10;

default-lease-time 600;
max-lease-time 7200;
allow booting;
allow bootp;

subnet 10.0.1.0 netmask 255.255.255.0 {
}

subnet 192.168.50.0 netmask 255.255.255.0 {
authoritative;
use-host-decl-names on;
option log-servers 10.0.1.4;
option domain-name "ajwhome";
option domain-name-servers 10.0.1.10;
option routers 192.168.50.254;
option broadcast-address 192.168.50.255;
option root-path "/opt/ltsp/i386";

host ajwhmpc1 {
hardware ethernet 00:07:e9:d0:93:18;
fixed-address 192.168.50.35;
next-server 10.0.1.4;
filename "/ltsp/i386/pxelinux.0";
}

host thin1 {
hardware ethernet 00:13:90:02:46:a4;
fixed-address 192.168.50.40;
next-server 10.0.1.4;
filename "ltsp/i386/pxelinux.0";
}

host ajwlaptop {
hardware ethernet 00:08:74:9f:f9:da;
fixed-address 192.168.50.36;
}
}

Regards,
Aaron J. Wood

[wildpossum]

I usually try doing a "telnet host service-port" to check the service availability from the target client location with my linux laptop first.

This way your able to ensure you can see and get a reply from the server service and that their is no "filter" inbetween. If you can't get through this way then your somewhat certain its filtered by a routing / firewall rule initially. Pinging only uses a ICMP packet, telent uses a full session packet and thus should trigger the correctnest in what the client is sending.

Give this a go as the first tool effort. Your mileage may vary but it should assist you moreso than just ping.

[aaronjwood]

Originally Posted by wildpossum

I usually try doing a "telnet host service-port" to check the service availability from the target client location with my linux laptop first.

This way your able to ensure you can see and get a reply from the server service and that their is no "filter" inbetween. If you can't get through this way then your somewhat certain its filtered by a routing / firewall rule initially. Pinging only uses a ICMP packet, telent uses a full session packet and thus should trigger the correctnest in what the client is sending.

Give this a go as the first tool effort. Your mileage may vary but it should assist you moreso than just ping.

Ok, does the default debian etch install have a telnet server running by default or do I need to start it?

Although I have not connected to the LTSP server via telnet I was able to do a simple tftp file transfer from the LTSP server to a windows botted pc on the same remote subnet (192.168.50.X). I actually transfered the pxelinux.0 file without any problem. Would this mean that nothing is being blocked, or could some obscure protocol needed to process the pxelinux.0 or the /pxelinux.cfg/default files still be getting blocked?

I am going to try and duplicate the remote subnet at the office and take the VPN tunnel out of play. Maybe my ISP is blocking something needed to remote boot via pxe...I dunno. I am at a loss on this.

[aaronjwood]

Originally Posted by wildpossum

I usually try doing a "telnet host service-port" to check the service availability from the target client location with my linux laptop first.

I installed telnetd and was able to telnet to the Debian LTSP/DHCP from the windows pc on the remote 192.168.50.X subnet without any problems. What next?

[wildpossum]

Unfortunately you miss understood me.

You do not need telnetd installed! Don't confuse "telnet" with "telnetd" as your NOT trying to create a telnet session but rather your using the telnet client session to discover what, if any ports are open/closed on that particular host machine. i.e.: Your using the telnet (client) to talk to the host to see if you can get a (ANY) response from the hostort a.k.a. that host's service. "telnet" [the client] exists on nearly all Linux boxes and probably windoze to, for just such purposes.

Example:
If you "telnet localhost ssh" on your laptop (ie: but to itself) it will respond with either:
A> Some jibberish + SSH version what-ever [your running sshd on your laptop and its is allowed connectivity],
B> or it will either tell you the host is not allowing communications,
C> and/or no open port currently.

You can use ANY port to ANY Host to test if it (the service) is OPEN and available for ACTION. That is the point of this testing exercise.

Of course "localhost" (above) can be ANY host IP (or FQDN if your running DNS), to ANY PORT in the range 0-65535 (see /etc/services, "man telnet -k" for more information).

So;

1> Remove telenetd [you installed] from your server - it is a security risk.

2> Can you "telnet" from the LTSP client cable connection (using your laptop) using "telnet [your-server-ip-adddress] tftp"?
if so then it is setup correctly. If not then you need to check /etc/hosts.allow, /etc/hosts.deny, firewall settings, etc.

3> If that is all OK, then what you are left with is either:
A> your dhcp setup is erroneous and/or,
B> the clients firmware (BOOTP code) is unable to correctly accept the downloading stream.

You will always find it best to set up your laptop to memic the BOOTP session (this will then guarentee the network, your tftp server settings and the boot file are correct), what is left is the client BOOTP setup, so that must be the problem.

It is all over to you now to check out these steps. There is nothing more that I can add. If you need greater understanding of step by step approach to fault finding your problem, then the RFC that covers tftp and bootp is what you need to read (then you can emulate the commands at the CLI level if you have too -- but that is the last step in my book).

[aaronjwood]

Originally Posted by wildpossum

Unfortunately you miss understood me.

You do not need telnetd installed! Don't confuse "telnet" with "telnetd" as your NOT trying to create a telnet session but rather your using the telnet client session to discover what, if any ports are open/closed on that particular host machine. i.e.: Your using the telnet (client) to talk to the host to see if you can get a (ANY) response from the hostort a.k.a. that host's service. "telnet" [the client] exists on nearly all Linux boxes and probably windoze to, for just such purposes.

Example:
If you "telnet localhost ssh" on your laptop (ie: but to itself) it will respond with either:
A> Some jibberish + SSH version what-ever [your running sshd on your laptop and its is allowed connectivity],
B> or it will either tell you the host is not allowing communications,
C> and/or no open port currently.

You can use ANY port to ANY Host to test if it (the service) is OPEN and available for ACTION. That is the point of this testing exercise.

Of course "localhost" (above) can be ANY host IP (or FQDN if your running DNS), to ANY PORT in the range 0-65535 (see /etc/services, "man telnet -k" for more information).

So;

1> Remove telenetd [you installed] from your server - it is a security risk.

2> Can you "telnet" from the LTSP client cable connection (using your laptop) using "telnet [your-server-ip-adddress] tftp"?
if so then it is setup correctly. If not then you need to check /etc/hosts.allow, /etc/hosts.deny, firewall settings, etc.

3> If that is all OK, then what you are left with is either:
A> your dhcp setup is erroneous and/or,
B> the clients firmware (BOOTP code) is unable to correctly accept the downloading stream.

You will always find it best to set up your laptop to memic the BOOTP session (this will then guarentee the network, your tftp server settings and the boot file are correct), what is left is the client BOOTP setup, so that must be the problem.

It is all over to you now to check out these steps. There is nothing more that I can add. If you need greater understanding of step by step approach to fault finding your problem, then the RFC that covers tftp and bootp is what you need to read (then you can emulate the commands at the CLI level if you have too -- but that is the last step in my book).

Grahame,

Let me first of all tell you that I am thankful for your help. I hope that you will be able to help me solve this issue.

I have changed so many things attempting to get this to work that I have lost track. I am right now doing a new install of Debian etch and will then install LTSP fresh. I will get the thinclient booting on the local subnet and then will test the remote subnet again. I did try to run "telent 10.0.1.4 tftp" as well as "telnet 10.0.1.4 69" from a computer on the local subnet but did not get a connection to the server. This is strange to me because if I run "netstat -aux | grep tftp" I get something listening there and didn't have any problems transfering files using tftp from a windows computer on the remote subnet. I also have checked my hosts.allow and hosts.deny and there are no entries there. So if tftp seems to work then why no answer on the telnet. I even did "telnet localhost tftp" on the server and it didn't answer. Actually the "telnet localhost tftp" gave a could not resolve error. The "telnet localhost 69" tried to connect to port 69 but said connection refused. Even with all this, the thinclient still booted fine on the local subnet. I am now using the Windows 2003 SBS as the DHCP clinet and sending the root path, boot file etc without any issue on the local subnet.

Once the install is done I will post the results.

Thanks,
Aaron