Win Nova T – DVB-TV Card - Jerky and often “Pixellated” Display

Help for v2
#1

Searches of these Forums have revealed several suggestions for resolving this issue.

Via CPF – Security – Advanced – Advanced Attack Detection & Prevention – Intrusion Detection – ICMP Flood, the rate has been changed to 250 which produced worse results than the default 50, and lowered to 10 failed to make any improvement.

CPF has correctly identified the IP of the Card and automatically entered it in the Trusted Zone area.

Switching Off the CPF – Network Monitor, resolves the problem but naturally weakens the protection.

There is much material to sift through, so I may have missed something, any pointers would be much appreciated.

The TV facility is used only for watching the news a couple of times per day, and if desk space were not an issue [or unless anyone knows of a small DVB TV to UK specifications at a reasonable price] I will consider removing the card from the PC.

#2

If disabling Network Monitor fixes the problem then you need to check the log to see what is getting blocked. It is under Activity > Logs. It might be as simple as allowing some ports access IN to get it working correctly. If you need help writing rules then someone will be glad to help you. Just right-click the log anywhere and choose “Export HTML” and post that back here.

jasper

#3

Thanks jasper2408 for your response.

Wow, it is possible to watch the data flow halting in time to the stopped movement on the TV display in real time via CPF, fantastic.

Observing that the culprit appears to be Rule ID 5 [the defaults have not been altered yet due to need to reinstall CPF after carrying out tests on OP4 FW], this rule was changed to “Allow” for a brief period. This seems to have resulted in the “DDOS Attack (UDP Flood)” recorded in the attachment. The time of the event coincides with my actions.

NB. While composing this post the “DDOS Attack (UDP Flood)” has occurred again and Rule ID 5 has remained “Blocked” during this period. There are no similar events in this log starting from installation last night. Other High concern events recorded I understand the reasons for. Could this be an actual threat/attack attempt as a result of the brief unblocking?

The system is behind a Router and overall the setup passes several online tests.

There was no change to the display problem and the sound is probably unaffected, but due the the lack of sync with the lips it is best just to listen.

TIA of further assistance.

[attachment deleted by admin]

#4

Try making a rule like this at the top of your rule list:

[b]ALLOW - check the checkbox
UDP
IN

SOURCE IP: any (If “ANY” works then change it to 192.168.44.21 and see if it still works)
DEST. IP: 192.168.44.21
SOURCE PORT: Choose “A Port Range” here: 9402-9406
DEST. PORT: Choose “A Port Range” and use 9402-9406 [/b]

You might have to restart the PC for the rule to kick in properly. Looks like the traffic is internal to your PC. Something is probably getting sent from your card to the PC. This could just be normal communication between the card and the PC. Just a guess.

Let us know how it goes.

jasper

#5

Hi jasper2408 thanks for the very clear directions on how to construct the rule.

Observing the information you used, and comparing that in the log plus the Activities - Connections info, the subject suddenly became less “misty” and a was a lot easier to do than I had imagined. To save time I stopped and restarted CPF rather than rebooting straight off.

The first “Any” direction worked like a charm so the TV Card Address was input as you suggested. Again it was functioning perfectly normally.

Then the acid test, reboot and the TV behaved in a very strange way. One channel was fine while another was worse than before implementing the rule. As the Net BIOS Ports had been recently blocked, following advice because I have no use for sharing, they were reinstated but had zero effect.

Looking at the Activity - Connections it was noticed that Port 9401 had been brought into play, so your directions were amended appropriately but to no avail. The pixel size increase is greater and more often displayed for longer and the movement halts are more noticeable. In normal unfettered use this TV picture makes even the demo HD pictures look sad.

Nothing to lose so try everything you know [one of my personal “drivers”], so the Security – Advanced – Advanced Attack Detection & Prevention – Intrusion Detection – ICMP Flood, the rate was changed to 250 as suggested elsewhere on this forum. Again no improvement and after a short spell of operation the picture appears to degrade.

I have recently run MEM Test on the RAM and the CPU temperature is lower than normal following lower room/ambient temperatures. There is a noticeable increase on start up in the lag between Win XP [rolling blue progress bar] screen closing [screen goes totally blank] and the opening of the log on screen. This is since applying the rule. Recently a trial of Outpost Pro 4 was run and their support staff are trying to resolve DVB-TV issues thrown up by this kit. I mention these points in case they provide any clues to knowledgeable members here.

I am very willing to try any solution suggested, except heave it all out of the window, but I am beginning to think it is time for some new hardware in the form of a space saving small TV. To save a lengthy explanation it has been described in my fifth post in this Thread at:

http://www.castlecops.com/t174597-Prevx1_Compatibility_with_CorelDraw_and_TrueCrypt.html

This is where the path crossed from OP to Comodo and still involved Prevx1.

#6

I looked thru your log a liittle closer and port 9407 needs to be added also. Sorry I missed that one before.

I noticed that you are getting pings plus some other things blocked in the log. Do you know where those pings are coming from? If I was setting it up on my own system I would make a rule for every single thing that is getting blocked in the log until I had no more block entries. You never know what is the culprit. Make one rule at a time to see if that frees it up then go to the log and make another rule. Be sure to Allow all of the popups when you start the program involved. I realize that some of those rules won’t be needed but sometimes you have to do that to track it down.

I would make rules for the 10.x.x.x and 224.x.x.x(multicast and streaming media) addresses just to be sure they aren’t causing the stoppage.

One question: Is rule #5 set to BLOCK IP IN/OUT or just to IN? If it is IN/OUT change it to IN.

Anyway that’s what I would do. One rule at a time.

jasper

#7

I am very lucky to have so much help from you jasper2408 at least it is not a lost cause.

I was not expecting another response until at least today [it is just a couple of hours old] and spent a long time contemplating the existing scenario. Turn Off all the Network Control Rules = Nil TV Troubles, Turn ON and the reverse is true. When I read your last post I duly set about applying your suggestions. The “switching scenario” was really bugging me, I was tired so decided to take a few decisions to speed things along. Guess who got lost on the journey. In a nutshell, after a break period, CPF has been carefully uninstalled and very carefully reinstalled.

The display issue persisted, but so did I in my attempts to check every setting possible. I said above:

CPF has correctly identified the IP of the Card and automatically entered it in the Trusted Zone area.

Which is not true, I was confused between Common Tasks - Add/Remove/Modify Zone [which refers to managing Network Zones] and Wizards - Define a new Trusted Zone [which also refers to Network Zones]. Because I was not now trying to run before I could walk each setting was attended in an orderly fashion. In the “Define a new Trusted Zone” the TV Card and Network Card were the choices. The TV Card was given Trusted Status.

This made two new Network Control Rules, #1 being:

ALLOW IP OUT FROM IP [Any] TO IP ZONE:[Hauppauge WinTV NOVA Adapter-Packet Scheduler Miniport]-192.168.44.0/192.168.44.255 WHERE IPPROTO IS ANY

and #2 being:

ALLOW IP IN FROM IP ZONE:[Hauppauge WinTV NOVA Adapter-Packet Scheduler Miniport]-192.168.44.0/192.168.44.255 TO IP [Any] WHERE IPPROTO IS ANY

I re-established the Net BIOS Port Rules and placed these just above the default Block Rule.

The Connections window shows the data flowing smoothly shared between the appropriate Ports, where before the irregular halting indicated what would happen to the display. Nothing is being added to the Log in fact it is quite boring now. The picture is perfect once again, even after a reboot. A very satisfactory conclusion and Comodo Firewall moves further up the rankings.

Sincere thanks for all your effort, and warmest seasons greetings.

#8

That’s great to hear Not.

I was just along for the ride. You did all the work.

Seasons greetings to you and yours. Have fun watching your TV over the holidays.

jasper

#9

Hi jasper2408

I have just got around to reapplying [again] the Rule you mentioned in:

One question: Is rule #5 set to BLOCK IP IN/OUT or just to IN? If it is IN/OUT change it to IN.

Anyway that’s what I would do. One rule at a time.

jasper

This has stemmed the flow of Orange and RED Log Entries, your “coming along for the ride” certainly pointed me in the right direction. Long may you continue to give directions to those who seek help.

The experience has whetted my appetite to learn more, perhaps even become experienced enough to offer meaningful assistance.

With the “tamed” Log output it will be easier to see the effects of future tweaks, from near panic [well furrowed brow then] to fun in a couple of days things are looking great.