summaryrefslogtreecommitdiff
path: root/ztscan.c
AgeCommit message (Collapse)Author
2008-08-14more license header updateskpfleming
git-svn-id: http://svn.digium.com/svn/zaptel/branches/1.4@4482 5390a7c7-147a-4af0-8ec9-7488f05a26cb
2008-05-14Temporarily revert revisions 4006 and 4009, until a better decision can be ↵qwell
made about channels on spans. Closes issue #12635 git-svn-id: http://svn.digium.com/svn/zaptel/branches/1.4@4285 5390a7c7-147a-4af0-8ec9-7488f05a26cb
2008-03-18ztscan can now accept optional list of span numbers and print output fortzafrir
those spans only. Default remains (when there are no parameters) to print output for all spans. git-svn-id: http://svn.digium.com/svn/zaptel/branches/1.4@4009 5390a7c7-147a-4af0-8ec9-7488f05a26cb
2008-03-18ztscan.c: Moving some code, renaming some variables, no change intzafrir
functionality. git-svn-id: http://svn.digium.com/svn/zaptel/branches/1.4@4006 5390a7c7-147a-4af0-8ec9-7488f05a26cb
2008-03-16ztscan: detect xpp (pri/bri), tor2 and torisa as digital as well as theytzafrir
currently claim to support CAS but not DACS. git-svn-id: http://svn.digium.com/svn/zaptel/branches/1.4@3996 5390a7c7-147a-4af0-8ec9-7488f05a26cb
2008-02-04Move kernel stuff to under kernel/ tzafrir
(merged branch /zaptel/team/tzafrir/move ) Closes issue #7117. git-svn-id: http://svn.digium.com/svn/zaptel/branches/1.4@3793 5390a7c7-147a-4af0-8ec9-7488f05a26cb
2007-12-10for broken analog ports, retain the signaling type that would have been ↵kpfleming
supported if the port wasn't broken in ztscan, report the port types of analog ports instead of the signaling type git-svn-id: http://svn.digium.com/svn/zaptel/branches/1.4@3383 5390a7c7-147a-4af0-8ec9-7488f05a26cb
2007-12-04the analog card drivers can now mark failed modules as 'broken', and ztscan ↵kpfleming
can output that information git-svn-id: http://svn.digium.com/svn/zaptel/branches/1.4@3294 5390a7c7-147a-4af0-8ec9-7488f05a26cb
2007-12-04eliminate the 'general' section from the ztscan output, as it doesn't ↵kpfleming
contain anything the GUI needs and one user is concerned about the 'totalspans' number having to be kept in sync if the output is edited git-svn-id: http://svn.digium.com/svn/zaptel/branches/1.4@3291 5390a7c7-147a-4af0-8ec9-7488f05a26cb
2007-12-04fix a bunch of silly bugs and do some code cleanupkpfleming
git-svn-id: http://svn.digium.com/svn/zaptel/branches/1.4@3290 5390a7c7-147a-4af0-8ec9-7488f05a26cb
2007-12-04add a new Zaptel scanning tool, primarily for use by the Asterisk GUI, ↵kpfleming
called 'ztscan'. this tool outputs an Asterisk-style configuration file containing one context for each Zaptel span with all the details that can be learned about that span. to enable this tool, the ZT_SPANSTAT ioctl gained a number of new elements to report information about the spans: - linecompat (available signaling modes for digital spans) - spantype (T1, E1 or J1 for digital spans) - location (PCI/PCI-Express location) - manufacturer - devicetype Along the way I also found that the digital span drivers always set T1-style signaling bits in 'linecompat' even for E1 spans, and that the ZT_SPANCONFIG ioctl did not properly check these bits when configuring E1 spans. The result of this is that it was possible to configure T1-only coding/framing (AMI/B8Zs, D4/ESF) on E1 spans (but not the reverse); this has been corrected and any attempt to use T1-only coding/framing on E1 spans will now result in an error from ztcfg. Also did some minor simplification of the Makefile rules that build the userspace tools. (the basics of ztscan were written by Brandon Kruse then reworked and fleshed out by me) git-svn-id: http://svn.digium.com/svn/zaptel/branches/1.4@3278 5390a7c7-147a-4af0-8ec9-7488f05a26cb
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-02 08:37:47 +0000