Channel and capture VoIP traffic on a dedicated NIC?
I'm trying to capture Freephoneline app calls on a dedicated PC NIC by running Wireshark 2.4.2 on a Windows 10 64-bit PC. The captured calls from Freephoneline to an ATA are SIP type, and show up in Wireshark VoIP Calls window. But only when just one PC NIC is enabled. When 2 NICs are enabled, Windows redistributes traffic between them in a way that makes capturing Freephoneline on a single dedicated NIC impossible - regardless of Metric manually set in each NIC Properties or auto assigned.
This happens despite Freephoneline app allows to bind it to a selected adapter at each launch. Apparently, such binding works only for some calls, and even for them handshake goes through an adapter with lower Metric. I also tried using ForceBindIP app to further bind Freephoneline to a certain adapter, yet again not all its traffic went through that adapter, thus preventing capturing it as VoIP call.
Are their other options to completely limit Freephoneline traffic only to one NIC, while several NICs are enabled on the PC? Is there any defect in latest ForceBindIP that prevents it from completely binding a selected app traffic to a certain adapter in both directions? AdapterWatch shows that the app seems to bind traffic OK, but probably some initial SIP packets still pass through the 2nd adapter with lower Metric. While I'm trying to separate all VoIP traffic to one dedicated adapter.
Some info is missing in your description.
First, do you need to limit all the VoIP call related packets to a single NIC just to facilitate capturing or for some other reason? Because Wireshark allows you to capture on several interfaces simultaneously.
Second, if the reason is different, do your NICs have IP addresses from the same subnet or from different ones?
Yes, a VoIP recording app can do it only on one selected adapter at a time. Also, it would allow to separate VoIP traffic through one NIC, and all other network and web traffic through another mic to ensure no interference. Subnet is the same as they are routed through the same gateway, but it can be made different if needed by using 2 gateways. Do you think its the solution - why?
There is but I guess there is no point in doing that as your issue is not Wireshark-related, as you've said you need to limit the VoIP data exchanges to a single NIC so that a VoIP recording app could work.
The reason why I've asked about IP subnets of the NICs was because the remote ends of SIP and RTP flows of the same call may be on different machines, so if routes to these different machines would use gateways in different subnets, it could explain something; as you say both NICs are in the same subnet, it is purely an issue of the network stack of the OS how it spreads the outgoing data among the two NICs.
If you receive the incoming data where you don't expect them, bear in mind that some systems ...(more)
I can look at ARP requests, but can it be controlled in any way on a Windows PC by a user?
As to whether my Q is Wireskark related, it is in a sense that Wireshark is used for variety of purposes, most of which are not related to finding Wireshark own bugs, but rather to the field of using Wireshark to analyze changes to network traffic, such as directing VoIP traffic through a single NIC rather than giving up to randomized Windows network chaos.
What I had in mind is that Wireshark tells you exactly what has happened but rarely why it has happened. And the way you've narrowed your question, it is neither from the group "how to do xyz in Wireshark" nor from the other one called "what field xyz means in protocol tuv" any more, because what you need to find out is how to convince your OS (Windows in this particular case) to behave the way you want it to, and this is something with which Wireshark cannot help you. The only point where Wireshark can help here is to confirm my theory regarding the ARP response carrying a MAC address of a "wrong" interface, but even if it confirms that, it cannot help you change that behaviour. What you might be able to do to circumvent such behaviour would be ...(more)