I found that Internet Protocol (IP) version numbers are published by IANA. It refers to the following table.
https://www.iana.org/assignments/version-numbers/version-numbers.xhtml
Decimal
Keyword
Version
Reference
0-1
Reserved
Jon_Postel, RFC4928
2-3
Unassigned
Jon_Postel
4
IP
Internet Protocol
RFC791, Jon_Postel
5
Reserved (Historic)
RFC1819, SC589H
6
IPv6
Internet Protocol version 6
RFC8200
7
Reserved (Historic)
RFC1475, RFC6814
8
Reserved (Historic)
RFC1621, SC589H
9
Reserved (Historic)
RFC1347, SC589H
10-14
Unassigned
Jon_Postel
15
Reserved
Jon_Postel
Looking carefully, I found that IP version 15 was reserved by Jon Postel. I already know the uses of the other versions, but I have never seen or heard of IP Version 15. Why is IPv15 reserved? What is its purpose?
Related
When attempting to connect to the Binance REST API from a Windows 11 computer, I got the following error:
ccxt.base.errors.ExchangeError: binanceus {"code":-71012,"msg":"IPv6 not supported"}
In this particular example I am using the ccxt Python library, but I assume the problem exists for any HTTP connection / library since the error comes from Binance. Here's sample code that replicates the issue on Windows 11 (works fine on a Linux machine):
import ccxt
exchange = ccxt.binanceus({'apiKey': '<your_key>', 'secret': '<your_secret>'})
print(exchange.fetch_balance())
I speculate that this is happening because by default in Windows 11 IPv6 has a higher priority than IPv4:
> netsh interface ipv6 show prefixpolicies
Querying active state...
Precedence Label Prefix
---------- ----- --------------------------------
50 0 ::1/128
40 1 ::/0
35 4 ::ffff:0:0/96
30 2 2002::/16
5 5 2001::/32
3 13 fc00::/7
1 11 fec0::/10
1 12 3ffe::/16
1 3 ::/96
I suppose one solution is to change this priority so IPv4 is used by default, but I don't want to do this, and I also prefer the code to work everywhere.
Under the hood, the ccxt library uses the Python requests library, and allows the user to construct a custom Session object.
I came up with the following hack/workaround which works for me
Is there a cleaner/better/more robust way to achieve the same thing?
import ccxt
import requests
from requests_toolbelt.adapters import source
import socket
def get_ipv4_session():
local_ipv4 = socket.gethostbyname(socket.gethostname())
src = source.SourceAddressAdapter(local_ipv4)
session = requests.Session()
session.mount("https://", src)
return session
exchange = ccxt.binanceus({
'apiKey': '<your key>',
'secret': '<your secret>',
'session': get_ipv4_session()
})
print(exchange.fetch_balance())
I read the answers here as well but they seem more complicated: Force requests to use IPv4 / IPv6
We are a group of uni students and we're currently developing a project involving the creation of a private tor network.
So far we have created 2 server authorities successfully and we want to create a middle node to check if the consensus can be generated, but we have a problem that we cannot solve and we seem to not find any documentation about:
Nov 21 18:17:34.000 [warn] Bad v3 identity digest 'v3ident=8ExA7smGhHOiDwEttS04pkINWRh72YBMJB7XOMaF7ww' on DirAuthority line
Nov 21 18:17:34.000 [warn] Bad v3 identity digest 'v3ident=3i+SLxtN6rKnEjLVBLy23BrX9e9YrqrMKdFYSaUShGc' on DirAuthority line
those 2 lines are from the middle node's log file, and refer to the two identity servers that we have specified in the torrc file of the middle node, the mentioned file is:
UseDefaultFallbackDirs 0
DirAuthority alejandro orport=6969 v3ident=8ExA7smGhHOiDwEttS04pkINWRh72YBMJB7XOMaF7ww 172.31.22.112:9050 C71F 48D4 36BC E2BD FD74 521A F6DF F76F 1805 CF6E
DirAuthority marti orport=6969 v3ident=3i+SLxtN6rKnEjLVBLy23BrX9e9YrqrMKdFYSaUShGc 172.31.25.34:9050 23D2 7887 9F7C E57C 6ABC 60B7 6F9F F662 AF4F 5425
DirAllowPrivateAddresses 1
TestingTorNetwork 1
ExtendAllowPrivateAddresses 1
EnforceDistinctSubnets 0
AssumeReachable 1
ORPort 172.31.20.85:6969
DirPort 172.31.20.85:9050
All the elements of the tor network are inside a private network and we have tested the connectivity between the machines.
I am analyzing some events against dns servers running unbound. In the course of this investigation I am running into traffic involving queries to the dns servers that are reported as having in some cases a source port between 1 and 1024. As far as my knowledge goes these are reserved for services so there should never be traffic originating / initiated from those to a server.
Since I also know this is a practice, not a law, that evolved over time, I know there is no technical limitation to put any number in the source port field of a packet. So my conclusion would be that these queries were generated by some tool in which the source port is filled with a random value (the frequency is about evenly divided over 0-65535, except for a peak around 32768) and that this is a deliberate attack.
Can someone confirm/deny the source port theory and vindicate my conclusion or declare me a total idiot and explain why?
Thanks in advance.
Edit 1: adding more precise info to settle some disputes below that arose due to my incomplete reporting.
It's definitely not a port scan. It was traffic arriving on port 53 UDP and unbound accepted it apparently as an (almost) valid dns query, while generating the following error messages for each packet:
notice: remote address is <ipaddress> port <sourceport>
notice: sendmsg failed: Invalid argument
$ cat raw_daemonlog.txt | egrep -c 'notice: remote address is'
256497
$ cat raw_daemonlog.txt | egrep 'notice: remote address is' | awk '{printf("%s\n",$NF)}' | sort -n | uniq -c > sourceportswithfrequency.txt
$ cat sourceportswithfrequency.txt | wc -l
56438
So 256497 messages, 56438 unique source ports used
$ cat sourceportswithfrequency.txt | head
5 4
3 5
5 6
So the lowest source port seen was 4 which was used 5 times
$ cat sourceportswithfrequency.txt | tail
8 65524
2 65525
14 65526
1 65527
2 65528
4 65529
3 65530
3 65531
3 65532
4 65534
So the highest source port seen was 65534 and it was used 4 times.
$ cat sourceportswithfrequency.txt | sort -n | tail -n 25
55 32786
58 35850
60 32781
61 32785
66 32788
68 32793
71 32784
73 32783
88 32780
90 32791
91 32778
116 2050
123 32779
125 37637
129 7077
138 32774
160 32777
160 57349
162 32776
169 32775
349 32772
361 32773
465 32769
798 32771
1833 32768
So the peak around 32768 is real.
My original question still stands: does this traffic pattern suggest an attack or is there an logical explanation for, for instance, the traffic with source ports < 1024?
As far as my knowledge goes these are reserved for services so there should never be traffic originating / initiated from those to a server.
It doesn't matter what the source port number is, as long as it's between 1 and 65,535. It's not like a source port of 53 means that there is a DNS server listening on the source machine.
The source port is just there to allow multiple connections / in-flight datagrams from one machine to another machine on the same destination port.
See also Wiki: Ephemeral port:
The Internet Assigned Numbers Authority (IANA) suggests the range 49152 to 65535 [...] for dynamic or private ports.[1]
That sounds like a port scan.
There are 65536 distinct and usable port numbers. (ibid.)
FYI: The TCP and UDP port 32768 is registered and used by IBM FileNet TMS.
I am trying to get a MRF24j40 on a BeagleBone Black to talk to an arduino with a mrf24j40. I have successfully communicated arduino to arduino but as of yet have not been able to receive the packets being sent out on the BBB.
The setup: I have GPIO_13 going to reset (pin 2), GPIO_14 going to wake (pin 3) and GPIO_29 going to interrupt (4). The 3.3v is going to vin on 10 and ground on pin 1. I am using SPI1 with the HDMI ports disabled. D0 is mapping to pin 7 (SDO) and D1 is mapping to pin 5 (SDI), P9.31 the clock goes to pin 6 and P9.28 goes to pin 8.
I have been able to log into the BBB via ssh. I then load the cape for the MRF24j40 using the echo to /sys/devices/bone_capemgr.9/slots
This appears to load the driver properly.
I have then been able to do:
iz listphy
iz: /lib/arm-linux-gnueabihf/libnl-genl-3.so.200: no version information available (required by iz)
iz: /lib/arm-linux-gnueabihf/libnl-3.so.200: no version information available (required by iz)
wpan-phy0 IEEE 802.15.4 PHY object
page: 0 channel: n/a
channels on page 0: 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
iz add wpan-
iz: /lib/arm-linux-gnueabihf/libnl-genl-3.so.200: no version information available (required by iz)
iz: /lib/arm-linux-gnueabihf/libnl-3.so.200: no version information available (required by iz)
Registered new device ('wpan0') on phy wpan-phy0
I decided to set all my addresses to simple things on the arduino side in case there is some sort of endian problem so the pan id is 0, the address of the sender is 0 and it sends the data to 1, thus I try to set the beaglebone to pan id 0, address 1 with a destination address of 0.
root#beaglebone:~# iz set wpan0 0 1 12
iz: /lib/arm-linux-gnueabihf/libnl-genl-3.so.200: no version information available (required by iz)
iz: /lib/arm-linux-gnueabihf/libnl-3.so.200: no version information available (required by iz)
ifconfig wpan0 up
Then I run
izchat 0 1 0
I get nothing on the BBB side even though the other side is constantly transmitting... and when I type into izchat, I do not receive anything on the other side.
Any help here would be appreciated... I just want to see some data before I start coding. Like I said, this has been tested arduino to arduino and does not have problems.
Virtualmin says:
Your Postfix version does not support per-domain outgoing IP addresses.
I have:
Name : postfix
Arch : x86_64
Epoch : 2
Version : 2.11.0
Release : 0.el6
Size : 13 M
Repo : installed
From repo : CentALT
Sender Dependent Outgoing IP Address
https://www.virtualmin.com/documentation/email/dependent
This behavior can be changed on systems running Postfix version 2.7 and Virtualmin 3.94 or later, so that outgoing email from a domain with a private IP address appears to come from that address. This can be useful for separating email from multiple domains as seen by other mail servers, or for setting up per-domain reverse DNS records.
requires Postfix 2.7 (seen on most modern Linux distributions), Virtualmin 3.93 and ideally Webmin 1.600. The steps to set it up are as follows..
Have not actually done this.