0012241: [patch] New Ztdynamic driver for Redfone Communications foneBRIDGE 2 platform

Notes
(0084161) tzafrir (manager) 2008-03-18 13:52	For starters, any reason why this module shouldn't replace the current ztd-eth, that for a long time has been reputed to be broken?

(0084165) brettcar (reporter) 2008-03-18 14:04	ztd-eth could certainly be deprecated in favor of this driver. However there could be users who still have legacy hardware (the original foneBRIDGE comes to mind as does the original foneBRIDGE 2 firmware) that uses the ztd-eth driver's packet protocol. I cannot comment on if ztd-eth is actually broken or not -- likely the code itself works since ztd-ethmf is heavily based on it. If something is wrong it's probably just that some kernel feature changed name or signature and so it won't compile on a recent kernel? Perhaps open a new bug for that?

(0084166) tzafrir (manager) 2008-03-18 14:05	Builds fine on my i386 system. On my amd64 system I get the following warning: /home/tzafrir/Proj/Asterisk/DigiumRW/zaptel/branches/1.4/kernel/ztd-ethmf.c: In function ‘ztdethmf_transmit’: /home/tzafrir/Proj/Asterisk/DigiumRW/zaptel/branches/1.4/kernel/ztd-ethmf.c:370: warning: integer overflow in expression /home/tzafrir/Proj/Asterisk/DigiumRW/zaptel/branches/1.4/kernel/ztd-ethmf.c:370: warning: integer overflow in expression Line 370: zh->subaddr = htons((0x8000 \| (span_count & 0xFF)));

(0084167) tzafrir (manager) 2008-03-18 14:08	Is this report intentionally private?

(0084168) tzafrir (manager) 2008-03-18 14:12	Now I tried building vs. kernel 2.6.24-1-amd64 . Fails: /home/tzafrir/Proj/Asterisk/DigiumRW/zaptel/branches/1.4/kernel/ztd-ethmf.c: In function ‘ztdethmf_transmit’: /home/tzafrir/Proj/Asterisk/DigiumRW/zaptel/branches/1.4/kernel/ztd-ethmf.c:370: warning: integer overflow in expression /home/tzafrir/Proj/Asterisk/DigiumRW/zaptel/branches/1.4/kernel/ztd-ethmf.c:370: warning: integer overflow in expression /home/tzafrir/Proj/Asterisk/DigiumRW/zaptel/branches/1.4/kernel/ztd-ethmf.c:380: error: ‘struct net_device’ has no member named ‘hard_header’ /home/tzafrir/Proj/Asterisk/DigiumRW/zaptel/branches/1.4/kernel/ztd-ethmf.c:381: error: ‘struct net_device’ has no member named ‘hard_header’ /home/tzafrir/Proj/Asterisk/DigiumRW/zaptel/branches/1.4/kernel/ztd-ethmf.c: In function ‘ztdethmf_create’: /home/tzafrir/Proj/Asterisk/DigiumRW/zaptel/branches/1.4/kernel/ztd-ethmf.c:588: warning: passing argument 1 of ‘dev_get_by_name’ from incompatible pointer type /home/tzafrir/Proj/Asterisk/DigiumRW/zaptel/branches/1.4/kernel/ztd-ethmf.c:588: error: too few arguments to function ‘dev_get_by_name’ Please check the latest fixes to ztd-eth.c . http://svn.digium.com/view/zaptel?view=rev&revision=3578 [^] (any shorthand for this?)

(0084174) brettcar (reporter) 2008-03-18 14:28 edited on: 2008-03-18 14:32	Trivial patch for the hard_header changes: --- zaptel51orig/ztd-ethmf.c 2008-03-18 15:25:21.000000000 -0400 +++ zaptel51/ztd-ethmf.c 2008-03-18 15:28:36.000000000 -0400 @@ -366,15 +366,20 @@ /* Setup protocol and such */ skb->protocol = __constant_htons(ETH_P_ZTDETH); + #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,22) skb_set_network_header(skb,0); #else skb->nh.raw = skb->data; #endif skb->dev = dev; + +#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,24) + dev_hard_header(skb, dev, ETH_P_ZTDETH, addr, dev->dev_addr, skb->len); +#else if (dev->hard_header) dev->hard_header(skb, dev, ETH_P_ZTDETH, addr, dev->dev_addr, skb->len); - +#endif skb_queue_tail(&skbs, skb); } } @@ -580,7 +585,12 @@ } z->subaddr = htons(sub); } - z->dev = dev_get_by_name(z->ethdev); + + z->dev = dev_get_by_name( +#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,24) + &init_net, +#endif + z->ethdev); if (!z->dev) { printk("TDMoEmf: Invalid device '%s'\n", z->ethdev); kfree(z);

(0084175) brettcar (reporter) 2008-03-18 14:31	As for the integer overflows... what size is an `unsigned short' on your platform? I compile on an x86_64 AMD Opteron without that problem. The operations are clearly 16-bit wide. Maybe something changed about htons() in the kernel version you are running? Additionally the selection of private was a mistake but I cannot find a way to change it, feel free to set to public if you can.

(0084177) tzafrir (manager) 2008-03-18 14:36	Formatting is not compliant with the one used in Zaptel. Generally, please follow the Linux kernel formatting guidelines. More specifically the last few functions (anything timer_callback) are a bit off.

(0084178) tzafrir (manager) 2008-03-18 14:37	The amd64 system: Debian Testing (Lenny), kernel: 2.6.22-3-amd64 linux-headers-2.6.22-3-amd64 2.6.22-6.lenny1

(0084182) brettcar (reporter) 2008-03-18 15:04	A patch to correct formatting to meet code format guidelines was added. I'll see if I can duplicate the overflow problem with Debian Testing tomorrow.

(0084188) tzafrir (manager) 2008-03-18 15:14	Instead of a patch almost twice as big as the original source, I suppose you can just upload the new source :-)

(0084190) brettcar (reporter) 2008-03-18 15:20	Done.

(0084221) juggie (manager) 2008-03-18 22:41	Private Removed By Request of patch submitter.

(0084227) tzafrir (manager) 2008-03-19 02:27	Thanks for your timely responses. Generally looks like something that can go into Zaptel. A few minor issues: * Please provide priorities to printk messages. e.g: printk(KERN_INFO "hello\n") * We had declared a small war of ours on strncpy . See http://svn.digium.com/view/zaptel?view=rev&revision=3846 [^] However I do like to get some "second opinion" on this, as I'm not familiar with ztdynamic (here, or on IRC/mail). BTW: to avoid unnecessary makefile changes while testing, you can put the file ztd-ethmf.c in the subdirectory kernel/ and run: make MODULES_EXTRA="ztd-ethmf"

(0084228) tzafrir (manager) 2008-03-19 02:32	Also, do you happen to have any updates to the README (list of drivers, or whatever) or zaptel.conf.sample ?

(0084229) JBenden (reporter) 2008-03-19 03:01	Brett, didn't this module depend on a few simple fixes to ztcfg and ztdynamic? Or am I thinking of the Solaris version and not the Linux version?

(0084267) brettcar (reporter) 2008-03-19 13:36	Joseph, There have been some additional changes since then (in house at Redfone) to the original ztd-ethmf driver.

(0084270) tzafrir (manager) 2008-03-19 13:46	So no changes are needed? Are there any patches you're interested in applying nevertheless?

(0084272) brettcar (reporter) 2008-03-19 13:50	Actually that is an excellent point -- there are probably changes to ztcfg (at a minimum) that I neglected. I thought Joseph was asking about something else. I'm still in the process of provisioning a Lenny system so I can try and reproduce that overflow bug. Once I've tackled that I will submit patches or files against Zaptel SVN that include any other needed changes.

(0084281) tzafrir (manager) 2008-03-19 14:33	If all else fails, use debootstrap :-) Just be sure then to set KVERS explicitly in the make command-line, as it will not be your running kernel.

(0084327) brettcar (reporter) 2008-03-20 11:43	branch1.4.diff contains an `svn diff' against the current tree at http://svn.digium.com/svn/zaptel/branches/1.4 [^] Included are changes to the README and the sample zaptel.conf. No changes to ztcfg or ztdynamic.c should be required.

(0084328) qwell (administrator) 2008-03-20 12:03	struct ztdeth z = NULL, Z = NULL; I would fail this patch based solely on that. Using only case to differentiate variables is BAD.

(0084330) tzafrir (manager) 2008-03-20 12:12	So no ztcfg changes are needed, right? Another note: ztd-ethmf reads: /* We don't have SSCANF :( Gotta do this the hard way / 'grep sscanf kernel//*.c' disagrees :-)

(0084331) brettcar (reporter) 2008-03-20 12:18	No ztcfg changes needed. Note that ztd-eth.c has the same comment too. A lot of the code is the same. ;) We can replace that routine in the future with a sscanf call.

(0084342) brettcar (reporter) 2008-03-20 13:37	qwell, I agree that's not a particularly good convention but the change is pretty trivial. --- kernel/ztd-ethmf.c.old 2008-03-20 15:54:35.000000000 +0000 +++ kernel/ztd-ethmf.c 2008-03-20 18:39:54.000000000 +0000 @@ -98,17 +98,17 @@ struct ztdeth ztdethmf_getz(struct zt_span span) { unsigned long flags; - struct ztdeth z = NULL, Z = NULL; + struct ztdeth z = NULL, found = NULL; spin_lock_irqsave(&zlock, flags); z = zdevs; while (z) { if (z->span == span) - Z = z; + found = z; z = z->next; } spin_unlock_irqrestore(&zlock, flags); - return Z; + return found; } struct zt_span ztdethmf_getspan(unsigned char addr, unsigned short subaddr)

(0084343) tzafrir (manager) 2008-03-20 13:38	The following is probably a general note regarding dynamic spans, but still I'd appreciate it if someone would at least document known issues and best practices. Suppose you have an ethmf span configured to point to 00:11:22:33:44:55 . And now you actually actually want it to point to a different device at 00:11:22:33:44:50 . What exactly do you need to do? From what I understand, you can't simply edit zaptel.conf and re-run ztcfg . This is because: 1. in ztcfg - it will attempt to destroy all spans listed in zaptel.conf . but will not do anything about dynamic spans that are no longer listed there. 2. in kernel/ztdynamic.c: you cannot destroy a span that is in use. So what is the correct order of operations?

(0084346) brettcar (reporter) 2008-03-20 13:53	tzafrir, The procedure I use is as follows. Suppose the spans are running on device eth0. (For loading a new version of the module) # ifconfig eth0 down # ztcfg -s # rmmod ztd-ethmf # rmmod ztdynamic (Make changes to zaptel.conf) # modprobe ztd-ethmf # ifconfig eth0 up OR (just for zaptel.conf changes) # ifconfig eth0 down # ztcfg -s (Make changes to zaptel.conf) # ztcfg # ifconfig eth0 up Allow me to explain. `ztcfg -s' will remove the dynamic spans that are currently running. This lets you unload the modules or edit zaptel.conf. Running `ztcfg' again will create the new spans. In the first example I only list `modeprobe ztd-ethmf'. This is intentional. Running `ztcfg' without the right modules loaded will load the modules and then load the spans. However, some installations have module loading hooks that run `ztcfg' when a Zaptel module is loaded. This results in `ztcfg' getting called twice and can create a race condition where multiple (identical) spans are instantiated. Finally, it is important to bring the Ethernet interface down when removing the spans with `ztcfg -s'. Removing the spans while processing packets will cause the system to hang. (This should probably be filed as a separate bug. I don't have the resources to tackle it right now and it exists with ztd-eth as well.)

(0084347) JBenden (reporter) 2008-03-20 14:02	Once this becomes a part of SVN, I'd have no problems in helping to fix remaining little oddities and problems. I'm sure Brett would be more than happy to pass me a list of their known issues. Additionally, I would also be happy to scan this code with a major software vendors static analysis tool, and resolve any problems reported by it.

(0084349) russell (administrator) 2008-03-20 14:05	"Once this becomes a part of SVN, I'd have no problems in helping to fix remaining little oddities and problems." Um, it shouldn't go in to svn with any known oddities or problems.

(0084351) JBenden (reporter) 2008-03-20 14:12	You know what I mean, please don't take that verbatim. :) Much of the existing Zaptel code fails many items in a static analysis, many of which are very important since this code runs in a kernel context. Additionally, ztd-eth/ztdynamic is ripe with problems because it's been largely ignored. This new driver is in a state of being committed, I would then just open new patches to fix span unloading and reloading without hanging the box, issues reported by static analysis, other items mentioned by Brett, etc.

(0084355) tzafrir (manager) 2008-03-20 14:38	Another matter of style: ztdethmf_rcv() and ztdethmf_transmit() could use some reduced nesting. e.g: in ztdethmf_create: instead of: if (z) { some_long_code; } return z; use: if (!z) return NULL; some_long_code; In other places got-s may help. Also in the same place above: is there a better way to fail when there's not enough memory?

(0084356) JBenden (reporter) 2008-03-20 14:47	Wasn't their talk with the new coding guidelines to not do any if/while/for/etc without braces?

(0084362) tzafrir (manager) 2008-03-20 15:06	It wasn't my vote there :-) And anyway, Zaptel should generally follow the Linux kernel CodingStyle.

(0084404) brettcar (reporter) 2008-03-21 12:04	I have incorpated all the above suggestions in `multiframe-032108.patch' which applies against the current SVN checkout of the 1.4 branch. Modifications include addition of kernel/ztd-ethmf.c, README changes, and sample zaptel.conf changes. At this point I would like to request that this gets moved forward for inclusion in SVN.

(0084423) tzafrir (manager) 2008-03-22 22:27	Looks OK to me. Commit? Commit without editing the list of modules in the makefile (till the next release?)

(0084430) svnbot (reporter) 2008-03-23 17:25	Repository: zaptel Revision: 4069 U branches/1.4/README A branches/1.4/kernel/ztd-ethmf.c U branches/1.4/zaptel.conf.sample ------------------------------------------------------------------------ r4069 \| tzafrir \| 2008-03-23 17:25:20 -0500 (Sun, 23 Mar 2008) \| 10 lines ztd-ethmf.c: Ztdynamic driver for Redfone Communications foneBRIDGE 2. This driver uses a network protocol that is different from the existing ztd-eth driver. This commit adds the driver though does not yet build it by default. For the moment use make MODULES_EXTRA="ztd-ethmf" . Patch multiframe-032108.patch from 0012241 by brettcar. ------------------------------------------------------------------------ http://svn.digium.com/view/zaptel?view=rev&revision=4069 [^]

(0084795) svnbot (reporter) 2008-03-31 12:22	Repository: zaptel Revision: 4113 U branches/1.4/Makefile U branches/1.4/README D branches/1.4/kernel/ztd-ethmf.c U branches/1.4/zaptel.conf.sample ------------------------------------------------------------------------ r4113 \| russell \| 2008-03-31 12:22:26 -0500 (Mon, 31 Mar 2008) \| 4 lines Remove the ztd-ethmf driver for now. It was not ready to be committed. (issue 0012241) ------------------------------------------------------------------------ http://svn.digium.com/view/zaptel?view=rev&revision=4113 [^]

(0084797) russell (administrator) 2008-03-31 12:24	1) The copyright header on this module indicates that someone other than the submitter of the code did most of the work. What is the history here? Brett, did you get these modifications made and you own this work? Otherwise, we have to ensure that the original author has a license on file for his contributions. 2) I have not done an extensive code review on this module. However, one thing I noticed at a quick glance was open coded linked lists. We should not be introducing any new code with this. It should use the kernel linked list implementation, instead.

(0084798) russell (administrator) 2008-03-31 12:27	ah, of course, JBenden is on this issue. JBenden, have you completed the license agreement on this site to cover this code?

(0084800) JBenden (reporter) 2008-03-31 12:45	Yes, I have a disclaimer on file.

(0084803) tzafrir (manager) 2008-03-31 13:08	I'll just point out that the linked lists originated in ztd-eth.c, which is already in Zaptel.

(0084818) russell (administrator) 2008-03-31 18:11	JBenden, according to your mantis account, you do not have a current license agreement on file. For new code submissions, you must fill out the electronic license agreement. Click "sign license" at the top of the page. tzafrir: yes, I figured as much. That doesn't mean we should introduce copies of bad code. :)

(0084823) JBenden (reporter) 2008-03-31 19:07	I have had a license on file since around 8/2005, which was around the time of this bug: http://bugs.digium.com/view.php?id=4953 [^] I had faxed a disclaimer to you guys. You guys always give me a hard time with everything I've ever helped with here - it's very annoying. If I need to submit another, I can do so, but I really ought to have one on file already. Sorry - just cranky from the ongoing battles with stuff here...

(0084824) russell (administrator) 2008-03-31 19:20	Well, hopefully the click through license agreement won't be too much of a burden. We switched to electronic handling of the process to make it much easier. The text of the agreement changed when we switched to the new system, so we have to get new submissions from everyone. But, like I said, we have tried to make it as easy as possible. I'm not trying to give you a hard time. I'm trying to ensure that we follow the rules in place with regards to licensing. Before that is taken care of, I'm not even supposed to look at the code, so I haven't been able to give it a more thorough review than the copyright header for the most part.

(0084826) JBenden (reporter) 2008-03-31 19:29	So sorry - I've just had a rough time around here. :) So, I read the license - the past one was much more honoring of my rights. In simple terms, does this license revoke my Copyright? I understand I'm allowing you to run off with it, for any purpose including commercial purposes - I've let Redfone run off with it ;) - I just do NOT want to loose my Copyright and my name from it as I want the recognition on the fact that I reformulated the TDMoE protocol. If that's the case, I'll click submit. :)

(0085045) svnbot (reporter) 2008-04-05 15:14	Repository: zaptel Revision: 4151 _U team/mattf/zaptel-1.4-stackcleanup/ U team/mattf/zaptel-1.4-stackcleanup/Makefile U team/mattf/zaptel-1.4-stackcleanup/README U team/mattf/zaptel-1.4-stackcleanup/doc/module-parameters.txt U team/mattf/zaptel-1.4-stackcleanup/firmware/Makefile U team/mattf/zaptel-1.4-stackcleanup/kernel/wct4xxp/base.c U team/mattf/zaptel-1.4-stackcleanup/kernel/wctdm.c U team/mattf/zaptel-1.4-stackcleanup/kernel/wctdm24xxp/GpakApi.c U team/mattf/zaptel-1.4-stackcleanup/kernel/wctdm24xxp/GpakApi.h U team/mattf/zaptel-1.4-stackcleanup/kernel/wctdm24xxp/Kbuild U team/mattf/zaptel-1.4-stackcleanup/kernel/wctdm24xxp/base.c U team/mattf/zaptel-1.4-stackcleanup/kernel/wctdm24xxp/wctdm24xxp.h U team/mattf/zaptel-1.4-stackcleanup/kernel/wcte12xp/GpakApi.c U team/mattf/zaptel-1.4-stackcleanup/kernel/wcte12xp/GpakApi.h U team/mattf/zaptel-1.4-stackcleanup/kernel/wcte12xp/GpakErrs.h U team/mattf/zaptel-1.4-stackcleanup/kernel/wcte12xp/GpakHpi.h U team/mattf/zaptel-1.4-stackcleanup/kernel/wcte12xp/Kbuild U team/mattf/zaptel-1.4-stackcleanup/kernel/wcte12xp/base.c U team/mattf/zaptel-1.4-stackcleanup/kernel/wcte12xp/gpakenum.h U team/mattf/zaptel-1.4-stackcleanup/kernel/wcte12xp/vpmadt032.c U team/mattf/zaptel-1.4-stackcleanup/kernel/wcte12xp/wcte12xp.h U team/mattf/zaptel-1.4-stackcleanup/kernel/xpp/README.Astribank U team/mattf/zaptel-1.4-stackcleanup/kernel/xpp/utils/Makefile U team/mattf/zaptel-1.4-stackcleanup/kernel/xpp/utils/print_modes.c U team/mattf/zaptel-1.4-stackcleanup/kernel/xpp/utils/zconf/Zaptel/Hardware/PCI.pm U team/mattf/zaptel-1.4-stackcleanup/kernel/zaptel-base.c D team/mattf/zaptel-1.4-stackcleanup/kernel/ztd-ethmf.c U team/mattf/zaptel-1.4-stackcleanup/zaptel.conf.sample ------------------------------------------------------------------------ r4151 \| mattf \| 2008-04-05 15:14:28 -0500 (Sat, 05 Apr 2008) \| 101 lines Merged revisions 4095-4096,4100-4101,4106-4107,4110,4113-4114,4119,4122,4130,4134,4137,4139,4141 via svnmerge from https://origsvn.digium.com/svn/zaptel/branches/1.4 [^] ........ r4095 \| tzafrir \| 2008-03-27 15:37:56 -0500 (Thu, 27 Mar 2008) \| 2 lines Also install wct4xxp/wct4xxp.o in 2.4 kernels... ........ r4096 \| sruffell \| 2008-03-27 16:17:46 -0500 (Thu, 27 Mar 2008) \| 5 lines - Updated wctdm24xxp and wcte12xp driver which are now more tolerant of systems which do not exhibit good real-time characteristics. - Bringing in improvements to battery alarm generation that was on kpflemings battery_alarms branch. (Issue 0012099) ........ r4100 \| sruffell \| 2008-03-27 16:48:30 -0500 (Thu, 27 Mar 2008) \| 2 lines The location of the fxo_modes structure changed. ........ r4101 \| sruffell \| 2008-03-27 17:08:24 -0500 (Thu, 27 Mar 2008) \| 3 lines No need to make the wctdm_fxomodes.h file anymore, since it would be the same as the fxo_modes.h file. ........ r4106 \| tzafrir \| 2008-03-29 01:30:02 -0500 (Sat, 29 Mar 2008) \| 2 lines Document some ABI changes. ........ r4107 \| tzafrir \| 2008-03-29 01:57:44 -0500 (Sat, 29 Mar 2008) \| 2 lines Minor asciidoc fix. ........ r4110 \| tzafrir \| 2008-03-31 03:30:17 -0500 (Mon, 31 Mar 2008) \| 5 lines Document when "D-Chan RX Bad checksum" is not a problem. Merged revisions 4109 via svnmerge from http://svn.digium.com/svn/zaptel/branches/1.2 [^] ........ r4113 \| russell \| 2008-03-31 12:27:08 -0500 (Mon, 31 Mar 2008) \| 4 lines Remove the ztd-ethmf driver for now. It was not ready to be committed. (issue 0012241) ........ r4114 \| russell \| 2008-03-31 12:39:14 -0500 (Mon, 31 Mar 2008) \| 2 lines revert a portion of rev 4113 that was committed by accident ........ r4119 \| tzafrir \| 2008-03-31 19:45:04 -0500 (Mon, 31 Mar 2008) \| 7 lines Do clean some modules when there's no kernel tree available. (and block the backport of r4082). Merged revisions 4118 via svnmerge from http://svn.digium.com/svn/zaptel/branches/1.2 [^] ........ r4122 \| sruffell \| 2008-04-01 11:39:05 -0500 (Tue, 01 Apr 2008) \| 3 lines Work around for host bridges that generate fast back to back transactions which the current version of the quad span cards do not advertise support for. ........ r4130 \| markster \| 2008-04-03 18:27:33 -0500 (Thu, 03 Apr 2008) \| 2 lines Have to use 'O' since 'F' is reserved (MFR2 fOrward) ........ r4134 \| mattf \| 2008-04-04 11:21:06 -0500 (Fri, 04 Apr 2008) \| 1 line ........ r4137 \| mattf \| 2008-04-04 12:47:58 -0500 (Fri, 04 Apr 2008) \| 1 line Add support for AEX410 ........ r4139 \| tzafrir \| 2008-04-04 13:20:16 -0500 (Fri, 04 Apr 2008) \| 5 lines Zaptel::Hardware - Add support for AEX410. Merged revisions 4138 via svnmerge from http://svn.digium.com/svn/zaptel/branches/1.2 [^] ........ r4141 \| markster \| 2008-04-04 18:12:04 -0500 (Fri, 04 Apr 2008) \| 2 lines Allow continuous MFR2 transmission continuously ........ ------------------------------------------------------------------------ http://svn.digium.com/view/zaptel?view=rev&revision=4151 [^]

(0085224) JBenden (reporter) 2008-04-09 13:11	Hello?

(0085938) brettcar (reporter) 2008-04-24 08:45	What needs to be reviewed or changed in order to recommit the Multiframe driver back to Zaptel?

(0087872) JBenden (reporter) 2008-06-05 16:56	I have signed the Digium license agreement. Any chance of this moving forward again?

(0088407) svnbot (reporter) 2008-06-07 13:56	Repository: dahdi Revision: 4069 U branches/1.4/README A branches/1.4/kernel/ztd-ethmf.c U branches/1.4/zaptel.conf.sample ------------------------------------------------------------------------ r4069 \| tzafrir \| 2008-06-07 13:56:47 -0500 (Sat, 07 Jun 2008) \| 10 lines ztd-ethmf.c: Ztdynamic driver for Redfone Communications foneBRIDGE 2. This driver uses a network protocol that is different from the existing ztd-eth driver. This commit adds the driver though does not yet build it by default. For the moment use make MODULES_EXTRA="ztd-ethmf" . Patch multiframe-032108.patch from 0012241 by brettcar. ------------------------------------------------------------------------ http://svn.digium.com/view/dahdi?view=rev&revision=4069 [^]

(0088409) svnbot (reporter) 2008-06-07 13:58	Repository: dahdi Revision: 4113 U branches/1.4/Makefile U branches/1.4/README D branches/1.4/kernel/ztd-ethmf.c U branches/1.4/zaptel.conf.sample ------------------------------------------------------------------------ r4113 \| russell \| 2008-06-07 13:58:05 -0500 (Sat, 07 Jun 2008) \| 4 lines Remove the ztd-ethmf driver for now. It was not ready to be committed. (issue 0012241) ------------------------------------------------------------------------ http://svn.digium.com/view/dahdi?view=rev&revision=4113 [^]

(0088411) svnbot (reporter) 2008-06-07 13:59	Repository: dahdi Revision: 4151 _U team/mattf/zaptel-1.4-stackcleanup/ U team/mattf/zaptel-1.4-stackcleanup/Makefile U team/mattf/zaptel-1.4-stackcleanup/README U team/mattf/zaptel-1.4-stackcleanup/doc/module-parameters.txt U team/mattf/zaptel-1.4-stackcleanup/firmware/Makefile U team/mattf/zaptel-1.4-stackcleanup/kernel/wct4xxp/base.c U team/mattf/zaptel-1.4-stackcleanup/kernel/wctdm.c U team/mattf/zaptel-1.4-stackcleanup/kernel/wctdm24xxp/GpakApi.c U team/mattf/zaptel-1.4-stackcleanup/kernel/wctdm24xxp/GpakApi.h U team/mattf/zaptel-1.4-stackcleanup/kernel/wctdm24xxp/Kbuild U team/mattf/zaptel-1.4-stackcleanup/kernel/wctdm24xxp/base.c U team/mattf/zaptel-1.4-stackcleanup/kernel/wctdm24xxp/wctdm24xxp.h U team/mattf/zaptel-1.4-stackcleanup/kernel/wcte12xp/GpakApi.c U team/mattf/zaptel-1.4-stackcleanup/kernel/wcte12xp/GpakApi.h U team/mattf/zaptel-1.4-stackcleanup/kernel/wcte12xp/GpakErrs.h U team/mattf/zaptel-1.4-stackcleanup/kernel/wcte12xp/GpakHpi.h U team/mattf/zaptel-1.4-stackcleanup/kernel/wcte12xp/Kbuild U team/mattf/zaptel-1.4-stackcleanup/kernel/wcte12xp/base.c U team/mattf/zaptel-1.4-stackcleanup/kernel/wcte12xp/gpakenum.h U team/mattf/zaptel-1.4-stackcleanup/kernel/wcte12xp/vpmadt032.c U team/mattf/zaptel-1.4-stackcleanup/kernel/wcte12xp/wcte12xp.h U team/mattf/zaptel-1.4-stackcleanup/kernel/xpp/README.Astribank U team/mattf/zaptel-1.4-stackcleanup/kernel/xpp/utils/Makefile U team/mattf/zaptel-1.4-stackcleanup/kernel/xpp/utils/print_modes.c U team/mattf/zaptel-1.4-stackcleanup/kernel/xpp/utils/zconf/Zaptel/Hardware/PCI.pm U team/mattf/zaptel-1.4-stackcleanup/kernel/zaptel-base.c D team/mattf/zaptel-1.4-stackcleanup/kernel/ztd-ethmf.c U team/mattf/zaptel-1.4-stackcleanup/zaptel.conf.sample ------------------------------------------------------------------------ r4151 \| mattf \| 2008-06-07 13:59:15 -0500 (Sat, 07 Jun 2008) \| 101 lines Merged revisions 4095-4096,4100-4101,4106-4107,4110,4113-4114,4119,4122,4130,4134,4137,4139,4141 via svnmerge from https://origsvn.digium.com/svn/zaptel/branches/1.4 [^] ........ r4095 \| tzafrir \| 2008-03-27 15:37:56 -0500 (Thu, 27 Mar 2008) \| 2 lines Also install wct4xxp/wct4xxp.o in 2.4 kernels... ........ r4096 \| sruffell \| 2008-03-27 16:17:46 -0500 (Thu, 27 Mar 2008) \| 5 lines - Updated wctdm24xxp and wcte12xp driver which are now more tolerant of systems which do not exhibit good real-time characteristics. - Bringing in improvements to battery alarm generation that was on kpflemings battery_alarms branch. (Issue 0012099) ........ r4100 \| sruffell \| 2008-03-27 16:48:30 -0500 (Thu, 27 Mar 2008) \| 2 lines The location of the fxo_modes structure changed. ........ r4101 \| sruffell \| 2008-03-27 17:08:24 -0500 (Thu, 27 Mar 2008) \| 3 lines No need to make the wctdm_fxomodes.h file anymore, since it would be the same as the fxo_modes.h file. ........ r4106 \| tzafrir \| 2008-03-29 01:30:02 -0500 (Sat, 29 Mar 2008) \| 2 lines Document some ABI changes. ........ r4107 \| tzafrir \| 2008-03-29 01:57:44 -0500 (Sat, 29 Mar 2008) \| 2 lines Minor asciidoc fix. ........ r4110 \| tzafrir \| 2008-03-31 03:30:17 -0500 (Mon, 31 Mar 2008) \| 5 lines Document when "D-Chan RX Bad checksum" is not a problem. Merged revisions 4109 via svnmerge from http://svn.digium.com/svn/zaptel/branches/1.2 [^] ........ r4113 \| russell \| 2008-03-31 12:27:08 -0500 (Mon, 31 Mar 2008) \| 4 lines Remove the ztd-ethmf driver for now. It was not ready to be committed. (issue 0012241) ........ r4114 \| russell \| 2008-03-31 12:39:14 -0500 (Mon, 31 Mar 2008) \| 2 lines revert a portion of rev 4113 that was committed by accident ........ r4119 \| tzafrir \| 2008-03-31 19:45:04 -0500 (Mon, 31 Mar 2008) \| 7 lines Do clean some modules when there's no kernel tree available. (and block the backport of r4082). Merged revisions 4118 via svnmerge from http://svn.digium.com/svn/zaptel/branches/1.2 [^] ........ r4122 \| sruffell \| 2008-04-01 11:39:05 -0500 (Tue, 01 Apr 2008) \| 3 lines Work around for host bridges that generate fast back to back transactions which the current version of the quad span cards do not advertise support for. ........ r4130 \| markster \| 2008-04-03 18:27:33 -0500 (Thu, 03 Apr 2008) \| 2 lines Have to use 'O' since 'F' is reserved (MFR2 fOrward) ........ r4134 \| mattf \| 2008-04-04 11:21:06 -0500 (Fri, 04 Apr 2008) \| 1 line ........ r4137 \| mattf \| 2008-04-04 12:47:58 -0500 (Fri, 04 Apr 2008) \| 1 line Add support for AEX410 ........ r4139 \| tzafrir \| 2008-04-04 13:20:16 -0500 (Fri, 04 Apr 2008) \| 5 lines Zaptel::Hardware - Add support for AEX410. Merged revisions 4138 via svnmerge from http://svn.digium.com/svn/zaptel/branches/1.2 [^] ........ r4141 \| markster \| 2008-04-04 18:12:04 -0500 (Fri, 04 Apr 2008) \| 2 lines Allow continuous MFR2 transmission continuously ........ ------------------------------------------------------------------------ http://svn.digium.com/view/dahdi?view=rev&revision=4151 [^]

Issue History
Date Modified	Username	Field	Change
2008-03-17 12:50	brettcar	New Issue
2008-03-17 12:50	brettcar	Zaptel Version	=> 1.4.9.2
2008-03-17 12:50	brettcar	SVN Branch (only for SVN checkou	=> N/A
2008-03-17 12:51	brettcar	File Added: ztd-ethmf.c
2008-03-17 13:51	file	Category	ztdynamic => NewFeature
2008-03-17 13:51	file	Summary	New Ztdynamic driver for Redfone Communications foneBRIDGE 2 platform => [patch] New Ztdynamic driver for Redfone Communications foneBRIDGE 2 platform
2008-03-18 13:52	tzafrir	Note Added: 0084161
2008-03-18 14:04	brettcar	Note Added: 0084165
2008-03-18 14:05	tzafrir	Note Added: 0084166
2008-03-18 14:08	tzafrir	Note Added: 0084167
2008-03-18 14:12	tzafrir	Note Added: 0084168
2008-03-18 14:28	brettcar	Note Added: 0084174
2008-03-18 14:31	brettcar	Note Added: 0084175
2008-03-18 14:32	brettcar	Note Edited: 0084174
2008-03-18 14:36	tzafrir	Note Added: 0084177
2008-03-18 14:37	tzafrir	Note Added: 0084178
2008-03-18 15:03	brettcar	File Added: formatting.patch
2008-03-18 15:04	brettcar	Note Added: 0084182
2008-03-18 15:14	tzafrir	Note Added: 0084188
2008-03-18 15:18	brettcar	File Added: ztd-ethmf-formatted.c
2008-03-18 15:20	brettcar	Note Added: 0084190
2008-03-18 22:41	juggie	Note Added: 0084221
2008-03-18 22:41	juggie	View Status	private => public
2008-03-19 02:27	tzafrir	Note Added: 0084227
2008-03-19 02:32	tzafrir	Note Added: 0084228
2008-03-19 02:59	JBenden	Issue Monitored: JBenden
2008-03-19 03:01	JBenden	Note Added: 0084229
2008-03-19 13:36	brettcar	Note Added: 0084267
2008-03-19 13:46	tzafrir	Note Added: 0084270
2008-03-19 13:50	brettcar	Note Added: 0084272
2008-03-19 14:33	tzafrir	Note Added: 0084281
2008-03-20 11:40	brettcar	File Added: branch1.4.diff
2008-03-20 11:43	brettcar	Note Added: 0084327
2008-03-20 12:03	qwell	Note Added: 0084328
2008-03-20 12:12	tzafrir	Note Added: 0084330
2008-03-20 12:18	brettcar	Note Added: 0084331
2008-03-20 13:37	brettcar	Note Added: 0084342
2008-03-20 13:38	tzafrir	Note Added: 0084343
2008-03-20 13:53	brettcar	Note Added: 0084346
2008-03-20 14:02	JBenden	Note Added: 0084347
2008-03-20 14:05	russell	Note Added: 0084349
2008-03-20 14:12	JBenden	Note Added: 0084351
2008-03-20 14:38	tzafrir	Note Added: 0084355
2008-03-20 14:47	JBenden	Note Added: 0084356
2008-03-20 15:06	tzafrir	Note Added: 0084362
2008-03-21 12:00	brettcar	File Added: multiframe-032108.patch
2008-03-21 12:04	brettcar	Note Added: 0084404
2008-03-22 22:27	tzafrir	Note Added: 0084423
2008-03-23 17:25	svnbot	Checkin
2008-03-23 17:25	svnbot	Note Added: 0084430
2008-03-31 12:22	svnbot	Checkin
2008-03-31 12:22	svnbot	Note Added: 0084795
2008-03-31 12:24	russell	Note Added: 0084797
2008-03-31 12:24	russell	Status	new => feedback
2008-03-31 12:27	russell	Note Added: 0084798
2008-03-31 12:45	JBenden	Note Added: 0084800
2008-03-31 13:08	tzafrir	Note Added: 0084803
2008-03-31 18:11	russell	Note Added: 0084818
2008-03-31 19:07	JBenden	Note Added: 0084823
2008-03-31 19:20	russell	Note Added: 0084824
2008-03-31 19:29	JBenden	Note Added: 0084826
2008-04-05 15:14	svnbot	Checkin
2008-04-05 15:14	svnbot	Note Added: 0085045
2008-04-09 13:11	JBenden	Note Added: 0085224
2008-04-24 08:45	brettcar	Note Added: 0085938
2008-06-05 16:56	JBenden	Note Added: 0087872
2008-06-07 13:56	svnbot	Checkin
2008-06-07 13:56	svnbot	Note Added: 0088407
2008-06-07 13:58	svnbot	Checkin
2008-06-07 13:58	svnbot	Note Added: 0088409
2008-06-07 13:59	svnbot	Checkin
2008-06-07 13:59	svnbot	Note Added: 0088411

Relationships