| |
PE1KDA > BPQ 20.09.95 23:58l 155 Lines 5616 Bytes #-11370 (0) @ EU
BID : 1425_PE1KDA
Read: DF5CH DH9MEC DG0EL GUEST
Subj: FBB, NETCHL, BPQ and Win95? Problems!!!
Path: DB0AAB<DB0MWS<DB0RBS<DB0HOM<DB0GE<LX0PAC<ON7RC<ON4AWP<ON6AR<PI8HWB<
PI8ZAA<PI8GCB<PI8WFL<PI8MBQ<PI8DBV
Sent: 950920/1805Z @:PI8DBV.#NH2.NLD.EU #:40059 [Haarlem] FBB5.15c $:1425_PE1KD
From: PE1KDA@PI8DBV.#NH2.NLD.EU
To : BPQ@EU
PE1KDA/TPK 1.81 Msg #:1425 Date:20-09-95 Time:19:02Z
Hi there, BPQ, FBB and NETChl users.
Anyone using these programs with Windows95 these days? And, does it work
the way you want it to?
Then you are the person that can help us out.
What did we have as a network setup.
ethernet
+--------+---------------------------------+----------+
| |
+-------+-------+ +--------+-------+
| NE1000 | | NE1000 |
+---------------+---+ +----------------+---+
| G8BPQ SWITCH |SCC+--> Radio | G8BPQ SWITCH |SCC+---> RADIO 1200 bps
| | | 4800bps | | +---> 9600 bps
| | | | | +---> Interlink
+---------------+---+ +----------------+---+ forwarding
| NETCHL | | F6FBB BBS |
+---------------+ +----------------+
286 PC, DOS6.20 386 PC, DOS6.20, Win311
One 386 PC, running DOS6.20, Windows3.11, BPQ and FBB Bulletin Board program.
Using the PA0HZP SCC card with 3 ports, fitted to radio's, and one NE1000
board, connected to a local ethernet segment.
The other PC, a 286, running DOS6.20, BPQ and NETCHL.
Using the PA0HZP SCC card with 1 port, fitted to a radio, and one NE1000
board, connected to a local ethernet segment.
Why this construction?
The FBB bulletin board system has 4 radio ports: 2 for forwarding at 23 cm
at 1200 bps and two LAP ports: 1200 and 9600 on 70 cm.
The ethernet connection makes it possible to interconnect the two pc's in
such a way, that when connected to the interlink port of the 386, you can
connect to the interlink port of the 286. The main purpose of this link is
to be able to deliver sysops mails from FBB by a forwarding mechanism to
the secondary PC, and from there on by SMTP to another site: the FBB PC stays
clean from sysop mail leaving the needed space to mail, messages and programs.
Also there is a possibillity to deliver files to the BBS by FTP-ing to the
secondary machine over NETCHL.
We used the following setup.
For the ethernet cards: Base I/O address 300, Interrupt 5.
For the SCC Cards: both Base I/O 150, irq 9.
The network card for the 286 is loaded with an ODI stack in the following
sequence:
'lsl
ne1000
odidrv 125
bpqcode
nodedrv4 0x61 33 1'
where the following 'net.cfg' is used:
'IPX Packet size limit=1514
Link Driver NE1000
Int 5
Port 300
Frame Ethernet_II
Frame Ethernet_802.3
Protocol IPX 0 Ethernet_802.3
Protocol IP 800 Ethernet_II
Protocol ARP 806 Ethernet_II
Protocol BPQ 08FF Ethernet_II'
By this sequence, the odipkt driver is loaded at interrupt 0x69.
The network card for the 386 is loaded with an odi stack too, but in the
following sequence:
'lsl
ne1000
odidrv 125
bpqcode
nodedrv4 0x61 33 1'
In the file bpqcode.cfg, the SCC ports are defined for use with G8BPQ and
are set to the desired speed, I/O address of the SCC card and corresponding
interrupt. The port names are defined in this file as well.
After that, the FBB software is successfully started and the BBS is
operational and all ports are accessable, by FBB and by using the Node
call from the G8BPQ configuration.
Where did it go wrong?
After we changed the 286 into a Pentium, running Windows95, and the same
software setup, there were no connections possible over the ethernet segment
any more.
A 'connect request' out of the Pent over the ethernet was received properly
by the 386, and detected in its monitor screen. The FBB BBS produces the needed
login screen, and returns this data over the ethernet to the Pent.
On this machine the data is received over the ethernet as an AX25 frame, but
the debugging of this data produces the message 'bad header': received data
can not be handled as BPQ data, representing AX25 data.
Due to the fact that the 386 does not receive a reply on its 'UA', it retries
every second for 16 times, and then disconnects the session.
On the other hand, the Pent does not 'see' a 'UA' on its 'SABM' and reties as
well every 10 seconds: this keeps on going until one 'disc'onnects the
session from the Pent in the NetCHL application. This 'Reset' is received
correctly by the 386, that immediately stops retransmission and closes
gracefully.
It seems to us that the BPQ application is unable to pass the received data
correctly to the NetCHL application, or that Win95 is intercepting the data
received by the NE1000 card, and that Win95 passes it to the NETCHl applica-
tion, thereby avoiding the BPQ encoding/decoding mechanism of AX25 into IP.
The link between both machines on BPQ based protocol is running fine: when the
terminal application 'term4' is used on the Pent, we are able to make a full
connection to the 386 and all its applications.
Does anyone have the same experiences and / or troubles using Win95 and BPQ?
There were some publications about problems using JNOS and Win95 (see the
TCP-Group Digests 216, 217 and 218), but a good solution was not given in these
mails.
Who knows? Do we need a new version of BPQ? Is BPQ to blame or can we avoid
this problem by reconfiguring BPQ? if so, how?
Please let us know if you have any experience in this field. We keep you
posted if we hear something too.
Regards,
Jelle, PE1KDA, cosysop of PI8DBV and
Peter, PA3DBV, sysop of PI8DBV.
-----------------------------
Read previous mail | Read next mail
| |
