aplonis has asked for the wisdom of the Perl Monks concerning the following question:

I'm working with our IT department's local, on-site administrator to arrange it so that my department's Perl PCs may enjoy the use of ActiveState's PPM and CPAN too. But we're having issues with figuring that out.

It is already agreed that various PPM repositories and CPAN ought to both be permitted. No issues there. But we are having a very hard time determining from which among our corporation's several (globally-adminstered) network softwares is blocking PPM and CPAN. Two or more of them might be effecting the blockage in combination for all we can tell. A couple of days now we've wasted trying this and that. So far nothing helps.

Some time before, both had been working. But that was quite some ago. Between then and now something has changed. But since I don't use either PPM or CPAN on even a weekly or monthly basis, I can't pin down the date on which either stopped working. I only discovered it recently when attempting a fresh install Perl on an additional PC newly installed in our lab.

I am hoping someone on this list might know which hoops to jump through. Any insite whatsoever whould help to narrow the focus for my plant's one-and-only (read overworked) IT administrator...an MS-oriented sort who, alas, knows nothing much about Perl.

The company uses Microsoft ISA on the global network. Tha installion is a whole time-zone distant. But I don't think it's that because I can see the various PPM repository sites and CPAN also in the MSIE browser. So I don't think it's a global keyword or URL block.

We are also using these on every WinXP PC in the plant...

If it's McAfee then we need clues on how to configure it. We can't just turn it off, not even as an experiment, without risk of major retibution. So don't suggest that, please.

FTP going outbound is not blocked. I can manually do FTP to my private server. And, as I said, I can visit the PPM repositories and also CPAN via MSIE 6.

I can do this.... C:> perl -MCPAN -e shell ...and do GET but the LWP always reports error[404] Not found. when I do. Likewise, when I call PPM and it goes to read from the repository list, I see Not found on all of them, including ActiveState's own.

I read on the ISA website, at least as of 2006, that ISA does not sniff for UserAgent. My IT admin has set my own privileges on the PC to highest. That didn't work. She came and logged in as herself in IT admin guise, and still PPM and CPAN don't work. It's really got us stumped. Might anyone possibly shed a ray of enlightenment, please?

Replies are listed 'Best First'.
Re: Help my IT admin unblock PPM and CPAN, please.
by crashtest (Curate) on Apr 21, 2010 at 20:52 UTC

    At $work, I installed Microsoft's Firewall Client for ISA Server. With it running, my non-MS applications (like, say, LWP) manage to authenticate themselves to the proxy and talk to the Internet.

    Without the client, my symptoms were different from yours. I got 407 errors from the proxy - not 404s. Perhaps you have something else going on.

    Can you talk to the Internet at all from your applications (outside of Microsoft applications)? If you can get LWP installed "by hand", can you use lwp-request to fetch Google's homepage? That would be how I'd start to narrow the problem down.

      Non-MS Firefox can connect, provided that it is set to auto-configure which picks up the in-house proxy server.

      I'll look into the hand-built LWP later today or Monday. Thank you.

Re: Help my IT admin unblock PPM and CPAN, please.
by BrowserUk (Patriarch) on Apr 21, 2010 at 22:57 UTC

    Can you get to CPAN/PPM urls if you use LWP::Simple::get()?

    If not, try using LWP::UserAgent and setting $ua->agent( ) to the same string as your browser uses. You can find that out by visiting one of the many websites that will show you the headers your browser is sending. (eg. Like this one.)

    If that let's you through, then it may give you a clue as to what needs to change.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      Yes, command get() from module LWP::Simple works for the these three URLs:

      • http://google.com
      • http://activestate.com
      • http://cpan.org

      I can see the HTML from all of those, no problem. I didn't need to do anything via LWP::UserAgent for that to happen.

Re: Help my IT admin unblock PPM and CPAN, please.
by proceng (Scribe) on Apr 21, 2010 at 23:12 UTC
    I would be inclined to believe that one of the two following conditions exist:
    • There is a proxy in place that is not being satisfied by the command line program.
    • There is a specific port that is being tried.
    For the first condition, Wireshark or some other sniffer may be your best bet to tell where the communication path is failing.

    For the second, try updating (through CPAN or CPANPLUS) after changing your urllist to:

    • ftp://ftp.funet.fi/pub/languages/perl/CPAN/
    • http://mirror.eunet.fi/CPAN
    • rsync.nic.funet.fi::CPAN
    (Note: Select just one module or simply ask for a list of available updates (r on CPAN or o on CPANPLUS). This will tell you which protocol(s) is/are failing to operate. That will give you more information as to the port(s) to look at.
    Also, if you are using FTP as your protocol, set communication to PASSIVE to make your life easier. That way, your firewall(s) only need to work with ports 20 and 21.

      On the Windows command line I can FTP to both ftp.funet.fi and to cpan.org no problem. From both I was able to manually get get Date-Calc-6.3.tar.gz without needing to specify PASSIVE.

Re: Help my IT admin unblock PPM and CPAN, please.
by bart (Canon) on Apr 21, 2010 at 21:08 UTC
    Make sure it's not the firewall on your own machine. Those can block connections, not per site, but per program: a browser can see the repository, but PPM or CPAN isn't allowed through.

    BTW virus scanners don't block internet access. At least, unless they're very broken. So I wouldn't suspect McAfee.

Re: Help my IT admin unblock PPM and CPAN, please.
by JavaFan (Canon) on Apr 22, 2010 at 11:35 UTC
    I'd say, start from the basics. Can you, from the same machine you're running the CPAN shell, actually FTP to a CPAN mirror? Try different mirrors if it fails. If you can connect, is your FTP connection using active or passive mode? If it's in active mode, it's the remote server that sets up the data connection - which may be blocked by your firewall(s). If you cannot connect using FTP, can you connect using HTTP? Try just doing a GET request first - or even a plain telnet to port 80 (or whatever port the mirror is using).

    If all that is failing, but you can ssh out to some machine (internally or externally) that can FTP or HTTP to a CPAN mirror, you could always set up an ssh tunnel.

      I can communicate via FTP on the Win32 command line to various places. There is no passive command listed under help for Win32 FTP daemon. I can do get via mini Perl script using LWP::Simple. Using the MSIE browser I can see the PPM repository web pages.

      I just keep getting Not found responses when I call get in regular CPAN and when PPM tries to fetch the packlist.

      I've ordered the book for Wireshark as I can't seem to make much from all the tons of info it delivers. This mystery is really quite frustrating. Grrr.

        I can communicate via FTP on the Win32 command line to various places.
        Including the CPAN mirror your CPAN client is connecting to? How is your CPAN client configured? How is it configured to fetch things? Which CPAN mirror(s) is it using?
        Using the MSIE browser I can see the PPM repository web pages.
        Do you run the browser from the same machine you're using the CPAN client from?
Re: Help my IT admin unblock PPM and CPAN, please.
by Argel (Prior) on Apr 21, 2010 at 23:12 UTC
    You can try doing a tracert to CPAN or PPM repository too see how far it can make it out. Just keep in mind that if a firewall is dropping packets then the problem will be one hop further out than what tracert reports. Do you get the 404s right away or after a considerable delay (e.g. 30+ seconds)?

    You could also use Wireshark to do a packet capture to see what kind of responses you are getting (or not getting) back. That might also give you some clues (and it might have the IP address of whatever is blocking you in it).

    Beyond that it starts getting more difficult.

    If McAfee or something else on your system is causing the problem then in theory it should be logged somewhere. Try looking for those logs and also check Windows' system and application event logs.

    Elda Taluta; Sarks Sark; Ark Arks

      You can try doing a tracert to CPAN or PPM repository too see how far it can make it out. Just keep in mind that if a firewall is dropping packets then the problem will be one hop further out than what tracert reports.
      Or further. Or less far. It's not uncommon nowadays for ICMP packets to have different firewall rules than TCP/IP packets.

      I got permission to install and use Wireshark from our local IT admin. I'm totally new to this tool and don't really know what I'm doing. But so far I have managed this...

      • Turned on capture in non-promisuous mode for my interface.
      • Called up PPM and waited while it returned 404, Not found for these repositories:
        • ActiveState's own
        • U. Winnepeg.
      • Stopped the capture.
      • Shows as follows:
        • Packets 76
        • Displayed 29
        • Marked 0
        • Dropped 0
      • Via Follow TCP Stream I note:
        • .RWS.b...(many dots)..@...me.mypc.perl.exe.RWS.
        • .RWS.%...(many dots)...(return)OURNETWORK\OURPROXY$.
      • Most of the captured are black on blue, with Info as follows:
        • remote-winsock > csoftragent [SYN, ACK]
        • remote-winsock > csoftragent [ACK]
        • remote-winsock > csoftragent [PSH]
      • One is black on gray, with Info as follows:
        • csoftragent > remote-winsock [SYN]
      • The last one is yellow on red, with Info as follows:
        • csoftragent > remote-winsock [RST, ACK]

      So am I correct in supposing that yellow on red can't be good?

        Considering e.g. the 404 you are getting I'm not sure if I would read too much into the TCP RST (the yellow on red). As IP Overview mentions under "Resetting a Connection", TCP RSTs are used to quickly tear down a connection. A 404 error on the remote side might translate into a a quick teardown scenario. The fact that the RST was also flagged with an ACK supports that.

        What was the remote site? Do you recognize it? Is it a proxy or firewall? It could very well be the culprit. If not, then do the packets leading up to the TCP RST offer any clues? It's hard to troubleshoot without seeing more details (and I am by no means a network guru).

        Elda Taluta; Sarks Sark; Ark Arks

Re: Help my IT admin unblock PPM and CPAN, please.
by herveus (Prior) on Apr 22, 2010 at 16:57 UTC
    Howdy!

    Are you having proxy issues? I just went through getting CPAN to play nice with the proxies here. I had to make sure I set the http_proxy and ftp_proxy parameters correctly *and* to set proxy_user to '' (empty string) instead of undef. Once I did that, it worked much better.

    yours,
    Michael

      I will look into that specifically on Monday. Crossing my fingers. But it would be odd for that to be it as I'm no longer able to do either PPM or CPAN on older PCs in the same network where I had formerly been able to do so. If it's that, then somehow all those other PCs got their prior settings rest or deleted. Hope it is, though. That would be an easy fix.

        But it would be odd for that to be it as I'm no longer able to do either PPM or CPAN on older PCs in the same network where I had formerly been able to do so.
        Speaking as a NetAdmin (and having been on the sharp end also :-)), there is always a possibility that the proxy configuration has changed.
        I would go back to the suggestion I made earlier (configure CPAN to use one http, one ftp and one rsync url, start wireshark, try to get a module within CPAN) and see what you get.

        The fact that you get a RST says that something in the route is shutting down your connection before completion, normally you should see data transfer and then a FIN, FIN+ACK sequence.

        The sending IP address on the RST transmission is your culprit, it will help to know which protocol is being blocked. If you try one at a time in the urllist, you will find it fairly quickly.

        Good luck, HTH

        Updated: Forgot to put the quote in that I was replying to