I'm completely new to net programming and can't solve this issue
I have a server (some kind of LPT port to TCP/IP proxy) that automatically tries to establish connection at random interval. I need to listen on specific port and communicate with server. Thats the client. It works fine with perl tcp server.. But in this case it waits.... nothing happens
#!/usr/bin/perl -w
use IO::Socket;
my $sock = new IO::Socket::INET(
LocalHost => '192.168.1.1',
LocalPort => '7000',
Proto => 'tcp',
Listen => 1,
Reuse => 1,
);
die "Could not create socket: $!\n" unless $sock;
my $new_sock = $sock->accept();
while (<$new_sock>) {
print $_;
}
close($sock);
It works OK with my simple tcp server, but with this 'black-box' - nope
On client machine there are two connection:
tcp 0 0 192.168.1.1:7000 0.0.0.0:* LISTEN
tcp 0 0 192.168.1.1:7000 192.168.1.2:33822 ESTABLISHED
But if I try with
nc -l 192.168.1.1 7000
It works like a charm, data is flowing. And only one connection is present (like the second one)
tcpdump fragment of one symbol transmission captured on client. Seems to be OK
21:42:00.242172 IP (tos 0x0, ttl 64, id 30448, offset 0, flags [DF], proto TCP (6), length 53)
192.168.1.2.33837 > 192.168.1.1.7000: Flags [P.], cksum 0x5646 (correct), seq 3592562130:3592562131, ack 1351632513, win 92, options [nop,nop,TS val 140364552 ecr 92554083], length 1
I don't know what I'm doing wrong... More complicated examples are don't working for me as I don't know how to debug them...
<$new_sock>, short for readline($new_sock), only returns after a complete line is received, which is to say when newline is received.
sysread will return as soon as data is available, so you could use that.
my $rv = sysread($new_sock, my $buf, 64*1024);
Alternatively, since the lines you receive end with carriage return, you could communicate this to Perl.
$/ = "\r";
Related
I have packets coming from a specific device directly connected to my machine. When I do a tcpdump -i eno3 -n -n, I can see the packets:
23:58:22.831239 IP 192.168.0.3.6516 > 255.255.255.255.6516: UDP, length 130
eno3 is configured as 192.168.0.10/24
When I set the socket the typical way:
gOptions.sockfd = socket(AF_INET, SOCK_DGRAM, 0);
memset((void *)&gOptions.servaddr, 0, sizeof(struct sockaddr_in));
gOptions.servaddr.sin_family = AF_INET;
inet_pton(AF_INET, gOptions.sourceIP, &(gOptions.servaddr.sin_addr));
gOptions.servaddr.sin_port = htons(gOptions.udpPort);
bind(gOptions.sockfd, (struct sockaddr *)&gOptions.servaddr, sizeof(struct sockaddr_in));
And I use the sourceIP of "255.255.255.255" on port "6516" - it connects and reads.
What I want to do, however, is bind such that I am limiting my connection from the source IP - "192.168.0.3". I have figured out how to connect on the device using either device name ("eno3") of the iface of that device ("192.168.0.10") - but that doesn't help as I may have multiple devices connected to "192.168.0.10" that blab on that port, but I only want the packets from 192.168.0.3 for port 6516.
I thought s_addr - part of sin.addr - was the source IP... but it is not.
You can't bind() to a remote IP/port, only to a local IP/port. So, for what you have described, you need to bind() to the IP/port where the packets are being sent to (192.168.0.10:6516).
Now, you have two options to choose from. You can either:
use recvfrom() to receive packets, using its src_addr parameter to be given each sender's IP/port, and then you can discard packets that were not sent from the desired sender (192.168.0.3:6516).
or, use connect() to statically assign the desired sender's IP/port (192.168.0.3:6516), and then you can use recv() (not recvfrom()) to receive packets from only that sender.
Can I detect whether a client application uses an UDP-socket or a connected UDP-socket?
If yes, how? If no, why?
As I said in my comment above, code call connect on a UDP socket. That enforces only traffic to/from the connection address is allowed (and all other packets get dropped) and allows you to use send instead of sendto, but the traffic is still UDP.
But you can use the netstat command from the command line to see if the datagram socket has a remote address association:
For example, imagine if the code did this:
// create a datagram socket that listens on port 12345
sock = socket(AF_INET, SOCK_DGRAM, 0);
port = 12345;
addrLocal.sin_family = AF_INET;
addrLocal.sin_port = htons(port);
result = bind(sock, (sockaddr*)&addrLocal, sizeof(addrLocal));
// associate the socket only with packets arriving from 1.2.3.4:6666
addrRemote.sin_family = AF_INET;
addrRemote.sin_port = htons(6666);
addrRemote.sin_addr.s_addr = ipaddress; // e.g. "1.2.3.4"
result = connect(sock, (sockaddr*)&addrRemote, sizeof(addrRemote));
A corresponding netstat -a -u will reveal the following:
ubuntu#ip-10-0-0-15:~$ netstat -u -a
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
udp 0 0 ip-10-0-0-15:12345 1.2.3.4:6666 ESTABLISHED
The presence of a value that isn't *:* in the Foreign Address column for the UDP socket will reveal if the socket has connection address associated with it.
i am try to get a better understanding on Perl and was stumble about sockets. i am try to understand a "simple" example i found on xmodulo. I was expecting that like in the example the port will be 7777. But it seems like the port used for this socket communication is somewhere above 35000 and on every call of the client script the port is incremented by +1. Why ist the port different to the 7777 and why it is incrementing on every call?
the server example looks like this:
use IO::Socket::INET;
# auto-flush on socket
$| = 1;
# creating a listening socket
my $socket = new IO::Socket::INET (
LocalHost => '0.0.0.0',
LocalPort => '7777',
Proto => 'tcp',
Listen => 5,
Reuse => 1
);
die "cannot create socket $!\n" unless $socket;
print "server waiting for client connection on port 7777\n";
while(1)
{
# waiting for a new client connection
my $client_socket = $socket->accept();
# get information about a newly connected client
my $client_address = $client_socket->peerhost();
my $client_port = $client_socket->peerport();
print "connection from $client_address:$client_port\n";
# read up to 1024 characters from the connected client
my $data = "";
$client_socket->recv($data, 1024);
print "received data: $data\n";
# write response data to the connected client
$data = "ok";
$client_socket->send($data);
# notify client that response has been sent
shutdown($client_socket, 1);
}
$socket->close();
the client example is:
use IO::Socket::INET;
# auto-flush on socket
$| = 1;
# create a connecting socket
my $socket = new IO::Socket::INET (
PeerHost => '192.168.1.10',
PeerPort => '7777',
Proto => 'tcp',
);
die "cannot connect to the server $!\n" unless $socket;
print "connected to the server\n";
# data to send to a server
my $req = 'hello world';
my $size = $socket->send($req);
print "sent data of length $size\n";
# notify server that request has been sent
shutdown($socket, 1);
# receive a response of up to 1024 characters from server
my $response = "";
$socket->recv($response, 1024);
print "received response: $response\n";
$socket->close();
A connection isn't defined by
local address
peer address
port
It's defined by
local address
local port
peer address
peer port
For example,
>netstat /a
Active Connections
Proto Local Address Foreign Address State
...
TCP 10.0.0.2:34208 stackoverflow:http ESTABLISHED
TCP 10.0.0.2:34212 stackoverflow:http ESTABLISHED
TCP 10.0.0.2:34213 stackoverflow:http ESTABLISHED
TCP 10.0.0.2:34224 stackoverflow:http ESTABLISHED
TCP 10.0.0.2:34226 stackoverflow:http ESTABLISHED
TCP 10.0.0.2:34227 stackoverflow:http ESTABLISHED
...
You didn't specify a local port for the client, so the system picked an available one. That's the right thing to do. There's no reason to limit the client to one port. It can even cause problems.
For example, let's say your web browser tried to bind its sockets to port 80 (the port on which web servers listen). Your web browser would only be able to have one request pending at a time. That would be bad. You want to be able to create multiple connections to the same service. This allows you to request two different images at the same time, this allows you to load two pages in two different tabs at the same time, and so on. In the example above, my machine had six connections to stackoverflow.com's port 80, but that wouldn't have been possible if the web browser has bound the socket to port 80.
I'm using IO::Socket::SSL to create a websocket in Perl:
my $ssl_server = IO::Socket::SSL->new(
Listen => 10, # What does this parameter do?
LocalPort => 5000,
Proto => 'tcp',
SSL_cert_file => '/etc/webserver/ssl/server.crt',
SSL_key_file => '/etc/webserver/ssl/server.key',
) or die "failed to listen: $!";
my $server = Net::WebSocket::Server->new(
listen => $ssl_server,
...
I have not been able to figure out what the Listen parameter means or does from this:
http://search.cpan.org/~sullr/IO-Socket-SSL-1.997/lib/IO/Socket/SSL.pod
A simple summary of the purpose of this parameter would be appreciated.
The Listen parameter is not really used in IO::Socket::SSL. Similar to PeerAddr, PeerPort, Blocking, Timeout, Reuse, Proto, LocalPort etc it will just forward all options not starting with SSL_ to the underlying socket class (i.e. IO::Socket::IP, IO::Socket::INET6 or IO::Socket::INET, depending on what you have installed).
But, it will look at this parameter to get a useful default setting for the SSL_server option, so you don't have to set both Listen (for TCP) and SSL_server (for SSL).
It tells IO::Socket::SSL that the socket is a server socket. I believe it may also set the allowed length of the queue of pending connections.
I'm working with tcl script under ubuntu 12.04, and I'm facing some problem when I try to configure a multicast socket. What I'm trying to do is to forward traffic from some socket to a multicast one, but I don't know why although the multicast socket is created well,apparently; it isn't bound to the multicast group I want to.
This is the script I'm using
#!/bin/sh
# test.tcl \
exec tclsh "$0" ${1+"$#"}
package require udp
set multicastPort "50003"
proc connector {unicastIP multicastIP port {protocol tcp}} {
if { [string equal $protocol "tcp"] } {
socket -server serverTCP -myaddr $unicastIP $port
puts "tcp"
} elseif {[string equal $protocol "udp" ] } {
serverUDP $unicastIP $multicastIP $port
puts "udp"
}
}
proc serverUDP {unicastIP multicastIP port} {
global multicastPort
set socketUDP [udp_open $port]
puts " $unicastIP"
fconfigure $socketUDP -blocking false -translation binary -buffering none -remote [list $unicastIP $port]
#fileevent $socketUDP readable [list gettingData $socketUDP]
set multicastSocket [udp_open $multicastPort]
udp_conf $multicastSocket -ttl 4
fconfigure $multicastSocket -blocking false -translation binary -buffering none -mcastadd $multicastIP -remote [list $multicastIP $port]
fileevent $socketUDP readable [list forwarding $socketUDP $multicastSocket ]
#puts $socketUDP "hello!"
#flush $socketUDP
}
proc forwarding {socketSrc socketDst} {
set data [read -nonewline $socketSrc]
puts "Read data-> $data"
puts -nonewline $socketDst $data
puts "Written data-> [read -nonewline $socketDst]"
}
connector 127.0.0.1 224.0.1.1 50000 udp
vwait forever
However if I run the script and check out the ports in my system, the multicast port is not assigned the proper multicast IP as you can see
~$ netstat -ptnlu
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 0.0.0.0:50000 0.0.0.0:* 3334/tclsh
udp 0 0 0.0.0.0:50003 0.0.0.0:* 3334/tclsh
Could anyone tell me the reason?
THanks in advance,
Regards!
AFAIK, that is OK. I have a multicast daemon in production using Tcl and its udp package, and netstat and ss tools also show me the socket as listening on the wildcard address.
"The trick" here, I suppose, is that multicasting is one level up the stack: joining a multicast group is not merely opening a socket or an endpoint on the group address but rather sending a very real IGMP "join" message to the local transport segment (Ethernet, in most deployments) and further communicating with the nearby IGMP routers (again, on Ethernet, they're mostly switches).
So, in your case, just fire up tcpdump and see what it dumps when you start your program. A useful call to tcpdump looks something like this:
tcpdump -i eth0 -n 'igmp and host 224.0.1.1'
To observe UDP traffic exchanges use
tcpdump -i eth0 -n 'udp and host 224.0.1.1 and port 50000'