Closed ramonsmits closed 1 week ago
ok, I've captured audio with the log output for this issue. In this capture the problem actually occurs multiple times.
I've tested this against all versions between 1.1.5 and 1.3.1 with FLEX and FLEX_NEXT (1.2+) and all show the same output.
proef-alarm-8uur.zip (FLAC file)
Without timestamp which is just computer time so pretty worthless ;-)
01> 1600/2/K/A|14.116|001120103|ALN|test
02> 1600/2/K/A|14.118|001523020|ALN|Passage Ambulance Wilhelminabrug Leiden
03> 1600/2/K/A|14.123|001523020|ALN|Passage Ambulance Leiderdorpsebrug Leiderdorp
04> 1600/2/K/A|00.001|000120901|ALN|A1 (DIA) 13991 Schmidtstraat 2064 Spaarndam 82106 regio 12
05> 1600/2/K/A|00.009|001123102|ALN|Fijne dienst
06> 1600/2/K/A|00.012|001180000|ALN|TESTOPROEP MOB
07> 1600/2/K/A|00.012|001400521|ALN|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
08> 1600/2/K/A|00.012|001400136|ALN|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
09> 1600/2/F/A|00.012|001400141|ALN|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rij
10> 1600/2/C/A|00.013|001400141|ALN|nmond.
11> 1600/2/K/A|00.013|001400311|ALN|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
12> 1600/2/K/A|00.013|001400321|ALN|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
13> 1600/2/K/A|00.013|001400511|ALN|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
14> 1600/2/K/A|00.014|001400231|ALN|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
15> 1600/2/K/A|00.014|001400561|ALN|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
16> 1600/2/K/A|00.014|001400531|ALN|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
17> 1600/2/F/A|00.014|001400483|ALN|Test: Pr
18> 1600/2/C/A|00.015|001400483|ALN|oefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
19> 1600/2/K/A|00.015|001400169|ALN|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
20> 1600/2/K/A|00.015|001400599|ALN|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
21> 1600/2/F/A|00.015|001400551|ALN|Test: Proefalarm
22> 1600/2/C/A|00.016|001400551|ALN|Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
23> 1600/2/K/A|00.016|001400651|ALN|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
24> 1600/2/K/A|00.016|001400221|ALN|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
25> 1600/2/F/A|00.016|001400285|ALN|Test: Proefalarm Ochtend B
26> 1600/2/C/A|00.017|001400285|ALN|randweer Veiligheidsregio Rotterdam Rijnmond.
27> 1600/2/K/A|00.017|001400441|ALN|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
28> 1600/2/K/A|00.017|001400442|ALN|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
29> 1600/2/F/A|00.017|001400745|ALN|Test: Proefalarm Ochtend Brandweer
30> 1600/2/C/A|00.018|001400745|ALN|Veiligheidsregio Rotterdam Rijnmond.
31> 1600/2/K/A|00.018|001400571|ALN|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
32> 1600/2/K/A|00.018|001400691|ALN|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
33> 1600/2/F/A|00.018|001400331|ALN|Test: Proefalarm Ochtend Brandweer Veilighei
34> 1600/2/C/A|00.019|001400331|ALN|dsregio Rotterdam Rijnmond.
35> 1600/2/K/A|00.019|001400541|ALN|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
36> 1600/2/K/A|00.019|001400232|ALN|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
37> 1600/2/F/A|00.019|001400461|ALN|Test: Proefalarm Ochtend Brandweer Veiligheidsregio R
38> 1600/2/C/A|00.020|001400461|ALN|otterdam Rijnmond.
39> 1600/2/K/A|00.030|001120107|ALN|A2 Rit: 105011
40> 1600/2/K/A|00.038|001123201|ALN|B2 Eindhoven Rit: 105012
41> 1600/2/K/A|00.040|002029572 001420033 001420999|ALN|A2 (DIA: ja) AMBU 17133 G v Voorneweg 3233TM Oostvoorne OTVOOR bon 125033
42> 1600/2/K/A|00.044|002029583 001220499 001220653|ALN|A2 Wijk en Aalburg rit: 146226
01> 1600/2|14.116.A|0001120103|SS|5|ALN|3.0.K|test
02> 1600/2|14.118.A|0001523020|SS|5|ALN|3.0.K|Passage Ambulance Wilhelminabrug Leiden
03> 1600/2|14.123.A|0001523020|SS|5|ALN|3.0.K|Passage Ambulance Leiderdorpsebrug Leiderdorp
04> 1600/2|00.001.A|0000120901|SS|5|ALN|3.0.K|A1 (DIA) 13991 Schmidtstraat 2064 Spaarndam 82106 regio 12
05> 1600/2|00.009.A|0001123102|SS|5|ALN|3.0.K|Fijne dienst
06> 1600/2|00.012.A|0001180000|SS|5|ALN|3.0.K|TESTOPROEP MOB
07> 1600/2|00.012.A|0001400521|SS|5|ALN|3.0.K|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
08> 1600/2|00.012.A|0001400136|SS|5|ALN|3.0.K|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
09> 1600/2|00.012.A|0001400141|SS|5|ALN|3.1.F|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rij
10> 1600/2|00.013.A|0001400141|SS|5|ALN|0.0.C|nmond.
11> 1600/2|00.013.A|0001400311|SS|5|ALN|3.0.K|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
12> 1600/2|00.013.A|0001400321|SS|5|ALN|3.0.K|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
13> 1600/2|00.013.A|0001400511|SS|5|ALN|3.0.K|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
14> 1600/2|00.014.A|0001400231|SS|5|ALN|3.0.K|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
15> 1600/2|00.014.A|0001400561|SS|5|ALN|3.0.K|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
16> 1600/2|00.014.A|0001400531|SS|5|ALN|3.0.K|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
17> 1600/2|00.014.A|0001400483|SS|5|ALN|3.1.F|Test: Pr
18> 1600/2|00.015.A|0001400483|SS|5|ALN|0.0.C|oefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
19> 1600/2|00.015.A|0001400169|SS|5|ALN|3.0.K|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
20> 1600/2|00.015.A|0001400599|SS|5|ALN|3.0.K|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
21> 1600/2|00.015.A|0001400551|SS|5|ALN|3.1.F|Test: Proefalarm
22> 1600/2|00.016.A|0001400551|SS|5|ALN|0.0.C|Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
23> 1600/2|00.016.A|0001400651|SS|5|ALN|3.0.K|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
24> 1600/2|00.016.A|0001400221|SS|5|ALN|3.0.K|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
25> 1600/2|00.016.A|0001400285|SS|5|ALN|3.1.F|Test: Proefalarm Ochtend B
26> 1600/2|00.017.A|0001400285|SS|5|ALN|0.0.C|randweer Veiligheidsregio Rotterdam Rijnmond.
27> 1600/2|00.017.A|0001400441|SS|5|ALN|3.0.K|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
28> 1600/2|00.017.A|0001400442|SS|5|ALN|3.0.K|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
29> 1600/2|00.017.A|0001400745|SS|5|ALN|3.1.F|Test: Proefalarm Ochtend Brandweer
30> 1600/2|00.018.A|0001400745|SS|5|ALN|0.0.C|Veiligheidsregio Rotterdam Rijnmond.
31> 1600/2|00.018.A|0001400571|SS|5|ALN|3.0.K|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
32> 1600/2|00.018.A|0001400691|SS|5|ALN|3.0.K|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
33> 1600/2|00.018.A|0001400331|SS|5|ALN|3.1.F|Test: Proefalarm Ochtend Brandweer Veilighei
34> 1600/2|00.019.A|0001400331|SS|5|ALN|0.0.C|dsregio Rotterdam Rijnmond.
35> 1600/2|00.019.A|0001400541|SS|5|ALN|3.0.K|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
36> 1600/2|00.019.A|0001400232|SS|5|ALN|3.0.K|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
37> 1600/2|00.019.A|0001400461|SS|5|ALN|3.1.F|Test: Proefalarm Ochtend Brandweer Veiligheidsregio R
38> 1600/2|00.020.A|0001400461|SS|5|ALN|0.0.C|otterdam Rijnmond.
39> 1600/2|00.030.A|0001120107|SS|5|ALN|3.0.K|A2 Rit: 105011
40> 1600/2|00.038.A|0001123201|SS|5|ALN|3.0.K|B2 Eindhoven Rit: 105012
41> 1600/2|00.040.A|0002029572|SG|5|ALN|3.0.K|0001420033|0001420999|A2 (DIA: ja) AMBU 17133 G v Voorneweg 3233TM Oostvoorne OTVOOR bon 125033
42> 1600/2|00.044.A|0002029583|SG|5|ALN|3.0.K|A2 Wijk en Aalburg rit: 146226
@bierviltje @EliasOenal @bertinholland @Zanoroy Any idea what could be wrong? Do you have any pointers on how I could further diagnose this? Any recommendations on resources for me to learn the FLEX protocol or how Multimon-ng handles this?
FLEX output
1600/2/K/A|00.044|002029583 001220499 001220653|ALN|A2 Wijk en Aalburg rit: 146226
FLEX_NEXT output
1600/2|00.044.A|0002029583|SG|5|ALN|3.0.K|A2 Wijk en Aalburg rit: 146226
This log also the issue that FLEX_NEXT captures only the group message and not the individual cap codes as can be seen in the entries above where FLEX_NEXT only has the group code (the code between 2029568 and 2029583)
This log also the issue that FLEX_NEXT captures only the group message and not the individual cap codes as can be seen in the entries above where FLEX_NEXT only has the group code (the code between 2029568 and 2029583)
That is correct, in my automation I still use FLEX because of that.
I think that is the following related issue:
@filibuster007 The missing capcodes is one of the issues with the 'FLEX_NEXT' one of the contributers made a stack of changes because he didn't like the code flow/logic and brought introduced a bunch of flaws for most group messaging networks as he only tested in SAGRN (Australia where group messaging is not used).
@ramonsmits I'm sorry if it seems obvious to you, but could you clarify the issue? Are you saying there is more to the messages and its been cut short?
1600/2/K/A|00.044|002029583 001220499 001220653|ALN|A2 Wijk en Aalburg rit: 146226 ????
1600/2/K/A|00.012|001180000|ALN|TESTOPROEP MOB ????
As for learning the FLEX spec, You need to find a copy of the "Flex G1.9b" specification. I have one, but I'm not sure of the licensing etc so I dont think I can share it here. make sure you get G1.9b, it changes a bunch of rules from G1.9 and almost contradicts previous versions. Its also the latest before Motorola dropped RE/FLEX.
You need to find a copy of the "Flex G1.9b" specification. I have one, but I'm not sure of the licensing etc so I dont think I can share it here. make sure you get G1.9b, it changes a bunch of rules from G1.9 and almost contradicts previous versions. Its also the latest before Motorola dropped RE/FLEX.
Thanks for this! My understanding of c is good enough but just very rusty (not been coding in c since 2003'isn) but good specifications helps to understand what I'm looking at.
I'm sorry if it seems obvious to you, but could you clarify the issue? Are you saying there is more to the messages and its been cut short?
I can understand its not obvious for non Dutch users.
Some messages get split. Its very clear in the logs as you see the same message repeated to several destinations.
FLEX:
09> 1600/2/F/A|00.012|001400141|ALN|Test: Proefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rij
10> 1600/2/C/A|00.013|001400141|ALN|nmond.
17> 1600/2/F/A|00.014|001400483|ALN|Test: Pr
18> 1600/2/C/A|00.015|001400483|ALN|oefalarm Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
21> 1600/2/F/A|00.015|001400551|ALN|Test: Proefalarm
22> 1600/2/C/A|00.016|001400551|ALN|Ochtend Brandweer Veiligheidsregio Rotterdam Rijnmond.
25> 1600/2/F/A|00.016|001400285|ALN|Test: Proefalarm Ochtend B
26> 1600/2/C/A|00.017|001400285|ALN|randweer Veiligheidsregio Rotterdam Rijnmond.
33> 1600/2/F/A|00.018|001400331|ALN|Test: Proefalarm Ochtend Brandweer Veilighei
34> 1600/2/C/A|00.019|001400331|ALN|dsregio Rotterdam Rijnmond.
37> 1600/2/F/A|00.019|001400461|ALN|Test: Proefalarm Ochtend Brandweer Veiligheidsregio R
38> 1600/2/C/A|00.020|001400461|ALN|otterdam Rijnmond.
I know 100% this is incorrect as a when the messages of the initial issue description were received I also received the same message on my pager (I myself are a voluntary firefighter) and the message was displayed correctly while the message for my pager addresses (1400581
and 1400582
) was split by multimon-ng flex decoder.
What is also interesting is that the same "split" happened for both 1400581
and 1400582
in the original issue description.
097> FLEX|2024-08-28 16:28:58|1600/2/C/A|07.040|001400582|ALN|delijke storing graag MOI incident ""uitval systeem"" uitlezen
139> FLEX|2024-08-28 16:29:12|1600/2/C/A|07.047|001400581|ALN|delijke storing graag MOI incident ""uitval systeem"" uitlezen
14
Likely it has something to do with data to be larger than a frame. I've read once somewhere that only in upcoming frames there is a flag to indicate that that new frame should be added to the previous frame. I'm not sure the current implementation detects this but I would almost think that is the cause.
Maybe its because the message text needs multiple frames or the addresses need multiple frames or maybe even both?
I think I would first want to somehow obtain the decoded bit/byte stream for analysis. I can then map the protocol specification against the binary data and check if according to the spec decoding would result in correct output. If it does.. then its easier to find the actual issue in the code.
O wait... I don't know why I haven't seen this earlier... BUT... based on the logs it seems multimon-ng just passes the frame per line and the processor would need to combine the lines themselves?
For example, I see F
and than C
for these split messages and on lines where these are not split I see a K
. 🤦 I should have rubber ducked this here earlier.
If that is the case I should just do something like:
If frame type F
(fragment?), append to messages until frame type is C
(complete?) or not F
.
@ramonsmits Multimon-ng Flex implementation does NOT attempt to stitch split messages together.
As you have determined: The F and C flags indicate the "F" Fragmentated message and "C" Complete message. The last fragment has a C flag (in the Flex spec the BIT is named "Continue" flag meaning there is another message to come)
So: A message split across two frames will have the first message with the "F" (Fragmented) flag and the last message will have a "C" (Completed) flag.
Anybody wanting to stich the messages back together is adviced to do so in something like Python, frame stiching wasn't really something we wanted to do inside multimon-ng.
I'm using .net 8 c# so I'm good. Sorry for not noticing this myself earlier.
@Zanoroy Do fragments only apply to the text or also to the addresses?
@ramonsmits only the message text.
I think technically the group address (I would need to review the spec to be sure) could go up to enough addresses to need to be split, but that would be a very large number of receipients and indication of a poorly designed capcode fleet.
In the real world, it wouldn't happen.
I think technically the group address (I would need to review the spec to be sure) could go up to enough addresses to need to be split, but that would be a very large number of recipients and indication of a poorly designed capcode fleet.
@Zanoroy Can you make a guestimate of the amount of addresses required?
The thing in the Netherlands is that there are chains of capcodes and a lot of monitor codes. For big incidents a whole bunch of different staff gets alerted and because these gets alerted their monitor codes also get included and based on incident type monitor codes for press releases get included, healthcare, multi level functions, etc. I'll check if I can find one :-)
In the real world, it wouldn't happen.
Here, hold my (crappy Dutch) 🍺. Just in the last few hours one with 28 addresses which I think resembles 112 bytes (address is unsigned 32 bit integer AFAIK)😊
FLEX|2024-09-05 15:25:08|1600/2/K/A|13.019|002029573 000106515 000106530 000106555 000106570 000106900 000106910 000107011 000107081 000107086 000107211 000107281 000107286 000107400 000107441 000107481 000107484 000107500 000107581 000107641 000107681 000107684 000107811 000107881 000108999 000127030 000127185 000127295|ALN|P 1 BNH-07 BR duin (Uitbr.: hoog) Bergweg Bloemendaal 121291 121294 121296 121201 121205 122302 122340 122502 122540 122160 123062 122462 123002 123540
I can assure you that there are alerts with more addresses....
Ok looking at the SPEC it appears you could have up to ~40 capcodes in the dynamic group call, followed by the message data within 4 minutes (128 frames) if more are needed the a second dynamic group call frame is setup and the process is repeated.
Basically the capcodes cannot be split across frames, so you don't need to worry about checking for it.
Today there was a message sent in bulk and this was logged by my instance:
For example, search on
storing graag MOI incident "uitval systeem" uitlezen
at https://112alarm.net/index.php shows the same issue and you search on similar websites a lot show the same issue which makes me think all these use multimon-ng ;-)