I want to intercept and tamper packets on Juniper MX500. How to intercept a packet? How does Junos filter a packet and drop it in the kernel? How does Junos implement its firewall? Is there a way to tamper a packet by writing program?
Related
I want to stream a video using RTSP via UDP. But I can't do it because my computer is behind NAT. The stream starts normally, but after about 10 seconds it closes the stream.
I've found why it happens. RTSP uses RTCP in order to control and check if streamer is still available. It sends some "reports" to a client and the client have to send a report back to the server that it is still alive. But the message from the server can't arrive to the client because RTCP usually work via UDP and due to NAT it can't arrive, because local UDP ports sent via RTSP to the server doesn't match ports mapped using NAT.
Of course, I can use TCP instead of UDP, it solves the problem, but streaming via TCP may be much slower. I want to use UDP if it's possible for me.
I've found out that Discord also sends and receives RTP packets, but via UDP, even when my computer is behind NAT. How it is possible? I use ffmpeg utility for streaming, how can I do it as well and use UDP?
Hope for your help!
There is actually an Internet draft which addresses this exact top: https://tools.ietf.org/id/draft-ietf-avt-app-rtp-keepalive-10.html
They list several approaches along with their recommendation for the preferred approach.
I want to design a system which reduces travel time of packet what is happening, in reality, am I send an SYN bit from the client side, this bit travel through the router then to server and server reply SYN+ACK which also travel through the router to the client.
So I just want something else like what if the client sends SYN to router, router then send this to server and copy this packet modify SYN to SYN+ACK and send back to client before server can send after server send this SYN+ACK to router, router just accept it(see it as the reply is coming) and discard it.
To achieve above goal, I design a setup in which I have one laptop which sends and receive packet from two ethernet interface and other one is desktop which acts as router(packets are coming and it only forward it to its destination) I set up the routing table from both side and enable the IP forwarding on desktop(which act as router).
All are working fine, on a laptop I have server and client program which send the packet and receive it but the problem is that I want to send the packets to from where it was coming (to source itself) so I modify the packet on routing side using Netfilter module, copy the entire skb(using skb_copy) and interchange its ip source and destination(I did this on NF_INET_PREROUTING) and also interchange the port number but the packet always goes to destination.
What other modification do I need to be done to send the packet to its source itself?
Before all, you have to deal here with some details.
First, on SYN-ACK packet, the server sends its sequence. So if in the router you modify the packet and send back to client, what will be your sequence? It's should be the same like the server will send and the server did not send anything yet.
Second, in the handshake there are several agreements like MSS, SACK enabled etc. So you can't to it on behalf of server.
About the question itself, you should do it in PRE_ROUTING, change the IP addresses and ports, and fix the checksum of both IP and TCP.
I'm needing to do some stress testing of an application I've written that takes packets from a mirrored port and processes them. I'd like to use Go to create a test harness that writes well-formatted, but otherwise random, HTTP packets on the wire, but I'm not sure how to do so without dialing a remote HTTP server before writing the packet.
Can someone point me in the direction of how to write raw data on the wire without needing to make a connection first? Is there a way in Go to treat a network interface as a generic I/O device and just write bytes to it?
I know that the X window system protocol was based over a network, and this is how clients communicate with the X server. Now Wayland seeks to remove this network reliance.
My question is, how are Wayland clients supposed to communicate with the compositor? What is the medium for the protocol messages?
https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Wire-Format
The protocol is sent over a UNIX domain stream socket
There is device connected to PC via 1Gbit Ethernet. WinXP/7
I want to capture data in the following way:
PC sends command to devices (initiate data acquisition)
Device is sending data to PC
User application waits for acquisition
Driver saves data in the memory
Device sends command to notify that it finished acquisition
Driver generates interrupt and user application starts reading data from driver
I have no idea how to implement that.
There is NIC driver. There is NDIS. Can user application communicate with NDIS?
Do i need to write additional driver to communicate with NDIS?
Your problem really has two parts:
How to send commands to the device
How to capture data sent from the device
The first problem has two possible solutions, depending on whether your device accepts commands encapsulated in IPv4/IPv6, or whether it requires some other low-level protocol. If the device accepts commands encapsulated in IPv4/IPv6, then just use the sockets API in your favorite programming language.
If the device requires its own non-IP protocol, then you need to add an NDIS protocol driver. There is a sample protocol driver that is included with the Windows Driver Kit; this driver essentially opens a channel that allows a usermode application to send any kind of packet. (This would be a security issue if it were deployed widely, which is why it's not a built-in feature of the operating system.) You may need to modify the protocol driver to selectively listen only for control messages from your device.
The second problem — packet capture — is already solved. You should be able to pull existing software off the shelf and integrate it in your solution. Microsoft Network Monitor has an API that you can use to easily start/stop packet capture, and iterate through the captured results. Alternatively, some people use WinPcap.