Is there an easy way to get the patlooptest binary installed within the freepbx distro? I checked, and I have rpms installed for dahdi-tools, dahdi-tools-debuginfo, dahdi-tools-doc, and kmod-dahdi-linux but none of these packages seem to include this utility.
These binaries are included in the asterisk packages, just not in the schmooze packages, so I opened a bug: http://issues.freepbx.org/browse/FPBXDISTRO-110
The following is off the top of my head and not tested:
yum install dahdi-devel
wget http://downloads.asterisk.org/pub/telephony/dahdi-tools/dahdi-tools-{YOUR_DAHDI_VERSION}.tar.gz
tar -xzvf dahdi-tools-{YOUR_DAHDI_VERSION}.tar.gz
cd dahdi-tools-{YOUR_DAHDI_VERSION}
cc -o patlooptest patlooptest.c
That out of the way as I said in the bug report you are going down the wrong path. Outside of actual hardware/firmware development you should never need this. This is not going to give you anything that will be useful to you.
My Telco says that layer 1 isn’t coming up, and I see the same with dahdi_tool. What I’m planing to do with patlooptest is verify wiring between the PBX and the Demarc (which are in seperate buildings). If you are saying that layer 1/2 diagnosing is beyond the scope of the freePBX project, that I understand, but you seem to be suggesting that performing layer 1/2 diagnostics is unwarranted and not useful. Dahdi itself is a layer 1/2 device, so I fail to see why requesting these diagnostic tools be included in the distribution is so far fetched. If the asterisk project saw these as debugging tools, then certainly they would put the binaries into a debugging RPM instead of the dahdi-tools RPM. All I’m asking is that when re-packaging the RPM, schmooze includes the binaries that the asterisk package includes.
Further on the layer 1/2 note, I see other tools included in the distribution that aide with diagnostics - one that immediately comes to mind is wireshark. Certainly if a tool that helps diagnose ethernet/IP/tcp network traffic is relevant to a PBX, then certainly a tool that helps diagnose T1 network traffic would also be relevant?
Forgive me if this sounds like a rant, I’m frustrated with a bad PRI deployment and a lack of tools to help diagnose.
To be clear, by “All I’m asking is that when re-packaging the RPM, schmooze includes the binaries that the asterisk package includes”, I’m referring specifically to the dahdi-tools RPM package made available by the asterisk project (not an RPM that includes the asterisk program).
here is the cliff notes of troubleshooting.
- buy or make a T1 loopback
—Connect pin 1 -> 4
—Connect pin 2 -> 5 - Plug it in to your T1 card.
—Does it come up? Your card is fine
—If not it is the card or config. - Plug it in to your Smart jack
—Does it come up? The smart jack is fine
—If not it is the smart jack or provider - If both sides come up it is your cable.
—Make sure you are using a straight cable or an RJ48 Crossover.
-----If one doesn’t work try the other
-----Note an RJ48 crossover is NOT the same as an Ethernet crossover.
So if you need that, don’t whine about rpm’s not including what you want, it’s as easy as :-
cd /usr/src
wget http://downloads.asterisk.org/pub/telephony/dahdi-linux-complete/dahdi-linux-complete-current.tar.gz
tar zxvf /usr/src/dahdi-linux-complete-current.tar.gz
cd dahdi-linux-complete*/tools
make tests
and you have the buggers 
(and yes they are invaluable tools for testing recalcitrant T1’s at a greater depth than just seeing if lights go on and guessing)
(hehe, call that my edge-of-the-cliff notes, working with real life telco engineers takes a little more experiance, but it can save the cost of a t-berd)
we use to say a t-bird would sync to a brick
Also no need to use a hammer when a screw driver will do.
K.I.S.S
I would reply that low level diagnostics like the dahdi tool suite are hardly ‘hammers’, they are in fact smaller than a screwdriver when it comes to ‘the size of your tool’ (ask any one)
In this case the OP did not have a Simple Solution, he seems to know of what he speaks and I assume he checked his LBO and timing on the span before posting.
He extended his demarc and can check that extension appropriately with the Digium tools so well crafted, but not with the KISS tools you suggest.
Perhaps in the future Schmooze could add the ‘make tools’ when they build their rpm, it would take two seconds and possibly an extra 3k bytes of space, would that be so hard?
Any way, hopefully jkillen has a temporary solution and will take it successfully from here.
This sits as a feature request but this doesn’t help him now. In 8 years actively troubleshooting T1 problems from around the world for a company that makes T1 hardware I never had to use patlooptest outside of development. a $0.02 loopback gets you 98% of the way. You would not believe how many people have a whole resume of acronyms after their name stating how awesome they are that simply need to swap out a cable.
From the comments above he wants patlooptest to test a cable. This test is easily performed with those simple lights. This is using a hammer to remove a screw.
Well, I have to toss my two cents in here.
The OP made perfect sense. He wants to provide a facility look back from his PBX, this indeed proves that the line driver (jumper in e1 mode,oooops) cable and smartjack/CPE are all correct.
I use external gateways and use these functions quite often.
Also I miss the days of T1 acceptance testing. running head to head, exchanging patterns. All 0’s to stress test N8ZS regen. You knew what you were getting.
As far as the OP’s issue, telco probably left a loop up and they are running to their loop. Most SMAS gear today provides loops in both directions.
Specifically, the telco was stating that when they ran a pattern test (with a loopback at the PBX room), that they were seeing bleed-over from the existing T1. Yes, I can (and have) put a loopback between the PBX room and the demarc, but without a load on the line, it’s hard to say how stable it is - that was my intent of running patlooptest.
This assumes that there binary compatibility between the schmooze provided install and the built-by-hand patlooptest. The last thing I want is for some incompatibility to cause the dahdi kernel module to crash (or worse).
In the bug, I specifically asked if using the patlooptest binary from the asterisk package would cause any problems. If it does not, then that would be a viable work-around.
BTW, I did end up trying it, and it seems to work fine - it’d just be nice if freepbx/schmooze would verify/certify that it works without problems. But then, I thought that was the point of making and distributing their own RPMs to begin with - to verify/certify the tools they provide all work together.
Yes - that was my exact thought, that adding it to the build process would be trivial. The whole thing seems to have blown up bigger than it needed to be.
As stated above this sits as a “feature request” in the tracker and will likely be added because the work to do so is minimal and including it doesn’t hurt anything. It may end up in a separate package but that is logistics stuff that is not relevant. The point was not that it “won’t happen” the point was “it will not happen last week”. In other words you need it NOW so it is best to find an alternative to get it now. It will likely be present in the future which could help others but won’t help you and your current need.
Fair enough.
For now, using the binary from asterisk’s rpm repository seems to work without any issue. We’re working with our line/wiring guy to track down the fault and should have it figured out soon.