Wanted to write better AI for the game Red Alert 2. Game uses IPX protocol for multiplayer. If i'm right, IPX protocol is on Layer 2, so there is only ETH frame without destination/source IP or destination/source Port, so game is running via it's own protocol. Therefore, i could analyse this protocol and programe AI, that would simulate real player. Do you think, tak it is realistic idea? Is there any way how to "generate" and send IPX packet (ETH frame)?
Thanks for any suggestions.
Is there any way how to "generate" and send IPX packet (ETH frame)?
IPX is a layer 3 protocol; but it doesn't contain IP addresses, because it's not an "IP" (internet protocol).
Assuming you're on Windows, the Winsock library is supposed to support IPX: see Winsock IPX/SPX Annex.
IPX is a packet-oriented (not stream-oriented), unreliable (not guaranteed delivery) protocol: like UDP, instead of like TCP.
I expect that using Winsock for IPX is like using Winsock for UDP, except using SOCKADDR_IPX etc.
Do you think, tak it is realistic idea?
If you'll need to reverse-engineer the contents of the packets, using only a packet sniffer, then I expect that will be difficult.
Related
I am new to Wireshark and capturing packets and all Stuff. Let me get it to the straight.
I have a hardware which outputs its data over Ethernet using a UDP Broadcast. I Can directly plug a Ethernet Cable to a In-line RJ-45 Coupler (attached to the hardware) and my PC Running Wireshark.
REQUIREMENTS : I need to Capture RAW Data which my hardware is broadcasting so that it can be given to other team so as to know the format in which it is providing for further post processing.
What I Did : Initially , I connected the Ethernet Cable from my home and Started capturing the packets which didn't make any sense to me.
Can you please point out if I am going in correct direction ? Sorry if its a very basic question, but raw data from the hardware is important for my further tasks....
As far as any software can understand a wire you will always get a packet. Between you (in front of a computer) and the cable in the in the RJ-45 jack sits a NIC (network interface controller, i.e. your network card).
Your Ethernet NIC will read the current on the cable (in manchester encoding for ethernet) and synchronize itself to any Ehternet traffic on that cable. What does "synchronizing" mane in there? In front of any Ehternet traffic come 64 alternate bits of 0s and 1s which are meant to synchronize the clocks on both communicating NICs. Without proper clock synchronization some data may be misinterpreted.
But why I am talking about clock synchronization? Because if you want the data as RAW as it is on the cable you will not get it. A NIC will never send any synchronization bit to the rest of the computer, therefore it is absolutely impossible to read exactly what is on the cable by using software.
On the other hand I find hard to believe you want the RAW data as RAW as that. After the synchronization bits come an Ethernet encapsulated packed. Yup, Ethernet uses packets. They're link layer packets (layer 2 in OSI).
And wireshark gives you exactly that (in most cases, see note at the end for two exceptions to this rule): every Ehternet packet that the NIC understands, manages to sync, and manages to read without collision is sent to the kernel and then read by wireshark. A cable has electrical interference and has no provision against collisions (it's just a piece of cooper!) therefore the NIC abstracts things like interferences and collisions.
I'll repeat it once more: After abstracting the synchronization bits, sender collisions (which turn the cable into one huge interference) and plain interferences; all that remains is a stream of packets, one after the other.
Extra Notes
NICs sometimes do ignore some Ethernet packets: packets that are not directed to their MAC. This can be changed by enabling promiscuous mode (available in most NICs). This is irrelevant for broadcast packets.
There are exception to the rule of wireshark getting all the traffic coming from the NIC:
If the traffic comes incredibly quick, wireshark may drop out of kernel schedule and not see some packets. It happens, nothign can be done about it.
If you listen on all interfaces (as opposed to selecting a single interface to listen at), wireshark will strip the Ethernet (or Wifi) headers. This is a wireshark hack needed to make output files uniform (and possible to be read by other applications).
TL;DR, wireshark output (pcap) is pretty much just the stream of packets that it got from the NIC, one after the other. That is as RAW as you can get with software.
I used to suport live555 client on android. it was supposed use rtp over udp/tcp. now I was asked to run it directly on udp/tcp in single program. Frankly, without rtcp/rtp, how could udp frames be reordered?
You would need to develop your own protocol. I'd suggest looking at how TFTP is implemented. Keep in mind however that with UDP datagrams, there are no guarantees; you will be responsible for ensuring out of order data is discarded and that lost/undelivered datagrams are handled/tolerated by your protocol.
I want to develop a program in c using pjsip for peer to peer file transfer. As pjsip uses ice and in ICE UDP is used, so do I need to handle the packet delivery assurance.
And as I would be sending the file by breaking it into several parts and them re assemble all the parts at the receiver's end, so do I have to maintain the sequence of the packets or can i assume that packets are delivered in the correct sequence??
With UDP you can neither assume that packets are delivered in order nor that they are delivered exactly once nor that they are delivered at all! So you need to come up with a protocol that does a lot of things which normally TCP would take care of. It has to reassemble the original data stream and handle the things I listed above.
Additionally, with UDP you can have the problem that you cause congestion. TCP can avoid that with its congestion avoidance algorithms, with UDP you can easily send packets too fast causing them to drop at the overloaded router.
All these are non trivial problems to solve so I suggest you read up on the topic. I'd start with a good book about TCP.
Does anyone know how to create a raw socket to a USB device? Like you can create raw sockets to ethernet devices, I would like to send/receive arbitrary data to a USB device.
Depends on the platform - you need a low level USB library.
Either http://sourceforge.net/projects/libusb/ or http://sourceforge.net/projects/libusb-win32/ is a good place to start
ps. It isn't a socket as such, sockets are specific to networks
You can write to the EndPoint using a Raw Socket but a certain protocol needs to be followed for the device to physically accept and reply to commands.
Depending on how the protocol is written you may be able to use a a RawSocket and some Usb sniffer to replay the data to the EndPoint but most devices employ a Timestamp and handshake process which needs to be performed dynamically for each connection and usually involves querying the device state and using the information to complete the handshake along with other information depending on the protocol of the device in question.
I have an application that is sending some UDP packets using multicast. I looked at the network traffic and there seems to be a lot of ancillary packets related to using multicast. I don't totally understand it, but does multicast by nature result in MORE network traffic. If so how can I throttle this down?
x
Other than the Multicast group join/remove messages, there are no ancillary messages created from you sending multicast data.
However, NIC's, routers, switches, printers, etc. all usually send some kind of multicast traffic, which is probably what you are seeing if you record the traffic.
In short, you need the networking equipment that forwards traffic between the client nodes to take care of this. Those vary depending on the network topology but would normally be:
Ethernet switches
IP routers.
Switch / router (implements functionality of a switch & router)
There are multicast control protocols such as IGMP but of course the source nodes and/or intermediate nodes (e.g. switches) must comply to these control protocols.
And YES multicast result in more network traffic : this is why plain Ethernet hubbing is practically extinct and additions to IEEE Ethernet such as VLANs are prevalent nowadays.
This is probably best addressed on some other sites (maybe this SO-style site PacketDrop).
LLC packets means you probably have sub-netting on your local segment, usually this doesn't mean extra packets though. You should change the network to a full class C if you want to remove LLC. On regular packets LLC or SNAP adds a 8-byte header.
http://ckp.made-it.com/ieee8022.html