[K12OSN] Window Clients can't get past the Linux Server
Steve Jackson
sjxn at bigpond.net.au
Fri Oct 5 07:03:34 UTC 2007
That's great! Full marks for persistence.
Where there's a Linux there's a way. :-)
Maybe your solution should be turned into a wiki article.
jones yeates wrote:
> I got it to work. It was an IPX problem. I described it on another
> thread:
> https://www.redhat.com/archives/k12osn/2007-October/msg00051.html
>
> Thanks again for all of your help.
>
> ------------------------------------------------------------------------
> Subject: Re: [K12OSN] Window Clients can't get past the Linux Server
> From: sjxn at bigpond.net.au
> To: k12osn at redhat.com
> Date: Tue, 25 Sep 2007 21:58:18 +1000
>
> 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 <mailto:sjxn at bigpond.net.au>>
> >Reply-To: "Support list for open source software in schools."
> ><k12osn at redhat.com <mailto:k12osn at redhat.com>>
> >To: "Support list for open source software in schools." <k12osn at redhat.com <mailto: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 <mailto: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 <mailto: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 <mailto:K12OSN at redhat.com>
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>
>
>
>
> ------------------------------------------------------------------------
> Express yourself with new emoticons. It’s easy! Try it!
> <http://www.freemessengeremoticons.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/20071005/aeacd9c2/attachment.htm>
More information about the K12OSN
mailing list