696 lines
28 KiB
Plaintext
696 lines
28 KiB
Plaintext
--------------------------------------------------------------------------------
|
|
|
|
ISDN4BSD Frequently Asked Questions
|
|
===================================
|
|
|
|
last edit-date: [Mon May 10 11:40:48 1999]
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
Contents:
|
|
=========
|
|
|
|
1. How do I get started with synchronous PPP (sPPP) ?
|
|
2. does anyone know a software that can receive/send fax over ISDN ?
|
|
3. does i4b callback only work with setups where the remote end
|
|
returns a busy ?
|
|
4. trouble with kernel options IPFIREWALL and IPDIVERT and natd
|
|
5. I want to use -r with isdnd but it does not work
|
|
6. How do I configure and run the answering machine ?
|
|
7. Teles S0/16.3 ... unknown ?
|
|
8. How do i integrate a new lowlevel driver into i4b ?
|
|
9. Why it always says "no Space in TX FIFO - State F4 awaiting" ?
|
|
10. Incoming alert - what does it mean ?
|
|
11. How do i change irq's on my teles 16.3 card ?
|
|
12. NL: i'm getting CAUSE 100 or CAUSE 101 when dialling out
|
|
14. I'm using sPPP. I can connect to my ISP but no TCP/IP services work. HELP!
|
|
15. i4b 0.80.00: problems with AVM Fritz PCI
|
|
|
|
|
|
1. How do I get started with synchronous PPP (sPPP) ?
|
|
================================================================================
|
|
|
|
Of course you first have to have sPPP interfaces in your kernel. If
|
|
you installed everything using FreeBSD/install.sh then the correct
|
|
entries should have been automatically made in /sys/conf/files for you.
|
|
For NetBSD it isn't quite as simple since NetBSD/install-netbsd.sh does
|
|
not do it for you.
|
|
|
|
Then all you need to do is put an entry like this:
|
|
|
|
pseudo-device "i4bisppp" 4
|
|
|
|
into your kernel configuration file (if it's not already there) and
|
|
generate and boot the new kernel. The above line will give you 4
|
|
sPPP interfaces - isp0 to isp3.
|
|
|
|
Then just modify /etc/isdn/isdnd.rc (see the example in etc-isdn/isdnd.rc)
|
|
to suit your needs (telephone numbers, etc).
|
|
|
|
The next step is to read the spppcontrol man page and then to look at
|
|
etc/rc.isdn-PPP. spppcontrol is a very important component in getting
|
|
sPPP working correctly and the spppcontrol lines in your /etc/rc.isdn
|
|
must be correct.
|
|
|
|
In my experience there are two things which can cause problems:
|
|
|
|
1) the authproto line has to agree with what your ISP desires. In
|
|
general I've found that it's best to have something like this -
|
|
|
|
spppcontrol <interface> myauthproto={pap,chap} myauthname=<AuthName>
|
|
myauthsecret=<AuthSecret> hisauthproto=none callin
|
|
|
|
The "hisauthproto=none" is usually needed because the ISP does not want
|
|
to authorise himself to you; he expects you to authorize yourself to him !
|
|
I once forgot to set hisauthproto and it took me quite a while to figure
|
|
out why I couldn't connect.
|
|
|
|
2) the IP address at your ISP's end must be correct.
|
|
|
|
How can I find out (1) whether my ISP wants pap or chap and (2) what his
|
|
IP address is ? you might ask. Generally, your ISP should have provide
|
|
this information to you. But, if he didn't, or you've mislayed the
|
|
documentation (as I did), there's still hope.
|
|
|
|
Fortunately, J"org Wunsch implemented the sPPP kernel code so that it
|
|
provides all the information required if the interface is configured
|
|
with the debug flag set (e.g. ``ifconfig isp0 debug''). It's just a
|
|
little cryptic.
|
|
|
|
By the way, I suggest turning the debug flag on until you have things
|
|
working and then turning it off. The debug output is rather voluminous
|
|
and could fill up your /var partition, otherwise.
|
|
|
|
The debug output will appear on the console and also be logged to
|
|
/var/log/messages (under FreeBSD) unless you changed /etc/syslog.conf.
|
|
|
|
A. How to figure out the authproto
|
|
----------------------------------
|
|
|
|
Here is an example where I configured isp0 with myauthproto=pap, my
|
|
ISP wanted chap, but was willing to accept pap:
|
|
|
|
/kernel: isp0: lcp up(starting)
|
|
/kernel: isp0: lcp output <conf-req id=0x7 len=10 5-6-34-e4-30-5a>
|
|
/kernel: isp0: lcp input(req-sent): <conf-req id=0x1 len=30 0-4-0-0-1-4-5-
|
|
f4-3-5-c2-23-5-11-4-5-f4-13-9-3-0-c0-7b-6e-fe-b5>
|
|
^^^^^
|
|
|___ c223 is chap, it's what the ISP wants to use
|
|
|
|
/kernel: isp0: lcp parse opts: 0x0 [rej] mru auth-proto 0x11 [rej]
|
|
x13 [rej] send conf-rej (I didn't agree)
|
|
/kernel: isp0: lcp output <conf-rej id=0x1 len=21 0-4-0-0-11-4-5-f4-13-9-3-
|
|
0-c0-7b-6e-fe-b5>
|
|
/kernel: isp0: lcp input(req-sent): <conf-ack id=0x7 len=10 5-6-34-e4-30-5a>
|
|
/kernel: isp0: lcp input(ack-rcvd): <conf-req id=0x2 len=13 1-4-5-f4-3-5-
|
|
c2-23-5>
|
|
/kernel: isp0: lcp parse opts: mru auth-proto
|
|
/kernel: isp0: lcp parse opt values: mru 1524 auth-proto [mine 0x0 !=
|
|
his chap] send conf-nak (we want to use pap, not chap)
|
|
/kernel: isp0: lcp output <conf-nak id=0x2 len=9 3-5-c0-23-5>
|
|
^^^^^
|
|
|___ c023 is pap
|
|
|
|
/kernel: isp0: lcp input(ack-rcvd): <conf-req id=0x3 len=12 1-4-5-f4-3-4-
|
|
c0-23> (he agrees to use pap)
|
|
/kernel: isp0: lcp parse opts: mru auth-proto
|
|
/kernel: isp0: lcp parse opt values: mru 1524 auth-proto send conf-ack
|
|
/kernel: isp0: lcp output <conf-ack id=0x3 len=12 1-4-5-f4-3-4-c0-23>
|
|
he agrees to use pap ___|^^^^^
|
|
|
|
so, if you have problems in the lcp phase, check which authentication method
|
|
your ISP wants to use. Usually chap is prefered, but pap will be accepted.
|
|
|
|
B. How to figure out the ISP's IP address
|
|
-----------------------------------------
|
|
|
|
======================================================================
|
|
|
|
UPDATE NOTE (February 8, 1999):
|
|
|
|
Jan Riedinger writes:
|
|
---------------------
|
|
>I further think Gary should mention
|
|
>in the FAQ in the section "B. How to figure out the ISP's IP address
|
|
>that it isn't normaly necessary to do it because of the auto
|
|
>address negotiation.
|
|
|
|
Gary answers:
|
|
-------------
|
|
I think you're right. I wrote that stuff before the support for
|
|
negotiation of the IPS's address was added to if_spppsubr.c.
|
|
|
|
======================================================================
|
|
|
|
|
|
I also intentionally configured the interface with the wrong address for
|
|
my ISP, like this:
|
|
|
|
ifconfig isp0 0.0.0.0 10.0.0.1 debug link1
|
|
|
|
this means that I want the ISP to assign me an address (the 0.0.0.0) and
|
|
that I expect him to use 10.0.0.1 (which is wrong). Here's the result:
|
|
(note that these addresses have been changed by me)
|
|
|
|
/kernel: isp0: phase network
|
|
/kernel: isp0: ipcp open(initial)
|
|
/kernel: isp0: ipcp up(starting)
|
|
/kernel: isp0: ipcp output <conf-req id=0x9 len=10 3-6-0-0-0-0>
|
|
/kernel: isp0: ipcp input(req-sent): <conf-req id=0x1 len=16 2-6-0-2d-f-1-
|
|
3-6-c-22-38-4e>
|
|
/kernel: isp0: ipcp parse opts: compression [rej] address send conf-rej
|
|
/kernel: isp0: ipcp output <conf-rej id=0x1 len=10 2-6-0-2d-f-1>
|
|
/kernel: isp0: ipcp input(req-sent): <conf-nak id=0x9 len=10 3-6-c-22-38-4e>
|
|
/kernel: isp0: ipcp nak opts: address [wantaddr 12.34.56.78] [agree]
|
|
^^^^^
|
|
|___ he assigns me this
|
|
|
|
/kernel: isp0: ipcp output <conf-req id=0xa len=10 3-6-c3-b4-eb-63>
|
|
/kernel: isp0: ipcp input(req-sent): <conf-req id=0x2 len=10 3-6-62-4c-36-20>
|
|
/kernel: isp0: ipcp parse opts: address
|
|
/kernel: isp0: ipcp parse opt values: address 98.76.54.32 [not agreed]
|
|
^^^^^
|
|
|_this is *his* address
|
|
send conf-nak
|
|
/kernel: isp0: ipcp output <conf-nak id=0x2 len=10 3-6-a-0-0-1>
|
|
I expect a different address and (incorrectly) reject what he wants.
|
|
I tell him that I expect 10.0.0.1. After this the connection fails.
|
|
|
|
Anyway, I now know that his address is really 98.76.54.32 and can use
|
|
it to correctly configure the interface.
|
|
|
|
With the correct IP address I shoulkd now be able to connect with no
|
|
problems. As stated above, the authorization protocol is normally not
|
|
so important since most ISPs are willing to use pap, although chap is
|
|
more secure. Generally, I'd try chap first and only switch to pap if
|
|
the ISP doesn't accept it.
|
|
|
|
(by Gary Jennejohn, Home - garyj@muc.de, Work - garyj@fkr.dec.com)
|
|
|
|
|
|
|
|
2. does anyone know a software that can receive/send fax over ISDN ?
|
|
================================================================================
|
|
|
|
> Hi,
|
|
>
|
|
> does anyone know a software that can receive/send fax over ISDN? I am
|
|
> using a Fritz!Card, which can handle group 3 (analogous) fax, but I
|
|
> can't find any hint in the i4b software that this is supported in any
|
|
> way.
|
|
|
|
This is probably not implemented.
|
|
|
|
Implementing G3 fax in ISDN would mean simulating an analog modem
|
|
on the digital link. This means having to generate the right waveforms
|
|
for the modulated data, and receive analog data from the other end
|
|
which you had to run FFT analysis on and then interpret.
|
|
|
|
In addition you have to do this in realtime, to be able to deal with
|
|
the timing involved in the fax protocol, something neither
|
|
FreeBSD or Linux is good at in their native form..
|
|
|
|
A third point is that a software simulated faxmodem usually does not
|
|
work well. I tested Teles software faxmodem in Win-95 towards an Ericsson V34
|
|
HE modem, and was able to send faxes from the ISDN card at 4800 baud
|
|
only, and receive faxes ad 9600 baud only(!) (And it is not the
|
|
Ericsson modems fault, it works flawlessly towards other fax machines.)
|
|
|
|
My point is that the best thing to do is to use an ordinary faxmodem
|
|
to handle faxes with Hylafax of mgetty+sendfax or efax, or you may use
|
|
a combined ISDN card with an analog part.
|
|
|
|
Of course, if you are crazy enough, you may try to implement a
|
|
software simulated modem in e.g. RT-linux, or a similar realtime
|
|
extension for FreeBSD.
|
|
|
|
Best regards,
|
|
Nils Ulltveit-Moe (etonumo@eto.ericsson.se)
|
|
|
|
|
|
|
|
3. does i4b callback only work with setups where the remote end returns a busy ?
|
|
================================================================================
|
|
|
|
> Is my assumption correct, does i4b callback only work with setups where
|
|
> the remote end returns a busy on the dialin?
|
|
|
|
Yes - otherwise you'll pay for the connection, at least here in Germany.
|
|
|
|
Most routers support two kind of callbacks - the one that i4b supports
|
|
means: the called system rejects (so no charge for this connection), waits
|
|
a configurable time and the calls back. Information on who has called and
|
|
who is to be called back relies on the ISDN calling party number information
|
|
and stuff statically configured in the routers (or isnd's) configuration.
|
|
|
|
The other type of callback (not supported by i4b right now) means: the
|
|
called system accepts the connection and starts ppp negotiation. During this
|
|
the ppp's aggree to do a callback. Information on who called in and who is
|
|
going to be called back is subject to the authentication/negotiation already
|
|
done by the two ppp's. Then ppp closes down, the connection is disconnected
|
|
and the called system calls back.
|
|
|
|
I've never seen someone actually use the second type due to its obvious
|
|
disadvantages. It may be usefull if you travel, call in from an unknown
|
|
number and want to be called back at that number.
|
|
|
|
Martin Husemann <martin@rumolt.teuto.de>
|
|
|
|
|
|
4. trouble with kernel options IPFIREWALL and IPDIVERT and natd
|
|
================================================================================
|
|
|
|
NOTICE: section obsolete since IP address changes are handled properly now!
|
|
===========================================================================
|
|
|
|
This section
|
|
> Trying to build a router/gateway between my privat Ethernet and
|
|
> the Internet (via my ISP), I have problems with I4B or NAT (I think:).
|
|
>
|
|
> The 2.2.5-R kernel with options IPFIREWALL and IPDIVERT works fine
|
|
> with ISDN4BSD 0.50-alpha and firewall rule 'pass all from any to any'.
|
|
> However, when I add 'divert natd all from any to any via isp0'
|
|
> and start natd, name server lookups to the ISP's NS don't work.
|
|
>
|
|
> Also, ping and nslookup fails from any other internal host.
|
|
|
|
I had exactly the same problems. natd doesn't seem to get a message if
|
|
the IP address of the interface changes (after successful dialout).
|
|
I have to manually send a HUP signal to natd. I do this via the following
|
|
(ugly?!) hack:
|
|
|
|
I added the following two lines to the system section of isdnd.rc:
|
|
regexpr = "call active" # look for matches in log messages
|
|
regprog = hup_natd # execute program whan match is found
|
|
|
|
The small script "hup_natd", located in /etc/isdn, looks like:
|
|
#!/bin/sh
|
|
pid=`cat /var/run/natd.pid`
|
|
kill -HUP $pid
|
|
sleep 3
|
|
kill -HUP $pid
|
|
sleep 5
|
|
kill -HUP $pid
|
|
|
|
It looks ugly, but at least for me it works. The two sleeps are necessary
|
|
since I have to wait for ppp negotiation to complete (I don't get a message
|
|
from isdnd for that). If I'm lucky I have my connection after 3 seconds,
|
|
but 8 seconds should suffice for worst case (the first HUP without a sleep
|
|
sometimes even succeeded on an slow 486/33 with 8MB RAM, more HUPs don't hurt).
|
|
|
|
I'm really interested in some more elegant method.
|
|
|
|
Daniel (rock@cs.uni-sb.de)
|
|
|
|
|
|
Arve Ronning replied:
|
|
=====================
|
|
|
|
> I had exactly the same problems. natd doesn't seem to get a message if
|
|
> the IP address of the interface changes (after successful dialout).
|
|
|
|
Well, it (natd) _does_ pick up the dynamic address supplied for isp0.
|
|
Try 'natd -verbose ...' and you'll see it. Otherwise I agree, there is
|
|
certainly something missing in natd's functionality, or maybe sppp
|
|
does'nt
|
|
supply what it's supposed to ??
|
|
|
|
> I have to manually send a HUP signal to natd. I do this via the following
|
|
> (ugly?!) hack:
|
|
|
|
YES...super; strange but correct. It works when I send natd a -HUP after
|
|
sppp is up. Thanx for the tip. However, natd must be -HUPed _every_ time
|
|
sppp has been down (idle timeout) and comes back up!
|
|
|
|
> I'm really interested in some more elegant method.
|
|
|
|
So am I, let's see what may come out of the discussion on the list.
|
|
|
|
|
|
|
|
5. I want to use -r with isdnd but it does not work
|
|
================================================================================
|
|
|
|
> > Use isdnd in fullscreen mode.
|
|
>
|
|
> I tried that already, but got an error when I start isdnd that way:
|
|
>
|
|
> /usr/local/bin/isdnd -d 0xf9 -f -r /dev/ttyv1 -t cons25
|
|
>
|
|
> root is logged in on device /dev/ttyv1, the message in /var/log/messages looks like:
|
|
>
|
|
> "May 22 11:52:28 asterix isdnd[4160]: ERR ERROR, cannot setup tty as controlling terminal: Operation not permitted"
|
|
>
|
|
> How can I give this device permission ?
|
|
|
|
|
|
In case you want to use switch "-r" noone else _must_ use the tty you redirect
|
|
to, you have to remove the getty from the virtual terminal in /etc/ttys and
|
|
restart the init process.
|
|
|
|
|
|
6. How do I configure and run the answering machine (under FreeBSD 2.2.x) ?
|
|
================================================================================
|
|
|
|
The answering machine will be activated, when isdnd executes the program
|
|
that has been named in "/etc/isdn/isdnd.rc" in the section "telephone
|
|
answering" at entry "answerprog = ". If the program is executed
|
|
without a pathname, the answer program is expected in "/etc/isdn".
|
|
Examples of such programs can be found in "/etc/isdn/samples". They
|
|
are named:
|
|
|
|
"answer" answers only, no recording
|
|
"record" answers, and records messages
|
|
"tell" the number of the calling person is told,
|
|
no recording.
|
|
"tell-record" calling number as answer, message is recorded
|
|
"isdntel.sh" answers and records messages; by using the
|
|
program "isdntel", one has the control over
|
|
the recorded messages in the directory
|
|
"/var/isdn". Look at "man isdntel" and
|
|
"man isdntelctl".
|
|
|
|
These programs have to be altered to suit your needs. Unfortunately there
|
|
is no program with which you can record your answer message. This is not
|
|
really bad, because you only have to alter the above mentioned program
|
|
"record" a bit (comment out the "if ... fi" statements for the beep
|
|
and msg messages). You have to create the directory "/var/isdn" first in
|
|
order to record messages. They will be stored in this location then.
|
|
|
|
Stefan Herrmann <stefan@asterix.webaffairs.net>
|
|
|
|
|
|
7. Teles S0/16.3 ... unknown ?
|
|
================================================================================
|
|
Hi,
|
|
|
|
I have just purchased a Teles S0/16.3 card.
|
|
But it's not what i4b is looking for .... I mean, it's a different card.
|
|
|
|
The docs (and sources)of i4b talks about a Telws S0/16.3 card with 3
|
|
address: d80 etc.
|
|
|
|
This one (is not PnP) has jumpers for 0x180 0x280 0x380.
|
|
|
|
It has the SIemens Chips numbered PSB 21525 N (HSCX TE V2.1) and PSB
|
|
2186N V1.1 (ISAC-S TE).
|
|
|
|
I undestand that the 16.3c is not supported, but over this board is
|
|
written "TELES.S0/16.3 Revision 1.3"
|
|
|
|
Can anybody tell me what is this card ???
|
|
|
|
answer:
|
|
-------
|
|
|
|
It's not a different card. The jumpers are documented to select
|
|
IO-address 0x180, 0x280 or 0x380 in some TELES manuals.
|
|
But in fact they select the addresses 0xd80, 0xe80 or 0xf80.
|
|
|
|
Wolfgang
|
|
|
|
|
|
And an additional note from Poul-Henning Kamp:
|
|
----------------------------------------------
|
|
There is an intricate story behind this, in short some ISA cards
|
|
only decode the first 10 address bits (0x3ff), which over the years
|
|
has resulted in a mutation the "de-facto-spec" such that addressbits
|
|
10-15 can be used by the card for selecting various stuff. This
|
|
is extensively used on obscure cards with massive IO needs, sound,
|
|
IEEE488 and ISDN cards often belong in this category.
|
|
|
|
|
|
|
|
8. How do i integrate a new lowlevel driver into i4b ?
|
|
================================================================================
|
|
|
|
1) Request a flag value from me
|
|
2) add an entry for the card into FreeBSD/CONFIG
|
|
3) add driver filename to FreeBSD/files.i386.cat
|
|
4) add entry for the card to FreeBSD/options.i386.cat
|
|
5) add support to print type of card to diehl/diehlctl/main.c
|
|
6) add support to print type of card to isdnd/support.c, name_of_controller()
|
|
7) place your file as named in 3) into directory layer1
|
|
8) add the flag value and function prototypes to layer1/i4b_l1.h
|
|
9) add support for NetBSD to layer1/isa_isic.c
|
|
10) add support for attach/probe to layer1/i4b_isic.c
|
|
11) add card type to machine/i4b_ioctl.h and update CARD_TYPEP_MAX
|
|
12) add an entry to the man page man/isic.4
|
|
|
|
Produce diffs (please use context diffs, flag "-c" for diff) and send them in.
|
|
|
|
|
|
9. Why it always says "no Space in TX FIFO - State F4 awaiting" ?
|
|
================================================================================
|
|
|
|
as I wrote about two weeks ago I had massive problems concerning this
|
|
"no space in TX FIFO"-thing,
|
|
|
|
/kernel: i4b-L1-ph_data_req: No Space in TX FIFO, state = F4 Awaiting Signal
|
|
|
|
Even though I used a correctly recognized Teles S0/16.3 nonpnp isdncard,
|
|
nothing worked, errormsgs were flooding the console until I rebooted the box.
|
|
|
|
I decided to play around in the BIOS-settings, I first just set them all
|
|
to default, which didn't work, and then changed lots of things - unfortunately
|
|
I can't remember them. After about hundreds of trial 'n errors I gave up.
|
|
|
|
A few days ago I just made another attempt, booted the box and to my surprise
|
|
it all worked without the smallest problem, great data rates :)
|
|
|
|
I tried hard to found what the something special was I changed in the BIOS
|
|
settings, but I just couldnt get isdnd back to its stupid behaviour it
|
|
showed all the time before, but I would recommend everybody who has this
|
|
kind of problem to look into his BIOS.
|
|
|
|
(from Meike Aulbach, strange@stoned.rhein-main.de)
|
|
|
|
|
|
i4b now works for me, I had a USB-device interfering on IRQ 9,
|
|
which was supposed to be only for my Creatix Card.
|
|
(NetBSD 1.3, Creatix)
|
|
|
|
Strange enough, my DOS s0-test worked, are they just polling the card?
|
|
|
|
Even when the testsoftware under DOS is working, don't be shure, that
|
|
your hw-setup is correct for xxx(x)BSD. Triplecheck all your IRQ and
|
|
enable and disable PNP to triple-verify. Even unconfigured devices can
|
|
block your card. .....
|
|
|
|
And that took me more than 2 months to discover :-((((
|
|
|
|
(from Andreas Lohrum, andreas.lohrum@consol.de)
|
|
|
|
|
|
when i changed the mainboard of a box that ran i4b alright, i forgot to
|
|
set 'used by isa' in the pnp-bios-settings for the irq of my teles
|
|
isdn-card. because of that some pci-card got the interrupt that the
|
|
isdn-card should have gotten.
|
|
i then also got this error: 'No space in TX FIFO'.
|
|
|
|
The reason occurred to my rather quick, but i would think, that this would
|
|
be a nice hint in a FAQ :)
|
|
|
|
(from Heiko Schaefer, hschaefer@fto.de)
|
|
|
|
|
|
after my huge amount of problems, Meike's hint (changing the
|
|
ISA/PNP-settings in the BIOS) finally fixed things.
|
|
I have only tried out this stuff with my Creatix-card, I'll check
|
|
out the PNP-stuff with my Sedlbauer-card soon too though.
|
|
|
|
(from Harold Gutch, logix@foobar.franken.de)
|
|
|
|
|
|
10. Incoming alert - what does it mean ?
|
|
================================================================================
|
|
|
|
In the log on vty6 (isdnd full screen log) I'm seeing
|
|
|
|
16.07.98 11:42:35 CHD 00001 rwth rate 90 sec/unit (rate)
|
|
16.07.98 11:42:35 CHD 00001 rwth dialing from 4191236 to 441291234
|
|
16.07.98 11:42:35 CHD 00001 rwth outgoing call proceeding (ctl 0, ch 0)
|
|
16.07.98 11:42:35 CHD 00001 rwth incoming alert <<<<<<<<<<<<<<<
|
|
16.07.98 11:42:35 CHD 00001 rwth outgoing call active (ctl 0, ch 0)
|
|
|
|
What does this 'incoming alert' mean?
|
|
|
|
|
|
It means that it is "ringing" at the remote end.
|
|
|
|
|
|
11. How do i change irq's on my teles 16.3 card ?
|
|
================================================================================
|
|
|
|
Question:
|
|
|
|
So how do you change irq's on your teles 16.3 card (under FBSD or DOS,
|
|
I don't have and don't want to have Windows running on that computer) ?
|
|
|
|
Answer:
|
|
|
|
The irq is configured into the card each time the driver under whatever
|
|
OS you currently boot initializes the card. Thus, change the irq for the
|
|
isic driver in your kernel config file to one of the supported (!) irqs
|
|
for this card (hint: read "man isic") which is currently unused in your
|
|
machine and generate a new kernel.
|
|
|
|
|
|
12. NL: i'm getting CAUSE 100 or CAUSE 101 when dialling out
|
|
================================================================================
|
|
|
|
This one seems to be specific for the Netherlands. (-hm)
|
|
|
|
Question:
|
|
|
|
I'm trying to get i4b running on my new FreeBSD 2.2.8 system. The kernel
|
|
compiles smootly and everything is looking fine until it's time to dial.
|
|
I get the following error:
|
|
|
|
Feb 10 20:31:00 goofy isdnd[498]: CHD 00018 I4BPPP outgoing call disconnected (remote)
|
|
Feb 10 20:31:00 goofy isdnd[498]: CHD 00018 I4BPPP cause 101: Message not compatible with call state (Q.850)
|
|
Feb 10 20:31:00 goofy isdnd[498]: ERR set_channel_idle: controller [0], invalid channel [-1]!
|
|
Feb 10 20:31:00 goofy isdnd[498]: ERR msg_disconnect_ind: set_channel_idle failed!
|
|
|
|
The remote site is a Cisco 4000 type router. I used debug to take a view at
|
|
the ISDN events on the router but according to that the call doesn't arrive
|
|
over there.
|
|
|
|
Same hardware has worked fine with FreeBSD 2.2.6/i4b 0.63.
|
|
|
|
Who knows what's wrong?
|
|
|
|
|
|
Answer:
|
|
|
|
This sounds very much like your local phone number or remote phone number
|
|
is configured wrongly... in the Netherlands you need to specify the number
|
|
EXCLUDING the city code... so if you live in Utrecht and your number is
|
|
0301234567 you specify 1234567.
|
|
|
|
I have seen this in several locations in the Netherlands for years, not
|
|
just with i4b, but also with differentt isdn equipment.. why? guess it
|
|
simply depends on which operator defines your line or what exchange it
|
|
is connected to... :P
|
|
What I found is that what solved this with other isdn hardware/software,
|
|
also solves it for i4b.. ie.. make sure the local phone number is
|
|
specified, and is specified without the city code.
|
|
The numbering plan should be 'unknown'
|
|
|
|
Anyway, it would be nice if the Dutch ptt (they are called KPN btw)
|
|
would tell us why this happens... they havent been able to tell me in the
|
|
past so I guess I give up on that, but if everyone finds out whats exactly
|
|
happening here I'd be interested to know... :)
|
|
|
|
List of number configurations that I have found to almost always work in
|
|
the Netherlands:
|
|
|
|
1. Local phone number:
|
|
usually your prefered msn without city code works here.
|
|
(ie, 1234567 if you would like to use 0201234567 for outgoing calls)
|
|
on some locations leaving it blank or defining it with the city code,
|
|
but without the leading 0 works as well here.
|
|
|
|
2. remote phone number:
|
|
When this is a 'local' call, don't specify city code.
|
|
For calling parties in other cities you of cource have to use the city
|
|
code... in general you can say that KPN only accepts the shortest
|
|
possible notation where it would still be clear who you want to call.
|
|
|
|
3. numbers for incomming call recognition:
|
|
KPN always specifies incoming caller ids with city code, but without
|
|
leading 0. so 0201234567 will be displayed as 201234567
|
|
|
|
|
|
Hope this helps.
|
|
Bart
|
|
|
|
(from Bart van Leeuwen bart@ixori.demon.nl)
|
|
|
|
14. I'm using sPPP. I can connect to my ISP but no TCP/IP services work. HELP!
|
|
==============================================================================
|
|
|
|
This is probably because you have the RFC1323 - TCP Extensions for High
|
|
Performance - support turned on and your ISP (or some router in the loop)
|
|
is discarding the extensions.
|
|
|
|
This can easily be checked by doing ``sysctl net.inet.tcp.rfc1323''. If the
|
|
result is 1, then the RFC1323 support is turned on.
|
|
|
|
Turn this off by doing ``sysctl -w net.inet.tcp.rfc1323=0'' (This is
|
|
called "net.inet.tcp.do_rfc1323" under BSD/OS).
|
|
|
|
For FreeBSD make sure that tcp_extension="NO" is in your /etc/rc.conf
|
|
(/etc/defaults/rc.conf with more recent versions of FreeBSD) and
|
|
/etc/rc.conf.local (in -STABLE and upcoming 3.2)
|
|
|
|
This may be different for NetBSD, OpenBSD and BSD/OS.
|
|
|
|
Martin Husemann writes:
|
|
-----------------------
|
|
This does apply for NetBSD too (and probably OpenBSD, since it's been
|
|
in NetBSD for a long time). The sysctl name is even compatible ;-) We don't
|
|
have a coresponding rc.conf entry, I do it in /etc/netstart.local.
|
|
|
|
I would suggest to set this to 0 on all machines routed over ISDN (not only
|
|
the router), as this "high speed options" in fact do slow down an ISDN link
|
|
by making VJ "compression" impossible - as far as I understood it. So there
|
|
should be a more general advice in the FAQ, not only "turn it off if it
|
|
doesn't work for you".
|
|
|
|
I've only seen the problems against old linux kernels (about two years ago),
|
|
are there still machines out there that have such a broken TCP/IP stack? We
|
|
should start to blame the vendors...
|
|
|
|
(by Gary Jennejohn, garyj@muc.de, with additions from
|
|
Harold Gutch <logix@foobar.franken.de> and
|
|
Martin Husemann <martin@rumolt.teuto.de>).
|
|
|
|
15. i4b 0.80.00: problems with AVM Fritz PCI
|
|
==============================================================================
|
|
|
|
Question:
|
|
=========
|
|
|
|
The system is FreeBSD 3.1-RELEASE with i4b-00.80.00-beta-070599 [...]
|
|
|
|
I'm trying to compile a Kernel with support for my AVM Fritz!PCI card,
|
|
however, when compiling, it fails with the following error
|
|
|
|
sh ../../conf/newvers.sh GENERIC -DAVM_A1_PCI
|
|
cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-
|
|
externs
|
|
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -
|
|
Wuninitializ
|
|
ed -Wformat -Wunused -fformat-extensions -ansi -nostdinc -I- -I. -I../..
|
|
-I/us
|
|
r/include -DAVM_A1_PCI -DKERNEL -DVM_STACK -include opt_global.h -elf
|
|
vers.c
|
|
loading kernel
|
|
i4b_isic_pci.o: In function `i4b_pci_attach':
|
|
i4b_isic_pci.o(.text+0x141): undefined reference to `avma1pp_map_int'
|
|
i4b_isic_pci.o: In function `isic_pciattach':
|
|
i4b_isic_pci.o(.text+0x196): undefined reference to `isic_attach_avma1pp'
|
|
*** Error code 1
|
|
|
|
|
|
Solution:
|
|
=========
|
|
|
|
> I have added
|
|
>
|
|
> i4b/layer1/i4b_avm_fritz_pci.c optional isic device-driver
|
|
>
|
|
> and am recomiling at the moment, but given that it's a 486, it could take
|
|
> some time :-)
|
|
|
|
The problem appears to be that overinstall.sh does not update files.i386
|
|
and options.i386, and that AVM_A1_PCI was added after 3.1-RELEASE and
|
|
hence is not defined.
|
|
|
|
Manually editing these files (using install.sh as a guide) allows the
|
|
kernel to compile cleanly.
|
|
|
|
|
|
(from Rich Wood, rich@dynamite.org)
|