How exactly should I discover all nodes that do something useful in my network?
Most CoAP documentation I've seen talks about protocol when connection is already established, but how to know where the endpoints are?
I found OIC specification which says that discovery packets should be sent over IPv6 to multicast FF0X:0:0:0:0:0:0:158 (All OCF Nodes) port 5683 (UDP?). The packet should be "GET /oic/res" senddiscovery request. What is that senddiscovery?
The OIC spec also says CBOR encoding should be used for response, but doesn't describe what is the meaning of the returned data.
Related
In most of IoT platforms, MQTT is used as M2M communication, one of the reasons being lightweight.
Device ---N/W--> MQTT Broker ---> another device
The device communicates to MQTT Broker over TCP/IP, which means there would be a payload addition as part of the TCP/IP layer.
This is my start of confusion:
If MQTT runs over TCP/IP, then how come it's a lightweight protocol?
What are you comparing MQTT to?
The problem with your question is the starting premise to compare MQTT to the underlying TCP/IP that it's using as it's base transport.
Since MQTT runs on top of TCP/IP it's not a valid comparison, try comparing it to say HTTP (with it's HUGE header) which also runs over TCP/IP.
Setting up a MQTT connection and then subscribing to a topic is handled in a few bytes + the topic name and the connection is persisted. When a message is sent it again has a couple of bytes of head + topic and the payload.
By comparison HTTP requests start with the URL + a bunch request headers, the response includes a whole bunch more response headers (there can easily be 100s of bytes of headers as it's all encoded as text) before we get to the payload and in general the connection is closed after the payload.
If you add in TLS/SSL overheads of starting up a new connection for each payload HTTP get even worse.
I am trying to analyze probe response .pcap files of a network to deduce the security protocol (as in wpa, wpa2, wep, open network).
I realized that in some beacon .pcaps, there is a tag with the wpa information and in the following image for example, it says that the WPA version is 1, meaning the security protocol is WPA. But in other beacon .pcaps that tag doesn't appear and I'm guessing it is not always there because that tag is vendor specific.
Either way, I couldn't find this tag in any probe response .pcaps and couldn't figure out the security protocol from the RSN Information tag. For example I tried checking if AES is in the Pairwise Cipher Suite List (since it isn't used in WPA, but is used in WPA2), but it appears in both WPA and WPA2 networks. Is there a reliable way to do this with any captured probe response packet?
I have a great confusion about tshark.
What is the basic unit of the messages captured by tshark? Ip, tcp, or http?
I see TCP http or ssl and so on in the protocol column in wireshark.
These protocols are in different layer.
In addition, what is the tshark command to capturing the http message with tshark.
See the man page. To quote:
TShark is a network protocol analyzer. It lets you capture packet data from a live network, or read packets from a previously saved capture file
Packets are usually either TCP or UDP (you can find a list of protocols here), When wireshark states that it is HTTP or SSL, then it is based on introspection of the packet (Probably based on destination port).
I need a solution for NAT traversal to transmit RDP data across the internet. I came across the following tool and it's really amazing - pwnat.
I have tried it with the two different machines behind different router, but i am unable to make it work as explained in the above link. So is pwnat still working and if yes what could I have done wrong? It would be very helpful for me.
Note: I am using a Windows machine for testing and downloaded the Windows version from the following link:
http://www.sumitgupta.net/pwnat-windows-complied-version/
No.
I assume you know how it worked:
the server sent ICMP echo request packets to the fixed address(for example, 1.2.3.4) where no echo replies wouldn't be returned from, the client, pretending to be a hop on the Internet, sent an ICMP Time Exceeded packet to the server, expected the NAT in the front of the server to forward the ICMP time exceeded message to the server.
The picture above is from the homepage of pwnat, it's on the premise that client is not behind NAT and the original payload in time exceeded message is typically not checked by NAT implementations. If both client and server are behind NAT like this,
=========================================================================================
| CLIENT | <---> | NAT-C | <---> { internet } <---> | NAT-S | <---> | SERVER |
=========================================================================================
It rarely works nowadays mainly for 2 reasons below:
When the server sends ICMP echo request packets to the fixed address, according to RFC 3022, the identifier field in ICMP echo request header will be uniquely mapped to a query identifier of the registered IP address by NAT-S so that it can route future ICMP Echo Replies with the same query ID to the sender, so ICMP header in ICMP Query packets must be modified to replace the query ID and ICMP header checksum. RFC 3022 ICMP error packet modifications section:
In a NAPT setup, if the IP message embedded within ICMP happens to be
a TCP, UDP or ICMP Query packet, you will also need to modify the
appropriate TU port number within the TCP/UDP header or the Query
Identifier field in the ICMP Query header.
But the client doesn't know the external query ID(the code in pwnat use 0 as the identifier of original request), it sends an ICMP Time Exceeded packet to the server, even if the packet can reach NAT-S in front of the server, NAT-S can't find the active mapping for the embedded packet, most of NAT implementations will drop it.
Moreover, according to rfc 5508, when the NAT-C receives the ICMP Error packet from the Private Realm, NAT-C uses the packet embedded within the ICMP Error message (i.e., the IP packet from the client to the server) to look up the NAT Session to which the embedded packet belongs. If NAT-C does not have an active mapping for the embedded packet, the NAT-C SHOULD silently drop the ICMP Error packet. It means the ICMP Time Exceeded packet from the client wouldn't arrive at NAT-S.
So pwnat only works with basic NAT devices(rfc 1631 describes) which do simple address translation, won't work with any NAPT device which has robust NAPT implementation. And This paper does mention this problem.
If suppose client does not listen on 68 port,when DHCP server receives the request, it can send it to the address from where it received request (with ephemeral port chosen by client at time of sending), then why does protocol specifies client to be listening on port 68?
The main reason is that the DHCP server might broadcast the "DHCP offer" on the mac level, instead of sending it unicast to the mac address it had received the request.
If the port wasn't constant, some hosts that are listening by chance to the this same random port, will accept the packet to layer 5 - the application layer.
In other words, an application will get message from completely different application, not an healthy situation.
I just had to face the same question myself, and after some research, I found the following on the RFC 2131, which describes the DHCP protocol, under section 1.6 Design Goals:
DHCP must provide service to existing BOOTP clients
Also on the RFC 951, which describe the BOOTP protocol, we can find the following:
The UDP header contains source and destination port numbers. The
BOOTP protocol uses two reserved port numbers, 'BOOTP client' (68)
and 'BOOTP server' (67). The client sends requests using 'BOOTP
server' as the destination port; this is usually a broadcast. The
server sends replies using 'BOOTP client' as the destination port;
depending on the kernel or driver facilities in the server, this may
or may not be a broadcast (this is explained further in the section
titled 'Chicken/Egg issues' below). The reason TWO reserved ports
are used, is to avoid 'waking up' and scheduling the BOOTP server
daemons, when a bootreply must be broadcast to a client. Since the
server and other hosts won't be listening on the 'BOOTP client' port,
any such incoming broadcasts will be filtered out at the kernel
level. We could not simply allow the client to pick a 'random' port
number for the UDP source port field; since the server reply may be
broadcast, a randomly chosen port number could confuse other hosts
that happened to be listening on that port.
So the answer to the question comes from the above. DHCP clients need to use the UDP port 68, in order for the DHCP to be compatible with the BOOTP protocol and the BOOTP protocol requires a specific port for the client, since BOOTPREPLIES can be broadcasted, and if a random port was chosen for the client, it could result in the confusion of other hosts listening on the same port.
Because it's in the RFC (Request for Comments) that specifies how DHCP behaves. RFC 2131 is the document that specifies how a DHCP client and server must behave.
See here for more info on DHCP (section 4.1 in particular). See here for info on what the RFCs are.