How to change Bandwidth port limit by SNMP? There are OID for check Bandwidth port traffic, but I can't find any MIB to change the port limit.
Changing port attributes can't be done directly through SNMP. You would need to have a system to create a file including all the configuration changes you want applied and then use SNMP to copy the file to the device and apply it.
Related
My knowledge of networking is very basic so please bear with what I am sure are some very fundamental questions.
Is it possible to determine which interface/adapter (on a machine with multiple physical and virtual interfaces/adapters) is directly connected to a device with a known static IPv4 address without changing the network (i.e. the first 3 octets of its IPv4 address) of the interface/adapter beforehand?
I am asking this because I am trying to automate the setting of interface/adapter static IPv4 addresses on multiple machines in order for them to be able to communicate with the device and for it to work even if the machines do not use the same interface/adapter.
My original idea was to brute-force it by
Getting the device's IPv4 address as user input
Getting all physical interfaces/adapters connected to an Unidentified.network
Saving their previous network settings somewhere and loop through them while configuring them to use an appropriate static IPv4 address based on input in step 1
Attempting to ping device for a specified duration and if timeout occurs, revert the network settings of the interface/adapter to its original one otherwise, keep the new network settings and break out of the loop
My current worry is that the above process may inadvertently cause original network settings to be lost if some unpredictable crash were to occur during it.
So, it would be ideal if I could skip steps 2 and 3 and immediately detect which interface/adapter needs to have its IP address changed but based on what I read, this does not seem possible at all since if you could detect the device, then there would be no need to set a static IP address for the interface/adapter in the first place (cause you can already detect it).
I've also seen that using the ARP cache would work if the first-time connection on all machines are done manually and then setting the appropriate entry to persistent so that it would survive across reboots but I would ideally want even first-time connections to be automated if possible.
Can anyone provide any insight as to whether I am attempting the impossible?
Or is there a better way to achieve what I want?
I have seen some recommendations to use wireshark to sniff for incoming ARP packets but that would require installing it on all the machines I would be deploying my automated approach on which may not be feasible.
For context, I am automating this on Windows 10 and would prefer using powershell/bash/python.
Edit 1
Thanks to the link provided in the comment, I have gained a better understanding of IPv4 terminology.
So I guess I can reformulate my question.
Device
IPv4: 192.168.0.216/24
Network: 192.168.0.0
Machine
First interface/adapter
IPv4: 169.254.19.133/16
Network: 169.254.0.0
Second interface/adapter
IPv4: 169.254.27.245/16
Network: 169.254.0.0
If there is already a physical connection between the second interface/adapter and the device, is there a way to detect (not communicate with) the device without having to change the network of the second interface/adapter beforehand?
Or is brute-forcing it the only way to achieve my goal?
In recent weeks, I'm learning to use EMANE to do the emulation about Ad hoc networks which uses the Predictive OLSR routing protocol.
The locations of the UAVs' location are taken into account to calculate the ETX metric in P-OLSR, which makes it different with ordinary OLSR. I get trouble in transferring the locations data of UAVs into the P-OLSR core. The patch file that I downloaded from the link mentioned above adds a gpsreceiver plugin to the protocol, which is used to receive location data from the out of P-OLSR then transfer it into P-OLSR. And in the olsrd.conf.example file, I'm supposed to set an interface, a multicast IP address and a port for the plugin, I don't know how to set these things when I use the EMANE emulation platform. I tried to set the multicast IP address and the port same as the value of eventservicegroup attribute. But the it cannot be right, because the data format is not consistent.
EMANE uses an application called eelgenerator which can generate location event to deliver the locations data of UAVs, but the data is in a eel log file format not in a NMEA format which is wanted by gpsreceiver. EMANE also has an application called gpsd location agent, and it can handle the location event, and transfer the locations data into NMEA format, but the output of gpsd location agent can only be connected to GPSd directly or to a pseudo terminal then connected by GPSd. GPSd can get the latitude, longitude and altitude information from the NMEA format location data, and serves the other applications via the port 2947 of localhost.
So, How can I transfer the locations data into P-OLSR core? If via the gpsreceiver, How should I set the olsrd.conf and do I need to write a program myself? If do not use the gpsreceiver plugin, can I make the P-OLSR core to get location data through GPSd? If can, how to realize that exactly?
PS:the version of my EMANE is emane-0.9.3. the version of my machine's kernel is 4.2.3-300.fc23.x86_64.
I solved the problem. I wrote a python script to read data from the pts and send it to the gpsreceiver. Here is the script:
import socket
fd = open("path of pts", "w+")
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.sendto(fd.readline(), (host, port))
I'm thinking about writing an anti-keylogger/anti RAT application. Basically, what I want it to do is this:
Monitor outgoing ftp traffic (maybe monitor all outgoing traffic and have an option to filter by ftp)
Analyze headers to find potential keyloggers/RATs
Sniff out the FTP address for any such connections
Block (or give user the option to block) connections to these addresses
I think I can handle steps 1-3, and I know I could block all FTP traffic, but how could I go about blocking specific addresses?
On a side note, can anyone suggest some libraries that might make steps 1-3 easier? Or libaries that'll do step 4, if they exist. I don't mind writing code to target multiple OS.
Snort allows you to monitor incoming/outgoing traffic and works based on a set of rules specified in a file. Once you've detected traffic going out that has a certain IP/port/body using snort, use SnortSAM in conjunction with a firewall to block traffic to that IP/port.
I like to send packet to a device with only MAC address associated to it and also connecting to my local LAN.
Is there anything in ruby / gem library that I can use to perform such task?
I want to do something like tcpreplay but in ruby instead. Thanks!
MACs are the addresses used on OSI layer 2, the package type you are using on this layer are e.g Ethernet frames. IP Sockets live on layer 3/4, thus if you are using an IP socket, you are sending IP packet.
So if you want to send something "to a MAC address", you need to send raw Ethernet frames which need to be understood on the other side. Given the really low level of this stuff, this is rarely what you really want to do.
Instead, you should try to get the proper IP addresses of the remote device in your local network (technically the broadcast domain) with either a broadcast/reply mechanism or with multicast (which is used e.g. by Bonjour). That way you can always use the much more supported IP layer. For that, your device needs to have an IP address of course. You can establish those with mechanisms like DHCP or address auto configuration for IPv6.
As for your question, I'm not aware of any library for Ruby to send raw Ethernet frames. But given you would need to invent a new protocol besides IP anyway (which is hard, really hard), sending the package is probably the least of your concerns.
I suppose there are a couple of approaches. You didn't say whether you wanted to send an IP packet of some kind, and if so you didn't say which IP protocol. (I can tell you want to send an ethernet frame but ... what encapsulated protocol?)
Anyway, you can open a SOCK_RAW with Ruby, something like:
Socket.open(Socket::PF_INET, Socket::SOCK_RAW, Socket::IPPROTO_RAW)
Another approach might be to just pick a link-local IP and then establish an IP/MAC mapping in your local ARP cache with something like:
system "arp -s host hw_addr"
Then you could communicate with it using more familiar socket ops using the link-local IP address.
You need to be root for all of these things.
Summary: I'm trying to create sockets to pass data between two physical interfaces that exist on the same machine, and Win32 sockets always forwards the traffic directly in the kernel instead of pushing through the physical interfaces. Is there any way to disable this behavior, perhaps through device settings, registry tweaks, routing table shenanigans, or socket options? We're using Windows XP SP3.
Some background. I'm attempting to build some completely automated IP tests to exercise our custom IPv4 equipment. We have a large lab of Windows XP machines, and individual physical ethernet interfaces for each device we're connecting to. Our devices are effectively ethernet routers each with their own IPs.
We need to send data out our lab machines, through our devices, then back into the same computer. We will be sending Unicast and Multicast UDP, TCP, and broadcast IP traffic through the devices.
We want (and likely need) the traffic to originate on the same machine it is destined to.
To do this, we configure two separate NICs each with their own IP on their own subnet, for instance NIC #1 with 10.0.0.1/24 and NIC #2 with 10.0.1.1/24. Our devices then act like simple passthrough routers, and have two interfaces, one on the 10.0.0.0/24 subnet, one on the 10.0.1.0/24 subnet, which they just forward packets back and forth from.
To generate our data, we'd like to be able to use Win32 sockets, since it is well-understood, well-supported, what our customers are using, and would probably be the most rapid approach. Packet injection is probably feasible for UDP and broadcast IP, but very likely not so for TCP. I'd entertain ideas that used packet injection, but would strongly prefer standard Win32 sockets.
As stated in the summary, the packets never leave the machine. I've googled like a madman and I've not found much. Any ideas?
Use Windows' command-line ROUTE utility. You can configure it so any IP packet sent to a specific IP address on a specific Subnet gets sent to another IP/device. For example:
route ADD <NIC_1_IP> MASK <NIC_1_SUBNET> <DEVICE_IP_CONNECTED_TO_NIC_2> METRIC 1
route ADD <NIC_2_IP> MASK <NIC_2_SUBNET> <DEVICE_IP_CONNECTED_TO_NIC_1> METRIC 1
Alternatively, if you know the index numbers of the NIC interfaces, you can specify them instead:
route ADD <NIC_1_IP> MASK <NIC_1_SUBNET> METRIC 1 IF <NIC_2_INTF>
route ADD <NIC_2_IP> MASK <NIC_2_SUBNET> METRIC 1 IF <NIC_1_INTF>
This way, whenever a packet is sent to NIC #1's IP, the packet goes to the device connected to NIC #2, which will then pass it on to NIC #1. And vice versa for packets sent to NIC #2's IP.
For instance, this is a useful technique for allowing WireShark to capture local IP traffic if the PC is connected to a network with a router. Packets from one local IP/Port to another local IP/Port can be bounced off the router back to the PC so they travel through physical interfaces that WireShark can monitor (WireShark will see duplicate copies of each local packet - one outbound and one inbound - but you can filter out the duplicates).
Winsock is always going to bring the packet data up into the kernel space and deal with it there. Thats the whole point to a generic API is that any device is dealt with at the same "layer". If you want to stick with Winsock, I don't believe you can (or would want to) work around this behavior.
You can remove some of the buffer copying with TransmitPackets or TransmitFile, but not between two device interfaces.
That being said, are you having a performance issue with the additional buffer coping that Winsock performs? Security concerns?
How about running the endpoints of your tester inside of distinct virtual machines? Then you need only a single piece of hardware, but you'll have separate TCP/IP stacks that don't know each other are local (and most VM solutions pass the packet straight through the host unchanged, I don't think the host is going to grab the packet and send it straight to another VM unless you configure bridging between VMs... but you'll bind each VM to a different physical network adapter).