From: Harry G. <ha...@hg...> - 2003-06-30 15:58:38
|
There's an easy way to diagnose what's happening. Login to IPCop as root via ssh or via a real console and issue the command: tcpdump -s 0 -i eth0 port 53 tcpdump will dump the full (-s 0) packets received or sent on (port 53) - DNS at its interface (-i eth0). If your green network is not on eth0, you may have to change the -i option. Then bring up IE or whatever and try to go to www or whatever and see what the resulting domain name is. Use Ctl-C to kill tcpdump. Harry At 1:14 AM +0100 6/30/03, Matthew Dale wrote: > > At 5:19 PM +0100 6/29/03, st...@wo... wrote: >> >On 29.06.2003 16:35 Matthew Dale wrote: >> >>Issue number 1: Local DNS >> >>Many people seem to have difficulty in getting to ipcop via >> >>http://ipcop:81 as stated in the manual - I am among these people. >> >>I'm using DHCP to set clients up - and the dns server is set as IPCop >> >>as it should be. However, all I get is 404s trying to access like >> >>that, and ping can't ping it either - leaving me with >> >>http://192.168.0.1:81 as the only surefire way to access it. >> >>I have recieved a couple of workaround, one of which in particular >> >>poses questions about how the lookup is handled. >> >>The first workaround is to set the DNS Suffix to mydomain.home (or >> >>something similar) and add a line "192.168.0.1 ipcop.mydomain.home" to >> >>/etc/hosts on the IPCop box. This works fine - it pings, and the >> >>browser can see it. >> > >> >I would have thought that you should be doing this anyway. I always have > >Maybe I should. I was just curious as to why it didn't work "as advertised". > >> Both Windows and Mac OS X have a different way they do DNS lookups >> from the Unix/Linux systems of the world, if they see a name with no >> periods. Unix/Linux will try any name with or without periods before >> they append the DNS suffix to it while Windows and Mac OS X >> immediately append the suffix. In other words, a Unix box will first >> send a query for "ipcop" and then for "ipcop.mydomain.home", while >> Windows and Mac will never send the query for ipcop. Adding a period >> makes everyone happy. >> >> BTW, if you make a typo and try to browse "www.ipcop.orgg", everyone >> will first try "www.ipcop.orgg" and then >> "www.ipcop.orgg.mydowmain.home". > >So basicly, it would work fine on a *nix machine - ok, I can live with that >and add to my grumble-list for windows and networking... > >> >> >> >>Issue number 2: Global DNS Suffixes >> >>As I said above in the first workaround, DNS suffixs work fine for me >> >>locally. >> >>However, global ones don't. Here is a test case I just ran. >> >>I set the DNS suffix to "bbc.co.uk". I renewed my DHCP lease and >> >>checked that the new settings had come through. I then flushed the DNS >> >>cache on the box I was using to test the suffix to remove any chance >> >>of it using a precached result. >> >>With this setup, requesting "www" should get me http://www.bbc.co.uk, >> >>and requesting "news" should get me http://news.bbc.co.uk, and so on. >> >>Not so. any request that relies on the suffix results in a 404. >> >>However, an inspection of the local DNS cache after the request >> >>reveals an entry like: >> >>news >> > >> >Are you running a web proxy, if so it might not work, since you >> >would look for news and so might the proxy. >> >If domain name was not defaulted on the proxy then the it would look for >news. >> >Just an idea. >I've tried it with squid on (transparent), on ('normal'), and off. I flushed >the local DNS cache and restarted IPCop before testing in each mode. I got >identical results in all modes - the DNS lookup would be sucessfully >recieved by the local machine but the browser would still 404. In all modes, >it worked for all other services. >In fact, I did a bit more testing, and here's where it gets odd. I tried >this at the windows command prompt: >telnet www 80 >I was expecting a destination unreachable error or something, but instead it >connected. Hitting enter resulted in what I'd expect to happen if I'd typed >the full address myself (I got the HTML for the "bad request" response >spewed down the screen because I'd not specified any HTTP header before >sending the CR). So it works at the lowest level - I guess there's something >up at the API level - still sufficiently low level that it's used by both >Mozilla and IE, but abstracted enough that using telnet circumvents it. >Yet another thing to add to the windows grumble list then. >> > >> >Why not net the domain and be done with it? >The people who will be using the system are used to being able to type >"mail" etc and being directed straight to thier webmail login. I'll just >have to sort out the local hosts files. > >> > >> ><me thinks out aloud> >> >Maybe people who 'know' about networking are setting the domain >> >without thinking about it, whereas those we problems are not. >> ></me thinks out aloud> >> >> This sounds like you're not getting the DNS domain set properly on >> the machine doing the browsing and are you sure you didn't type >> "news."? >> >> Harry > >I definately didn't. I tried it later out of interest, but during the >testing I didn't use a trailing period. >Ah well, it looks like IPcop is functioning perfectly and windows is just >being irregular as usual. Maybe there should be a section added to the FAQ >on this, detailing both workarounds? > >Thanks for your responses anyway. > > > > >------------------------------------------------------- >This SF.Net email sponsored by: Free pre-built ASP.NET sites including >Data Reports, E-commerce, Portals, and Forums are available now. >Download today and enter to win an XBOX or Visual Studio .NET. >http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 >_______________________________________________ >IPCop-devel mailing list >IPC...@li... >https://lists.sourceforge.net/lists/listinfo/ipcop-devel |