Is there a way to send UDP packets through a SOCKS5 proxy in NodeJS?
Similarly, is it possible to bind a UDP socket to a specific localAddress?
The SOCKS5 protocol supports UDP connections, however most libraries for SOCKS5 only support TCP since UDP isn't very frequently used on the web (except for DNS). The protocol itself isn't very complicated, so it shouldn't be to hard to rewrite an existing library (maybe this one?) to suit your needs.
To send UDP packets from your client, you have to specify value 0x03 in field 2 of your client's connection request. See the fields of the client's connection request:
field 1: SOCKS version number, 1 byte (must be 0x05 for this version)
field 2: command code, 1 byte:
0x01 = establish a TCP/IP stream connection
0x02 = establish a TCP/IP port binding
0x03 = associate a UDP port
field 3: reserved, must be 0x00
field 4: address type, 1 byte:
0x01 = IPv4 address
0x03 = Domain name
0x04 = IPv6 address
field 5: destination address of
4 bytes for IPv4 address
1 byte of name length followed by the name for Domain name
16 bytes for IPv6 address
field 6: port number in a network byte order, 2 bytes
For instance, the line of code in the referenced library would need change from 0x01 to 0x03:
buffer.push(0x01); // Command code: establish a TCP/IP stream connection
I don't know how you could bind to specific local address.
According to http://www.ietf.org/rfc/rfc1928.txt and http://en.wikipedia.org/wiki/SOCKS#SOCKS5, UDP should really be supported in Socks5.
However, if you look at some SOCKS5 implementation, you'll see that UDP is not supported in the implementation. For example: https://gist.github.com/telamon/1127459 or https://gist.github.com/robertpitt/3203203 (.
So, the short answer is NO, unless you'll find library that supports it (UDP binding).
Related
I have a piece of equipment that sends a stream of unicast UDP packets to a network interface on my Linux machine. I'm receiving them in my application using a normal UDP socket bound to INADDR_ANY and the expected destination port. The destination port and IP address in the datagrams are correct, but the source IP address in the IPv4 header is populated as 0.0.0.0 by the device.
I've found that when the source address is 0.0.0.0, my calls to recv() on my socket never return any packets; they appear to be getting filtered somewhere in the OS UDP processing. I confirmed via tcpdump that the packets are being received (and this is what told me the source address was all zeros):
11:32:41.239706 50:12:34:80:07:2d > 09:22:45:ab:e8:90, ethertype IPv4 (0x0800), length 4194: 0.0.0.0.84 > 192.168.137.144.10000: UDP, length 4152
Is there a way for me to configure my UDP socket so that the datagrams with this source address are not discarded? I have rp_filter configured to disable reverse-path filtering on all of my network interfaces already.
I have a typical requirement, I want to have a converter module, that can convert UDP packet to TCP packet.
And I need to do it before the packet can be processed in IP layer.
I will explain this complete scenario using an example
Lets say we have 3 machines A, B and C.
A sent an UDP packet
B received UDP packet
At B, when packet is being given to IP layer (from Link / MAC / Ethernet layer) , I want to get hold of packet. I want to delete the UDP and IP header in packet. I want to add TCP and IP header (assuming C is the destination host).
Now from B machine, packet is sent to C machine
Can somebody help me how this can be done.
I am using linux machines.
Though libpcap can be one of the option (from wireshark), but it is not suitable for me because of performance reasons.
I want a very light weight solution for this problem.
Can't be done. TCP is a stateful, reliable, connection-oriented byte-stream protocol. UDP is a stateless, unreliable, unconnected packet protocol.
The best you can do is, on machine B, open a new socket/TCP connection to C, accept socket/UDP packets from A, and write the contents of those packets to the TCP stream. Data flowing the other direction is a bit more difficult because you have to create UDP packets to A no larger than the maximum UDP packet size supported by your systems.
You can not do it directly but if you will use a UDP VPN than you can do it very easily.
Just connect you system/PC with UDP VPN network and it work as you are want.
check below my image for more information, i am also using same.
I am using raw socket to capture network packets. I captured Ethernet header and then I accessed IP header and in IP header, there is a field of 'protocol'. I printed this field and compare with values present in /etc/protocols. I have received '0' value that means-
ip 0 IP #'internet protocol, pseudo protocol number'
That means IP header contains protocol that is also IP. What does that mean ?
According to Protocol Numbers this is the protocol IPv6 Hop-by-Hop Option [RFC2460].
I have TCP client and server sockets and I have set the socket option IP_TOS on both the client and server socket with different values(say Client dscp = 0x21 and Server Dscp = 0x38).
Now when I am trying to connect to the server the syn Packet contains dscp value 0x21 but the Syn ack packet from the server does not contain dscp 0x38 instead it is same as client i.e. 0x21.
Is this the correct behaviour??
Consider both server and client is linux Socket.
Yes it is the correct behaviour. Any ACK packet including a SYN/ACK belongs to the stream it is ACK-ing, so it obeys the sequencing, TOS, etc, of that stream.
I'm developing a tftp client and server and I want to dynamically select the udp payload size to boost transfer performance.
I have tested it with two linux machines ( one has a gigabit ethernet card, the other a fast ethernet one ). I changed the MTU of the gigabit card to 2048 bytes and left the other to 1500.
I have used setsockopt(sockfd, IPPROTO_IP, IP_MTU_DISCOVER, &optval, sizeof(optval)) to set the MTU_DISCOVER flag to IP_PMTUDISC_DO.
From what I have read this option should set the DF bit to one and so it should be possible to find the minimum MTU of the network ( the MTU of the host that has the lowest MTU ). However this thing only gives me an error when I send a packet which size is bigger than the MTU of the machine from which I'm sending packets.
Also the other machine ( the server in this case ) doesn't receive the oversized packets ( the server has a MTU of 1500 ). All the UDP packets are dropped, the only way is to send packets of 1472 bytes.
Why the hosts do this? From what I have read, if I send a packet larger than MTU, the ip layer should fragment it.
I fail to see the problem. You are setting the "don't fragment" bit, and you send a package smaller than the sending host's MTU, but larger than the receiving host's MTU. Of course nobody will fragment here (doing so would violate the DF bit). Instead, the sending host should get an ICMP message back.
Edit: IP specifies that an ICMP error message type 3 (destination unreachable) code 4 (Fragmentation Required but DF Bit Is Set) is sent to the originating host at the point where the fragmentation would have occurred. The TCP layer handles this on its own for PMTU discovery. On connection-less sockets, Linux reports the error in the socket's error queue if the IP_RECVERR option is activated; see ip(7).
That "DF bit" you're setting, stands for "Don't Fragment". The IP layer should not be expected to fragment packets when you've told it not to.
It is not correct to run hosts with different interface MTUs on the same subnet1.
This is a host/network misconfiguration, and IP path MTU discovery is not expected to work correctly in this situation.
If you wish to test your application's path MTU discovery, you will need to set up multiple subnets connected by a router2, with different MTUs. In this situation, the router is the device that will pick up the MTU mismatch, and send back an ICMP "Fragmentation Needed" error.
1. Well, technically, same broadcast domain.
2. The devices sold as "home routers" are really router/switches - they route between the WAN and the LAN, but switch between the ethernet ports on the LAN. This isn't sufficient to separate networks with different MTUs.