using cometbird with local intranet

[horhota]

I just downloaded Cometbird and like it a lot. I've been using it at work but I can't seem to access my local intranet web pages. I key in my http address (http:\\servername\folder\pagename) - but Cometbird wants to put "www" in front of the server name and then fails to find the page. I've already looked in a lot of settings etc and searched this forum for "intranet" but can't see anything that I can change to get this to work. Anyone have any ideas? Thanks!

[kluelos]

If you're just using a servername, then you will need to specify that this is a file you are going after, not a web page on the internet.

Your system, not specifically Cometbird, tries to resolve "servername" into a qualified domain. (Try adding "www." at the front, maybe that will work? Nope. Can't resolve, fail.) This would normally depend on a DNS server also on the intranet, but many don't have them because they're not organized that way. Yours makes me think that your intranet isn't, either.

Assuming it's a Windows network, the url I would expect to see would look more like

file://///SERVERNAME/Sharename/filename

You may have had bookmarks set up this way, so you wouldn't have necessarily noticed. One way to clarify this is, if you can physically browse to the index file location on the intranet, drag&drop that file onto your browser, and bookmark it.

Another way to check is to look at somebody else's working contact, and just have them copy/email you the url.

[greywizard]

Just to add a couple of notes, if you put http: in front of the URI then you NEED to have a HTTP server running on the target machine and as kluelos said, either have a DNS server running somewhere locally or if your HTTP server is a public one, then probably you will be able to use your public default DNS server to resolve the URI.

The alternative would be to manually add an entry in the hosts file.

Second, URLs use slashes "/" to delimit their internal hierarchy.

The way you wrote that path, it looks more like a Windows UNC path (which uses backslashes "\" instead of slashes because, well... they always knew better than the rest of the world). Except "http:" has no business being there.

[horhota]

Thanks for the replies. Sorry about the slashes. I was at home, tired, late - my fingers slipped up - should be forward slashes as in the following:

http://nms/test/ccs030.pgm

To clarify my situation, I'm a mainframe developer and building programs and pages such as the above. Now, I normally use Internet Explorer or Firefox and have never had to do anything special for my pages. We have our choice of one or two proxy servers one of which I've set up in Cometbird as a http proxy. After reading your replies and considering the DNS issue, I tried entering the IP address instead of servername and it worked. Then I took another look at the internet connections page. I saw the box "No proxy for" and looked at some of the suggested entries. I decided to enter the names of the local iSeries servers I use. Once I did that, and changed one of my links to just servername/library(folder)/pagename, Cometbird worked. So must be something different in the way Cometbird works with DNS as compared to InternetExplorer and Firefox. That's a bit nasty since most of my commonly used intranet pages are set up as icons on my desktop and the links would need to be changed to accommodate Cometbird. I'm also wondering if links from one page to another are going to have a problem. Any thoughts or suggestions?

[greywizard]

Just to clarify, none of us, the staff of this forum, is part of the development team for any of the applications for which this forum provides support.

So, I can't say that I know exactly how CometBird works intimately.

But if we can draw a pretty accurate sketch of the problem then we can forward it to the dev team, as soon as we establish beyond any doubt that CometBird is at fault here.

Right now it's not very clear to me what the logical network topology is at your work site, so that's a big question mark.

Is this a private LAN, using private IP addresses?

Is the HTTP server you're trying to access on the same subnet as your machine or on a different one?

Or perhaps, alternatively the HTTP server is using a public IP address?

Does your company network have a DNS server?

Is the server accessible from the public domain too (extranet and intranet), or just available internally for the company?

Does the proxy you use have a public IP (i.e. is it situated beyond the NAT/firewall of your company) or a private one?

Just a reminder (if you know this ignore it); the private IPv4 ranges are:

192.168.0.0 /16

172.16.0.0 /12

10.0.0.0 /8

Just trying to figure out for myself, what are the steps that CometBird will have to take "behind the scene" in order to translate the URL to an IP and subsequently reach the HTTP server.

Since it can access the server using just the IP, this obviously has to do with DNS in some way but right now I can't say I have a clue where things are going wrong.

What happens if you set CometBird to bypass the proxy but don't modify the URL?

[horhota]

I'll try and answer your questions as best I can. I am a database developer - not a network specialist - and also work at one of several sites in the company which are connected by WAN with all internet access being routed through our head office.

Our LAN is restricted to our site. It cannot be accessed directly from outside of the company. We reach the internet(outside world) through the WAN and the firewall at our head office.

The HTTP server is on the same subnet as most if not all of the computers at our site. Only some third party process control equipment is on a separate subnet.

I don't know if we have a DNS server at our site or head office. We used to have one years ago before we joined our current company.

I would say that our HTTP servers( we run servers on several of our local mainframes(IBM AS400/iSeries) and Windows servers) do not have public IP addresses since they cannot be accessed via the outside world. For EDI stuff, we get our head office to modify the main firewall to allow specified IP addresses to transact with our servers.

The Proxy choices I have(local or head office) I would say have private IP addresses. I have to admit that I'm not familiar with the private vs public IP terminology.

I haven't tried removing/bypassing the proxy because I believe that doing so would stop me from accessing the internet and limit me just to the site intranet.

Due to cutbacks etc there is no longer anyone at our site with networking experience. Asking these questions at our head office would cause problems - i.e. "you should only be using company prescribed software etc." If I was happy with the performance of Internet Explorer I wouldn't be here!

Bottom line to all of this is that the change I made to "No Proxy for" seems to have solved the problem. I'm definitely impressed with Cometbird and even if I couldn't use it at work I'd definitely plan to use it at home. Now, at home, I stick with Linux, notably Puppy Linux, for any web browsing so I'll be most interested when they offer a Linux version or someone comes up with a Cometbird pet for Puppy.

Again, thanks to you and all who responded and passed along suggestions.

[greywizard]

I wasn't suggesting that you disable proxies altogether, I was just referring to the Firefox/Cometbird option you were talking about ("No proxy for") suggesting that you only use it for the URLs of the HTTP servers or the domain they're residing on, in order to prevent CometBird from forwarding the DNS requests out of your LAN (in case the DNS server being used is beyond your proxy). I said that, because in your previous post you seemed to indicate that you used this option but also modified the URLs so it wasn't clear which of the two actions made it work.

I'm not sure if I understand you right, but are you saying that you managed to actually solve your issue by using the "no proxy" option, mentioned above (i.e. you got it to work after adding the servers in the "no proxy" zone)?

To make it more clear, the private IP ranges I indicated above translate like this:

192.168.0.0 /16 <==> 192.168.0.0 - 192.168.255.255 (anything in between these two addresses)

172.16.0.0 /12 <==> 172.16.0.0 - 172.31.255.255 (anything in between these two addresses)

10.0.0.0 /8 <==> 10.0.0.0 - 10.255.255.255 (anything in between these two addresses)

You can verify the IPs of the HTTP servers and of the proxy servers against these ranges to determine if they are local or public and to verify if they're part of the same subnet as your workstation or residing on a different one.

You can also determine the DNS server(s) used by your workstation by checking the TCP/IP properties of the network connection or by simply typing ipconfig /all at the command prompt in Windows (just make sure you identify your active NIC used for connecting to the network since this command displays results for all the network adapters found in the computer).

With this information in hand you can draw a pretty informed conclusion about the logical whereabouts of your DNS server and whether a DNS request has to go through the proxy, by default.

Anyway, if you solved the issue already, then regard the info above just as informative. Else you can use it to help track down the issue and narrow down the possible causes.