MacOS version: Mojave
I have a program listening on a local port(2080). I would like to forward all network requests to this program.
In order to accomplish this, I have configured the Wi-Fi network service to use a socks5 proxy as well as dns server pointing to local host.
This works as long as the Wi-Fi network service is connected to any network, regardless wether that network is connected to the internet. (For instance, a chromecast).
Is there a way to force the packages to the program without having to connect to a network?
Previous attempts include creating a network service attached to the lookback device, lo0, with the proxy and dns settings as before (couldn't get any packets to be routed through the program, network panel says not connected) And installing tun/tap discussed in this question.(Virtual network interface in Mac OS X).
The device will show up in ifconfig, but not in network services after editing the SystemConfiguration/preferences.plist
Any guidance is welcomed.
Nevermind I figured it out. The Tun/Tap will work, just need to configure the virtual network service with correct DNS and proxy settings.
I am trying to modify a ethernet driver using WDK tools provided in Visual Studio 2012.
The samples provided in the WDK are 'miniport adapter' and 'NDIS Light Weight Filter' among others. I am still at the very beginning of driver writing and hence finding it tough to navigate through the code.
I was able to install the miniport adapter after building it in Visual Studio 2012 [Shows up as 'Microsoft Virtual Miniport Adapter' in my network adapters list.] I am able to assign it a IP address and Subnet mask also.[I found out that this does not connect to any physical device on my PC].
I also setup the 'Debug View' software to check the driver messages from my adapter.[ I used 'DbgPrint' statements in the code and then built it.] But, The debug messages are printed repeatedly.
1- Why are the messages printed again and again? The messages are from the 'datapath.c' file of the program and is from the function 'MPSendNetBufferLists'. ['Net Buffer' specifies data sent or received on the network.]
2- I setup Wireshark to capture the data on the adapter and it shows that there are requests from ARP,HTTP,SSDP,MDNS etc coming out of it. I am not able to understand what is actually talking to the adapter? and how can I stop it from talking?
I can use 'ping' to see if there is a connection on the IP address I have assigned to the adapter and it responds with a success telling all packets were sent and there was no packet loss.
My goal is to send and receive 'data' packets via a IP address to this ethernet adapter. ie- I want an application to connect to the IP address assigned to the adapter and talk to it.
3- Can I actually do it with the samples provided in WDK?
Any other suggestions or advice are welcome.
PS- I wasn't able to use the windows debugger built into Visual Studio 2012. I used 2 PCs and was able to connect and install the driver onto the 'target' PC but couldn't do anything with breakpoints etc. The code and Program just did nothing after installing the driver on the 'target' PC. Any suggestions on this?. I thought I could do step-by-step debugging of drivers also.[I know I am wrong].
Thanks
Aditya
NDIS miniport drivers, like many low-level drivers, are meant to talk to hardware. The miniport's responsibility is to take send packets from the OS, translate them into whatever format is required by the hardware, and instruct the hardware to send the packet on the wire.
The WDK could (and in fact, used to) include a real-world sample driver that sends packets on real-world hardware. But this leads to some confusion, since real-world drivers have to deal with lots of hardware-specific details that distract from the main point of the sample. If you starting from a real-world driver, the first thing you'd have to do would be to identify all the hardware-specific bits and rip those out, so you could replace them with your own hardware-specific bits.
Instead, the "netvmini" sample in the WDK is a fake driver. That means it pretends to have actual hardware, but secretly it's all a lie. When the OS sends packets to netvmini, the netvmini driver will simply broadcast those packets to any other netvmini miniport adapters installed on that machine. (In effect, installing 2 netvmini adapters on the same machine simulates what would happen if you had two real adapters plugged into the same Ethernet hub.) So in ASCII-art, this is what happens if you install two netvmini adapters on the same system:
TCPIP TCPIP TCPIP
| | |
Real physical miniport Your netvmini #1 Your netvmini #2
| \ /
[The Internet] [The netvmini virtual hub]
As hopefully the ASCII-art illustrates, your netvmini adapters don't have any path to the Internet. So your driver won't get a "real" IP address that can route to the Internet until you add in details of your hardware. Until then, Windows will just keep trying to send ARPs and HTTP requests that will never go anywhere.
To answer your specific questions:
The messages from MPSendNetBufferLists are printed every time the OS attempts to send a packet. Because the OS thinks that you have a real network connection, the OS will make several attempts to use it. Eventually that should quiet down a bit, when everything comes to the conclusion that this isn't a useful link.
The requests are coming from TCPIP. If you don't want TCPIP to send data, then unbind it from the adapter.
You can definitely send data to the adapter. In fact, you've observed that you're already sending random HTTP packets and etc. But the data won't actually reach the Internet, until you teach the driver how to talk to your real hardware.
If you're sitting there thinking "but I don't have hardware!", then you might want to create a virtual miniport of some sort. Virtual miniports are like netvmini in that they don't have real hardware, but they still do have some way to get the packets off the machine. For example, VPN miniports that operate at layer-2 (like L2TP) will typically install a second driver — an NDIS protocol driver — that sends and receives data from the "real" physical miniport. Then the virtual miniport talks to its protocol whenever it needs to get packets off the machine. The result is:
TCPIP
|
Your virtual miniport
|
Your NDIS protocol
|
The real physical miniport
|
The Internet
There are alternative architectures; for example, a VPN that operates at layer-4 (like SSTP) might decide to open a WSK socket instead of implementing an NDIS protocol driver:
TCPIP
|
Your virtual miniport
|
WSK socket
|
TCPIP
|
The real physical miniport
|
The Internet
What firewall settings must be used on the remote machine for a remote kernel connection to work?
In particular I'm interested in connecting from Windows (front end) to a Linux machine (kernel).
I don't know the exact ports, but this is a generic way to solve most such firewall issues: (at least with connections using TCP)
Try to use the 'netstat -n' command and see which remote ports do the connections that are being blocked by the firewall use. They should be in the SYN_SENT state or something similar. Then on the remote machine open those ports and try to repeat this process until it works.
Is there a way to find out the IP address of a device that is directly connected to a specific ethernet interface? I.e. given one host, one wired ethernet connection and one second host connected to this wired connection, which layer or protocol below IP could be used to find this out.
I would also be comfortable with a Windows-only solution using some Windows-API function or callback.
(I know that the real way to do this would probably via DHCP, but this is about discovering a legacy device.)
Mmh ... there are many ways.
I answer another network discovery question, and I write a little getting started.
Some tcpip stacks reply to icmp broadcasts.
So you can try a PING to your network broadcast address.
For example, you have ip 192.168.1.1 and subnet 255.255.255.0
ping 192.168.1.255
stop the ping after 5 seconds
watch the devices replies : arp -a
Note : on step 3. you get the lists of the MAC-to-IP cached entries, so there are also the hosts in your subnet you exchange data to in the last minutes, even if they don't reply to icmp_get.
Note (2) : now I am on linux. I am not sure, but it can be windows doesn't reply to icm_get via broadcast.
Is it the only one device attached to your pc ?
Is it a router or another simple pc ?
To use DHCP, you'd have to run a DHCP server on the primary and a client on the secondary; the primary could then query the server to find out what address it handed out. Probably overkill.
I can't help you with Windows directly. On Unix, the "arp" command will tell you what IP addresses are known to be attached to the local ethernet segment. Windows will have this same information (since it's a core part of the IP/Ethernet interface) but I don't know how you get at it.
Of course, the networking stack will only know about the other host if it has previously seen traffic from it. You may have to first send a broadcast packet on the interface to elicit some sort of response and thus populate the local ARP table.
Windows 7 has the arp command within it.
arp -a should show you the static and dynamic type interfaces connected to your system.
Your Best Approach is to install Wireshark, reboot the device wait for the TCP/UDP stream , broadcasts will announce the IP address for both Ethernet ports
This is especially useful when the device connected does not have DHCP Client enabled, then you can go from there.
You can also get information from directly connected networking devices, such as network switches with LDWin, a portable and free Windows program published on github:
http://www.sysadmit.com/2016/11/windows-como-saber-la-ip-del-switch-al-que-estoy-conectado.html
LDWin supports the following methods of link discovery: CDP (Cisco Discovery Protocol) and LLDP (Link Layer Discovery Protocol).
You can obtain the model, management IP, VLAN identifier, Port identifier, firmware version, etc.
I often run into problems where I can't get something to connect to something else. I usually forget to check something obvious. Can you help with:
A tip/technique for diagnosing a connection issue
The name of a tool or application that can help (and the situation in which it's useful)
I know the question is a little non-specific, but hopefully the answers can form a useful starting point for anybody who's stuck trying to get computers/programs talking to each other.
Please can you give one answer per answer so the best ones can be voted up.
Simple checks to run when debugging network problems:
Has each machine got an IP address, Go to command prompt and run ipconfig. Key things to check here are the interfaces and ensuring the appropriate ones have IP addresses.
Check both machines IP addresses are in the same range and subnet if you are running it on an internal or Virtual network.
Try pinging each machine from the other to see if they can communicate with each other. Note that some firewalls will block ping requests.
If Pinging fails then check to see if firewalls are active. If the communication is within a 'safe' internal network then try disabling the firewalls and re-pinging.
If the connections are over a wireless network then check signal strength.
If pinging fails and you are connecting through several networks then try running a tracert to see at which will may show you where on the network the connection is failing.
If you are able to ping but not connect then check firewall settings and network connection settings. Windows 2000+ has the capability of setting port an ip access on a connection properties.
Try drawing a network diagram of the connections to help in visualising the problem.
If you are connecting through routers, firewalls and loadbalancers then check that all devices are not tied to any specific ip addresses and that the IP address redirection (if in place) is correct. Also check any NAT logs to see if connections are being received and properly re-directed.
Wireshark
Latest versions of ProcMon
netstat
Wireshark www.wireshark.org
Wireshark is a network protocol analyzer for Unix and Windows.
Features:
Deep inspection of hundreds of protocols, with more being added all the time
Live capture and offline analysis
Standard three-pane packet browser
Multi-platform: Runs on Windows, Linux, OS X, Solaris, FreeBSD, NetBSD, and many others
Captured network data can be browsed via a GUI, or via the TTY-mode TShark utility
The most powerful display filters in the industry
Rich VoIP analysis
Read/write many different capture file formats: tcpdump (libpcap), Catapult DCT2000, Cisco Secure IDS iplog, Microsoft Network Monitor, Network General Sniffer® (compressed and uncompressed), Sniffer® Pro, and NetXray®, Network Instruments Observer, Novell LANalyzer, RADCOM WAN/LAN Analyzer, Shomiti/Finisar Surveyor, Tektronix K12xx, Visual Networks Visual UpTime, WildPackets EtherPeek/TokenPeek/AiroPeek, and many others
Capture files compressed with gzip can be decompressed on the fly
Live data can be read from Ethernet, IEEE 802.11, PPP/HDLC, ATM, Bluetooth, USB, Token Ring, Frame Relay, FDDI, and others (depending on your platfrom)
Decryption support for many protocols, including IPsec, ISAKMP, Kerberos, SNMPv3, SSL/TLS, WEP, and WPA/WPA2
Coloring rules can be applied to the packet list for quick, intuitive analysis
Output can be exported to XML, PostScript®, CSV, or plain text.
work the OSI model from the bottom up
Physical (Do you have a network adapter/connection)
Link layer (arp, ethernet port blocked by network team (I've seen this where locked down environments see two MAC addresses coming from one workstation port and shut down the port)
Network layer (ipconfig, tracert, ping,)
Do you have a network address (DHCP, fixed)
Are you on a proper subnet/have routing between subnets
Is something in the middle blocking you
firewalls, routing tables
When in doubt, check to see if the windows firewall is messing with your communications. 8 times out of 10, it's at fault.
Using tracert is a good start to see how far along the chain you are getting.
For virtual machines it's usally a good idea to make sure you have the loopback adapter set correctly in the Host os.
Most frequently used tool is the ping. It can be used both to test your connection and the availability of a target
Second tool is the tracert if you want to see where the packets get lost.
For more advanced debugging I use the following tools: nmap, wireshark, etc.
Windows has a netstat utility which is pretty similar to the Unix netstat and can do a number of different things that might help you solve network issues.
Random example:
netstat -r displays routing information
netstat /? for usage information
Since you said you're using 2 virtual machines I would hazard a guess that both machines are setup in a NAT configuration (rather than a unique network device) -- In the NAT configuration, neither machine would (typically) be able to ping the other.
If you're familiar with the command line, you can try the "netstat" command.
You can also try "arp -a" to list all the IP/MAC addresses known to your PC.
The "tracert [ip address]" command will show you how many gateways/routers your packets jump through on their way to their destination. (This is probably not helpful if both machines are on the same network, though.)
And don't forget to check your Windows firewall settings.
Otherwise, if you want to get down and dirty, you can try the packet sniffer known as Wireshark: http://www.wireshark.org/ (aka. Ethereal)
Pull the network cable out
If you can get some communications to a device (eg a ping), but can't get your program to talk to a service on the computer. Then, try pulling the network cable out and see if the ping stops. This will verify you're communicating with the computer you really think you are.
On windows i user PortQueryUI : http://www.microsoft.com/en-us/download/details.aspx?id=24009
DNS activity: Portable DNS Cache and Firewall;
General network activity: Wireshark, Network Monitor;
Windows utilities: ping, netstat, nslookup.
You need to be use the process of elimination, for example if you can ping the ip address but not the hostname then there's DNS issues. If you can ping the system but not connect to a share etc.
DNS out of sync
If you're using a virtual machine and you perform a roll-back on it, then it could become out of sync with the DNS (Domain name server). Try to remove and re-add the machine to the domain, or if you've got access to the DNS machine, then get it to flush its cache.