generally, we can send byte in C or C++ socket program, so I want to know can i do this in Ruby?
Yes, the Ruby standard library has general support for socket programming; specifically, see the Socket.tcp method for connecting to a host and sending a byte. For example:
require 'socket'
Socket.tcp('127.0.0.1', 9999) do |sock|
sock.send(255.chr, 0) # Send the byte 0xff.
sock.recv(1) # Read a byte from the remote host.
end # Socket is closed upon exiting the block.
If you are looking to do something like. Open a connection, and send some data constructed in bits and bytes via it. You can do that in ruby.
Take a look at this source file from a ruby gem called APNS as a example of how to do it. In the given file, they are sending a push notification(s) through a socket which connects to Apple's APNS.
Ruby has a Socket library, plus Net libraries for higher level communications.
The online version of Programming Ruby has an overview of the network and web libraries.
They all have sample code
Related
How do I close tcp v4 and tcp v6 connections on Windows? I don't want to kill the entire process that has the open connection as this obviously will kick everyone else off that process. I need to do this from a separate process, and so will not have access to socket handles, etc. I am using Windows API to get tcp table, etc. so I know which connections are active.
One way might be to enumerate all open handles on the system, or at least the open handles of a given target process, until you find the SOCKET handle you are interested in (see HOWTO: Enumerate handles, Socket Handles, and C++ Get Handle of Open Sockets of a Program - though I'm not sure how you would be able to retrieve the IP/Port pairs of a SOCKET to compare to the active connection you are interested in, without injecting remote getsockname()/getpeername() calls into the owning process of the SOCKET).
Once you have found the SOCKET handle you want, you can then close it by using DuplicateHandle() with the DUPLICATE_CLOSE_SOURCE flag 1.
1: This is how the "Close Handle" feature in Process Explorer works.
Since I'm using C#, I cannot PInvoke SetTcpEntry, even as administrator with an app.manifest file, it always sends a 317 error. So I created a C++ .exe to close a comma separated list of ipv4 addresses on the command line using SetTcpEntry, works fine even without an app.manifest file. That solves kicking ipv4 connections.
I tried using the get handles approach with NtQuerySystemInformation but never could get it working quite right, and it is a private mostly undocumented API and seems unsafe to use.
So, for ipv6, I am using windivert and injecting RST flag to ipv6 packets with certain ip addresses. It is as simple as setting the RST flag of an incoming packet before sending it on through with windivert. The downside is, if the client never sends another packet, the ipv6 socket still stays open indefinitely.
Perhaps someday Microsoft will add a SetTcpEntry6 function, but until then this appears to be the only realistic way.
UPDATE 2022-05-01, found this gem at https://www.x86matthew.com/view_post?id=settcpentry6
I would like to connect to a WebSocket via Julia. I attempted to get an echo response from wss://echo.websocket.org, but it does not seem to respond as I would have expected it to. Interestingly, it does seem to connect, though, whereas an invalid address will not.
julia> client = connect("echo.websocket.org", 443)
TCPSocket(open, 0 bytes waiting)
julia> println(client, "Hello, world!")
julia> readline(client)
""
Is it possible to accomplish this?
There is now a specific library https://github.com/JuliaWeb/WebSockets.jl. Examples of how to use it are provided in examples/chat.jl and examples/chat-client.html.
Web socket clients cannot be implemented by opening a socket and reading and writing directly to it. There is a reasonably complicated protocol that needs to be implemented. Further, a websocket client is meant to receive push request, and hence needs some way to handle them asynchronously.
There is a websocket client library implemented in Julia: https://github.com/dandeliondeathray/DandelionWebSockets.jl
To install it, do: Pkg.clone("https://github.com/dandeliondeathray/DandelionWebSockets.jl")
To use it involves defining event handlers for network events. Please see here for an example using echo: https://github.com/dandeliondeathray/DandelionWebSockets.jl/blob/b23307f360ef0b62e3064c6b1484599eb660f63f/examples/echo.jl
I'm trying to use Pcap.Net to open a tcp connection.
I'm sending following package:
The server is responding with:
After this, Windows on its own sends the reset packet:
Why is this happening, and how do I block this behavior?
I'm doing this on Windows 7
As Mr Harris says, you can use WinDivert to do what you want. E.g. to just do the TCP handshake, you can write something like the following:
// TCP handshake using WinDivert:
HANDLE handle = DivertOpen("inbound && tcp.SrcPort == 80 && tcp.Syn && tcp.Ack", 0, 0, 0);
DivertSend(handle, synPacket, sizeof(synPacket), dstAddr, NULL);
...
DivertRecv(handle, synAckPacket, sizeof(synAckPacket), &srcAddr, &length);
...
DivertSend(handle, ackPacket, sizeof(ackPacket), dstAddr, NULL);
...
The DivertRecv() function redirects the server response into user space before it is handled by the Windows TCP/IP stack. So no pesky TCP RST will be generated. DivertSend() injects packets.
This is the main differences between WinDivert and WinPCAP. The latter is merely a packet sniffer, whereas the former can intercept/filter/block traffic.
WinDivert is written in C so you'd need to write your own .NET wrapper.
(usual disclosure: WinDivert is my project).
Essentially, the problem is that scapy runs in user space, and the windows kernel will receive the SYN-ACK first. Your windows kernel will send a TCP RST because it won't have a socket open on the port number in question, before you have a chance to do anything with scapy.
The typical solution (in linux) is to firewall your kernel from receiving an RST packet on that TCP port (12456) while you are running the script... the problem is that I don't think Windows firewall allows you to be this granular (i.e. looking at TCP flags) for packet drops.
Perhaps the easiest solution is to do this under a linux VM and use iptables to implement the RST drops.
Either by using Boring Old Winsock to make a TCP connection to the server, rather than constructing your own TCP-over-IP-over-Ethernet packets and sending them to a server, or by somehow convincing the Windows Internet protocol stack to ignore the SYN+ACK (and all subsequent packets) you get from the server, so that it doesn't see the SYN+ACK from the server, notice that no process has tried to set up a TCP connection from 192.168.1.3:12456 to 192.168.1.1:80 using the standard in-kernel networking stack (i.e., nobody's tried to set it up using Boring Old Winsock), and send back an RST to tell the server that there's nobody listening at port 12456 on the machine.
You might be able to do the latter using WinDivert. It does not itself appear to have a .NET wrapper, so you might have to look for one if you're going to use .NET rather than Boring Old Unmanaged C or Boring Old Unmanaged C++.
Is it possible to track XWindow protocol with a tool? I thought wireshark would be a good framework to host such an idea but there seems no support. What should be done to achieve this goal?
Wireshark does have the ability to dissect the X-Window protocol.
However: You first have to be able to capture the actual X-Window traffic between an X-client (app) and an X-Server before Wireshark can dissect it.
X-Windows traffic between an app (X-Windows client) and an X-Windows Server both running on your local machine probably uses "Unix Domain sockets" to do direct interprocess communication (IPC) between the client and the server. There's no underlying network protocol used and thus the traffic is (AFAIK) not capturable for dissection by Wireshark).
It's been a while since I've dealt with X but I think basically what is needed is that an X-Server be running on a box such that the server is listening for (and willing to accept) network connections. If an Xclient app on a remote node (or local node ?) then connects to the XServer over the network, you will then be able to capture that traffic for dissection by Wireshark.
X is complicated; If you're not familiar with the details of running X, you'll need to do some reading or ask for additional info. I've long since blanked out details related to X.
It is possible in principle to capture X-Window protocol that goes through Unix socket using strace. Then it is possible to wrap this packet for Wireshark using text2pcap.
Example:
capture X-window protocol frames that goes to X-server with pid 1998 on unix socket with file descriptor 41:
bash$ sudo strace -e trace=read,write -e read=41 -p 1998 2>&1 | grep '^[ ]|' >/tmp/xdata.log
prepare the captured data for wireshark:
bash$ text2pcap -T 1234,6000 /tmp/xdata.log /tmp/xdata.dump
Now one can use wireshark on /tmp/xdata.dump.
Back in the '80s, there was an open source Xwindow proxy program that would be placed between the Server and the client. It was written in 'C' and easily modifiable to count types of messages, or volume of data passing in each direction. It also recognized malformed Xprotocol that would result when folks used the wrong functions in interrupt handlers.
I can't remember the name, but maybe searching on "Xwindow proxy" might help...
I'm not sure what the XWindow protocol is, but you could make a Lua Dissector for Wireshark:
http://wiki.wireshark.org/Lua
I want to capture packets whoes has a special target ip, then forward these packets by UDP. Does Ruby can do this ? thanks
Packet, you mean? If you want see packets in userspace, not kernel-level then you can use several ways.
libpcap: libpcap is packet capture library used in tcpdump/wireshark
libipq: iptables packet queueing library. http://rubyipq.rubyforge.org/
for libipq, there is also ruby binding but it doesn't seems to be in activated.
Actually libipq is deprecated by libnetfilter_queue
You can make ruby binding of libnetfilter_queue.