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].
Related
I am trying to get the caller address of the incoming requests to my tornado server using tornado RequestHandler class request.remote_ip variable as mentioned in the official doc: https://www.tornadoweb.org/en/stable/httputil.html#tornado.httputil.HTTPServerRequest.remote_ip
I am getting IPv4 address for most of the caller, but for one particular caller I am getting a IPv6 address.
Is it possible to get the IPv4 address of the caller? Is it something related to the requests being framed by the caller which provides only the IPv6 address.
This depends on how DNS lookup works. Let me illustrate:
Client types in your website's address in their browser.
Browser asks the operating system for the IP address of the domain.
Operating system makes DNS request to ISP's servers.
Since your server supports both IPv4 and IPv6, and the client's OS also supports both, the ISP sends back your server's IPv6 address.
The operating system gives the IPv6 address to the browser.
The browser makes the request to the IPv6 address.
The request is made over IPv6 protocol, so the client also has an IPv6 address.
As you can see, it's upto the ISP to decide which IP protocol should be used. So, if the client is sending a request over IPv6 protocol, they will not have an IPv4 address.
If you want to only support IPv4, you should turn off IPv6 for your server.
Check with your hosting provider or remove your server's AAAA record.
If the remote side connected via IPv6, that is all the information available – IPv4 is not involved in the connection at all. There is no general way to get "the" IPv4 address from the IPv6 address: The remote host may have no, 1, or many IPv4 addresses which may-or-may-not have the same reachability as the IPv6 address.
If you want only IPv4 addresses, do not allow IPv6 connections. Better yet, support both IPv4 and IPv6 in your application.
Recently I found that I was able to bind Apache on 127.0.0.73 without 127.0.0.73 to be present.
Only 127.0.0.1 is present as normal.
I also spoke with a friend and he said that is "normal" on Linux and probably on Windows and not works on MacOS, but he has no idea why.
I can do following:
[nmmm#zenbook nmmm]$ curl 127.10.0.123
curl: (7) Failed to connect to 127.10.0.123 port 80: Connection refused
and it shows that whole A class network is available.
How this works?
I do not see anything special in ifconfig and ip, except lo interface has no broadcast. Is that the key point?
According to https://en.wikipedia.org/wiki/Localhost
IPv4 network standards reserve the entire address block 127.0.0.0/8 (more than 16 million addresses) for loopback purposes.2 That means any packet sent to any of those addresses is looped back. The address 127.0.0.1 is the standard address for IPv4 loopback traffic; the rest are not supported by all operating systems. However they can be used to set up multiple server applications on the host, all listening on the same port number. The IPv6 standard assigns only a single address for loopback: ::1.
Or from https://www.rfc-editor.org/rfc/rfc3330
127.0.0.0/8 - This block is assigned for use as the Internet host
loopback address. A datagram sent by a higher level protocol to an
address anywhere within this block should loop back inside the host.
Even though you can't see anything from ifconfig or ip, you still can ping all the addresses in that 127.0.0.0/8 block.
I'm trying to send IPv6 packets with scapy. I don't really care what higher-level protocol is used, so I simply send:
send(IPv6(dst="2001:db9:1::4"))
I have a route toward that destination, running ip -6 route show I see:
2001:db9:1::4 dev vt0 metric 1024
If I send a ping request from the command line, I can see it in tcpdump in the destination device. But if I send the IPv6 packet with scapy, I get these messages, and I don't see anything in tcpdump:
WARNING: No route found for IPv6 destination 2001:db9:1::4 (no default route?)
WARNING: No route found for IPv6 destination 2001:db9:1::4 (no default route?)
WARNING: more No route found for IPv6 destination 2001:db9:1::4 (no default route?)
.
Sent 1 packets.
But it works if I use the link-local address of the destination device. I only get one warning message (similar to the first line in the messages above), and I see the packet in tcpdump.
Any idea why this happens, and how can I fix it?
The sending interface needs to have a global IPv6 address.
Packets with a global destination address must have a global source address as well, otherwise the packet won't be forwarded.
Which is the source IP address in tcp socket if bind is called on a multihomed client host? Client has two interfaces eth0(IP0) and eth1(IP1) and the client tcp socket is bound to IP0. After socket, bind, connect in client, it sends a packet to server.The destination IP isservIP. But servIP and IP0 are not in a same subnet(Maybe servIP and IP1 are). Which is the source IP in the packet sent to server? And what will getsockname return?
There are two separate issues here:
1) Which IP to bind on?
When calling bind() you have an option to specify and address to bind on or you can leave this decision to TCP/IP stack on your computer. You can pass a specific address in 'addr' parameter or leave it as INADDR_ANY. You can find more information how to do it in manual page of ip(7). If you call bind() providing the valid IP address and call to bind() succeeds, then datagrams sent using the binded socket will have their source address set to the value provided in call to bind().
2) How the packet is routed?
The way your packet is routed depend only on the destination address and not the source address. It can be that your source address will be the one from eth0 and it will go out through eht1. This is because the routing system in your OS is using destination based routing as opposed to source based routing. You can always see which adapter will be used by issuing "route" command in the console of your OS and comparing the output with the destination address
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).