When checking on a local PC, "v10.events.data.microsoft.com:443" packets continuously occur, so please inquire about the phenomenon.
It is necessary to check why the packet is generated and when it occurs.
May I know if there is a way to prevent that packet from being generated?
thank you.
Related
I am making a CAN simulator for GPS trackers, they only record CAN data and doesn't send ACK. Is it possible to send CAN data with raspberry, using mcp2515/tja1050, without any device on bus that would trigger ACK?
This will usually generate a continuous retransmit.
Some devices have a "one-shot" transmit mode when just sends the CAN frame and does not attempt a retransmission. If you transmitter has this mode you can do what you describe, otherwise you will get a lot of retransmissions.
No it isn't possible, you need at least 2 nodes that are actively participating in the communication. This can however be fixed by just providing another CAN controller on the bus, which doesn't have to do anything intelligent except the ACK part.
For development/debug/test purposes you can however put your own node in "loopback mode", meaning it will speak to itself. Can be handy if you have to proper hardware available yet.
You can try to set the controlmode presume-ack to on.
Assuming you are using the ip command for creating your can sockets that would be something like
ip link set <DEVICE> type can presume-ack on
This will ignore missing ACKs. However I am not sure whether this works with all controllers.
I am working on project that can capture the data passed from the user to the network in the same machine and modify its contents.
But I don't know if Winpcap can only capture or can also modify the data???
I hope my question was so obvious for you!
You can capture. You can modify what you capture, but that doesn't affect what goes through the network stack: only what you have in your own sniffing process. You can't filter packets out either.
I'm trying to improve the usefulness of the error reporting in a server I am working on. The server uses TCP sockets, and it runs on Windows.
The problem is that when a TCP link drops due to some sort of network failure, the error code that I can get from WSARecv() (or the other Windows socket APIs) is not very descriptive. For most network hiccups, I get either WSAECONNRESET (10054) or WSAETIMEDOUT (10060). But there are about a million things that can cause both of these: the local machine is having a problem, the remote machine or process is having a problem, some intermediate router has a problem, etc. This is a problem because the server operator doesn't have a definitive way to investigate the problem, because they don't necessarily even know where the problem is, or who might be responsible.
At the IP level, it's a different story. If the server operator happens to have a network sniffer attached when something bad happens, it's usually pretty easy to sort of what went wrong. For instance, if an intermediate router sent an ICMP unreachable, the router that sent it will put its IP address in there, and that's usually enough to track it down. Put another way, Windows killed the connection for a reason, probably because it got a specific packet that had a specific problem.
However, a large number of failures are experienced in the field, unexpected. It is not realistic to always have a network sniffer attached to a production server. There needs to be a way to track down problems that happen only rarely, intermittently, or randomly.
How can I solve this problem programmatically?
Is there a way to get Windows to cough up a more specific error message? Is there some easy way to capture and mine recent Windows events (perhaps the one Microsoft Network Monitor uses)? One way I've "solved it" before is to keep dumpcap (from Wireshark) running in ring buffer mode, and force it to stop capturing when a bad event happens, that I can mine later.
I'm also open to the possibility that this is not the right way to solve this problem. For instance, perhaps there is some special Windows mode that can be turned on to cause it to log useful information, that a network administrator could use to track this down after-the-fact.
I like being able to use a torrent app to grab the latest TV show so that I can watch it at my lesiure. The problem is that the structure of the protocol tends to cause a lot of incoming noise on my connection for some time after I close the client. Since I also like to play online games sometimes this means that I have to make sure that my torrent client is shut off about an hour (depending on how long the tracker advertises me to the swarm) before I want to play a game. Otherwise I get a horrible connection to the game because of the persistent flood of incoming torrent requests.
I threw together a small Ruby app to watch the incoming requests so I'd know when the UTP traffic let up:
http://pastebin.com/TbP4TQrK
The thought occurred to me, though, that there may be some response that I could send to notify the clients that I'm no longer participating in the swarm and that they should stop sending requests. I glanced over the protocol specifications but I didn't find anything of the sort. Does anyone more familiar with the protocol know if there's such a response?
Thanks in advance for any advice.
If a bunch of peers on the internet has your IP and think that you're on their swarm, they will try to contact you a few times before giving up. There's nothing you can do about that. Telling them to stop one at a time will probably end up using more bandwidth that just ignoring the UDP packets would.
Now, there are a few things you can do to mitigate it though:
Make sure your client sends stopped requests to all its trackers. This is part of the protocol specification and most clients do this. If this is successful, the tracker won't tell anyone about you past that point. But peers remember having seen you, so it doesn't mean nobody will try to connect to you.
Turn off DHT. The DHT acts much like a tracker, except that it doesn't have the stopped message. It will take something like 15-30 minutes for your IP to time out once it's announced to the DHT.
I think it might also be relevant to ask yourself if these stray incoming 23 byte UDP packets really matter. Presumably you're not flooded by more than a few per second (probably less). Have you made any actual measurements or is it mostly paranoia to wait for them to let up?
I'm assuming you're playing some latency sensitive FPS, in which case the server will most likely blast you with at least 10-50 full MTU packets per second, without any congestion control. I would be surprised if you attract so many bittorrent connection attempts that it would cause any of the game packets to be dropped.
I am trying to find a solution to monitor the traffic (in and out) through a specific port. It is not required to capture the packets, or do anyting else. What it does is to be a traffic listener to make sure there are messages sent to or received from this port every 10 minutes. It has to be running at the background all the time (like a daemon), and without significant performance impact. Based on my research, one choice is to use an existing tool to do that. There are a bunch of tools out there to monitor or sniff the traffic, such as wireshark. Well, seems most of them monitor the traffic passing through a interface, instead of a port, or they can't run as a daemon. Another choice to write a program to do this. SharpPcap seems to be a good choice, but I still need to capture and analyze the packets to know whether such traffic exist. Could somebody suggest what I should do?
SharpPcap handles packet capturing in the same manner as Wireshark, so you can set filters to limit the packet being captured to a specific port the same way in SharpPcap as you can in wireshark. Except, SharpPcap will be a much lighter weight option vs wireshark.
Download the SharpPcap source tree and look at the Example05.SetFilter.
To narrow down the results so you capture only the packets you want to see you'll need to employ a few filters.
Pcap uses a common language across all applications that use it do specify the filters to set. Capture programs that use winpcap (windows) or libpcap (*nix) include, sharppcap, wireshark, pcap.net, winpcap, libpcap, tcpdump, etc... For a great resource on how to use pcap filters see this link.
Here are the filters you need:
ether host ehost
port port
Where the ehost is the MAC address of the computer sending/receiving the packets and the port is the port you want to monitor. So the full filter string would be.
SetFilter("ether host ff:ff:ff:ff:ff:ff and port 60");
The MAC and port here are for illustration purposes only, you'd obviously change them with the values that pertain to your specific setup.
This, used in the SetFilter example will simply print out a line of info with the time of when the packet was captured to the command line every time a packet is captured and meets the criteria if your filter.
If you want more detailed info about the packet, such as info from the headers or the packet's payload, you'll need to parse the incoming raw packet. Be sure to ask for help on the sourceforge project's forum if you need some tips on how to do this. The project developers are very active and always willing to help.
The best way that will limit the impact your tool will have on performance is via an ETW (Event Tracing for Windows) Real-time Consumer (i.e. a tool that activates an ETW trace and reads it immediately instead of saving it to a file). This MSDN sample is a great way to see how to do this via C# and it gives you some code to get started.