We have requirement to test TCP/IP Protocol Suite ( TCP/UDP/IP/ARP/ICMP/Ethernet) using CANAalyzer / CANoe with CAPL and have below queries :-
Are there any API provided to send / receive /
configure different protocols packets within TCP/IP Protocol Suite like ARP
/ ICMP / TCP / UDP / IP
?
If no separate API available , how can we send / receive / configure the protocol packets ? Do we need to set / get raw packet and create / decode using CAPL scripts ?
In help sections there are functions for UDP and TCP communication. Some of which are TcpOpen, OnTcpReceive, kindly check.
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.
Say ff a socket is open for Ethernet then is it same as socket in TCP/IP ? In some existing code i have found that, it supports Ethernet protocol, does that mean i can connect to this Ethernet socket using TCP socket client.
I am in confusion, please help.
Thanks in advance
Sagar
A raw ethernet socket, e.g. SOCK_RAW, cannot be used for TCP communication without you writing the protocol handler (you don't want to do that). You are expected to know how to serialize/deserialize ethernet frames when a socket is opened in raw ethernet mode. SOCK_STREAM is the mode for TCP and the internet is awash with examples of TCP client/server code.
There is some confusion. Ethernet is a layer 1 and 2 technology in the OSI model and the TCP/IP model. For communicating directly over 802.3, in Linux you can use packet sockets to directly generate an 802.3 frame and send it out through the NIC. You can also use packets sockets to receive 802.3 frames. Something different is TCP socket, stream sockets. Use stream sockets for a TCP connection. With a packet socket you can always receive a 802.3 frame containing an IP datagram which contains a TCP segment. However, in order to establish a TCP connection you need to have a TCP communication established between two points. If the code you saw says "Ethernet protcol", you should check it is actually doing, it could just be a misconception on the programmer side. Check the type of socket they are using.
I have created a test account to IOThub and pulled down the azure-iot-sdks git archive to test with.
I have added my connection string to both the iothub_client_sample_http and iothub_client_sample_mqtt .c files.
When I run the iothub_client_sample_http I see a couple of network packets sent and acked before I get a segmentation violation in pthread_mutex_lock called from PR_lock. I will track this down and fix it.
More importantly, I want to use the MQTT protocol. When I execute the iothub_client_sample_mqtt app I get a timeout in the connect code. I have looked at the packets with wire shark and what I see is:
TCP 74 33226 > secure-mqtt [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=81898578 TSecr=0 WS=128
Then two more packets going out the same with retransmission. I never see any reply packets.
Is there something I need to enable at the IOThub to allow using MQTT?
I actually want to use mosquitto in the product and I get the same scenario from my code.
Thanks for any help.
You can also use MQTT over WebSockets which uses 443 port instead of 8883.
See more details from https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-mqtt-support
Thanks for the answer. It turns out the company was filtering all packets to port 8883 and that was my issue.
MQTT has some particular advantages over other protocols to the hub. As it becomes more popular IT organizations will need to change this type of thing.
Thanks again.
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'm trying to implement the following UDP protocol, but I'm having a little trouble figuring exactly how I should approach this.
The protocol states that I should send a particular UDP packet to a certain server, after which the server will stream (several UDP packets that are related) a response back to me, also as UDP packets. I have managed to send the UDP packet fine using the following code:
connection, error := net.DialUDP("udp", nil, endpoint)
...
if written, error := connection.Write(query.ToBytes()); error != nil {
...
} else {
log.Printf("Successfully wrote %d bytes to %s", written, connection.RemoteAddr())
}
When I use Wireshark and take a look at what's going over the wire, it looks like it sent the packet just fine (the only issue here is that I never get a reply from the server, but that's unrelated to this question).
What's the best way for me to handle the server reply in this case? Can I use the previously established connection to read server responses back (this seems unlikely to me, as it's UDP so connectionless) or should I use net.ListenUDP(...) to establish a server on the correct local address and port to read whatever the server sends back to me?
The intent of the protocol is clearly that you just use the same UDP socket to receive the reply that you used to send the request. If you have a client-side firewall, you will have to explicitly open a UDP port and bind the UDP socket to that port before you send. Otherwise just let the system choose the local port, by not binding at all.
The phrase 'the same port as was established by the intial packet' is misleading. Are they your words, or the protocol specification's? What really happens when you do the first send is that if you haven't bound the socket yet, it is automatically bound to a system-chosen port, exactly as if you had bound it to port zero.
Because of the specific protocol design, it's impossible to know on which port the server will send its reply packets. After taking a second look at the packet dumps, I noticed that the server in fact does reply, only the client immediately replies back with an ICMP message saying Destination port unreachable. So the server was trying to reply, but it couldn't because the client would not accept the packets on that port.
To solve this, I have used net.ListenUDP to listen for incoming packets immediately after the client sends the initial packet using the established connection's local address:
incomingConnection, _ := net.ListenUDP("udp", connection.LocalAddr().(*net.UDPAddr))
log.Printf("Listening for packets on %s", incomingConnection.LocalAddr())
defer incomingConnection.Close()
After which incomingConnection can be used as a Reader - for example - read the packets that the server is sending.