After upgrade having problems printing with DEPCON

Unanswered Question
Dec 11th, 2008

Good Evening. I hope someone can help me because I am at my wits end and TAC is at a loss. It seems that shortly after I applied the IPS-K9-6.2-1-E3.pkg

IPS 6.2 Minor Upgrade File (All Supported Platforms Except AIM-IPS and NME-IPS) to my 4240 last month, I suddenly started experiencing problems printing. I have already applied several signatures so downgrading is not an option.

What is happening is we use software called Depcon to print to remote sites via the internet. Large print jobs keep restarting from page 1 unless I keep the IPS in "Bypass Mode".... which I am not happy about. There is nothing in the event logs that indicates the traffic to/from the source/destination Ips are being messed with in any way.

To make matters worse I can find little to no info on Depcon on the internet.

Would appreciate any and all assistance.

Thank You,


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
marcabal Fri, 12/12/2008 - 08:08

A few things you could try:

1) Set Normalizer signatures to their default values, and add produce-verbose-alert to all of the Normalizer signatures.

Some users have tried disabling Normalizer signatures or removing the default actions on some of the Normalizer signatures. However, sometimes these signatures and actions are necessary for the Normalizer to do it's job and so in some cases the action will stick place even if removed from the configuration. This can cause difficulties in trying to diagnose the issue. So it is better to leave the signatures and actions at their defaults until determining what the problem really is.

Some of the signatures do not have produce-alert by default. Adding produce-verbose-alert will force creation of an alert if these signatures are being triggered, and by doing the "verbose" it can also add more information into the alert.

Now try printing and monitor very closely for any Normalizer signatures firing between the addresses of the Print Client and Print Server.

2) Trace down the packet path for connections to your Print Server. If the packets are passing through your sensor twice for some reason, then the Normalizer could be getting confused.

If your client and server are on separate networks, then the traffic could be being routed through the sensor twice.

There are configuration changes that could be made to alleviate this problem on the sensor if you determine that this is what is happening.

3) Another change to try temporarily is to configure the virtual sensor's inline-TCP-evation-protection-mode to asymetric.

This in effect disables the Normalizer.

If your print server starts working with the sensor in this mode, then the Normalizer is likely doing something to the packets.

The next step would be to set it back to "strict" and using method 1 and 2 above to determine what the issue is.

Once the issue is known, there may be another configuration option for the sensor to get it working right.

The asymetric mode is a good option to get things working temporarily while trying to determine the Normalizer problem. But should only be used long term if you actually are forced to run in an asymetric environment.

4) If the asymetric mode doesn't help, then it is likely Not the Normalizer.

Next step would be to take a closer look at the alerts. It it might be that the particular signature being triggered by your printer communications could be firing often enough that it is in Global Summary mode. And in Global Summary mode you won't see any of the addresses involved.

So look not only for alerts containing the specific IPs, but also for any alerts with as the addresses. The addresses show it is a Global Summary alert.

5) Also take a close look at your filters. You might unintentionally be filtering out the generation of the alert, but still allowing a deny to happen.


This Discussion