I use wireshark to capture the packets of my computer. I want to get the packets of 219.231.143.116(source ip) ,and my ip is 219.231.143.220(destination ip).
In fact,I got what i wanted, but to my surprise,I got some others' packets.Those packets' source IP and destination IP were not 219.231.143.116 or 219.231.143.220.
As I know,tcp is a 3rd layer in TCP/IP protocol,the switch would not send those packets that don't belong to me. So,the problem is why could i capture them on my computer? Is this the issue of wireshark or the switch?
（Due to my level is too low,so the image is here,i'm sorry!）
http://mysource.lofter.com/post/1cfd51e8_55d5972
The switch decides which packets to send you. You can't change this. You can only filter out (in Wireshark) the packets you don't want to work with.
Wireshark will show you all the packets you actually receive (in promiscuous mode).
All the additional packets you highlight in your image are TCP Retransmission packets. The switch may be casting the packets wider because retransmissions are occuring, so something is timing out. Or, there may be a broadcast or multicast flag set in the packet, as the source attempts to get it's retransmissions heard.
You won't get a lot of packets destined for other computers, and you won't get a complete sequence of sent & received packets belonging to another device (unless you configure the switch to do so with port mirror)
If you really really don't want to see or leak those packets to a particular device, you could use a physical firewall like pfsense or a router between you and the switch, to absolutely filter out multicast traffic originating in your network. This would be an usual use case.
Related
I have a software which uses a TUN device to read datapackets, process something on them and send them out. Now I am asking myself, if it is possible, to send the "tun packets" without touching them.
Over the TUN device I get IP Packets but over a RAW socket I just can send self defined transport layer packets...
Is there a possibility to just take this packet from the TUN device and send it over a network card out?
If anybody is interested in that topic, I wrote a witepaper to wrap up all needed information to use RAW-sockets: http://tuprints.ulb.tu-darmstadt.de/6243/1/TR-18.pdf
You didn't enable IP_HDRINCL socket option on the RAW socket?
If IP_HDRINCL option is enabled, you can send self defined network layer packets.
I'm in the process of making a multiplayer game, where the players' movements are sent over the network and their positions are stored in the server. I've been told that UDP would be best since it doesn't rely on constant connection and it won't matter if the client misses a packet. The clients could be on any router, not necessarily within the server's LAN.
Is it possible to set up a server that the clients can connect to that will send all of them periodic updates of the positions of nearby objects/players?
I don't want to have to send packets to each individual client, and I heard multicasting can solve this problem, but every example I've seen only sends packets over a local network. Can I multicast past routers, and if so, how can I do that in Java? (And explain it to me like I have no idea what I'm doing, which is mostly true)
Ex.
Server has IP address 71.10.200.133
Client A has IP address 38.49.339.293
Client B has IP address 37.28.487.388
...
Client Z has IP address 43.38.382.949
Client A sends an update about the player's position to Server
Server sends update to B-Z without iterating a packet to each individual client. How do I accomplish this (if it's possible)?
Multicasts will traverse a router if and only if the router allows it. Unless you're in control of all the routers between you and your clients, the answer to your question is 'no'.
Multicast packets are broadcasts, thus they reach each node on that subnet. For you to send a multicast packet out on the web is not an effecient nor smart way of sending data.
For LAN based traffic:
Multicast is fine
But, for internet traffic I would suggest making a:
UDPClient
or
TCPClient
for internet based traffic and possibly multicast for LAN based (to mix things up a bit).
For internet traffic: Keep in mind, clients will need to initiate the connection first since most routers (household) have a firewall blocking all NEW outside-to-in traffic. So create a socket to listen over a designated port/ports for any incoming connections and from there on use which ever method of packet broadcasting/sending you like
You do also have the option of using Multicast proxies or Layer 2 VPNs if you have the capabilities. L2TP, https://en.wikipedia.org/wiki/Layer_2_Tunneling_Protocol
A layer 2 VPN would relay unicast and multicast packets.
That would basically allow you to control the routers as EJP suggested above.
This questions also 3 year old so you've probably already figured a way to do it by now.
Im a student and as a hobby I am writing a program that is supposed to perform a man in the middle attack with ARP spoofing, and then manipulate the traffic before sending it on to the victim. For this I need to examine the packets, manipulate them and forward them to my victim.
Note: This is strictly a hobby project and the network is my own local network at home. Its just some generic AT&T homeportal and a bunch of machines connected via wireless.
I know that when I enable IP forwarding on my machine, it does the following to packets that are to be forwarded:
Put my MAC as SRC in the ethernet header
Put forwarding target's MAC as DST in ethernet header
Decrement TTL
Recalculate IP Header checksum
Send the packet
Since I want to manipulate the traffic before sending it on, I am trying to write a program that does the manipulation and then the forwarding manually so to speak. What I tried to do:
See if packet is for my victim
If so, manipulate it how I want
Put my homeportals MAC address as SRC in the eth header
Put my victims MAC as DST in eth header
Send the packet
My train of thought was that when looking at the packets it would be indistinguishable from "normal" traffic. If I decrement the TTL and recalc. the checksum and put in my machines MAC as SRC, its kinda easy to notice whats going on if you look at the packets.
However, my method does not work. As in, if I put the homeportals MAC as SRC on the ethernet header, for some reason none of the webpages load on machine A.
If I put in my machines mac address, the webpages load although slowly and wireshark shows me a lot of TCP retransmissions coming from the webpages server, I am guessing this is because my program is forwarding the packet too slowly to machine A and so A can't respond in time?
So anyway, thats pretty much my question: Why can't I pretend to be the homeportal? As in put its MAC address in the ethernet header of the packets I forward to A. Also, what else could cause all the retranmissions from the webpage servers when I use my machines MAC address? English isn't my first language so I hope this is not too vague.
I'm writing a PMTUD app for both IPv4 and v6. I am doing this on Ubuntu 12.04, but I would like to make it as OS-independent as possible, and that's where I stumbled upon a problem.
IPv6 packets get fragmented by the sender by default, and I do not know how to turn this behaviour off. I found some socket options like IPV6_MTU_DISCOVER and IPV6_DONTFRAG, but I found these under linux/in6.h, which does not help as I'm using the netinet header family and neither of those is under netinet/in.h - although IPV6_MTU_DISCOVER should be there according to this. Am I missing something?
EDIT: Let me clarify a bit then.
I have a socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6) through which I wish to send an ICMPv6 packet of such size that I will receive a reply telling me it's too big, and from that reply I will get the path MTU.
However, to truly get the MTU along the whole path I also have to factor in the outgoing device's MTU.
I am using miredo to tunnel IPv6, which has a set MTU of minimal size, e.g. 1280. Sending a packet bigger that 1280 will result in fragmentation of said packet (this behaviour I observed in Wireshark), but I need the socket to REFUSE to send the packet and inform me about it rather than fragment it.
You do not need to do this yourself. MTU discovery is supposed to happen automatically. As a side effect of this, all devices along the path MUST allow ICMP V6 packets to pass.
IPv6 packets get fragmented by the sender by default
No. TCP packets get fragmented by the sender and intermediate routers by default.
, and I do not know how to turn this behaviour off.
You cannot turn it off. You can certainly try, but the only result will be non-delivery. If a router needs to fragment a packet and you don't permit it, it will drop it instead. However the sending host also needs to fragment, to fit inside the path MTU, and you cannot stop that. If you write the receiver correctly, i.e. in the expectation that it is reading a byte stream rather than discrete messages, it should make no difference to you whether the packets got fragmented in transit or not.
I'm trying to find a way for client to know socket server ip:port, without explicitly defining it. Generally I have a socket server running on portable device that's connect to network over DHCP (via WiFi), and ideally clients should be able to find it automaticaly.
So I guess a question is whether socket server can somehow broadcast it's address over local network? I think UPnP can do this, but I'd rather not get into it.
I'm quite sure that this question was asked on Stack lot's of times, but I could find proper keywords to search for it.
One method of doing this is via UDP broadcast packets. See beej's guide if you're using BSD sockets. And here is Microsoft's version of the same.
Assuming all the clients of the application are on the same side of a router then a broadcast address of 255.255.255.255 (or ff02::1 for IPv6) should be more than adequate.
Multicast is another option, but if this is a LAN-only thing I don't think that's necessary.
Suggestion
Pick a UDP port number (say for the sake of an example we pick 1667). The client should listen to UDP messages on 255.255.255.255:1667 (or whatever the equivalent is. e.g.: IPEndPoint(IPAddress.Any, 1667)). The server should broadcast messages on the same address.
Format Suggestion
UDP Packet: First four bytes as a magic number, next four bytes an IPv4 address (and you might want to add other things like a server name).
The magic number is just in case there is a collision with another application using the same port. Check both the length of the packet and the magic number.
Server would broadcast the packet at something like 30 second time intervals. (Alternatively you could have the server send a response only when a client sends a request via broadcast.)
Some options are:
DNS-SD (which seems to translate to "Apple Bonjour"): it has libraries on macOS, but it needs to install the Bonjour service on Windows. I don't know the Linux situation for this. So, it's multi-platform but you need external libraries.
UDP broadcast or multicast
Some other fancy things like Ethernet broadcast, raw sockets, ...
For your case (clients on a WiFi network), a UDP broadcast packet would suffice, it's multi-platform, and not too difficult to implement from the ground up.
Choosing this option, the two main algorithms are:
The server(s) send an "announce" broadcast packet, with clients listening to the broadcast address. Once clients receive the "announce" packet, they know about the server address. Now they can send UDP packets to the server (which will discover their addresses for sending a reply), or connect using TCP.
The client(s) send a "discover" broadcast packet, with the server(s) listening to the broadcast address. Once the server(s) receive the "discover" packet, it can reply directly to it with an "announce" UDP packet.
One or the other could be better for your application, it depends.
Please consider these arguments:
Servers usually listen to requests and send replies
A server that sends regular "announce" broadcast packets over a WiFi network, for a client that may arrive or not, wastes the network bandwidth, while a client knows exactly when it needs to poll for available servers, and stop once it's done.
As a mix of the two options, a server could send a "gratuitous announce" broadcast packet once it comes up, and then it can listen for "discover" broadcast requests from clients, replying directly to one of them using a regular UDP packet.
From here, the client can proceed as needed: send direct requests with UDP to the server, connect to a TCP address:port provided in the "announce" packet, ...
(this is the scheme I used in an application I am working on)