[K12OSN] Window Clients can't get past the Linux Server
Steve Jackson
sjxn at bigpond.net.au
Tue Sep 25 11:58:18 UTC 2007
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:
> 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 <sjxn at bigpond.net.au>
> >Reply-To: "Support list for open source software in schools."
> ><k12osn at redhat.com>
> >To: "Support list for open source software in schools." <k12osn at redhat.com>
> >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
> >>http://www.redhat.com/archives/k12osn/2007-August/msg00221.html 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
> >>K12OSN at redhat.com
> >>https://www.redhat.com/mailman/listinfo/k12osn
> >>For more info see <http://www.k12os.org>
> >>
> >
> >_______________________________________________
> >K12OSN mailing list
> >K12OSN at redhat.com
> >https://www.redhat.com/mailman/listinfo/k12osn
> >For more info see <http://www.k12os.org>
>
> _________________________________________________________________
> Former Police Officer Paul Gillespies TAKE BACK THE INTERNET tips and
> tricks, watch the video now http://safety.sympatico.msn.ca/
>
> _______________________________________________
> K12OSN mailing list
> K12OSN at redhat.com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/k12osn/attachments/20070925/d29675af/attachment.htm>
More information about the K12OSN
mailing list