I’m software engineer in a parental control company and i work on a project to intercept dns request at the kernel level.
To do so, i’ve implemented a driver which install a WPF callout which allow me to intercept packets in order to read/write them.
When the Avast web agent is desactivate, everything is fine, packets are intercept and can be reinject without any issue.
But when the Avast web agent is activate since version 2015.10.0.2208, there is no more DNS resolution, it seems that the packet are drop in this context.
I guess that the web agent consider the reinjected packets as malicious and block/discard them.
I had no issues with the others tested antivirus (AVG, Avira) and the previous version of Avast worked fine also.
Can you please give some hints about how works the web agent, and what can produce this behaviour ?
Is blocking dns/udp packet a normal behaviour for the web agent or is it a bug in this version?
Unfortunately the problem still be there, when i reinject the packet to let the Dns resolution occur there is no response and the program send resolution request in loop.
Again when the web filter is desactivate, the resolution works without any trouble.
I don’t modify any information in the packet during my interception (i just read some information from it).
Does some one have an idea to solve/understand this problem?
The best thing you can do in my opinion is submitting a ticket to avast.
Tell the problem and send them your application/files so that they can have a look at it.
I actually started a thread a couple of weeks ago about event log warning 1014 DNS Client events and DNS resolution so it’s good to see someone else with more knowledge pin point it down a bit more than I could. Hopefully they get this fixed quickly
According to our last investigations using the beta version (2015.10.0.2209), it seems that one of the avast filter is changing the packet information in the case of udp dns request
More precisely the checksum is set to zero in this configuration.
To figureout we have tested several configuration of packet transport (tcp/udp/ipv4/v6). using the driver which intercept the packet at wfp level
When avast web agent is desactivate, there is no change between the packet send and the one receive in any configuration.
When it’s activate, the checksum in the udp dns request packet is changed and set to zero. So it seems that one of the filter is messing with this type of request.
Packet info before sending/ after receive:
Packet send
HdrLength : (5)
Version : (4)
TOS : (0)
Length : (14592)
Id : (36896)
FragOff0 : (0)
TTL : (73)
Checksum : (6203)
ADDRESS DST : 8.8.4.4
ADDRESS SOURCE : 17.0.0.0
SrcPort : (17888)
DstPort : (13568)
Length : (9472)
Checksum : (42786)
I can’t provide independent test of the coexistence of products on one computer, because you do not provide name of your parental product. So, it’s hard to provide any deepr investigation of the issue here in AVAST.
But, from symptoms I guess that the problem is caused by this scenario:
If you build and reinject the UDP DNS packets from scratch, that it will be definitely this problem, because NBL lost info about previous injections.
You do not describe how you get this No-checksum packets, but if you get them again on TRANSPORT or DATAGRAM DATA SEND layers, then it is correct, because UDP checksum is calculated here later on lower layetrs of the TCP stack and is not necessary to calculate the UDP checksum here (see WFP documentation)
If you will provide FWP_ACTION_PERMIT action in your callout without any additional processing and re-injection, I believe that packet will be processe and send correctly even the checksum is set to 0…
If not, please provide more detailed info how you capture those packets.