I've been looking at how to use the VITA 49.2 standard to key/unkey a radio and how to perform flow control.
I did not see something available in the existing attributes of the context/control packets for the items I mentioned.
Does this mean if I want to do keying or flow control through 49.2 I have to define these packets myself through extension packets?
I thought keying/unkeying a radio and performing flow control would be something commonly done with VITA 49.2, so I thought attributes for these items might have already existed in the standard.
Related
I'm trying to create a trigger in zabbix which will show me a problem and alert me on my email whenever an interface in a cisco switch (with snmpv2) crosses 80% of it's bandwidth (100 mbps or 1000 mbps) without hardcoding anything, I tried using this trigger expression:
{/switch name:net.if.out[ifHCOutOctets./switch interface].min(10)}>80000000
I would like to know how can I write this trigger expression which works fine without applying it to every single interface item in every switch. I think that maybe macros could help in these situations but found no explanation or any guide about how to use them or how to use low level discovery which maybe have a part at the solution for my need.
Thanks in advance.
You are correct, you want to use Low Level Discovery to do this, as well as to discover all your interfaces. Low level discovery at a high level consists of two things. 1) you have to tell zabbix how to go discovery a bunch of dynamic things and asssign a LLD macro to them, that is done a the high level of the Discovery rule. 2) you have to tell zabbix what item protototypes, trigger protorypes, etc to dynamically create as actual items and triggers, every time the discovery rule runs.
Take a look at the Arista SNMPv2 template included with zabbix as an example. There are a number of Discovery Rules included in that template, one of which is the Network Interfaces discovery rule. Within the network interfaces discovery rule, zabbix basically does an snmp walk and gets a list of all the interfaces and assigns LLD(Low level discovery macros) for each interfaces such as #IFINDEX, #IFSTATUS, etc. The discovery Rule, like all LLD rules, takes the output of the "Network Interfaces" discovery rule, and uses them to dynamically create actual items on each host the template applied to.
The next part of this to understand is the prototypes. Once zabbbix finds all the network interfaces, your question should be, how do i get it to create new Items in my host for each interface it finds, and how do i get it to create triggers for each interface it finds dynamically, automatically and without user intervention. The answer is protoyptes. Prototypes are child elements of a Low Level Discovery. They are what actually creates the new items and triggers for every thing it discovered.
Take a look here for some examples and docs on low level discovery rules.
https://www.zabbix.com/documentation/4.2/manual/discovery/low_level_discovery#trigger_prototypes
Zabbix can create LLD rules via numerous discovery methods including SNMPv#, which is all capable of being configured in the UI or api, and other customer discovery rules not included through the use of user parmaters, externel checks, etc.
If your make and model of switch is already known to zabbix, a template in "Templates/Network Devices", at least i think thats the path, will exist just like the arista and juniper ones.
You can create custom low level discovery rules as well for non snmp stuff. basically you write a script that will go find the things you want to dynamically add to zabbix and your script needs to return a valid json output with #macronames and values you want added. For example a custom file system discovery rules, which shouldn't be needed because there already included if your using the agent, would produce lines like the ones shown in this example in the official docs.
https://www.zabbix.com/documentation/4.2/manual/discovery/low_level_discovery#creating_custom_lld_rules
In short, check to see if a template exists for your switch already and a discovery rule with the item prototypes to discover things the way you want them already. LLD basically allows zabbix too walk a dynamic data structure of any source, as long as that data structure has a definition known to zabbix, and you tell it what keys and values in the JSON you want to create as items, triggers, etc.
You should leverage the low level discovery feature of Zabbix.
After a standard setup you should have a "Template Module Interfaces SNMPv2", which is used by some other templates as a standard for interface discovery.
Within the template you will find a "Network Interfaces Discovery" discovery rule that runs every hour to:
query the target device for an interface list
create N items for each interface (bits in, bits out, speed, type etc), defined as Item Prototypes
create some triggers, defined as Trigger Prototypes
The speed item is the negotiated interface speed (ie: 1000 for a gigabit switch port), which is your 100% limit.
You can add some definitions to this template to get the alert you need:
Create a calculated item prototype and set its formula to
100*(currentOutputBits/speed)
Create a template macro to define your alert threshold, ie {$INTERFACE_OUTPUT_THRESHOLD}, and set it to 80
Create a trigger prototype that matches when the calculated item is
greater than {$INTERFACE_OUTPUT_THRESHOLD} for N minutes
Optionally, do the same for the currentInputBits item
This setup will create 1 additional item and 1 additional trigger for each physical or logical interface found on the target device: it makes sense to unflag the "create enable" option on the trigger prototype and enable it only on specific ports of specific devices.
The threshold macro can be changed at template level, affecting any device linked to it, or at host level for a custom threshold.
Thanks for your replies, I actually checked again the Template Module Interfaces SNMPv2 and saw that there is a prototype trigger that solves my question.
for anyone who wants to do the same with a switch:
Add to your switch (host) the "Template Module Interfaces SNMPv2" template.
Change the IF_UTIL_MAX macro to whatever value you want it to be, the default is 90 (this is the macro which is responsible for the percentage of the bandwidth which will trigger a problem, for example, if you change it to 60, when a host bandwidth utilization averages more than 60% in any interface for 15 minutes, a problem will be added to the problems tab or to the dashboard).
If the time of 15 minutes isn't right for you, you can change it by going to: configuration -> templates -> Template Module Interfaces SNMPv2 -> Discovery rules -> Network Interfaces Discovery -> Trigger prototypes -> search for a trigger name which contains high bandwidth usage -> in the problem expression and the recovery expression find the .avg() function and change the value inside it to whatever value is right for you, for an example: 15m = 15 minutes, 1s = 1 second etc...
I actually recommend to clone the trigger prototype, change it and then disable the built in one instead of just changing the time inside it for easily debugging errors in the long run. So you can change the name of the trigger prototype and then clone it by pressing clone in the bottom left corner of the screen, then change it's name and settings for whatever suits you the best.
Press add in the bottom left corner of the screen and if you took my advice you also need to click on the green "Yes" link of the built in trigger in the trigger prototypes table for it to disable.
You can also go ahead and try the other answers on this thread, I'm seriously thankful for them but I don't have enough time to check if those work since I already figured it out after reading Simone Zabberoni's and helllordkb's answers and checking the built in low level discovery in the "Template Module Interfaces SNMPv2" template.
I'm look for a DICOM image reconstruction tag. Is there any tag to recognize a DICOM Image is result of a reconstruction?
First try searching for "MPR" (multiplanare Rekonstruktion) but just for Siemens?
(0008,0008);Image Type;DERIVED\PRIMARY\AXIAL\CT_SOM5 MPR
(0008,103e);Series Description;Abdomen nativ 3.0 MPR kor
Image Type (0008, 0008) is the field you are searching for. Unfortunately, you will run into three issues:
Not all vendors stick to the defined terms for this attribute, some treat them as free text. So does Siemens - "CT_SOM5 MPR" is not a defined term for this attribute.
it depends on the type of object (SOP Class UID) which defined terms apply and from which component of Image Type they can be obtained.
DERIVED\SECONDARY\MPR (MPR is value 3 for MR objects)
DERIVED\SECONDARY\ANGIO\RESAMPLED (RESAMPLED is value 4 for Enhanced IODs)
There are several reconstruction techniques, MPR is just one of them
There is an attribute Volume Based Calculation Technique (0008, 9207) from which this could be safely determined, but so far I have never seen it included in practical datasets. Plus, it is not allowed for all IODs
Long story short: Using Image Type and sticking to the rules and defined terms applying to this attribute would be DICOM conformant and correct, but fail in some practical cases. I do not see any other generic approach. To include more practical cases, you will need to implement vendor-specific heuristics.
Carrier aggregation combines the existing spectrum, say if the carrier had previously 20MHz in the area, with the newly acquired spectrum of 20MHz, to give a wider pipe or bandwidth for data flow between the mobile device & the base station tower.
My question is, why don't they just operate the new bandwidth as a separate pipe? So that there would be two pipes of 20MHz each, instead of one aggregated pipe of 40MHz?
Benefits:
Carriers won't have to deal with the complexity of Carrier Aggregation technology, as the two bands are totally separate (2300MHz & 1800MHz). End-users can be divided over the two frequencies. Theoretically this should halve the load on one channel, providing double the speeds to connected users.
Many existing 4G devices use single antenna for 4G operation. The LTE-A tech needs MIMO support on both mobile & tower to work. Essentially it needs 2 antennas on both mobile & tower for operating 2 different frequencies, which only stresses the mobile device. Existing hardware cannot benefit from LTE-A, where speeds will continue to remain the same post upgradation. In fact, it may slightly decrease post LTE-A implementation, since newer LTE-A devices will share load on both the frequencies, but existing LTE users can only use one.
For those new, this simple image explains how Carrier Aggregation works. https://www.techtalkthai.com/wp-content/uploads/2014/12/qualcomm_carrier_aggregation.jpg
1) Assuming that the operator already has 2 bands, it is really not complex to enable and configure carrier aggregation. It is likely that they already have the ability as part of the latest LTE software upgrades and it is just a matter of configuring it and possibly paying for a license to use it.
The scenario you describe of using two separate pipes instead of a single CA pipe is not feasible (or may not be possible?). When a device establishes a connection in an LTE network, a default bearer is configured which would not be able to simultaneously use two radio connections without CA or other similar features. Multiple bearers can certainly be established simultaneously, however they serve different purposes (e.g. voice vs data). That said, really CA is using two different pipes, but they act as a single (logical) bearer. Another advantage of CA is that the control plane signaling takes place on only one of the component carriers and therefore the other component carriers can be fully dedicated to user plane traffic.
2) I'll clear a few things up:
MIMO has nothing to do with Carrier Aggregation.
Most 4G devices today transmit on a single antenna and receive on two antennas. (Although they most likely have at least 2 tx and 2 rx antennas, and many have 4 tx and 4 rx antennas, although 4x4 MIMO has not been implemented by most operators.)
Existing devices are already taking advantage of LTE-A features and some operators are currently rolling out 3-carrier CA, 4x4 MIMO as well as 256QAM.
Here is a recent news article which discusses LTE-A features which have already been implemented: https://newsroom.t-mobile.com/news-and-blogs/lte-advanced.htm
I am using XBee Digimesh Modules in API-Mode to send data between different industrial machines allowing them to share data, information and commands.
The API-Mode offers some basic commands, mainly to perform addressing and talk with the XBee Module itself in order to do configuration, etc.
Sending user data is done via a corresponding XBee API-Command which allows to send user-defined data with a maximum payload of 72 Bytes.
Since I want to expand this communication to allow integration of more machines, etc. I am thinking about how to implement a basic communication system that's tailored perfectly to the super small payload of just 72 Bytes.
Coming from the web, I normally would use some sort of JSON here but that would fill up the payload very quickly.
Also it's not possible to send a frame with lot's of information since this also fills up the payload very quickly.
So I came up with a different way of communicating. Instead of transmitting frames packed with information, what about sending some sort of Messages like this:
Machine-A Broadcasts: Who's there?
Machine-B Answers: It's me I am a xxx-Machine
Machine-C Answers: It's me I am a xxx-Machine
Machine-A now evaluates the replies and decides to work with Machine-B (because Machine-C does not match As interface):
Machine-A to B: Hello B, Give me some Value, please!
Machine-B to A: There you go: 2.349590
This can be extended to different short messages. After each message the sender holds the type of message in a state and the reply will be evaluated in relation to the state / context.
What I was trying to avoid was defining a bit-based protocol (like MIDI) which defines all events as bit based flags. Since we do not now what type of hardware there will be added in the future I want a communication protocol that's very flexible and does not need a coordinator or message broker, etc.
But since this is the first time I am thinking about communication protocols I am curious to know if there might be some existing frameworks that can handle complex communication on a light payload.
You might want to read through the ZigBee Cluster Library specification with a focus on the general commands. It describes a system of attribute discovery and retrieval. Each attribute has a 16-bit ID and a datatype (integers of various sizes, enumerated types, bitmaps) that determines its size.
It's a protocol designed for the small payloads of an 802.15.4 network, and you could potentially based your protocol off of a subset of it. Other ZigBee specifications are simply a list of defined attributes (and commands) for a given 16-bit cluster ID.
Your master device can go through a discovery process to get a list of attribute IDs, and then send a request to get values for multiple IDs in one shot. The response will be packed tight with a 16-bit ID, 8-bit attribute type and then variable length data. Even if your master device doesn't know what the ID corresponds to, it can pass the data along to other systems (like a web server) that do know.
I would like to know how to capture packets of a specific wireless network using wireshark.
I'm already able to capture all packets of different networks setting my wireless card in monitor mode but for a specific analysis i need to discard all the packets not related to my network during the capture procedure.
I know that exists display filters to do that but i need to filter them ahead (like with capture filters).
If i go to CAPTURE->OPTIONS i can set capture filters but i don't know the exact filter because they are different from display filter infact wlan.bssid==xx:xx:xx:xx:xx:xx
does not work.
any suggestions?
thanks
You could use an index from the start of the wlan packet.
It needs some coaxing, but the BSSID field is in a fixed, predictable position. By using brackets, you should be able to reference the proper positions in the packet.
The BSSID is at position 16, so if you wanted to emulate something like:
wlan.bssid=12:34:56:78:9a:bc
you would have to do something like this:
wlan[16:4] == 0x12345678 and wlan[20:2] == 0x9abc
You have to convert the first 4 octets into a int32 and the last 2 into an int16 and use 2 clauses, as BPF cannot express a 6 byte number, but I've used it and it works fine. This can also be adapted to other uses as well (you just need the offset).
Excellent question and something I've been trying to figure out also.
The short answer is the wireshark tools cannot filter on BSSID. Wireshark uses pcap, which uses the kernel Linux Socker Filter (based on BPF) via the SO_ATTACH_FILTER ioctl. There is no BPF filter for BSSID.
Another tool, airodump-ng, CAN capture by BSSID because it passes all 802.11 frames into user space and decodes/filters frames there. It works surprisingly well considering all the user-space processing.
But even a low-volume 80211 network is fairly noisy. For example, my SOHO captures 11K frames in under two minutes; and I still drop frames. Grabbing all the 80211 frames for the five visible (but small!) BSSIDs near me and I receive 141K frames (104MB) in just under three minutes.
I'm looking to do an embedded frame sniffer/injector using EMMC or SD flash so I need to be careful about pushing the limits.
So I'm trying to write a custom BDF filter to filter only the local BSSID frames. And I hope to extend it to drop a good amount of the "noisy" frames - most of the control and management frames can be filtered.
The BSSID address location in the frame is based on ToDS and FromDS control bits.
Anyway, hope I provided some breadcrumbs to the solution. It may just be an airodump user-space solution is the easiest.