The general situation: I have Windows 7 64-bit professional, network connection via ethernet and plugged USB GSM modem. The problem is that sometimes my Internet provider has some outage and during such time I'd like to automatically use USB modem. I've already written some Perl code that actively tests if connection is down and can run a shell command to switch the adapter used for Internet access.
The question is how to change the adapters from command prompt. I'd prefer not giving the script administrative privileges but if it's unavoidable, I can bear this.
Preliminary look-around:
C:\Windows\system32>wmic nic get name, index
Index Name
0 WAN Miniport (SSTP)
1 WAN Miniport (IKEv2)
2 WAN Miniport (L2TP)
3 WAN Miniport (PPTP)
4 WAN Miniport (PPPOE)
5 WAN Miniport (IPv6)
6 WAN Miniport (Network Monitor)
7 Realtek PCIe GBE Family Controller
8 WAN Miniport (IP)
9 Microsoft ISATAP Adapter
10 RAS Async Adapter
11 Teredo Tunneling Pseudo-Interface
12 Microsoft ISATAP Adapter
13 Microsoft 6to4 Adapter
"netstat -rn" shows that adapter for Local Area Connection has higher priority for binding than the modem, which is good.
The usage of my USB modem for casual user consists of running a bespoke application for it and clicking a button "Connect/Disconnect". AFAIK the app doesn't have command line options.
In one direction I figured out a workaround that has additional advantage of keeping the connection alive: AutoConnect 0.1.3.1 by Jarek "Shider" Wieczorek. AFAIK it has no command line options, but just running it after it has been once configured establishes GSM connection and later reconnects in case, which is great.
Now I stuck on how to switch back to LAN (which is my primary, quicker access to the net) after some time, when Internet access has been restored. After killing AutoConnect, the connection is still via modem. I suspected that switching back could be some netsh command but haven't found anything obvious in the help. In a desperate attempt I thought of disabling the modem using devcon.exe but the program downloaded from
http://support.microsoft.com/?kbid=311272
didn't run (some errors that I won't cite because they're actually unrelated to the main issue) and before downloading huge Windows Driver Kit 7.1.0 for a hopefully better version I thought I'll ask here for some suggestion/solution :)
Thank you in advance for any neat general solution or a small specific solution on how to turn off USB connection (maybe Windows will automatically use LAN then) or switch to LAN.
EDIT:
Belatedly, I came up with a solution. Supposing a modem connection has the name ABCD, the following terminates it after closing AutoConnect:
rasdial ABCD /disconnect
However, I still think the whole idea I presented is quite awkward and would gladly see some neat approach. Thanks.
Related
I am trying to use more than one Huawei E303 modem on the same computer.
However, it appears that the modem starts with the default IP 192.168.1.1, so when more than one modem is inserted, they conflict.
Is there any way to change the default IP of this modem?
I thank everyone,
I apologize the question was irrelevant to others.
I did a search and some debugging on the system, on Windows when the modem is inserted, there is a | Huawei service that does the assembly of the modem and the creation of a network interface.
However this service always mounts the modem with ip 192.168.1.1, no matter how many are inserted, not offering modification option.
In summary, without modifying the service code it is not possible to define an ip for each modem.
To solve this problem I will exit Windows and create a solution with Linux using PPP connections.
Thank you
I'm trying to establish a connection over SSH from my Win 8.1 laptop to my raspberry pi 3 model B as the host. Connecting over wifi works flawlessly each time, however I need to demo projects in class and the campus wifi does not play well with SSH, our professor stated that we must use an Ethernet connection. I have tried both putty and Bitvise SSH clients with same results - either "connection refused" or "no connection could be made because the machine actively refused it".
I have tried:
Enabling internet sharing on the Ethernet connection and enabling the SSH services (port 22 both TCP and UDP)
Disabling wifi on Win
Forgetting wifi on raspberry
Manually activating SSH server on raspberry even though I'm pretty sure it was activated already.
Deleting SSH keys from the wifi sessions
Completely disabling the firewall
ipconfig /release ipconfig /renew
Restarting both machines after every of the above
Reimaging memory card with newest Raspbian
Any help would be greatly appreciated.
Edit: The link What can be the reasons of connection refused errors? did not help, the listed reasons are closed ports or firewall and as I already said I tried to open the required ports through the shared Ethernet connection and turned off Windows firewall completely with no other firewall programs running. From my understanding Raspbian doesn't come with any enabled firewalls and allows all traffic. Can someone correct me if I'm wrong?
I finally found a guide that works: http://www.circuitbasics.com/how-to-connect-to-a-raspberry-pi-directly-with-an-ethernet-cable/
The crucial step was to set the static IP address of the pi to my laptop's Ethernet adapter address but modify the last part. You're welcome, all you poor souls from the future.
Wireshark doesn't show the Ethernet interface after the miniport driver is installed. Wireshark shows "No interfaces found". But Microsoft Message Analyzer and NetMon can locate the adapter interface and show the captured packets.
But if I restart the machine then Wireshark is able to find the interface. I suspect it's due to binding issues between WinPcap and my miniport driver. Please correct me if I'm wrong! Do I need to change the INF file or look at the OID requests part as the NPF filter (used by WinPcap) isn't able to get it's hands on the miniport driver ?
With regards,
Jenson
From what I recall, if network adapters are installed or removed the pcap service needs to be restarted to pick up the changes.
To stop the service, from a command line with Administrator rights:
net stop npf
To start it again:
net start npf
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
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.