I am looking at a project that requires the crafting of S1 Application Protocol (S1AP) packets. It is used between a eNodeB and MME of a 4G LTE network. S1AP is IP based and carried by the Steam Control Transmission Protocol (SCTP).
Does anyone have any idea if the current library for SCTP in Scapy is sufficient to do this, or I might have to define a new protocol?
My first goal is to emulate a connection (via a program) to a physical MME, anyone have any suggestions?
Thanks!
It depends on your development environment & requirement. In the case of linux/FreeBSD based development setup, the libsctp and ASN.1 tools should be enough for having S1-AP over SCTP protocol in the interface with the MME.
Coming to Scapy, note that it is based on python.
Scapy seems to have support for all types of SCTP chunks and so it must most probably be fine for your testing.
S1-AP protocol uses ASN.1. For generating S1-AP packets, you should integrate with ASN.1 for S1-AP encoding/decoding and use over scapy. Scapy provides support for ASN.1.
The S1-AP support extension should be done by you. The best part is that you can extend Scapy without having to edit source files for making your automated tool based on the type of requirement.
Related
I would like to communicate over USB using COAP protocol.
I am currently planning to use libcoap, it has examples but it is based on UDP server-client.
If I want to use USB, what must be done?
Thanks
Depends a bit on the deployment scenario, but in general I'd recommend using USB Ethernet inbetween (CDC-ECM). Then you can use CoAP over USB like you use it over any other network connection. (If you use RIOT for your embedded device and build the gcoap example on a board with native USB and enable the usbus_cdc_ecm module, you get that almost out of the box).
The large downside of this approach is that you are subject to the whims of the host OS's network setup. Probably it'll take up at least the IPv6 link-local interface so you can go ahead with requests to fe80::addr:ess (or even use link-local multicast to find your device), but there may be pitfalls.
There is the slipmux proposal which would do CoAP over serial, but a) I don't know implementations thereof, and b) it leaves you with similar issues of how to make sure your application can really find the right serial port.
It wouldn't be impossible to specify CoAP over custom USB commands (which would then be taken up by an application), but there'd need to be really good reasons not to just go through USB networking to justify them, and I'm not sure that the complexity of ensuring that your NetworkManager is set up correctly counts.
I feel like I am missing something, all of the VITA49 examples seem to be using TCP or UDP.
Is there a specification or standard way of providing VITA49 packets for consumption?
Should I be performing the conversion and providing standard complex samples with Keywords?
I have looked at the rh.vita49 loopback demo waveform, and the MSDD device source, as well as the sourceVITA49 and sinkVITA49 component. All of these use either a tcp or udp packet stream.
If the standard is to use sockets to pass VITA49 packets, then where should I be looking to understand how to construct a device that adheres to the standard?
ANSWER
I was able to talk to an experienced REDHAWK developer.
There is no standard, per-se, with that said the approach I took was to make use of the socket.sourceVita49 asset. This asset consumes the Vita49 packets and inserts appropriate keywords etc based upon context packet. This required me update my device to support setting the hardware up to send Vita49 via TCP. This actually provided an easier solution for me, as I wasn't having to bust the VRT apart.
Examples:
The best example I found of consuming Vita49 was the MSDD device asset.
NOTE:
After reviewing the MSDD, it does not look to be too difficult to create a device that consumes VITA49 VRL,VRT packets and produce time stamped samples. I will be investigating that in the future.
I am working on fpga firmware, in which i want to have very fast data transfer using ethernet . I got help from FPGA forum they say that suggest designs for data transfer using light weight internet protocol (LWIP).
How this is different from transfering the data using NDIS. I will be grateful if you can suggest me some guide to interface my visual c++ application to the network guide and tranfer the data.
many greeting in advance.
LWIP is a library for talking IP on a network.
NDIS is a specification for how an OS talks to network cards.
Neither is necessarily what you appear to want.
If you want to transfer data very simply and quickly point-to-point using Ethernet, you need to understand how Ethernet works at the packet level, and form your data into some Ethernet packets. You can make up your own protocol for this if you have control over both ends of the link.
If you want to transfer the data over an existing network topology, you would be better doing it using an existing protocol. UDP/IP might be one such protocol, depending on your requirements for data-rate, latency, software complexity, reliability etc. LWIP is one library which implements UDP, so might be of use.
For a school project, I need to make an eavesdropping experiment between a SIP user agent and a SIP server. The experiment has to include the following steps:
i)Establish a voice/data communication between two SIP agent.
ii) Capture the signal (i.e. SIP packets) in wireshark.
iii) Change the content of the signal via wireshark or some
other tool that fits better to this purpose.
iv) Encrypting/securing the communication between the agents somehow
to avoid third parties (e.g. wireshark to eavesdrop the communication)
from eavesdropping.
Could you please tell me if there are tools for simulating the above scenario? I prefer to do this programmatically actually and I know there is an open source SIP stack named resip (resiprocate.org) which provides an example user agent and server already in C++. Can I simulate this scenario programmatically or it's better to use some tools that can do this?
There are bunch of possibilities you can check/use for your project purposes.
i)Establish a voice/data communication between two SIP agent
The best way will be to use some already made solution (like e.g. some soft SIP phones).
iii) Change the content of the signal via wireshark or some other
tool that fits better to this purpose.
I think that it is not possible to change traffic using wireshark at all. This is only packet sniffer so you can grab the packets without any modifications of it. You will need some tool that will be able to read and modify packets payload (look at some open source IPS code for some hints).
iv) Encrypting/securing the communication between the agents somehow
to avoid third parties (e.g. wireshark to eavesdrop the communication)
from eavesdropping.
The easiest way will be to establish some tunnel (e.g. VPN) between client and server. This will encrypt and secure the communication.
A sip proxy would be able to capture, manipulate/modify sip packets as well as implement SSL encryption if setup correctly. Generally these servers sit in between 2 sip UA's. Some popular sip proxies are
https://www.kamailio.org/
https://www.opensips.org
I am trying to implement a custom UDP protocol for Linux kernel for college project. I also need to implement a user land program that communicates using the protocol. I am looking for a detailed guide on it including sample code, but could not find it anywhere. Most of the books are deal with theory but I want something more practical - which files to change and which functions to implement specifically for Linux kernel.
Have you tried:
(Programming Linux sockets, Part 2: Using UDP)
http://www.ibm.com/developerworks/linux/tutorials/l-sock2/
In the Linux kernel, the UDP implementation for IPV4 is in:
linux-a.b.c/net/ipv4/udp.c
That's a good starting point. Check the functions this UDP implementation exports to other network layer protocols, so you can create your own version of this protocol, export your own functions to other network layer protocols and call then from there.
For example, when the network layer protocol (IP) finishes the processing of an incoming packet, it calls udp_rcv() to deliver packet to UDP when the upper layer protocol is UDP (value 17, according to IANA, in the protocol field of IPV4's header).
Look into Linux Device Drivers, 3rd Edition by O'Reilly Chapter 17.
Additionally, in the Linux source tree, a couple of drivers to start looking at include:
drivers/net/loopback.c
drivers/net/plip/plip.c