Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Remove Entourage X delay on quit (revisited) Apps
[Editor's note: There's another thread with a different solution to this problem that involves closing your PPP connection before quitting. I felt this one was different enough to merit separate a separate thread.]

With certain ipfw firewall configurations and dialup connections there is a long delay when quitting Entourage v.X. By blocking remote ports 49000-50000and local ports 3000-4000 this delay is gone (the ports can probably be narrowed down). This can be done by the shell command (as user root)
ipfw 10000 add deny tcp from any 49000-50000
to any 3000-4000 out xmit ppp0
NOTE: Shown on two lines; enter as one!

The rule number might have to be changed based on your firewall settings. If there is no firewall (by using "ipfw flush") the delay does not exist at all. I'm sure a program like BrickHouse that's used to configure ipfw can be used as well. --Paul pdrake@cs.utah.edu
    •    
  • Currently 0.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (0 votes cast)
 
[8,061 views]  

Remove Entourage X delay on quit (revisited) | 8 comments | Create New Account
Click here to return to the 'Remove Entourage X delay on quit (revisited)' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Office X checks for other instances on the network
Authored by: Stephan on Dec 14, '01 10:34:12AM

Office X uses TCP port 3264 and UDP port 2222 to see if any other Office X applications are running and checks the licence-keys for duplicates.
This could have something to do with the delays...

The following rules stop this:
ipfw [insert number here] add deny log tcp from any to any 3264 via en0
ipfw [insert number here] add deny log udp from any to any 2222 via en0

You can do this for the apropriate interfaces (en0, en1, ppp0)



[ Reply to This | # ]
another way
Authored by: Joachim on Dec 14, '01 06:09:25PM

I saw another hint on these delays at MacFixit forums (IIRC). It said to allow any connections from and to device lo0, the local loop. So I added to ipfw config (I used Firewalk-X though editing by hand should do as well):

add [insert rule number] allow log TCP from any to any in via lo0
add [insert rule number] allow log UDP from any to any in via lo0

It works. No more delays closing Office v X apps.

If this has any adverse effect please tell me.

-joachim



[ Reply to This | # ]
Update
Authored by: pdrake on Dec 16, '01 03:02:03AM
I tried the "lo0" option but it didn't work for me. The ipfw that ships with OS X maybe doesn't support it (I know other *BSDs do)? I saw no mention of "lo0" in the ipfw man file either.

I found some connection problems with Napster. The way to fix this (other than "lo0") so it's blocking specifically what's coming from your local computer to your local computer (and solves these kind of conflicts) is below. "127.0.0.1" and "localhost" don't work, so don't try it.

File /etc/ppp/ip-up which is:

#!/bin/sh
myip=$(/sbin/ifconfig ppp0 | grep inet | cut -d" " -f2)
/sbin/ipfw add 10000 deny tcp from $myip 49000-50000 to $myip 3000-4000 out via ppp0


File /etc/ppp/ip-down which is:

#!/bin/sh
/sbin/ipfw delete 10000


Make them as user root and don't forget to chmod a+x ip*

To see what's going in and out use this as user root: tcpdump -l -q

This works great, would like to know anyone that has problems. Dynamic IPs are a pain in the a$$, huh?

--Paul

[ Reply to This | # ]
Rule Number?
Authored by: Anonymous on Dec 17, '01 02:29:27AM

How do I know what rule number to use?



[ Reply to This | # ]
Rule Number?
Authored by: pdrake on Dec 17, '01 04:22:06AM

After any custom rules and before the "65535 allow ip from any to any"

If you use BrickHouse, put it right before the 5xxxx rules.



[ Reply to This | # ]
Entourage delay in quitting when connected to Internet
Authored by: ellen west on Mar 08, '02 06:57:26PM

I had this problem too and it stems from Office vX's transmission, verifying itself (this stops more than one copy, with the same serial number) being used at the same time. You need to either configure your Firewall (or download one first) to deny the applications in the Office suite access to IP address: 62.253.43.109

Make sure that you deny each program: Entourage, Word, Excel, Powerpoint access to this address. It does work, I downloaded a copy of Firewalk x 2 from: http://www.pliris-soft.com and had it set up in less that 5 minutes. I can now quit all office applications immediately when connected to the Internet. Cost: $34. Hope this helps.



[ Reply to This | # ]
Oh, dynamic IP!
Authored by: ellen west on Mar 08, '02 08:36:41PM

Well, my last post wont work then! I've just set up Firewalk to deny all connections except my smtp, mail and news servers. Works ok so far. If there's an easier way can someone post simple (not new to Mac, but new to OSX/Unix) instructions - using Firewalk preferably. Thanks.



[ Reply to This | # ]
Oh, dynamic IP!
Authored by: 128K Mac on Mar 08, '02 11:41:04PM

ellen

There may be several different issues at play and I too have not yet found that right "combination" with Firewalk X 1.x. (As I understand it the interface for 2.x gives it much more power, but also makes it a good deal more difficult to use.)

Issues:

1. Does the "network" use static or dynamic IP(s)?

2. Is the "network" merely one Mac and one DSL/cable modem or does it consist of two or more Macs plus modem?

3. Not quite an OS X issue, but many users of Linux, FreeBSD, et al jump into these threads and what works for those flavors of *nix doesn't necessarily work for OS X. (witness some of the comments in this topic).

I started beating this horse in Dec. You'll find posts from me elsewhere in other similar topics on MacOS X Hints. This one summarizes what I believe to be the issues for my setup.

By now everyone knows, or is finding out quickly, that the "slow-to-quit" (or never quit; must force quit problem) is related to the Microsoft PUD which "checks" for duplicate serial numbers on a "network."

The result of this "check" on a "network" like mine (static DSL; one Mac and one modem; OS X) is that I have to wait for the "check" to time out and quit, allowing the app(s) to quit, because it finds no other Macs at all and just hangs. This for some reason seems to work differently on a "network" with more than one Mac. (??)

In recent correspondence with the Firewalk X support, and I encourage you to write them giving them all relevant information, they suggest that blocking ingoing and outgoing TCP and UDP for Port 2222. Haven't gotten roun' tuit. This is identical (I think) to a command line "fix" which was posted on the daily news page of MacFixIt six weeks (?) ago. Using it with my config simply prevented the apps from ever quitting.

MacFixIt has extensive discussions on this issue as well but they, like the ones here, confuse me further. My impression is that there's not a universal cure all, for DSL and dialup, for the two "types" of networks as I've defined them, and also not if other flavors of *nix are involved.

BTW, I tried the "lowest level" and "middle level" (recommended) default settings of Firewalk X. Didn't work. The M$ pud "slow-to-quit" problem is present with both (plus QT streaming is blocked with either setting).

Have also purchased and tried Intego's NetBarrier. Am unimpressed. I don't feel comfortable using it (although the PUD problem is gone attempts to tweak about anything seem to lead to another issue) and I wouldn't trust the Symantec product either.

Have tried using Apple's Console as an aid to trouble shooting with no luck, but was encouraged to try again by Firewalk X tech support.

Am rather burned out on the whole issue presently. Hope these comments may help point you in right direction. I think dealing with the three issues I've suggested are all valid in searching for an individual solution.

Jerry



[ Reply to This | # ]