Re: /dev/ttyS2 and /dev/ttyS3
On Fri, Feb 04, 2000 at 03:45:06AM +, [EMAIL PROTECTED] wrote:
Message-Id: 1462_kb2shu
From: kb2shu@kb2shu.#sca.ca.usa.noam
To: [EMAIL PROTECTED]
I've created the following init file:
[root@gateway /proc]# cat /etc/rc.d/rc.serial
SETSERIAL=/bin/setserial
echo "Configuring serial ports"
#
${SETSERIAL} /dev/ttyS0 uart 16550a port 0x3f0 irq 4 ^fourport
${SETSERIAL} /dev/ttyS1 uart 16550a port 0x2f0 irq 3 ^fourport
${SETSERIAL} /dev/ttyS2 uart 16550a port 0x3e0 irq 10 ^fourport
${SETSERIAL} /dev/ttyS3 uart 16550a port 0x2e0 irq 10 ^fourport
#
echo "done"
Try this insteadworks here!
${SETSERIAL} /dev/cua0 uart 16550a port 0x3f0 irq 4 ^fourport
${SERSERIAL} /dev/cua1 uart 16550a port 0x2f0 irq 3 ^fourport
Rubbish. (excuse me :) )
/dev/ttyS0 and /dev/cua0 are in fact the same device so your change makes
absolutely no difference. The only difference between the two is the
opening behaviour. ttyS0 blocks when the attached device is not
ready (DCD low etc.) while cua0 lets you go on. And IIRC cua0 blocks if there
is an other user already _connected_ (i.e. transmitting data).
*** THE USE OF ANY cua* PORT IS DEPRECATED ***
because most (all) serial commuication programs expect and use lockfiles
which won't work with differently named devices.
You should not be surprised if someday suddenly all cua* prots are gone :-)
and so on.
Brians real problem seams he want to adjust the base address to 0x3f8 (he says
so in his text) but infact uses 0x3f0 (typo!) in his rc-script
73 Thorsten
--
| Thorsten Kranzkowski Internet: [EMAIL PROTECTED]|
| Mobile: ++49 161 7210230Snail: Niemannsweg 30, 49201 Dissen, Germany |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, [EMAIL PROTECTED] [44.130.8.19] |
Re: /dev/ttyS2 and /dev/ttyS3
On Fri, Feb 04, 2000 at 10:56:06AM +0800, Philip Maley wrote: Hi Brian and others I was running a fourport card for a while on vk6bbs but it used only a single irq (5). My understanding is that each fourport card has a single irq and each port has a unique There are such cards, you are right. But chances are when the card has IRQ jumpers for each port (e.g. 4 on a 4-port card) that there is _no_ IRQ sharing cirquity. If you want to share several fourport-type cards you stll would have to make modifications to them, or possibly use IRQ-sharing cables on a special connector on that cards. io port address. The other thing is why is there a "^" before "fourport"? It means 'not a fourport'-type card. Fourport cards and some clones have a special register to quick look up which of the ports really has caused an interrupt. (As opposed to polling each port individually). Linux can use that register if available. In fact it's the default for some ports ttyS5 onwards. So one can switch it off. '^fourport' not needed on ttyS0..3 (because it's the default) but it won't hurt either. 73 Phil Maley vk6ad 73 Thorsten -- | Thorsten Kranzkowski Internet: [EMAIL PROTECTED]| | Mobile: ++49 161 7210230Snail: Niemannsweg 30, 49201 Dissen, Germany | | Ampr: dl8bcu@db0lj.#rpl.deu.eu, [EMAIL PROTECTED] [44.130.8.19] |
RE: Routing problem
On 03-Feb-2000 Robin Gilks wrote: Greetings all This one has me beat for the moment. I have set up a remote router with 3 full duplex links. These links are implemented as one transmit and 3 receive ports. Port 'A' has the TX and one RX, port 'B' has an RX only and port 'C' is RX only as well. There is one station associated with each port who all have full duplex capability. The routing problem is that I can ping from the box to any of the 3 stations associated with the 3 receives (I have arp entries set up OK) and I can ping the router from any of the three stations OK - I can even ping 'C' from 'B' via the router (and visa versa) but I can't ping 'B' or 'C' from station 'A'. I have ip_forward enabled in the /proc system but I'm thinking there must be another parameter that allows a route to go back out the port it came into - which is what I want to happen for the scenario that fails. Is there another parameter or does Linux strictly not allow routing back out the same port. If this is the case I've got some serious rethinking to do :-(( The setup is: stock RedHat 6.1 ax25-apps-0.0.4 ax25-tools-0.0.5 libax25-0.0.7 all ax25 stuff compiled as modules -- Have a look at the "advanced routing" options in the kernel. CONFIG_IP_MULTIPLE_TABLES: x x x x Normally, a router decides what to do with a received packet based x x solely on the packet's final destination address. If you say Y here,x x the Linux router will also be able to take the packet's source x x address into account. Furthermore, if you also say Y to "IP: use TOSx x value as routing key" below, the TOS (Type-Of-Service) field of the x x packet can be used for routing decisions as well. In addition, if x x you say Y here and to "IP: fast network address translation" below, x x the router will also be able to modify source and destination x x addresses of forwarded packets. x x x x If you are interested in this, please see the preliminary x x documentation at http://www.compendium.com.ar/policy-routing.txt andx x ftp://post.tepkom.ru/pub/vol2/Linux/docs/advanced-routing.tex. You x x will need supporting software from ftp://ftp.inr.ac.ru/ip-routing/ Dirk G1TLH -- Dirk-Jan Koopman, Tobit Computer Co Ltd At the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer.
Re: Routing problem
On Thu, Feb 03, 2000 at 07:36:57PM -, Robert A Jenkins wrote: For machines within the same subnet to work via an intermediate system, you must add specific routes to the target machines with the intermediate as a gateway. I set mine up in rc.local. Well, they are not really on the same subnet then if an active intermediate is required. Can you change the subnet mask to the correct value, which may even be 255.255.255.254? (I don't know that such a mask is actually supported to be honest..) Hamish -- Hamish Moffatt Mobile: +61 412 011 176 [EMAIL PROTECTED] Rising Software Australia Pty. Ltd.http://www.risingsoftware.com/ Phone: +61 3 9894 4788Fax: +61 3 9894 3362USA: 1 888 667 7839
Re: Routing problem
On Sat, 5 Feb 2000, Hamish Moffatt wrote: On Thu, Feb 03, 2000 at 07:36:57PM -, Robert A Jenkins wrote: For machines within the same subnet to work via an intermediate system, you must add specific routes to the target machines with the intermediate as a gateway. I set mine up in rc.local. Well, they are not really on the same subnet then if an active intermediate is required. Can you change the subnet mask to the correct value, which may even be 255.255.255.254? (I don't know that such a mask is actually supported to be honest..) They would probably want .252 as .254, while most-likely a technically correct netmask, has no room for any host addresses. :)
Re: Routing problem
On Sat, 5 Feb 2000, Hamish Moffatt wrote: On Thu, Feb 03, 2000 at 07:36:57PM -, Robert A Jenkins wrote: For machines within the same subnet to work via an intermediate system, you must add specific routes to the target machines with the intermediate as a gateway. I set mine up in rc.local. Well, they are not really on the same subnet then if an active intermediate is required. Can you change the subnet mask to the correct value, which may even be 255.255.255.254? (I don't know that such a mask is actually supported to be honest..) I'm not sure but I don't think the subnet / netmask issue is of relevance here. The main point of the problem is that Linux 2.2 seems to refuse to send out an IP datagram on the same interface it came in. At least with AX.25 interfaces. I tested this at home by setting up a route to certain host through my only radio port. I tested that the route works from my machine and from another machine on my home ethernet. I then went to another site that is on the same frequency as mine (actually I dialed it up but anyway) and set up the route there to point _through_my_box_. With older kernels, this would have worked. With kernel 2.2 my box just throws the datagram away. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
RE: Routing problem
Hi Dirk I've had a look and this appears to do exactly what I *don't* want to do - ie. restrict the destination interface based on the source interface (unless I'm missing something here). Does anyone have a 2.0 system they can check to see if it behaves the same as 2.2 - be nice to know if this is a 2.2 problem only. If it is its move back time (despite other threads urging us to move on the bleeding edge). Either way its a pain after all the time spent putting this system together to find that it doesn't behave as ipchain -C reports nor the route table reports :-(( On Fri, 04 Feb 2000, you wrote: Have a look at the "advanced routing" options in the kernel. CONFIG_IP_MULTIPLE_TABLES: x x x x Normally, a router decides what to do with a received packet based x x solely on the packet's final destination address. If you say Y here,x x the Linux router will also be able to take the packet's source x x address into account. Furthermore, if you also say Y to "IP: use TOSx x value as routing key" below, the TOS (Type-Of-Service) field of the x x packet can be used for routing decisions as well. In addition, if x x you say Y here and to "IP: fast network address translation" below, x x the router will also be able to modify source and destination x x addresses of forwarded packets. x x x x If you are interested in this, please see the preliminary x x documentation at http://www.compendium.com.ar/policy-routing.txt andx x ftp://post.tepkom.ru/pub/vol2/Linux/docs/advanced-routing.tex. You x x will need supporting software from ftp://ftp.inr.ac.ru/ip-routing/ Dirk G1TLH -- 73 de Robin. G8ECJ Hub manager gb7ipd NTS: G8ECJ@GB7TVG.#42.GBR.EUAmprNet: [EMAIL PROTECTED] Internet: [EMAIL PROTECTED] http://www.gb7ipd.freeserve.co.uk/ Shack: (+44) 1628 533311Fax: (+44) 1628 850165 Club pages (g4xyw modem etc) at http://www.tvipug.freeserve.co.uk
RE: Routing problem
On 04-Feb-2000 Robin Gilks wrote: I've had a look and this appears to do exactly what I *don't* want to do - ie. restrict the destination interface based on the source interface (unless I'm missing something here). I thought that what you essentially wanted was for a packet to go out on the same interface as it came in on. My understanding is that some combination of these flags gives you that. The early 2.0.xx kernels had a patch that did that after MJS had two internet feeds and a default route on one of them. He wanted stuff destined for a certain subnet to go out on the appropriate interface and the rest to go out on the other (default) interface. ACKS were to go out on the interface they came in on. Dirk G1TLH -- Dirk-Jan Koopman, Tobit Computer Co Ltd At the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer.
RE: Routing problem
On Fri, 4 Feb 2000, Robin Gilks wrote: Does anyone have a 2.0 system they can check to see if it behaves the same as 2.2 - be nice to know if this is a 2.2 problem only. If it is its move back time 2.0 lets you route back to the interface the datagram came in. I can verify that anytime on my home system. (despite other threads urging us to move on the bleeding edge). 2.2 is not bleeding edge... -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
RE: Hardware TNC (Baycom etc.)
Hello, I have used a sound card(SB32) under Linux and DOS and once configured it works, but will it work for 9K6 quite as good as it does for 1k2? -Original Message- From: Sergej Pryadko [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 02, 2000 4:58 AM To: [EMAIL PROTECTED] Subject: Re: Hardware TNC (Baycom etc.) Hello Gerd Hello All The second reason is that the SoundModem driver must be considered experimental, and is sometimes not easy to set up. Even more, it seems that Thomas's support for that driver has slightly vanished. He does not want to enhance tools like smdiag or smmixer any more and even starts ranting if someone talks about their limitations. IMHO for normal adjustment, it is quite enough of this tool. The third reason is that exactly aligning the soundcard is sometimes very difficult due to the lack of reliable diagnostic software (smdiag does not work on most newer kernels, it is even missing in some of the newest ax25-* packages). It is not lack of diagnostic software. Do not use development Kernel and (or) development ax25 packages. And, if you finally managed to get some soundcard to decode incoming packets, the detection rate is often much worse than with a BayCom in hardware. Probably this bug is connected to the device /dev/hands :-) The fourth reason is that the (few) soundcard designs supposed to work with SoundModem are not available any more. That is because ISA cards are generally vanishing. The incorrect conclusion, too hasty. For PCI cards, there's no SoundModem support available. Here, it sounds a little bit ironic that Thomas Sailer, developer of the SoundModem driver, has written the Linux Kernel sound driver (http://www.ife.ee.ethz.ch/~sailer/linux/pciaudio.html) for the Ensoniq AudioPCI (http://www.ife.ee.ethz.ch/~sailer/linux/es1370.html) and the S3 SonicVibes PCI sound card (http://www.ife.ee.ethz.ch/~sailer/linux/sonicvibes.html) but seems to be too busy to extend SoundModem. This devices, yet has no standard. And still question will - whether sometime this devices standard. When you buy the similar device, it is necessary to think of it. The fifth reason is that if you want to avoid long PTT delays you'll have to use one of the parallel or serial ports from the computer to drive PTT. Yes, there us also a circuit that uses the MIDI port but a) it looks complicated, compared with the circuits for the serial or parallel port or VOX, b) it depends on a correct MIDI port setting (in other words, you'll have to make sure it is enabled and not working as a joystick port accidentally). The sixth reason is that one can easily have more than one modem of that type connected to the computer. But how about two or even more soundcards? Besides the problem of not having enough ISA slots on recent mainboards there is the problem of confguring them correctly. PCI cards are, unfortunately, not supported yet. On my computer work 2 Sound Cards. ESS-1868 - AFSK 300bps HF SB-16 Vibra - AFSK 1200bps VHF Also there is one more free ISA slot. Problem with configuring of devices, it not with a problem of the software. Now there is a new hardware design using a new chip that reportedly replaces the TI chip. Am I missing something here? Is there a significant advantage to using such an approach over using a soundcard? I mentioned six reasons. Maybe, there are even more. IMHO these reasons in the greater degree are taken from the device /dev/null Best regards Serge, rz6hff
RE: node dies with no errors
Special thanks to Richard, I found my problems with node-0.3.0! As I originally suspected it had to do with the file permissions. /usr/sbin/node's permissions from the binary rpm were set to 755. Using chmod I changed then to 4755, and the rest is history. Symtoms were inabilty to use network devices from within the node when logged in as a user, with the ability to make outbound ax25 connects. RedHat6.0 kernel-2.2.12-20 kernel-source-2.2.12-20 libax25-0.0.7-1 libax25-devel-0.0.7-1 node-0.3.0-1 etc. Regards, Wilson, WJ3G [EMAIL PROTECTED] P.S. Does node use /var/ax25/node/loggedout? Now on to make listen work for users:-)
Re: /dev/ttyS2 and /dev/ttyS3
Message-Id: 1467_kb2shu
From: kb2shu@kb2shu.#sca.ca.usa.noam
To: [EMAIL PROTECTED]
Try this insteadworks here!
${SETSERIAL} /dev/cua0 uart 16550a port 0x3f0 irq 4 ^fourport
${SERSERIAL} /dev/cua1 uart 16550a port 0x2f0 irq 3 ^fourport
Rubbish. (excuse me :) )
Well genius, take a look at the SETSERIAL docs before you shoot your
mouth off.
73 for now de Paul.
kb2shu@kb2shu.#sca.ca.usa.noam
kb2shu.ampr.org [44.16.2.46]
[EMAIL PROTECTED]
www.moonlink.net/~paul
Re: /dev/ttyS2 and /dev/ttyS3
Message-Id: 1468_kb2shu
From: kb2shu@kb2shu.#sca.ca.usa.noam
To: [EMAIL PROTECTED]
Maybe some of this *rubbish* will help you:
# AUTOMATIC CONFIGURATION
#
# Uncomment the appropriate lines below to enable auto-configuration
# of a particular board. Or comment them out to disable them
#
# NOTE! Although the automatic configuration is enabled by default,
# I strongly suggest that you comment out this section and use the
# manual configuration section instead. It's more work to set up, but
# it's more reliable.
#
###
# Do AUTOMATIC_IRQ probing
#
AUTO_IRQ=auto_irq
# These are the standard COM1 through COM4 devices
#
# If you have an internal modeme with a Rockwell Chipset, add a "skip_test"
# to the /dev/cua3 line below. (It's not added by default because it will
# screw up people with 8514 displays).
#
${SETSERIAL} /dev/cua0 ${AUTO_IRQ} skip_test autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua1 ${AUTO_IRQ} skip_test autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua2 ${AUTO_IRQ} skip_test autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua3 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
# These are for the first AST Fourport board (base address 0x1A0)
#
${SETSERIAL} /dev/cua4 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua5 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua6 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua7 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
# This enables the new multiport masking feature, which is highly recommened
# for AST FourPort boards.
#
#${SETSERIAL} /dev/cua4 set_multiport port1 0x1BF mask1 0xf match1 0xf
# These are for the second AST Fourport board (base address 0x2A0)
#
${SETSERIAL} /dev/cua8 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua9 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua10 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua11 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
# This enables the new multiport masking feature, which is highly recommened
# for AST FourPort boards.
#
#${SETSERIAL} /dev/cua8 set_multiport port1 0x2BF mask1 0xf match1 0xf
# These are the 3rd and 4th ports on the Accent Async board.
#
#${SETSERIAL} /dev/cua12 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
#${SETSERIAL} /dev/cua13 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
# Usenet Serial Board II (base address 0x100)
#
#${SETSERIAL} /dev/cua16 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
#${SETSERIAL} /dev/cua17 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
#${SETSERIAL} /dev/cua18 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
#${SETSERIAL} /dev/cua19 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
# BocaBoard 4 port (BB-1004) (base address 0x100)
#
#${SETSERIAL} /dev/cua16 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
#${SETSERIAL} /dev/cua17 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
#${SETSERIAL} /dev/cua18 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
#${SETSERIAL} /dev/cua19 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
# BocaBoard 8 port (BB-1008) (base address 0x100),
# or two BB-1004's (base addresses 0x100 and 0x120)
#
#${SETSERIAL} /dev/cua16 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
#${SETSERIAL} /dev/cua17 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
#${SETSERIAL} /dev/cua18 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
#${SETSERIAL} /dev/cua19 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
#${SETSERIAL} /dev/cua20 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
#${SETSERIAL} /dev/cua21 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
#${SETSERIAL} /dev/cua22 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
#${SETSERIAL} /dev/cua23 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
# BocaBoard 16 port (BB-1008), (base address 0x100),
# or two BB-1008's (base addresses 0x100 and 0x140),
# or four BB-1004's (base address 0x100, 0x120, 0x140, and 0x160)
#
# Warning --- some of these ports may conflict with the Future Domain
# SCSI controller. If you want to run both the BocaBoards and the
# Future Domain controller, you may need to change the port assignment
# of the Bocaboards -- see below in the section on manual configuration.
#
${SETSERIAL} /dev/cua16 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua17 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua18 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua19 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua20 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua21 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua22 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua23 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua24 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua25 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua26 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua27 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua28 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua29 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua30 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua31 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
# This enables the new multiport masking feature, which is highly recommened
# for
Re: /dev/ttyS2 and /dev/ttyS3
On Fri, 4 Feb 2000 [EMAIL PROTECTED] wrote:
Try this insteadworks here!
${SETSERIAL} /dev/cua0 uart 16550a port 0x3f0 irq 4 ^fourport
${SERSERIAL} /dev/cua1 uart 16550a port 0x2f0 irq 3 ^fourport
Rubbish. (excuse me :) )
Well genius, take a look at the SETSERIAL docs before you shoot your
mouth off.
On a box with kernel 2.2 - /usr/src/linux/Documentation/Changes :
General Information
===
...
Also, please remember that cua* devices are now obsolete. Switch to
the corresponding ttyS* device instead (e.g., cua0 - ttyS0, cua1 -
ttyS1, etc.).
...
Recommending the use of /dev/cua* is not really sensible anymore. Even if
it happened to work for someone, it will cause unnecessary trouble the
next time they upgrade...
--
Tomi Manninen Internet: [EMAIL PROTECTED]
OH2BNS AX.25: [EMAIL PROTECTED]
KP20ME04Amprnet: [EMAIL PROTECTED]
Re: API and driver interface
On Thu, 3 Feb 2000, Jens David wrote: Hmmm, are KISS TNCs still in use someplace (seriously)? -- Jens Yes, here. They still work fine. Maybe I'll put them to rest (perhaps use them as dumb modems) when there exists a DAMA/Flexnet master in place of the Linux node. That would be nice and better to cope with bandwidth greedy and impatient users ... 73, Jose --- Ing. Jose A. Amador Fundora | Tel: (537) 20-7814 Dept. de Telecomunicaciones | E-Mail : [EMAIL PROTECTED] Facultad de Ing. Electrica | ISPJAE|
Re: Routing problem
I should have given a few more clues as to the routing and arp entries in place... Here we go - note that the TX is all on ax4 but the RX ports differ: # Robin at gb7ipd - RX is on ax4 /sbin/route add -host 44.131.161.230 mss 472 window 1728 ax4 /sbin/route add -net 44.0.0.0 netmask 255.0.0.0 gw 44.131.161.230 mss 472 window 1728 ax4 # Steve at gb7itg - RX is on ax3 /sbin/route add -host 44.131.160.250 mss 472 window 1728 ax4 /sbin/route add -net 44.131.160.0 netmask 255.255.255.0 gw 44.131.160.250 mss 472 window 1728 ax4 /sbin/route add -net 44.131.163.0 netmask 255.255.255.0 gw 44.131.160.250 mss 472 window 1728 ax4 /sbin/route add -net 44.131.166.0 netmask 255.255.255.0 gw 44.131.160.250 mss 472 window 1728 ax4 /sbin/route add -net 44.131.167.0 netmask 255.255.255.0 gw 44.131.160.250 mss 472 window 1728 ax4 # Ardley node - RX is on ax6 /sbin/route add -host 44.131.160.127 mss 472 window 1728 ax4 # I'm going to need some ARP entries due to split port usage /sbin/arp -t ax25 -i ax4 -s 44.131.160.127 gb7va-1 /sbin/arp -t ax25 -i ax4 -s 44.131.161.230 gb7ipd /sbin/arp -t ax25 -i ax4 -s 44.131.160.250 gb7itg-10 Robin A few more clues please: the output of netstat -rnv of gb7ipd, gb7va, gb7itg and the 'box' and the IP addresses and netmasks of ax3, ax4 ax6 My first thought is is this a case of a split horizon (multiple subnets on one LAN) for which the answer may be secondary IP addresses for ax4. -- Regards Richard ~~~ My opinions are mine, all mine. None to spare for unopinionated masses. This message comes from a WinTel free zone. CPU = Cyrix, OS = Linux. ~~~
Re: /dev/ttyS2 and /dev/ttyS3
On Fri, Feb 04, 2000 at 05:53:25PM +, [EMAIL PROTECTED] wrote:
Message-Id: 1468_kb2shu
From: kb2shu@kb2shu.#sca.ca.usa.noam
To: [EMAIL PROTECTED]
Maybe some of this *rubbish* will help you:
# AUTOMATIC CONFIGURATION
#
# Uncomment the appropriate lines below to enable auto-configuration
# of a particular board. Or comment them out to disable them
#
# NOTE! Although the automatic configuration is enabled by default,
# I strongly suggest that you comment out this section and use the
# manual configuration section instead. It's more work to set up, but
# it's more reliable.
#
###
# Do AUTOMATIC_IRQ probing
#
AUTO_IRQ=auto_irq
# These are the standard COM1 through COM4 devices
#
# If you have an internal modeme with a Rockwell Chipset, add a "skip_test"
# to the /dev/cua3 line below. (It's not added by default because it will
# screw up people with 8514 displays).
#
${SETSERIAL} /dev/cua0 ${AUTO_IRQ} skip_test autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua1 ${AUTO_IRQ} skip_test autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua2 ${AUTO_IRQ} skip_test autoconfig ${STD_FLAGS}
${SETSERIAL} /dev/cua3 ${AUTO_IRQ} autoconfig ${STD_FLAGS}
[rest of obsolete rc.script snipped]
Now the script that comes with setserial 2.15:
#
# /etc/rc.serial
# Initializes the serial ports on your system
#
# chkconfig: 2345 50 75
# description: This initializes the settings of the serial port
#
# Distributed with setserial version 2.15
#
# note: as of 2.15, the autosave feature doesn't work if you are
# using the multiport feature; it doesn't save the multiport configuration
# (for now). Autosave also doesn't work for the hayes devices.
#Will fix later...
#
#
SETSERIAL=/bin/setserial
RCLOCKFILE=/var/lock/subsys/serial
ALLDEVS="/dev/ttyS?"
if /bin/ls /dev/ttyS?? /dev/null ; then
ALLDEVS="$ALLDEVS /dev/ttyS??"
fi
[ rest snipped ]
See?
Tomi has already mentioned Documantation/Changes.
And another one (FAQ from mgetty+sendfax):
From: "Theodore Y. Ts'o" [EMAIL PROTECTED]
/dev/ttySxx devices are fully POSIX-compliant TTY devices. If you are
only going to be using one set of tty devices, you should be using
/dev/ttySxx.
[...]
While this will allow for simple lockouts between a user using a modem
for callout and a getty listening on the line for logins, it doesn't
work if you need to arbitrate between multiple programs wanting to do
dialout --- for example, users wanting to do dialout and UUCP.
I originally implemented the cuaXX/ttySXX lockout mechanism back before
FSSTND established a standard convention for the use of tty lock files.
Now that it's there, people should use the tty lock files and not try
using /dev/cuaXX. The only reason why /dev/cuaXX hasn't disappeared yet
is for backwards compatibility reasons.
- Ted
Please note that Ted is the author maintainer of setserial.
Ok, I noted some /dev/cua occurrences in the setserial manpage, I'll send
Ted a note about that.
BTW. I've 14 serial ports running in my system, 2 onboard, 4 on a dumb
ISA card and 8 on a fourport compativle card. I've reprogrammed the
address decoding PAL-Chip on the dump card to use other base addresses.
One port runs a 4800 Baud Baycom style modem.
I think I know what I'm doing :-)
Thorsten
--
| Thorsten Kranzkowski Internet: [EMAIL PROTECTED]|
| Mobile: ++49 161 7210230Snail: Niemannsweg 30, 49201 Dissen, Germany |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, [EMAIL PROTECTED] [44.130.8.19] |
Re: API and driver interface
Gerd wrote: Hello Jens, hello all, [...] Hmmm, are KISS TNCs still in use someplace (seriously)? What other chances do you have to work with a TNC under Linux other than in the KISS mode? I guess there are still a lot of TNC users out there (think of You can and should use 6PACK instead... bye Stefan
Starting 24h ham radio server on LinuxPPC
Hi all, I have been testing ham radio (ax.25) drivers and server applications on LinuxPPC from time to time as I reported before. Yesterday, I finally switched my 24h radio/home server to LinuxPPC from x86. All x86 boxes can be thrown away from my place (I won’t do so though). I believe this is still a news. The spec of the new server is like this: PowerMac 7600/200 + Sonnet Crescendo G3 300/150/1M, 256MB DIMM LinuxPPC 1999 Q3, Paulus 2.2.15pre4 Symbios 53c895 (not recognized by MacOS but works for LinuxPPC!) 2x 8GB U2W disks by IBM Quantum 800MB SCSI disk for MacOS (only for boot purpose) RocketPort Octacable (the driver has been ported by myself) 4 TNCs (TNC2 complients a KAM) libax25-0.0.7, ax25-apps-0.0.4, ax25-tool-0.0.5 (latest ones) xfbb 7.01I by Jean-Paul ROUBELAT F6FBB (unfortunately FBB compression doesn’t work due to endien problem) DX Spider 1.38 by Dirk Koopman G1TLH mailgw 0.3.1 by Heikki Hannikainen plus patch by JH4XSY myself. Common ppp, file, mail, printer and other servers are also installed for home use. Running 24h as the main server, further problem may be reviled. Best regards, Ichiro Hieda JE1SGH [EMAIL PROTECTED] http://ocean.kz.tsukuba.ac.jp/~je1sgh/
Re: Routing problem
Hi Richard Can't help on the netstat for other than the 'box' - they are running *NOS. Can't think how that can effect matter as gb7bw has no knowledge (and I assume needs none) of how the packets are generated The output of netstat at gb7bw is as follows. ax2 is a 4m interface that I'm currently using for RX from gb7ipd so as to ensure that packets aren't routed back out the same interface. [g8ecj@gb7bw g8ecj]$ netstat -rnv Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 44.131.159.224 0.0.0.0 255.255.255.255 UH0 0 0 ax2 44.131.161.230 0.0.0.0 255.255.255.255 UH 472 1728 0 ax4 44.131.159.234 0.0.0.0 255.255.255.255 UH0 0 0 ax2 44.131.161.50.0.0.0 255.255.255.255 UH 472 1728 0 ax2 44.131.160.250 0.0.0.0 255.255.255.255 UH 472 1728 0 ax4 44.131.160.127 0.0.0.0 255.255.255.255 UH 472 1728 0 ax4 44.131.166.044.131.160.250 255.255.255.0 UG 472 1728 0 ax4 44.131.167.044.131.160.250 255.255.255.0 UG 472 1728 0 ax4 44.131.163.044.131.160.250 255.255.255.0 UG 472 1728 0 ax4 44.131.160.044.131.160.250 255.255.255.0 UG 472 1728 0 ax4 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 44.0.0.044.131.161.230 255.0.0.0 UG 472 1728 0 ax4 [g8ecj@gb7bw g8ecj]$ /sbin/ifconfig ax3 ax3 Link encap:AMPR AX.25 HWaddr GB7BW-3 inet addr:44.131.161.242 Mask:255.0.0.0 UP RUNNING MTU:511 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 [g8ecj@gb7bw g8ecj]$ /sbin/ifconfig ax4 ax4 Link encap:AMPR AX.25 HWaddr GB7BW-4 inet addr:44.131.161.242 Mask:255.0.0.0 UP RUNNING MTU:511 Metric:1 RX packets:3754 errors:0 dropped:0 overruns:0 frame:0 TX packets:825 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 [g8ecj@gb7bw g8ecj]$ /sbin/ifconfig ax6 ax6 Link encap:AMPR AX.25 HWaddr GB7BW-6 inet addr:44.131.161.242 Mask:255.0.0.0 UP RUNNING MTU:511 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 [g8ecj@gb7bw g8ecj]$ On Fri, 04 Feb 2000, you wrote: Robin A few more clues please: the output of netstat -rnv of gb7ipd, gb7va, gb7itg and the 'box' and the IP addresses and netmasks of ax3, ax4 ax6 My first thought is is this a case of a split horizon (multiple subnets on one LAN) for which the answer may be secondary IP addresses for ax4. -- 73 de Robin. G8ECJ Hub manager gb7ipd NTS: G8ECJ@GB7TVG.#42.GBR.EUAmprNet: [EMAIL PROTECTED] Internet: [EMAIL PROTECTED] http://www.gb7ipd.freeserve.co.uk/ Shack: (+44) 1628 533311Fax: (+44) 1628 850165 Club pages (g4xyw modem etc) at http://www.tvipug.freeserve.co.uk
Re: What triggers repeated poll/final transmissions?
John Ackermann wrote: The Linux setup is kernel 2.0.34 with ax25-module-14 and utils 2.1.42a. For the 19.2 link, we're running a T1 timer of 2.5 seconds, and T2 timer of 200ms. [Fri Feb 4 20:40:00 2000] Port pi0a: AX25: N8BJQ-W8APR-3 RR C P R0 [Fri Feb 4 20:40:00 2000] Port pi0a: AX25: W8APR-3-N8BJQ RR R F R0 [Fri Feb 4 20:40:02 2000] Port pi0a: AX25: N8BJQ-W8APR-3 RR C P R0 [Fri Feb 4 20:40:02 2000] Port pi0a: AX25: W8APR-3-N8BJQ RR R F R0 What do you have your T3 timer set to? (cat /proc/sys/net/ax25/*/t3_timeout). I think that would be what is causing these transmissions. T3 is known as 'CHECK' in some AX.25 implementations. It's an idle poll to ensure the remote end is still there. regards Terry
