<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.14.1"> </HEAD> <BODY> Hmmm. I think you need help from someone more familiar than me with the Novell logon process at this point. However.... As I understand things, the DNS suffix is used when querying DNS servers, and is added to the name of the machine being sought if it is not specified. Thus if your machine name was 'daneel,' your DNS suffix was 'robots.com' and you asked 'daneel' to ping 'giskard' without specifying a fully-qualified name such as 'giskard.solaria.net' then 'daneel' would query for 'giskard.robots.com,' adding its own DNS suffix on to the sought-for name. A connection-specific DNS suffix lets you tell a computer with more than one network interface that it is to use a different DNS suffix on each network it has available. In most cases there is only one network interface and the connection-specific suffix is not needed; but it is set by DHCP anyway, just in case you didn't give Windows a fully-qualified name, or in case that name doesn't work on this particular network. I am afraid I have no idea whether this will affect the Novell logon process. To find out, if you place the PC directly on the main network, does it login correctly? What DNS suffix does it get there? What happens if you set that DNS suffix in the DHCP settings on the LTSP server? (The terminals will get this suffix too, but it shouldn't matter AFAIK unless they are running local apps or print servers etc). As an aside, I assume you've looked in the log files on the Windows machine, to see if the Novell client is trying to tell you anything. I don't know where Novell would put that information (anyone?), but I would start with the Event Viewer. Also, it would be helpful to see the output of 'iptables -v -L' on the LTSP machine. With tcpdump, it's probably only worth doing this if you know a bit about recognising network packets. On the other hand, I see no way to get any further without doing something like it, after proving the logon works with the Windows box on the main network. Others may like to recommend a better protocol analyser for this, such as ethereal - I'm just telling you what I would do, having a limited memory :-) I would first try to see what happens on the terminal network, like this: 1. Start a command line on the LTSP server and type 'ifconfig' (omit the quotes, they are just for clarity here) to see which network is on which interface - look at the ip addresses for eth0, eth1, etc. Let's say eth0 is the terminal network (with 192.168.0.254) and eth1 the main network for what follows. If yours are different, make the appropriate changes below. 2. Make sure all other computers and terminals on the terminal network are turned off, to avoid extra traffic or having to use a filter while tcpdump-ing. 3. Do 'tcpdump -vv -i eth0 >file0' in the command line on the LTSP server - this causes tcpdump's output to be captured in a text file called 'file0'. 4. Turn on the Windows machine (this is so we capture any preliminary lookups it tries before logon). 5. Try to log in to Novell when Windows is ready. 6. When the login fails, use Ctrl/c on the LTSP server to interrupt the capture. 7. Shut down the Windows machine again. Now we repeat the process capturing traffic on the main network. You won't be able to shut everything down here, but try to do it at a quiet time. 8. With the Windows machine off, do 'tcpdump -vv -i eth1 >file1' on the LTSP server. 9. Repeat steps 4,5,6. Now compare the two capture files 'file0' and 'file1'. (I suggest doing the two captures separately so that file0 will give you a guide to what is relevant in file1, without having to search hard for it amongst all the other traffic.) The ip addresses (and ports on the LTSP server end) will be different owing to NAT, but you should see an outgoing packet in file1 for every incoming relevant packet in file0 (this is where it gets hard to describe what you are really looking for), and appropriate responses coming back from the DNS and Novell servers on the main network in file1, and being passed back to Windows in file0. Look out for repeated requests that give a clue about a response going missing. If you can't work out the order of packets, you could repeat steps 2-6 but using 'tcpdump -vv -i any >file2' which will capture both interfaces at once, in order. Again, look for corresponding packets on each side being relayed by the LTSP server. Look out for DNS lookup failures, and also look out for broadcasts other than ARP on the eth0 side (sent to a .255 address) - it may even be that Novell relies on broadcasts to find servers, but I sincerely hope not! It would be instructive to compare the results with a trace of a successful login on the main network, if you can manage that - but Windows has no native equivalent to tcpdump, and I don't know about Netware. By the way, I'm using Ubuntu to check the command parameters I'm telling you - they might be slightly different on FC5, but I doubt it. That's all I can think of at the moment. I hope it helps! Good luck! On Tue, 2007-09-25 at 05:05 +0000, jones yeates wrote: <BLOCKQUOTE TYPE=CITE> <PRE> I tried to get the dhcp server to give the client the DNS server ip addresses on the school's network, and it still didn't work. As you mentioned, the Linux thin clients ended up not being able to connect properly. I noticed that the school machines have a different Connection-specific DNS Suffix than the LAN and I'm not sure if I should change it to what the school has or not. I don't know what that does. The Windows clints can ping the DNS servers. I installed tcpdump, but I'm not sure how to use it to see the packet flow from the Window's client. >From: Steve Jackson <<A HREF="mailto:sjxn@bigpond.net.au">sjxn@bigpond.net.au</A>> >Reply-To: "Support list for open source software in schools." ><<A HREF="mailto:k12osn@redhat.com">k12osn@redhat.com</A>> >To: "Support list for open source software in schools." <<A HREF="mailto:k12osn@redhat.com">k12osn@redhat.com</A>> >Subject: Re: [K12OSN] Window Clients can't get past the Linux Server >Date: Sun, 23 Sep 2007 08:23:11 +1000 > >This sounds like a DNS lookup problem to me. DNS is used to locate domain >servers in Active Directory, assuming that's what you mean by "tree server" >- and the same for Novell I think. >To diagnose, I would hand-configure the W2K DNS server entry to be the same >address as it would get if it were connected to the "main" network, and see >if it now works. If it does, you need to look at where the LTSP server's >DNS service is forwarding requests it can't handle to, and make it try the >"main" network's DNS. If your LTSP server doesn't have a DNS service, >change its DHCP config to tell the clients to use the main DNS address. > >Transparent proxying only affects web traffic IIRC (and I'm not sure what's >going on with squid, can't help there). The ip_forward setting must be 1. >NAT must be used unless the "main" network knows how to route packets back >into the "terminal & w2k" network. > >Steve > >jones yeates wrote: >>I am using a floppy to boot onto the LTSP server. It is working fine. >>The clients can log in and access the Internet. =] >> >>When the client doesn't boot from the floppy, it loads up Windows (2000). >>It is unable to find the "tree server" to authenticate the Windows user. >>However, if I say "Yes" to work on the Window's desktop, I can access the >>Internet. >> >>On the Fedora Core 5 server that is running K12LTSP, I tried: >> #echo 1 > /proc/sys/net/ipv4/ip_forward >>and that took care of the Windows client being able to access the >>Internet. >> >>I tried: >> #chkconfig --levels 345 transparent-proxying on >>and there was no change so I entered >> #chkconfig --levels 345 transparent-proxying off >> >>I restarted the server, for another attempt at solving this. >>I turned off the firewall, installed and ran squid. I made the changes >>discussed in >><A HREF="http://www.redhat.com/archives/k12osn/2007-August/msg00221.html">http://www.redhat.com/archives/k12osn/2007-August/msg00221.html</A> but it >>failed to #service squid restart. I removed the transparent value and >>#service squid restart worked fine. >> >>I tried >> #chkconfig --levels 345 transparent-proxying on >>again. This time it couldn't be found. I listed all the values for >>chkconfig and it wasn't on the list. I am not sure how I removed that >>item, is there a way I can get it back? >> >>Below is what the ipconfig looks like on the Window's client. >> >>E:\>ipconfig /all >>Windows 2000 IP Configuration >> Host Name . . . . . . . . . . . . : c-23 >> Primary DNS Suffix . . . . . . . : >> Node Type . . . . . . . . . . . . : Hybrid >> IP Routing Enabled. . . . . . . . : No >> WINS Proxy Enabled. . . . . . . . : No >> DNS Suffix Search List. . . . . . : ltsp >>Ethernet adapter Local Area Connection 2: >> Connection-specific DNS Suffix . : ltsp >> Description . . . . . . . . . . . : Intel(R) PRO/100 VE Network >>Connection >> Physical Address. . . . . . . . . : 00-01-04-EB-12-1C >> DHCP Enabled. . . . . . . . . . . : Yes >> Autoconfiguration Enabled . . . . : Yes >> IP Address. . . . . . . . . . . . : 192.168.0.218 >> Subnet Mask . . . . . . . . . . . : 255.255.255.0 >> Default Gateway . . . . . . . . . : 192.168.0.254 >> DHCP Server . . . . . . . . . . . : 192.168.0.254 >> DNS Servers . . . . . . . . . . . : 192.168.0.254 >> Lease Obtained. . . . . . . . . . : Friday, September 21, 2007 >>4:25:40 PM >> Lease Expires . . . . . . . . . . : Friday, September 21, 2007 >>10:25:40PM >> >>As a Windows client, I am able to ping outside of the 192.168.0.0 LAN and >>onto the school's regular network. I believe nat is working because I can >>access the Internet on the Window's client. >> >> >>I am not sure what else to try. The transparent thing is my only guess. >> >>_________________________________________________________________ >>Windows Live Hotmail. Even hotter than before. Get a better look now. >>www.newhotmail.ca?icid=WLHMENCA148 >> >>_______________________________________________ >>K12OSN mailing list >><A HREF="mailto:K12OSN@redhat.com">K12OSN@redhat.com</A> >><A HREF="https://www.redhat.com/mailman/listinfo/k12osn">https://www.redhat.com/mailman/listinfo/k12osn</A> >>For more info see <<A HREF="http://www.k12os.org">http://www.k12os.org</A>> >> > >_______________________________________________ >K12OSN mailing list ><A HREF="mailto:K12OSN@redhat.com">K12OSN@redhat.com</A> ><A HREF="https://www.redhat.com/mailman/listinfo/k12osn">https://www.redhat.com/mailman/listinfo/k12osn</A> >For more info see <<A HREF="http://www.k12os.org">http://www.k12os.org</A>> _________________________________________________________________ Former Police Officer Paul Gillespies TAKE BACK THE INTERNET tips and tricks, watch the video now <A HREF="http://safety.sympatico.msn.ca/">http://safety.sympatico.msn.ca/</A> _______________________________________________ K12OSN mailing list <A HREF="mailto:K12OSN@redhat.com">K12OSN@redhat.com</A> <A HREF="https://www.redhat.com/mailman/listinfo/k12osn">https://www.redhat.com/mailman/listinfo/k12osn</A> For more info see <<A HREF="http://www.k12os.org">http://www.k12os.org</A>> </PRE> </BLOCKQUOTE> </BODY> </HTML>