All,
Released to beta is DAHDI v3.4.0-5+asl. This package corrects some issues with compiling the DAHDI modules that ASL/app_rpt needs and permits them to be build on “cloud” kernels that lack certain hardware-related kernel elements. Once this package is promoted to production, it will no longer be necessary to replace the “cloud” kernels on VPS installs. At that time, the manual will be updated appropriately.
Jason N8EI
Nice work. Question: Is the DAHDI driver where incoming IAX packets are processed? How as part of a new feature to be added in ASL could the IAX packet header data be accessed from within app_rpt? For instance, if the sender IP addresses or node# of incoming IAX packets could be read, this information could be made available through AMI to dashboards such as Allmon and AllScan which could then cross-reference that with node DB info to support display of currently keyed node#/call sign. This could be a powerful feature. (Currently, dashboards can show if a directly connected node is keyed, but not indirectly connected nodes. ie. if you’re connected to a hub that has 50 other nodes connected there is no way I know of to see in real time which of those other nodes is keyed.) Thanks
I am not by any means an expert on the innards of exactly what gets processed where. However I do not believe that app_rpt processes IAX2 packets directly. It’s only using the IAX2 system to send/receive data. I believe that any downstream telemetry like that would need to be passed along as metadata through successive app_rpt systems. Currently, the system “talking” too an app_rpt instance is its neighbor by ID regardless of what downstream node keyed the neighbor.
I think IAX packets go direct from the origin to the final destinations without going through multiple ‘hops’ ie. through intermediary connected nodes. For example if you have node A which is connected to node B and node B is connected to node C (but A is not directly connected to C), I believe IAX packets from A will go direct to B and C rather than to B only and then forwarded by B to C. This is really the only thing that would make sense from a standpoint of minimizing latency. Otherwise if you had several hubs, bridges, etc. IAX packets might need to make 5+ hops from node to node and incur many 100’s of mS of latency rather than just being sent direct in a single UDP hop. If you have information that contradicts my belief in how this works please let me know where you saw that. But if this is true then the UDP packets will in fact contain the origin IP address for all incoming audio packets and it should be easy in DAHDI or wherever this is being done to dump the header data into a message queue or pipe where it can be read by app_rpt. I suppose I can try posting this question on a Asterisk / DAHDI developers group, if you happen to know of any links to such a group or have any other ideas where I can find more info on these IAX details LMK. Thanks
This is incorrect. In your example, a transmission from A goes only to B and then B reforwards the transmission to C. Large link clouds do, in fact, have 10s of milliseconds of latency. In extreme cases, maybe 100s of ms. That’s why larger AllStarLink systems use hub nodes in low-latency data centers… To serve all the clients.
OK thanks for that info, it would definitely be simpler from a call management perspective for each node to only send data to other directly connected nodes. I will try snooping some UDP packets eg. with tcpdump or ngrep and should be able to confirm if there is any useful info available there about indirectly connected keyed nodes.
Yes, exactly this.
My system is being served by six geographically diverse hubs, almost all of which are on dedicated hardware in data centers to avoid the unpredictability of shared resource usage from a VPS, which tends to result in weird behavior when the host machines are inevitably oversold, which happens a lot, especially on the low-end of the price range.
It’s definitely more expensive maintaining a system like that, but I do enjoy the rock solid performance, and being able to handle hundreds of connections without issue.
How IAX is used for app_rpt is documented here: IAX Text Protocol - AllStarLink Wiki
I just did a little Wireshark/tcpdump snooping. I don’t see any information that could be used to determine which non-directly-connected node is currently keyed. I was hoping that the K: Key type IAX text messages referenced here would be present, but I am not seeing it passed to/from my ASL3 hub at all, not even to/from directly connected nodes when keyed/unkeyed. Only L: Linked and T: Telemetry type text messages are being sent.
This would be amazing and would solve a LOT of operability issues that hub owners/users have. It sucks to have to request people to connect directly to your hub node # just to be able to see on a single webpage what is going on. I’m so used to having to divide my monitor between 9 different Allmon/Supermon pages.
I’m dreaming of an Allmon3 that has a ‘+’ expand button on the left of each node showing the nodes linked to that node #. An ‘auto-expand all’ at the top that shows you every single node # that is linked to the local node #, no matter how many “hops” away, on one page. You can get a list of all direct/indirect nodes via asterisk -rx "rpt nodes [local_node_num]", but that doesn’t help build a visual tree of the structure (like the ASL bubble chart).
If there is any information about keyed/unkeyed events for indirectly connected nodes that can be programmatically accessed, this would be an amazing feature to implement in Allmon/Allscan/etc. L: Linked IAX2 text messages looked promising and got me excited, but sadly do not appear to be implemented. I hope I’m just missing something.
Yes and also I sometimes see issues where busier repeaters or hubs will get kerchunked repeatedly or have QRM which they believe is originating from ASL but if it’s not a directly connected node there’s no easy way to disconnect the node causing the issue. They can just disconnect whatever directly connected node it’s coming through but it might be better for overall system security and manageability if app-rpt was updated to attach its node # to outgoing IAX packets on each key up, and forward received node# metadata with outgoing forwarded IAX data. Seems this would be more in line with the intent of FCC rules also, where the general idea is that stations transmitting in the ham bands (whether directly on RF or through a linked repeater system) should identify themselves periodically. Attaching meta data to an IAX packet would not directly result in an audible ID but at least the information would be present and could be shown on a dashboard or accessed in other ways. From a security standpoint this could also be important longer-term. It should be as easy as possible for repeaters that have integrated ASL to be able to quickly identify and address sources of any issues. It just seems like a good general practice to require that the originating node# of any audio packet data be retained as that audio is forwarded between various nodes. The digital radio modes such as DMR seem to all do that and it’s quite useful as the radios can then show right on the screen who is keyed up. I suppose this could be opened as an enhancement request to app-rpt, even though some of the work may involve changes to DAHDI or Asterisk. I’d be happy to do that if no one has any other suggestions.