I've been searching ways to get router devices list on my network and I'm asking for your help. I've found few protocols such as IRDP, LLDP, CDP, MNDP which i can might try however, they mixed my mind completely.
To sum up, I have a network which contains many router devices from different manufacturers.I want to get them programmaticaly by sending a request over network. Which request should i send ?
Related
I'm using ForcebindIP to point an app at a specific network adapter, like this:
forcebindip -i 192.168.0.5 MyCSharpApp.exe
This works fine and the app isn't aware (or doesn't access) any of the other network adapters on the PC.
Is it possible to restrict ForceBindIP to outbound traffic only leaving the app to receive data from any local network adapter? Or even to specify a network adapter for outbound and another for inbound traffic?
I can't find an extra startup parameter for ForceBindIP that does this.
I'd appreciate any help with this.
If I get your problem correctly, you want to bind your application to listen for packets on all available interfaces but return packets to only through one given interface. I also assume it's a server application and you don't have neiter source code nor control over its behaviour.
Disclosure: I do not know how ForceBindIP works internally, I'm basing my understanding of it on this passage from the website:
it will then inject a DLL (BindIP.dll) which loads WS2_32.DLL into memory and intercepts the bind(), connect(), sendto(), WSAConnect() and WSASendTo() functions, redirecting them to code in the DLL which verifies which interface they will be bound to and if not the one specified, (re)binds the socket
Problems to overcome
I don't believe your desired configuration is possible with just one application level DLL injector. I'll list a few issues that ForceBindIP will have to overcome to make it work:
to listen to a socket, application has to bind() it to a unique protocol-address-port combination first. An application can bind itself to either a specific address or a wildcard (i.e. listen on all interfaces). Apparently, one can bind to wildcard and specific address simultaneously as outlined in this SO question. This however will be two different sockets from the application standpoint. Therefore your application will have to know how to handle this sort of traffic.
When accepting client connection, accept() will create a new socket and parameters on that are managed by Windows, I don't believe there's an API to intercept binding here - by this time the connection is considered established.
Now imagine, we somehow got a magic socket. We can receive packets on one interface and send to another. The client (and all routing equipment on the way) will have to be aware that two packets originating from two different source IP addresses are actually part of the same connection and be able to assemble the TCP session (or correctly merge UDP streams).
You can have multiple gefault gateways with different priorities and rules (which is a whole different topic to explore) but as far as I'm aware that's not going to solve your particular issue: majority of routing protocols assume links are symmetric and expect packets to keep within same interface. There are special cases like asymmetric routing and network interface teaming but they have to be implemented on per-interface level.
One potential solution
One way to achieve what you're after (I don't know enough about your environment to claim it will work), will be to create a virtual interface, set it into yet another IP network, bind your application to it, then use firewall (to, say, allow multicast backets into the "virtual" network) and routing from that network to required default gateway with metric set to 1. I also suspect just any Windows will not be that flexible, so you might need like a Server Edition.
I am sorry this didn't turn out to be the ready-to-fly solution, I however am hoping this gives you more context to the problem you are facing and points you into other directions to explore.
You can use Set-NetAdapterAdvancedProperty command in Powershell to set the flow control of your specified adapter
To get the names and properties of all the network adapter :-
Get-NetAdapterAdvancedProperty -Name "*"
Suppose you want the network adapter named "Ethernet 2" to be only used to receive data from internet then type :-
Set-NetAdapterAdvancedProperty -Name "Ethernet 2" -DisplayName "Flow Control" -DisplayValue "Rx Enabled"
You can find more in :
https://learn.microsoft.com/en-us/powershell/module/netadapter/set-netadapteradvancedproperty?view=win10-ps
Microsoft winsock example has a usage in their example for limiting a socket to only send or receive mode. It might help.
https://learn.microsoft.com/en-us/windows/win32/winsock/complete-client-code
Outbount and Inbount limits are not imposed while binding. But latter or when connection is established.
Line of code pertaining to this in client code is toward the end.
// shutdown the connection since no more data will be sent
iResult = shutdown(ConnectSocket, SD_SEND);
For mobile Apps, it is a valid assumption that the network may be intermittent, or it may switch from one to another as the user keeps moving. For example, your device is connected to a startbucks wifi and you are using the App before you grab your coffee and walk out of the store -> Your mobile device network may switch from wifi to carrier network, 3G/4G/LTE. Even with the carrier network itself, it may switch among 3G/4G/LTE depending on their coverage at your position.
Question,
Will this intermittent network, or frequently network switch affect the http communication?
For example, an http request was sent out with Wifi, and while the server is processing the request, the device already switched to 4G. Will the device still be able to receive the response?
If Yes, how is Http or TCP designed to support this scenario?
If No, should we try to solve the problem from the application layer? and How?
Will the device still be able to receive the response?
For current practice, No. After network is switched:
Device's public IP address is changed.
TCP connection is based on IP protocol, so all current TCP connection would be destroyed.
HTTP is based on TCP connection, so it would be destroyed too.
Actually, you can make a simple experiment to verify this: Put a web page on internet and make the web server delay the page delivery for 30 seconds. Visit this page and switch network while waiting for the response.
However, this is a classic problem in mobile world, so some work is doing to give mobile device a constant IP, which will keep TCP&HTTP alive when device switches from one network to another. You can check Mobile IP in wikipedia for more information on various technologies and protocols.
If No, should we try to solve the problem from the application layer?
It depends on whether you can tolerate network interruption for your application. If it is a static web page, I think it is totally OK to leave this problem alone, and wait for Mobile IP technology improvement in future. If it is a highly network-dependent application, such as online video or stock market app, I think this problem should be solved in application layer.
and How?
There are 3 methods to fix/workaround this problem (maybe more):
Cache. Prefetch resources, so that when TCP connection is destroyed and reconnected, device can use cached resources. This works well in online audio/video apps, but it does not apply when no resource can be prefetched (realtime stock market data for example).
Take TCP re-connection as first priority. Check your code, when HTTP failed due to destroyed TCP connection, re-send HTTP request as early as possible.
Improve user experience when network interruption do happens.
I am a student and today for a lab, we were asked to install and use Wireshark. The installation went well, I installed the correct version, installed WinPcap, and the program started without any issues.
I was connected to the University's Wifi and as part of our lab we had to visit http://www.cas.mcmaster.ca/~rzheng/course/CAS4C03W17/Labs/INTRO-wireshark-file1.html and answer questions about the data captured in Wireshark.
Problem is, I am not getting any get or post requests, filtering by http.request.method == "GET" shows nothing, and http.request.method == "POST" shows nothing as well. Filtering by http shows the 200 OK and 304 Not Modified (if I refresh).
I was the only one in my lab who had this problem, and my instructor wasn't able to figure it out. He saved and sent me his output which has Get and Post requests so I can continue my work.
Did anyone have this problem before or have any idea on how to solve it? I can upload the saved outputs if you think it would help. Thanks!
Capture sample looks like it's filtered, since it contains only packets sent to your PC IP address. What is missing:
There is not a single outgoing packet, despite they are obviously on the net. E.g. there are "TCP acknowledge" packets received by PC in capture file, but packets sent by PC, which are acknowledged by them, aren't shown.
Not a single incoming broadcast/multicast packet. This situation is possible, but not very likely.
So there is some trouble with sniffer setup on your site. Possible explanations:
accidentally configured capture filter (don't mix with display filter)
Some interfering software is installed. Example of the same complaint
Method to determine if issue is gone: apply !(ip.dst == YOUR_IP_ADDR) display filter and check if packets output isn't empty on visiting any web page. Possible plan of troubleshooting:
check capture filter
check different network card (e.g. non-wireless connection)
check wireshark operability in pure environment (e.g. liveUSB)
try removing suspected interfering software
I have been writing my own version of the 802.11 protocol with network stack. This is mostly a learning experience to see more in depth on how networks work.
My question is, is there a standard for replying to client devices that a certain protocol is unsupported?
I have an android device connecting to my custom wifi device and immediately sending a TON of requests at the DNS port of my UDP protocol. Since I would like to test out other protocols I would very much like a way for my wifi device to tell the android device that DNS is not available and get it to quite down a little.
Thanks in advance!
I don't see a possibility to send a reply that a service is not available.
I can't find anything about this case in the UDP specification.
One part of the DNS specification assumes that there are multiple DNS servers and defines how to handle communication with them. This explains part of the behavior in your network, but does not provide much information how to handle it.
4.2.1 Messages - format - UDP usage
The optimal UDP retransmission policy will vary with performance of the
Internet and the needs of the client, but the following are recommended:
The client should try other servers and server addresses
before repeating a query to a specific address of a server.
The retransmission interval should be based on prior
statistics if possible. Too aggressive retransmission can
easily slow responses for the community at large. Depending
on how well connected the client is to its expected servers,
the minimum retransmission interval should be 2-5 seconds.
7.2 Resolver Implementation - sending the queries
If a resolver gets a server error or other bizarre response
from a name server, it should remove it from SLIST, and may
wish to schedule an immediate transmission to the next
candidate server address.
According to this you could try to send garbage back to the client, but this is rather a hack, or an error, but how does an error look like? Such a solution assumes that you have knowledge about the service that you don't support.
I believe that the DNS - requests can be avoided by using DHCP. DHCP allows to specify DNS-servers as listed in the linked page. This is the usual way that I know for a DNS-resolver in a LAN to get initial DNS servers although I don't find anything about this in the DNS specification. You can give the Android - device a DNS-server with DHCP so that it does to need to try to query your device. Querying your device could be a fallback.
Additionally to DNS there is mDNS which uses multicasts in the network to send queries. This seems not to be the protocol you have to do with because it uses the special port 5353.
Not possible to stop DNS in the way you intend. However, only for your tests you can check the UDP messages and find out the names the device is looking for. Then you update the hosts file (google how to do it: http://www.howtogeek.com/140576/how-to-edit-the-hosts-file-on-android-and-block-web-sites/) and add those names with some localoop IP address. That might work for your test.
Other possibility is to change DNS server to some localloop IP address: http://xslab.com/2013/08/how-to-change-dns-settings-on-android/
Again, this is only to avoid having all the DNS messages through the wifi connection.
What I'm trying to do is get all the ip addresses in my network, and I thought, assuming I know the address of all subnets could use arp requests to achieve that if there was a way to forward these requests over different subnets.
For example , assume I had two hosts
192.168.0.2/24 and 192.168.1.2/24
connected via router using IP addresses 192.168.0.1/16 192.168.1.1/16.
I would like to send an arp request from 192.168.0.2/16 to 192.168.1.2/16.
I thought maybe if the arp request was encapsulated in layer 3 header containing 192.168.1.2/24, or 192.168.1.255/24 as the dsetination this will work.
If it is possible and you know a tool that does that I will be happy to know about this tool.
If it isn't, I would like to know what happens to a packet like the one I described above
I would like to know what happens to a packet like the one I described above
If you encapsulate some info into standard IP-packet, then, naturally, it will be routed to the IP-destination host. Yet if the remote host knew nothing about this non-standard packet, then nothing would happen.
If you really want to get something out of this, you need to have up and running some software server on that remote host, which is able to process your requests. That is, you need some Proxy ARP: either existing implementation, or made of your own.
If you don't have such "an agent" in the target subnetwork, then you're out of luck. Go with sequential IP-scanning until be banned by admin.