I use packet sender to generate UDP flooding traffic. However, I have multiple NICs and the NIC packet sender using is not what I want. How do I specify the NIC in the packet sender?
Update: Latest release of Packet Sender now supports this.
The UDP traffic generator does not bind to custom IPs in the current release. It only does a general bind. That has been added for the next release.
Actual commit with the fix:
https://github.com/dannagle/PacketSender/commit/0c0e60d33a6e4a378c0395e347bc95d2a955d22a
Hopefully, new people visiting this question will have it available.
Until that fix gets released, you can use the CLI version of the UDP traffic tool with this bindip option:
-B, --bindip <IP> Bind custom IP. Default is IP:Any.
Related
I'm am facing to an issue when sniffing on the loopback interface when using a JTAG debug probe, which uses a TCP socket. It completly flood the loopback, and freeze Wireshark after a few seconds.
As a workaround, I have made a dummy LUA dissector for this case (redlink-server protocol). Wireshark is no longer freezing, but it produces like 8Gb of packets in a few minutes...
(the plugin consists in an empty dissector function, add register this dissector for TCP port 3490)
Is there a simple way to delete those packets from dump file not to overflow my RAM ?
Tanks by advance
Thomas.
You can apply a capture filter, not a display filter, to avoid capturing the traffic. In your case, the capture filter to exclude the unwanted traffic would be not tcp port 3490.
Refer to pcap-filter for more information on capture filters, as well as the Wireshark User Guide, Section 4.10. Filtering while capturing.
I have a question that I encountered in my Operating Systems exam today.
Given a process that "forges" the IP address in every sent packet (gives the wrong IP address), does the ARP work correctly?
I maintain that it doesn't, since the packet wouldn't know where to return the "ack".
Would love to hear your opinions.
I maintain that it doesn't, since the packet wouldn't know where to return the "ack".
It is returned to the sender's MAC address, not IP address.
From RFC 826:
When an address resolution packet is received, the receiving Ethernet
module gives the packet to the Address Resolution module which goes
through an algorithm similar to the following. Negative conditionals
indicate an end of processing and a discarding of the packet.
?Do I have the hardware type in ar$hrd?
Yes: (almost definitely)
[optionally check the hardware length ar$hln]
?Do I speak the protocol in ar$pro?
Yes:
[optionally check the protocol length ar$pln]
Merge_flag := false
If the pair <protocol type, sender protocol address> is
already in my translation table, update the sender
hardware address field of the entry with the new
information in the packet and set Merge_flag to true.
?Am I the target protocol address?
Yes:
If Merge_flag is false, add the triplet <protocol type,
sender protocol address, sender hardware address> to
the translation table.
?Is the opcode ares_op$REQUEST? (NOW look at the opcode!!)
Yes:
Swap hardware and protocol fields, putting the local
hardware and protocol addresses in the sender fields.
Set the ar$op field to ares_op$REPLY
Send the packet to the (new) target hardware address on
the same hardware on which the request was received.
What this means?
ARP is return addressed using MACs, although IP addresses can also be included in the Sender protocol address (SPA) field of the packet. This means that although the sender IP address (SPA) is spoofed, there is no mention of the Sender hardware address (SHA) being spoofed in your question.
This means that the sender will receive the ARP replies and ARP will function (from the point of view of the sending machine). However, as the ARP packets contain a spoofed SPA, the target machines (and possibly other devices on the network) will associate the sender as having that IP address, enabling a successful ARP poisoning attack:
e.g. Linux ignores unsolicited replies, but on the other hand uses seen requests from other machines to update its cache.
I think it will know where to return the ack to, because the sender sends his MAC address and this what matters. Yet I think it won't work because the receiver will change his ARP table according to the MAC&IP he got from the sender. (this is a trivial optimization).
I have an RN-171 wifly module connected with a micro-controller.
I am using the UDP-protocol to communicate with the module. Also, I am using the firmware's UDP auto-pair feature to set the host ip. As soon as the module receives a UDP packet, it sets the host IP address to the ip from where it received the data. Now, this host ip cannot be changed without entering into the command mode.
I want the module to behave in the following way:
Every time it receives a UDP packet, it updates the host ip to the ip address from where that signal came from.
Also, I can use the TCP protocol but it only allows a single connection at a time. One more problem that I faced using the TCP protocol was that if I try to initiate a second TCP connection with the module, it not only refuses the second connection but also hangs the first stable connection. Even if the second connection initiation does not hang the module and it just gets refused, I will be ready to work with TCP.
I have been researching a lot on the web regarding this problem but since these modules are not widely used, they have a very limited support.
I've used RN-171 extensively and have many resolved tickets in their support system.
According to the WiFly Command Reference, Advanced Features and Applications User’s Guide, you cannot open more than one TCP port with the module. (the default number being 2000)
Unfortunately, regarding the UDP functionality, there's not much you can do. If you have a new host wishing to communicate over UDP, connect to the module over TCP, go into command mode and set the address using "$$$", "set ip host 0.0.0.0", "save", "exit" commands. Alternatively, instead of 0.0.0.0, you can enter the new host's own ip address: "$$$", "set ip host ###.###.###.###", "exit". Replace "###.###.###.###" with the ip address of the device.
This way, you won't get wrong host ip in case more than one device communicates over UDP at the same time. Also, by not using "save", the auto-pairing will still be saved to EEPROM memory. Also, you can send "ip flags 0x##" before "exit", this way you can also set bit[6] to 0 (UDP auto pairing disabled) temporarily by using the hex value that has this bit set to zero.
One of my problems that Microchip technical support tested around the summer of 2013 is that you cannot use RN-171 as an access point for other RN-171s since they have a firmware error preventing one from doing that and, as of firmware v4.41, released in January of 2014, there is no fix yet nor planned.
I myself do not recommend the latest firmware version v4.41, since it does not appear to work with most routers; however Soft AP mode on this works fine. On the other hand, v4.00.1 is much more compatible, however you should take care when cutting off the power since it has a potentially disastrous bricking problem if you cut the power when flash writing is in progress - the module may lock its memory forever.
I recommend registering and opening a Microchip ticket which usually will be answered within two business days and they're quite supportive. Their firmware update cycle is however quite long, and it usually takes a year or so for a new update.
I have a router1-switch-router2 connection. My problem is if I send a packet from router1 to router2, it is not received at router2. I am sure the ipaddress/subnet address are correct. And am also sure that packets are going out the router1. And I am also sure of the internal port connections of the switch. I have access to the onpath switch. Is there any specific command that can be used in the switch to check whether the packet is received or not? ARP itself not getting resolved
You can have a packet capture app running on both the sender and receiver that would tell the incoming and outgoing packets on both boxes.
In this case probably your packet is getting dropped either on the sender or receiver side. There can be million reasons for a packet drop. But this is a good step to start with.
There is an old program a member of this online community made for everyone to use, but he is no longer around and no longer supports it. I wanted to help the community by extending it's features somewhat. To do that, I need to know how data is sent from it. How can I capture the network traffic it sends, and determine what it's sending?
WireShark is your friend. Available for UNIX and Windows.
Wireshark is a network packet analyzer. A network packet analyzer will
try to capture network packets and tries to display that packet data
as detailed as possible.
Wireshark User's Guide
#Kerrek SB's Tip: use tcpdump -s0 -w /tmp/data -i eth3 or so to create the dump file, and analyze it with Wireshark later as an unprivileged user.