On Aug 24, 2008, at 6:54 PM, Aaron Elekes wrote:
> No the KE5KAF is the main callsign for the repeater. I do not use
> that call when using Dstar. I am aware of the problems that would
> occur.
>
> Thanks anyways...
>
Pete AE5PL recently noted problems with a Gateway that had the "S"
callsign registered on the Personal Info page. If I understand his
information he sent to the Gateway list correctly, he saw a bunch of
packets constantly streaming between the Controller and Gateway that
really shouldn't have been there.
KE5KAF S -- Try removing the KE5KAF S from the Personal Info page
while logged into the system as the Admin/KE5KAF and then reboot the
controller, and see if the problem goes away.
As Pete pointed out, nothing in the documentation says there should be
an "S" callsign registered that he was aware of.
We had a degradation in service on W0CDS that I never *directly*
traced to this, but somewhere during our setup I was also fooled into
thinking an "S" callsign was a requirement in the Personal Info tab
for the main system's callsign. Around the time of the controller
reboot that cleared the problem, this info was coming out on Gateway,
and I removed it. Nothing like that has happened since that time.
My thought about it is this: If something in the software doesn't
"like" there being an "S" login, the controller only has a 10 Mb/s
*HALF-DUPLEX* Ethernet connection. Extra packets on that LAN segment
between the controller and the Gateway server are going to collide
sooner or later with the desired audio traffic.
Additionally, I think it adds another point of failure that's not
necessary when I see folks running the Controller-to-Gateway Ethernet
connectivity through a switch or a hub. Put an Ethernet cross-over
cable between them and keep it totally separated from other traffic.
The only two machines necessary on that LAN segment for most setups
are those two... why have anything in-between them at all, if the
controller is as touchy about latency and packet loss as people say it
is.
Finally, I think you can *see* the traffic Pete mentioned and of
course all other dstar traffic going to/from your Gateway with Robin
AA4RC's dshark tool. If you haven't loaded it, it's definitely worth
having for troubleshooting!
Finally -- the SIMPLE stuff. NO ERRORS on any interface when you look
at the output of the "ifconfig" command, right? None. If there are
any, you have to stop there and fix that before moving on...
[EMAIL PROTECTED] tools]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:14:D1:14:D3:C0
inet addr:10.0.0.2 Bcast:10.255.255.255 Mask:255.0.0.0
inet6 addr: fe80::214:d1ff:fe14:d3c0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3241297 errors:0 dropped:0 overruns:0 frame:0
TX packets:1546792 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:515843599 (491.9 MiB) TX bytes:117161379 (111.7
MiB)
Interrupt:169 Base address:0xcc00
eth1 Link encap:Ethernet HWaddr 00:1B:B9:CA:3A:17
inet addr:172.16.0.20 Bcast:172.16.0.255 Mask:255.255.255.0
inet6 addr: fe80::21b:b9ff:feca:3a17/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3128502 errors:0 dropped:0 overruns:0 frame:0
TX packets:3128544 errors:0 dropped:0 overruns:0 carrier:0
collisions:21 txqueuelen:1000
RX bytes:193128030 (184.1 MiB) TX bytes:218297538 (208.1
MiB)
Interrupt:201 Base address:0xe800
If you're using a crossover Ethernet cable between the Controller and
the internal Ethernet interface on the Gateway, you'll see this with
mii-tool:
[EMAIL PROTECTED] tools]# mii-tool eth1
eth1: autonegotiation failed, link ok
Completely normal. 10 Mb/s Half-Duplex devices like the Controller
don't know HOW to autonegotiate. (Why they made the controller half-
duplex, is beyond me. Another in a long list of basic IP/network
engineering mistakes from Icom.)
--
Nate Duehr, WY0X
[EMAIL PROTECTED]
