According to RFC 4566 https://www.rfc-editor.org/rfc/rfc4566#page-22, the m= line in an sdp contains a port:
m=audio 49170 RTP/AVP 0
Aren't ports determined by ICE candidates already? These contain ports as well:
a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host
As RFC 5245 https://www.rfc-editor.org/rfc/rfc5245#page-9 states,
"ICE is an
extension to the offer/answer model, and works by including a
multiplicity of IP addresses and ports in SDP offers and answers,
which are then tested for connectivity by peer-to-peer connectivity
checks."
Would that mean the port specified in the m= line is obsolete?
When using libjingle to create a new sdp offer, it shows an IP address of 0.0.0.0, together with port 9 (which is the "discard" port). So it obviously does not see the port in the m= line as relevant:
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 9 102 0 8 106 105 13 127 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
Does anybody know?
IP and candidates in the m= line is a relict from pre-candidate eras, where fixed IPs and ports were used for communication.
At least with WebRTC, as specified in https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-jsep-15 on page 33,
"The port value is set to the port of the default ICE candidate for
this m= section, but given that no candidates have yet been
gathered, the "dummy" port value of 9 (Discard) MUST be used, as
indicated in [I-D.ietf-ice-trickle], Section 5.1.", and
"The m= line MUST be followed immediately by a "c=" line, as specified
in [RFC4566], Section 5.7. Again, as no candidates have yet been
gathered, the "c=" line must contain the "dummy" value "IN IP4
0.0.0.0", as defined in [I-D.ietf-ice-trickle], Section 5.1.",
it is in simple words specified, that the m= line contains a dummy IP and port, as long as no candidates have been gathered and no media flow is desired, and the IP and port of the default candidate thereafter.
Related
I am trying to write a port scanner in Python for Scapy to find out on which port a webserver is listening. The server does not use port 80 and port 443. The range to be scanned is from 5000 to 10000 (this is an assignment for university). I need to use Scapy for this, so no nmap and other is allowed.
The code I have written so far (it is an adaptation of this original work https://is.muni.cz/th/n9spk/dp.pdf):
target = "172.16.51.142"
ports = range(5000, 10000)
ip = IP(dst=target)
tcp = TCP(dport=ports , flags="S") # SYN flag
ans, unans = sr(ip/tcp) # send packets
for sent, rcvd in ans:
if rcvd.haslayer(TCP): # TCP packet
if rcvd.haslayer(TCP).flags & 2: # SYN/ACK flag
print (sent.dport) # open ports
The first part until the for-loop works as intended:
But when the for-loop starts, I get the following error:
I don't know how to fix this problem.
I have used the online documentation https://scapy.readthedocs.io/en/latest/usage.html#send-and-receive-packets-sr and https://scapy.readthedocs.io/en/latest/usage.html#tcp-port-scanning but could not find a solution.
rcvd.haslayer(TCP).flags isn't possible as haslayer returns a Boolean.
You're looking for
rcvd.getlayer(TCP).flags
I have added the following line in my hosts file: C:\Windows\System32\drivers\etc\hosts
127.0.0.1 firsthostfirsthostfirsthostfirsthostfirsthostfirsthostfirsthost
The above is working fine(length is 63), able to ping and the host is responding. But if I put the hostname as
127.0.0.1 firsthostfirsthostfirsthostfirsthostfirsthostfirsthostfirsthostf
(Here the length is 64.),a message is shown: "Ping request could not find host firsthostfirsthostfirsthostfirsthostfirsthostfirsthostfirsthostf. Please check the name and try again."
Please help me to understand the cause. Any reference link would be appreciated.
Thanks in advance.
RFC 1035 limits the length of a fully-qualified domain name (FQDN) to 255 characters, and each "label" - the portion between dots - to 63 characters.
Your first example works because it's a 63 character label. Your second example fails because it doesn't comply with the rules set out in RFC 1035.
I got a DNS internal query log file and I would like to do analysis on it, so onw record looks like this:
18-Jun-2017 04:00:10.139 client #XXXXXXXXXXXX ip-address#number (ip-address): view internal: query: ip-address IN AAAA + (ip-address in the format of ipv4)
I am really new to this so I tried to search on line but I couldn't find what does the "+" mean in the record, and as far as I understand, AAAA should represent the ipv6 ip format, why I got a following ipv4 address following it ?
Can some one explain it to me what does this record means or some links I could read myself ?
Many thanks !!
You're right AAAA (or the quad record) is for IPV6 addresses. The IPV6 addressing scheme allows for trailing or leading zeros to be omitted, so an IPV4 address of 192.169.1.1 may be represented as 00:00:00:00:C0:A8:01:01 which without the leading zeros is C0:A8:01:01 or 192.168.1.1 if your text editor converts Hex to Decimal.
I'm trying to find a way to reliably find the global IPv6 address of the local router. The command "ip -6 neigh show" doesn't display it. I have found the following works, so long as the router is using EUI-64 to generate a host address:
NET=$(ip -6 route|egrep "^[23]"|cut -d':' -f1-4)
EUI=$(ip -6 route|egrep "^default.*metric 1 "|cut -d':' -f3-6|cut -d' ' -f1)
ping6 $NET:$EUI -B -c 1 > /dev/null 2>&1
However this obviously doesn't work when EUI-64 isn't being used. Is there any other way I can find it?
There is no reliable way to determine this, as your local router doesn’t have to have a global IPv6 address at all. Best practice says it should, and the vast majority of routers out there will, but technically it’s possible that your router could only have link-local addresses on both interfaces and still route global prefixes. (Yes, I have done this before. And yes, it’s evil.)
Unless you manually added a default route pointing to a global address, you probably learned your default route via Router Advertisement which means the routing table and neighbour table (as you pointed out above) will contain a link-local address only.
However, if you perform a traceroute, the first hop is probably (key word: probably — it’s possible to spoof this stuff) your local router.
traceroute to 2600:: (2600::), 30 hops max, 80 byte packets
1 2001:db8:1::1 0.534 ms 0.510 ms 0.749 ms
2 2001:db8:2::1 32.494 ms 33.944 ms 35.406 ms
3 2600:: 36.935 ms 38.102 ms 39.860 ms
TL;DR it’s not possible to reliably determine this, so the short answer is “no”.
I used wireshark to collect data from some sites, and then used tcpdump to get it as a text file. For the project I'm working on, I want to count how many DNS resolutions are involved in accessing a particular website, and what the nature of the DNS responses was. The problem is I don't really understand the output from wireshark or how to interpret it to find what I'm looking for. For instance, here is a line:
21:08:05.454852 IP 10.0.0.2.57512 > ord08s09-in-f21.1e100.net.https:
Flags [.], seq 1:1419, ack 55, win 65535, options [nop,nop,TS val
1348891674 ecr 2473250009], length 1418
What do the different parts of this mean, and what will the data I'm looking for look like? I'm worried I might be using Wireshark incorrectly without knowing it.
I used wireshark to collect data from some sites, and then used tcpdump to get it as a text file.
Most people who use both tools use them for the opposite purposes. :-) I.e., they use tcpdump to capture traffic into a file and then read the file with Wireshark. If you're only using Wireshark to capture traffic, that's probably overkill - you can do the same thing with dumpcap or possibly even tcpdump.
The output you're showing is text output, so, if you "used tcpdump to get it as a text file", it's output from tcpdump, not from Wireshark; text output from Wireshark would look different. If you "used wireshark to collect data from some sites, and then used tcpdump to get it as a text file", the output from Wireshark is either a pcap file or a pcap-ng file, which is a binary file, and is completely uninterpreted raw data. The interpretation of the data in your example is being done by tcpdump, not Wireshark.
What the output is saying is:
"21:08:05.454852": the packet arrived at 21:08:05 and a fraction of a second, local time.
"IP": the packet is an IPv4 packet.
"10.0.0.2.57512 > ord08s09-in-f21.1e100.net.https": the packet is from IP address 10.0.0.2, port 57512, to the IP address whose for which the host name is "ord08s09-in-f21.1e100.net", and the port for "https", which is port 443.
See the tcpdump man page, and a description of TCP, for details on the rest of the line.
The key point here is that this is NOT DNS traffic! It's probably "HTTP-over-SSL", or "https", traffic.
In tcpdump, DNS traffic would look like
11:06:25.247272 IP 10.0.1.3.50953 > 10.0.1.1.domain: 7088+ A? www.kernel.org. (32)
11:06:25.282723 IP 10.0.1.1.domain > 10.0.1.3.50953: 7088 3/0/0 CNAME pub.us.kernel.org., A 149.20.4.69, A 198.145.20.140 (85)
or
11:06:30.622744 IP 10.0.1.3.62767 > 10.0.1.1.domain: 2439+ A? e3191.c.akamaiedge.net.0.1.cn.akamaiedge.net. (62)
11:06:30.639279 IP 10.0.1.1.domain > 10.0.1.3.62767: 2439 1/0/0 A 184.85.109.15 (78)
"A?" means that a query is being done for an A record; "CNAME" means that a CNAME record is being returned (i.e., "www.kernel.org" is an alias for "pub.us.kernel.org", and "A" means that an A record is being returned, giving an IPv4 address.
In Wireshark or TShark, it would look like:
12.316361 10.0.1.3 -> 10.0.1.1 DNS Standard query 0xc2fa A 1.courier-sandbox-push-apple.com.akadns.net
12.332894 10.0.1.1 -> 10.0.1.3 DNS Standard query response 0xc2fa A 17.149.34.59 A 17.149.34.61 A 17.149.34.62 A 17.149.34.63 A 17.149.34.57
or
15.163941 10.0.1.3 -> 10.0.1.1 DNS Standard query 0x168c A www.gnu.org
15.176266 10.0.1.1 -> 10.0.1.3 DNS Standard query response 0x168c CNAME wildebeest.gnu.org A 208.118.235.148
If you're only trying to capture DNS packet, you should use a capture filter such as "port 53" or "port domain", so that non-DNS traffic will be discarded. That filter will work with Wireshark, TShark, or tcpdump (as they use the same libpcap code for packet capture).