Tilman Schmidt schreef op wo 18-09-2019 om 18:16 [+0000]: So I just implemented a timeout and if, after that time, the HD_READY_SEND_ATDATA signal still hasn't arrived, the driver sends the next command anyway, assuming that the signal has just been lost and hoping that the base will complain in a sensible way if that assumption is wrong, most probably by indicating a stall. (A possible alternative would be to send an empty command, analogously to what gigaset_write_cmd() does in the symmetric case...
Am 18.09.2019 um 20:16 schrieb Tilman Schmidt: Hi guys, so finally I couldn't resist looking into this a bit more. Isn't our whole industry based on creating irresistible temptations? Thanks for giving in :-) Malte
Hi guys, so finally I couldn't resist looking into this a bit more. Am 19.08.2019 um 10:30 schrieb Paul Bolle: Jul 26 09:00:02 servi kernel: [41511.530376] bas_gigaset 1-1.5:1.0: timeout waiting for HD_READY_SEND_ATDATA This seems to be the root problem. You see, the Gigaset base is supposed to send an HD_READY_SEND_ATDATA message whenever it is ready to receive a command, and the driver is not supposed to send a command as long as it hasn't received that message. However the Gigaset documentation...
Am 18.09.2019 um 00:51 schrieb Tilman Schmidt: Hi Paul, Am 17.09.2019 um 20:28 schrieb Paul Bolle: As far as I know the gigaset driver was written by people unfamiliar with i4l, CAPI, the linux network stack, the linux USB stack, etc. That is correct as far as I am concerned. "Etc." would notably include the serial line discipline interface which is used for connecting the ser_gigaset driver to the serial port framework of the kernel. (I was in fact familiar with the concept of line disciplines from...
Am 17.09.2019 um 20:28 schrieb Paul Bolle: Malte Forkel schreef op di 17-09-2019 om 17:32 [+0000]: I think I found out what might be causing the connection failures I reported: There seems to be a conflict between gigacontr using the USB connection to the Gigaset base and a digital video recorder program (vdr) using a DVB-C adapter connected to the Raspberry Pis. This is a Hauppage WinTV soloHD USB adapter; is uses the em28xx kernel driver. Good news! Both Gigaset base and DVB-C adapter are connected...
Tilman Schmidt schreef op di 17-09-2019 om 22:51 [+0000]: "Etc." would notably include the serial line discipline interface which is used for connecting the ser_gigaset driver to the serial port framework of the kernel. (I was in fact familiar with the concept of line disciplines from Unix SVR4 but they Linux implementation is quite different and I had to fix a few errors and omissions in Documentation/serial/tty.txt first before being able to use it.) This reminds me that I had to ask you what on...
Hi Paul, Am 17.09.2019 um 20:28 schrieb Paul Bolle: As far as I know the gigaset driver was written by people unfamiliar with i4l, CAPI, the linux network stack, the linux USB stack, etc. That is correct as far as I am concerned. "Etc." would notably include the serial line discipline interface which is used for connecting the ser_gigaset driver to the serial port framework of the kernel. (I was in fact familiar with the concept of line disciplines from Unix SVR4 but they Linux implementation is...
Malte Forkel schreef op di 17-09-2019 om 17:32 [+0000]: I think I found out what might be causing the connection failures I reported: There seems to be a conflict between gigacontr using the USB connection to the Gigaset base and a digital video recorder program (vdr) using a DVB-C adapter connected to the Raspberry Pis. This is a Hauppage WinTV soloHD USB adapter; is uses the em28xx kernel driver. Good news! Both Gigaset base and DVB-C adapter are connected to an external USB hub with its own power...
Malte Forkel schreef op di 17-09-2019 om 17:01 [+0000]: Thanks, Paul, for working on the driver! I'm very much in favor of keeping it in the kernel. I would definitely like to continue using it to control my Gigaset base, e.g. for initiating telephone calls from my desktop and retrieving the list of incoming and outgoing connections. Please let me know what I can do to support that cause. Test it like there's no tomorrow! And learn C, while you're at it. Paul Bolle
I think I found out what might be causing the connection failures I reported: There seems to be a conflict between gigacontr using the USB connection to the Gigaset base and a digital video recorder program (vdr) using a DVB-C adapter connected to the Raspberry Pis. This is a Hauppage WinTV soloHD USB adapter; is uses the em28xx kernel driver. Both Gigaset base and DVB-C adapter are connected to an external USB hub with its own power supply. So insufficient power should not be the problem. Also,...
Am 13.09.2019 um 20:23 schrieb Paul Bolle: Paul Bolle schreef op za 31-08-2019 om 21:09 [+0200]: Perhaps I'll try a similar test on my live base (behind a ISDN <-> VOIP bridge). If I'll do, the results will be summarized here. What I have done instead is to hack on the driver with a sledgehammer: - drop ser-gigaset.c; - drop capi.c; - remove /a lot/ of unreachable code; - make the driver Unimodem only. This allowed me to cut out 2/3s of the driver. And in the end I looked at a driver depending only...
Paul Bolle schreef op za 31-08-2019 om 21:09 [+0200]: Perhaps I'll try a similar test on my live base (behind a ISDN <-> VOIP bridge). If I'll do, the results will be summarized here. What I have done instead is to hack on the driver with a sledgehammer: - drop ser-gigaset.c; - drop capi.c; - remove a lot of unreachable code; - make the driver Unimodem only. This allowed me to cut out 2/3s of the driver. And in the end I looked at a driver depending only on TTY and USB. gigacontr still works, to...
Malte Forkel schreef op ma 19-08-2019 om 16:18 [+0000]: No spare base, but currently I'm its only user. So no reason not to run tests. I've run a few hundreds downloads of the log from a spare base in quick succession. Think: every 15 seconds. Nothing quite as serious as you saw in the logs. Note that I'm running v5.3-rcx. Perhaps I'll try a similar test on my live base (behind a ISDN <-> VOIP bridge). If I'll do, the results will be summarized here. Paul Bolle
Hi Paul, Am 19.08.2019 um 10:30 schrieb Paul Bolle: Hi Malte, Malte Forkel schreef op do 15-08-2019 om 11:55 [+0000]: I'm still using self-compiled modules (capi and gigaset) to connect to a Gigaset 3075 base from Raspberry Pi running Raspbian stretch (currently kernel 4.19.58-v7+) as reported in an earlier post (https://sourceforge.net/p/gigaset307x/discussion/75814/thread/c03320a0/). Malte and I determined off list that Malte's setup doesn't require capi. dummy link level will do. But this problem...
In my experiments, unplugging and replugging the USB cable to the base helped best. At one point I even tried to find out whether I could simulate that from the driver, but found no way to do so Temporarily unplugging the base did not work for me (just tried one, though). These are the log entries caused by unplugging and replugging: Aug 18 19:28:29 servi kernel: [95501.773787] bas_gigaset 1-1.5.1:1.0: disconnecting Gigaset base Aug 18 19:28:45 servi kernel: [95517.275818] usb 1-1.5.1: Product: Gigaset...
Hi Malte, Malte Forkel schreef op do 15-08-2019 om 11:55 [+0000]: I'm still using self-compiled modules (capi and gigaset) to connect to a Gigaset 3075 base from Raspberry Pi running Raspbian stretch (currently kernel 4.19.58-v7+) as reported in an earlier post (https://sourceforge.net/p/gigaset307x/discussion/75814/thread/c03320a0/). Malte and I determined off list that Malte's setup doesn't require capi. dummy link level will do. But this problem also happens while running the dummy LL. Too bad....
Tilman Schmidt schreef op za 17-08-2019 om 16:42 [+0000]: In my experiments, unplugging and replugging the USB cable to the base helped best. At one point I even tried to find out whether I could simulate that from the driver, but found no way to do so. So I assume a rmmod/insmod sequence (or its modprobe equivalent) didn't reset the base state to something usable? Paul Bolle
In my experiments, unplugging and replugging the USB cable to the base helped best. At one point I even tried to find out whether I could simulate that from the driver, but found no way to do so.
Is there anything I can do short of rebooting to access the Gigaset base again?
I'm afraid I cannot help you. I don't have a Gigaset base anymore, and those "endpoint stalled" errors were always difficult to make sense of even when I encountered them on my own installation, let alone remotely.
Hello, it seems I'm the only one needing help with the Gigaset drivers... :-) I'm still using self-compiled modules (capi and gigaset) to connect to a Gigaset 3075 base from Raspberry Pi running Raspbian stretch (currently kernel 4.19.58-v7+) as reported in an earlier post (https://sourceforge.net/p/gigaset307x/discussion/75814/thread/c03320a0/). Every hour, the base gets queried for the journal log entries by a cron job. I'm also using this for dialing. Last year, connection problems requiring a...
and one that interprets and dials text selected on my Windows desktop. "Dials text"? It uses the current text selection, presumably a telephone number, to run a CGI script on the Rasberry Pi that interprets the text and has the Gigaset base dial the number.. You're free to dive into the source to see what each individual message might mean, what triggers them, etc. (Drop in an email if you need a few pointers.) Perhaps a few tweaks to the code might make those messages go away. Thanks. But I know...
On Sat, 2018-01-27 at 13:18 +0000, Malte Forkel wrote: 0 - I'm currently using two utilities that I build on top of the frontend tools. One that continuously updates a log of incoming and outgoing telephone calls, I see. and one that interprets and dials text selected on my Windows desktop. "Dials text"? 1 - I'd be happy to provide my packaging for Debian / Raspbian if there is interest. No. But I could add the source to the project. Need to see it first, obviously. But nowadays it's probably easiest...
Thanks, Paul. I'm very sorry it took me half a year to reply. I guess I was expecting an automatic notification about a reply and never checked myself... I hope it's not too late now to answer your questions: 0 - I'm currently using two utilities that I build on top of the frontend tools. One that continuously updates a log of incoming and outgoing telephone calls, and one that interprets and dials text selected on my Windows desktop. 1 - I'd be happy to provide my packaging for Debian / Raspbian...
Any advice? 0 - Thanks for posting these questions. I'm thrilled to notice someone is still using this driver. Care to share what your goals are with this project? 1 - Consumer grade ISDN is slowly moving to a very small niche. So it's understandable that distributions disable the gigaset drivers. And, as far as I know, the frontend tools have never been carried by distributions. 2 - It seems that everything worked as expected. Is that correct? (I did test bas_gigaset lightly on, I think, an rc for...
Hello, I am accessing a Gigaset 3075 isdn from a RaspberryPi using the gigaset kernel modules of kernel 4.9.35 and frontend utilities 0.7.2. I had to compile and package all those componets myself, because the kernel modules are not included in the standard Raspbian kernel and there is no package for the frontend in the Raspbian distribution. May be that explains the following log entries. On system start Jul 21 14:09:29 servi kernel: [ 2.395378] usb 1-1.3: New USB device found, idVendor=0681, idProduct=0002...
gigacontr: remove toulong()'s base parameter
gigacontr: check whether '*buf' is NULL
gigacontr: remove unused toint()
gigacontr: make createmsg() static
gigacontr: remove tolongrange()'s base parameter
lib: remove m10x_connected()
gigacontr: remove touintrange()'s base parameter
lib: remove gigaset_dsversion()
lib: remove gigaset_usleep()
gigacontr: make parse_ext_char() static
lib: #if 0-out gigaset_utf8_to_septets()
sms: move three functions out of header
gigdata: remove unused functions
lib: remove gigaset_mayinterrupt()
sms: remove unused functions
gigacontr: remove touint()'s base parameter
phonebook: move two functions out of header
gigacontr: remove unused variable "retry"
lib: remove gigaset_pbent()
m10x: fix handling of intlist allocation failure
interf: make two functions static
gigacontr: make errorstr() static
gigacontr: remove toulongrange()'s base parameter
lib: silence ar
gigacontr: remove tointrange()'s base parameter
gigacontr: remove tolong()'s base parameter
am: remove gigaset_amdelall()
sms: make gigaset_smslist2msg() static
gigdata: make two functions static
gigaset: don't bother setting "driver" to NULL
ser_gigaset: inbuf can't be NULL
ser_gigaset: handle initialization error properly
gigaset: fix a leak in an error path
ser_gigaset: tty->disc_data won't just disappear
ser_gigaset: remove unneeded check at unload
gigaset: make gigaset_enterconfigmode() static
gigaset: remove stub (un)throttle operations
gigaset: use drv->tty to check for a tty
gigaset: cs is never NULL in gigaset_freecs()
gigaset: remove have_tty
gigaset: specify struct gigaset_ops members
ser_gigaset: drop unneeded test from WARN_ON()
isdn/gigaset: use tasklet_kill in device remove...
ser_gigaset: bail out if gigaset_initcs() fails
gigaset: set drv->tty to NULL in error path
ser_gigaset: remove unneeded check at ldisc open()
gigaset: make gigaset_if_initdriver() return a tty
ser-gigaset: rename platform device to pdev
gigaset: fail init if initializing tty_driver f...
ser_gigaset: don't touch tty->disc_data on close
bas_gigaset: unify error handling in module init
remove driver code
delete web directory
remove obsolete install docs
remove ldattach
gigacontr: fix --mregister argument handling
Gigaset CAPI drivers
0) CAPI support was added in Linux kernel v2.6.33, see commit 7bb5fdc2fb02 (" gigaset:...
frontend/README: added credit
web: update gigacontr manpage to release 0.7.2
release 0.7.2
qgigaset: add a translation
gigacontr: add --cfxset operation
gigacontr: add --cfxset to manpage