Testpmd is running in a Hyper-V VM, and there are two NICs which connect to "internal virtual switch". I just want to test the availability of netvsc PMD.
./app/dpdk-testpmd -l 2,3 -- --total-num-mbufs=2048 -i --portmask=0x3 --port-topology=loop
I have used "start" or "start tx_first", and then used "show port stats all" to check. There are no Tx-packets or Rx-packets on two NICs.
Then I used "set fwd txonly", and I could find Tx-packets on two NICs, but it is not my want. So what steps can I do?
Typically, one wants to use a packet generator on the side that is opposite to a pair of ports harnessed by testpmd. Such a generator starts sending packets, whilst testpmd simply receives them on one port and transmits them back from the other one. This is what port-topology of type paired stands for, and this port-topology is used by default in testpmd. Another parameter, forward-mode, in turn, is set to io by default, which means that testpmd does not change the received packets before transmitting them back (in example, does not swap MAC addresses, etc.).
However, in your case there's no packet generator employed, and that means that testpmd must generate and send a batch of packets itself in order to kick-start forwarding. This is accomplished by specifying option --tx-first.
But apart from omitting option --tx-first you for some reason use option --port-topology=loop, which might be the reason behind your setup being non-functional. Variant loop means that packets received by a given port (say, Port 0) must be transmitted back from the very same port (that is, from Port 0). What you might want here is --port-topology=paired, which, as I stated before, is anyway used by default.
So, the short of it, you should probably try running testpmd as follows:
./app/dpdk-testpmd -l 2,3 -- --total-num-mbufs=2048 -i --portmask=0x3 --tx-first
Please note that this way forwarding is started automatically but you get no testpmd> prompt to enter command in. Should you wish to start forwarding automatically and, at the same time, get an interactive command prompt, please try running testpmd this way:
./app/dpdk-testpmd -l 2,3 -- --total-num-mbufs=2048 -i --portmask=0x3 --tx-first --auto-start -i
DPDK application testpmd is not a packet generator that will automatically generate and send Packets. But there is an option --tx-first which allows sending a burst (default 32) dummy packets from each interface.
Since your environment is physically connected this should work. But I highly recommend first check with the Linux driver whether ping or arp is able to reach the cross-connected interface first.
Note:
I highly recommend reading testpmd doc for more details
for enabling promiscus mode use option set promisc all on
Related
I am setting up an Intrusion Detection System (IDS) using Suricata. I want to write a custom rule which will generate an alert whenever a failed login attempts occur to my virtual machine.
Example:
alert tcp any any -> $HOME_NET 22 (msg:"SSH Brute Force Attempt";flow:established,to_server;content:"SSH";nocase;offset:0; depth:4;detection_filter:track by_src, count 2, seconds 2;sid:2005; rev:1;)
I tried various combinations for SSH rule but not able to see any alerts in the Suricata Alerts section with multiple bad SSH attempts. (Bad attempts => using invalid password to generate alerts)
Kindly let me know how to go about this.
Since you are really attempting to look at the encrypted content (which is where the authentication and subsequent failure message will be), Snort/suricata isn't the ideal tool to use in the way that you describe. Instead, log monitoring would be a better approach.
There are other alternatives, however. You might look into Fail2Ban for automatic blocking at the IPTables level.
If you really want to do it with Snort/Suricata, you could use alert thresholds. For example:
alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"Possible SSH brute forcing!"; flags: S+; threshold: type both, track by_src, count 5, seconds 30; sid:10000001; rev: 1;)
This tells Snort/Suricata to generate an alert on inbound connections (inbound packets with SYN set) when a threshold of 5 connections are seen from a single source in the space of 30 seconds. The threshold "both" indicates that it will not alert until this threshold is passed and that it will only generate one alert to notify you, rather than starting to inundate you with alerts.
Note that I have marked the flags as S+. Don't use just SYN. Remember that ECN has become a real "thing" and that you may find that the two bits that Snort/Suricata still call "Reserved" are set as a result of an ECN negotiation.
The RFP for TFTP says that TID's in most circumstances:
should be randomly chosen, so that the probability that the same
number is chosen twice in immediate succession is very low.
The thing is, these "TID"s are also used as UDP port numbers. But a typical network interface cannot just be dedicated for TFTP use. Some ports are liable to be in use, and others should essentially be "reserved" for specific applications. I'm not even sure where a program could go to look up this information at runtime.
So how is a TFTP implementation supposed to deal with this?
Since the host selecting the TID/port is the one opening it and telling the other party which one it's opened, you can simply try to open the port; if it's already in use or otherwise unavailable, this will fail, and you can re-try with a different port. (Note that since UDP and TCP are difference protocols, a TCP application and a UDP application can both be using the "same" port, since they are not, in fact, the same at all!) Do this in a simple loop until you find a "good" one. (Probably best to define a maximum number of tries and simply fail the connection if that's met before a good port is found, as this could be a sign of other issues that prohibit this from working at all.)
Stick to the ephemeral port range to play nice with best practices, although note that different systems define different ranges for this purpose. You could pick the range suitable to your system, or simply try to use a port above the "well-known" port range (i.e. above 1024); this may not give you an "ephemeral port" per se for your system, but so long as you can open it it should work fine.
I have a weird problem. I have a successfully working C++ (boost asio) P2P application which works on most of the NAT. The problem is when I give the initial start port number as 1000 it checks if 1000 is free else increment by one and chooses a port and starts handshaking. But when I have 10000, 20000, or any other huge port number the hole punching doesn't work on port restricted cone NAT.
How is that possible? I am pretty sure it nothing to do with the code. and recently it doesn't work on one of my friends' full cone NAT as well, but it has worked in many other full cone NATs. What could be the reason? Is there something I am missing about how a NAT behaves?
In many NAT implementations, there are protection rules in place which prevent one host from tying up a large percentage of ports on the WAN interface, e.g. like described here.
Depending on the router, the NAT table entries have different lifetimes, and there are always limits on how many ports can be allocated to a single client (I've seen numbers from 128 to 4096).
So I think when you get to the point where you need to use high ports, the NAT table for your source IP address is already full (or almost full) with entries from old connections, or connections from other apps, so the router either decides to decline or can't fit the new NAT entry for your port.
However, to be sure, I would try to repeat that on a controlled environment collecting Wireshark dumps on both sides of the NAT and analyze the packets. If possible, it would also be helpful to enable router logs and peek into them.
I understand this is not a "magic bullet", but hope it somehow helps you.
Don't try to choose the port number yourself. The operating system can do this faster and better than your code can.
Bind your socket to port 0 and let the OS choose an available port number for you. You didn't specify what programming language, but it usually involves a call to getsockname() after the bind() call is made to discover what local port is going to be used. Java and .NET have equivalent APIs for doing the same thing.
Then follow all the other steps here:
https://stackoverflow.com/a/8524609/104458
Not sure if this'll help but have you tried having one instance of the client application starting at 1001 and the other starting at 1000, then both increment by 1.
While the 1000 will fail on client B, client A has already tried 1001 and so punched that hole, so hopefully it'll work, right? In theory, it sounds OK in my head.
Does libpcap get a copy of the packet or the actual packet?
By copy, I mean: the application using libpcap gets packet A, and the kernel also gets packet A.
By actual, I mean: only the application using libpcap gets packet A, but the kernel didn't get it.
libpcap will not allow you to do what you want. The goal of pcap is to transparently receive a copy of every packet in the system.
You should investigate how to inter-operate with the existing firewall in your system, or how to add your own filters to the netfilter system (on Linux)
The kernel will get the packet then pass it through a list of filters (for example, there's usually a filter for IPsec, a firewall and so on) and once it's gone through all of these filters, it passes the packet on to the application. libpcap is another filter, but it simply adds the packet to an internal database for processing, rather than inspecting the packet, modifying or whatever else the other filters will do.
For what you want to do, the simplest solution would be to use a firewall.
If I understand the parallel port right, sending data from (D0 to D7) simultaneous, but that it can control the sticks individually?
example:
D0 = Input
D1 = Input
D2 = Output
...
...
...
D7 = Input
would it work?
what I want to do is to both send and receive data simultaneously.
Data wires (D0-D7) are being read or set simultaneously. For various tecniques for bidirectional I/O read the attached articles:
Standard parallel port: http://www.beyondlogic.org/spp/parallel.htm
EPP: http://www.beyondlogic.org/epp/epp.htm
ECP: http://www.beyondlogic.org/ecp/ecp.htm
This site is a good source for programming the parallel port.
The basic idea is that you need a DLL, add-on or library that allows you to access the I/O Ports of the PC. For Windows XP on up you need a specific driver that will allow you do this as the OS doesn't offer access out of the box.
The Parallel port will generally reside at one of three address 278,378, 3BC. This port. have the bytes you are reading or writing.
The (base)+1 port allows access to the status bytes. IE. 279,379, 3BD
The (base)+2 port allows access to the control bytes. IE. 27A,37A,3BE
The parallel port documentation will tell not only how to implement the common modes (like bi-directional) but how to control the port at the byte level to implement your own custom.
Back in the day there was only the standard mode available. You pump out your bytes at the (base) port. Some application, like mine, manipulated individual bits of that ports as form of cheap Digital I/O Controller. We did use the status and control bytes as additional inputs and outputs. There were commands you can send to the Parallel Port chip configure the modes precisely.
Today there are are hundreds of sites with example of using the Parallel Port to solve all kinds of problems. I would be surprised that one of doesn't have something you can use for you specific application.
Again the book I recommend starting with is Parallel Port complete. It tells just about everything you need to start with. If your application is too esoteric for that book it will give a springboard from which you can find the exact setup you need.
Of course by sending a number that has just the required bit set (2n) you'd get the expected result.
I'm not sure about bidirectional access though. I guess it's achieved by using control pins along with the data pins but that's just a guess.
Parallel ports doing EPP or ECP only allow D0-D7 to be all input or all output. Trying to do otherwise may fry your hardware.
See http://www.nor-tech.com/solutions/dox/ieee1284_parallel_ports.pdf, page 6.
However, parallel ports have several control lines that may be useful if you only need a small amount of input/output in the "other" direction.
I believe its bit 5 in the port's control register (base address + 2) that switches direction. (no hardware line attached)