In simuLTE, the LteHandoverManager is trying to send a self-constructed packet "X2HandoverControlMsg" to the SCTP layer for further processing. After receiving the packet, however, the SCTP layer discards it and sends a self-defined "DATA" packet to the IP layer.
The problem is: I want to send customized packets constructed in the LteHandoverManager and pass through the layers including SCTP, IP and PPP all the way down to the destination node. Does anybody know if it is possbiel to do that and how?
Related
I am using OMNET++ INET for Ad hoc networks. I would like to send the UDP packet to multiple end nodes so that they all receive the same packet and not that the end node is chosen randomly. How should I set the destAddress in file omnetpp.ini?
Send it to 255.255.255.255 which is the IP broadcast address. Or you can send to the local broadcast address which looks something like 10.0.0.255 (if you have an 8 bit subnet). The lower layers will know how to deal with these addresses and do the appropriate broadcast on the local network.
If you want to send to specific nodes (not to all nodes) then you should either use multicast addresses (but that's pretty complicated to set up), or you indeed need to modify the UDPBasicApp and change the behavior that it can send out also packets to multiple addresses. i.e. instead of the random selecion from the host list, you could implement a loop sending out to all addresses. Or you could keep the random selection behavior and use a different syntax to denote nodes that should be treated as a single group for sending. For example "host1,host2,host3 host4,host5" would mean: choose randomly from either host1,host2,host3 or host4,host5 and then send out the UDP packet to all hosts in the comma separated group.
One last tip: If you don't insist to use UDP, PingApp does support sending out pings to multiple hosts in the target address. It can in fact ping all host interfaces in the simulation with the * notation.
Not sure if this works for you, but I used the UdpBasicBurst node application and set the destAddresses field to 'Broadcast'.
Even after using UdpBasicBurst node application and setting the destAddresses field to 'Broadcast' I am not getting it.Could anyone have any another suggestions please
Using Omnet++ and INET framework.
I want to see the data after the transmission process with errors, noise and all channel impairments.
I found out that I can insert it in the .msg file, but it won't be affected by channel impairments.
My question is: Where can I insert the data (packet content) to be transmitted such that I can see the effect of channel impairments on it?
When a packet (for example an IPv4 packet) is transmitted between two nodes via channel with some impairments, in the destination node only the following events may occur:
The packet is received without errors, then link layer delivers it to the upper layers.
The packet is received without errors but with extended delay, then link layer delivers it to the upper layers.
The packet is received with error, then link layer discards the whole packet.
So there is no possibility that upper layer will receive the packet with errors.
I am checking out the behaviors of Websocket.
Is Websocket message oriented unlike TCP stream?
For example, when I send data ABC, DEF, GHI, then is it guaranteed to receive data ABC, DEF, GHI? In TCP stream, it is not guranteed: we may receive AB, DEFG, HI.
Yes, it is message-oriented (well, actually frame-oriented).
Per RFC 6455:
After a successful handshake, clients and servers transfer data back
and forth in conceptual units referred to in this specification as
"messages". On the wire, a message is composed of one or more
frames. The WebSocket message does not necessarily correspond to a
particular network layer framing, as a fragmented message may be
coalesced or split by an intermediary.
...
The WebSocket Protocol is designed on the principle that there should
be minimal framing (the only framing that exists is to make the
protocol frame-based instead of stream-based and to support a
distinction between Unicode text and binary frames). It is expected
that metadata would be layered on top of WebSocket by the application
layer, in the same way that metadata is layered on top of TCP by the
application layer (e.g., HTTP).
Conceptually, WebSocket is really just a layer on top of TCP that
does the following:
adds a web origin-based security model for browsers
adds an addressing and protocol naming mechanism to support
multiple services on one port and multiple host names on one IP
address
layers a framing mechanism on top of TCP to get back to the IP
packet mechanism that TCP is built on, but without length limits
includes an additional closing handshake in-band that is designed
to work in the presence of proxies and other intermediaries
I am writing an interface to a clinical lab machine, which uses ASTM protocol for communication (http://makecircuits.com/blog/2010-06-25-astm-protocol.html).
To start with, I am trying to use golang's TCP Server to receive data. But not able to figure how to send ACK back to lab machine. I am a newbie in golang. Can any one suggest how I can proceed?
The protocol in the link you supplied is for RS232. When sending data over TCPIP it is a stream (the receiver has to know when the data ends). Normally when changing an RS232 protocol to TCPIP, a header is added to each message which is the length of the message (often two bytes), so if you want to send ASCII ACK you send three bytes a two byte length and one byte data. When writing this you must flush the buffer, as for such a small packet it will not be transmitted until you do.
I'm writing a packet filter in netfilter. Is there a way I can get the source and destination port of a ICMP packet?
I have extracted icmp_hdr from the sk_buff structure. But I don't see any property from source and destination address?
Port numbers are the way the TRANSPORT layer recognizes which packet belongs to what process at the end systems.
They're used to let the process-to-process delivery work; but ICMP, from a functional point of view, is not a transport layer protocol.
ICMP is a messaging protocol at the Network layer(on top of the IP; but not really in the transport layer), it's got a lot of responsibilities but none of them has anything to do with process-to-process delivery, so having a port number there wouldn't make any sense.
Take an example, when you ping(ping uses ICMP echo messages) an IP address, which port are you really pinging?
The answer is: no port, you're pinging the whole station to see if it's alive.
Now, ICMP has many types of messages; if you want to filter out, for example, ping messages, you should check the field type and if it equals ICMP_ECHO, you can return NF_DROP.