in reply to Help my IT admin unblock PPM and CPAN, please.

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

  • Comment on Re: Help my IT admin unblock PPM and CPAN, please.

Replies are listed 'Best First'.
Re^2: Help my IT admin unblock PPM and CPAN, please.
by JavaFan (Canon) on Apr 22, 2010 at 11:28 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.
    Or further. Or less far. It's not uncommon nowadays for ICMP packets to have different firewall rules than TCP/IP packets.
Re^2: Help my IT admin unblock PPM and CPAN, please.
by aplonis (Pilgrim) on Apr 22, 2010 at 14:52 UTC

    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