Troubleshooting Enet-attached device

On Wed, 18 Sep 2019 03:03:02 -0400, Paul wrote:

Char Jackson wrote:
On Tue, 17 Sep 2019 21:49:56 -0400, Jason wrote:

In article ,
lid says...
That's both irrelevant and unimportant. When you're trying to connect
from within your LAN, the router has nothing to do with it. You could
remove the router entirely, replacing it with a simple switch.

Exactly. That's why I compared it to a shared printer.
Simple, right?

This is why I'm leaning toward something obscure(?) within
Windows - a setting somewhere I haven't found.

Tonight I'll try something I have not yet - to connect
from my laptop.

Are you trying to connect via its hostname or via its IP address? Have
you manually assigned an IP address that's within the subnet of your
LAN, or are you using DHCP? How are you supposed to connect? Is it via a
web browser, a telnet session, SSH, something else? Do you need to
explicitly try to connect to the destination on port 60000? (That's from
memory, I didn't go back and recheck.) What happens when you try to
connect? Is there an error message or does the request silently time
out?

By the way, are you familiar with network packet capture tools such as
Wireshark or Windump? Sometimes there's nothing better than being able
to see the packets as they traverse the network.


The ARCP890 Windows program, loaded on a computer, is supposed to
connect to particular ports on the Kenwood, to perform remote control.
The ports are not named, for LAN operation.

The manual says they use the following:
TCP port 60000 for command communication
UDP port 60001 for voice communication

It's assumed the user
clicks the "Allow" button when the Windows Firewall complains that
ARPC890.exe is "dialing particular ports that aren't normally uses".

Or just temporarily disable the firewall for a minute or two while
troubleshooting. Actual configuration can take place later.

In article , VanguardLH
wrote:


Consumer-grade routers don't do DNS lookups.

some do

Char Jackson wrote:

On Wed, 18 Sep 2019 08:13:36 +0100, Andy Burns
wrote:

Char Jackson wrote:

That's both irrelevant and unimportant. When you're trying to connect
from within your LAN, the router has nothing to do with it.

For most home networks the router is most likely the DHCP server, that
would make it relevant, but doesn't look like it's causing any problem
in this case.

One of the questions I asked in a follow-up was whether he's using DHCP.
I would recommend not using DHCP during this troubleshooting phase, but
you never know.

Also, the router comment was in response to others suggesting that he
might have to configure his router to allow specific port forwarding.
For intraLAN operation, that kind of router configuration would be
completely irrelevant and not applicable in the slightest. When you stay
within your LAN, there is no 'router' functionality involved.

Some routers can block traffic between their ports. Outward traffic is
allowed (upstream to Internet) but not between the ports. Also, since
the router has a switch, it might be setup for subnetting. The OP could
reset his router to return it to factory defaults. Better would be to
eliminate the router altogether and just connect the Kenwood directly to
his host (running the Kenwood software) to see if the problem is with
network config or security software on his host.

On 9/18/19 2:13 AM, Andy Burns wrote:
Char Jackson wrote:

That's both irrelevant and unimportant. When you're trying to connect
from within your LAN, the router has nothing to do with it.

For most home networks the router is most likely the DHCP server, that
would make it relevant, but doesn't look like it's causing any problem
in this case.

While your DHCP server is usually run on the same hardware as the
router, is doesn't have to be that way. A couple of times I have run a
DHCP server on a computer (that PC needs a static IP).

A router would be necessary for some "smart devices" that insist on
running everything through their server even if you're on the same LAN
(maybe it's a way to steal your data).

--
98 days until the winter celebration (Wed, Dec 25, 2019 12:00:00 AM for
1 day).

Mark Lloyd
http://notstupid.us/

"A man is accepted into church for what he believes--and turned out for
what he knows." -Mark Twain

On 9/18/19 10:38 AM, nospam wrote:
In article , VanguardLH
wrote:


Consumer-grade routers don't do DNS lookups.

some do

This would be a useful feature to have, at least if it could be
configured to do local DNS (for connections within that LAN).
Maintenance would be a lot easier than a HOSTS file on every PC.

--
98 days until the winter celebration (Wed, Dec 25, 2019 12:00:00 AM for
1 day).

Mark Lloyd
http://notstupid.us/

"A man is accepted into church for what he believes--and turned out for
what he knows." -Mark Twain

In article , Mark Lloyd
wrote:


Consumer-grade routers don't do DNS lookups.

some do

This would be a useful feature to have, at least if it could be
configured to do local DNS (for connections within that LAN).

zeroconf/bonjour/avahi already does that independent of the router,
using the dhcp host name.

Maintenance would be a lot easier than a HOSTS file on every PC.

many consumer routers have content filtering, without needing a local
dns server, for the entire lan as well as individual devices.

Mark Lloyd wrote:

Andy Burns wrote:

For most home networks the router is most likely the DHCP server

While your DHCP server is usually run on the same hardware as the
router, is doesn't have to be that way.

What percentage of homes would you estimate have the DHCP server on a
device /other/ than the router their ISP sent them?

In article , Andy Burns
wrote:


For most home networks the router is most likely the DHCP server

While your DHCP server is usually run on the same hardware as the
router, is doesn't have to be that way.

What percentage of homes would you estimate have the DHCP server on a
device /other/ than the router their ISP sent them?

that's why he said usually.

dhcp not on the router offers many advantages, such as being able to
swap out the router without needing to reconfigure dhcp reservations.

nospam wrote:

Andy Burns wrote:

For most home networks the router is most likely the DHCP server

While your DHCP server is usually run on the same hardware as the
router, is doesn't have to be that way.

What percentage of homes would you estimate have the DHCP server on a
device /other/ than the router their ISP sent them?

that's why he said usually.

well yes ... the same reason I said "most likely"

On Wed, 18 Sep 2019 09:10:01 -0500, VanguardLH wrote:

Jason wrote:

The fact that the radio can negotiate with ntp.pool.org to set its clock
tells me it's resolving names properly. In its setup I have the primary
DNS server set to the default - the router's address, and an external
one as secondary.

Consumer-grade routers don't do DNS lookups. SNIP

I don't think he was suggesting that they do.

On Wed, 18 Sep 2019 11:38:14 -0500, VanguardLH wrote:

Char Jackson wrote:

On Wed, 18 Sep 2019 08:13:36 +0100, Andy Burns
wrote:

Char Jackson wrote:

That's both irrelevant and unimportant. When you're trying to connect
from within your LAN, the router has nothing to do with it.

For most home networks the router is most likely the DHCP server, that
would make it relevant, but doesn't look like it's causing any problem
in this case.

One of the questions I asked in a follow-up was whether he's using DHCP.
I would recommend not using DHCP during this troubleshooting phase, but
you never know.

Also, the router comment was in response to others suggesting that he
might have to configure his router to allow specific port forwarding.
For intraLAN operation, that kind of router configuration would be
completely irrelevant and not applicable in the slightest. When you stay
within your LAN, there is no 'router' functionality involved.

Some routers can block traffic between their ports.

That is extremely rare in consumer networking gear. Isolation between
the wired ports versus the wireless ports is more common, but isolation
between the individual wired switch ports is practically nonexistent
until you get to Enterprise-level equipment.

Also, since the router has a switch, it might be setup for subnetting.

Again, assuming factory firmware, that's practically nonexistent in
consumer gear. Both of the things mentioned above are possibilities, but
quite remote.

The OP could
reset his router to return it to factory defaults. Better would be to
eliminate the router altogether and just connect the Kenwood directly to
his host (running the Kenwood software) to see if the problem is with
network config or security software on his host.

That suggestion is incomplete without also pointing out that no DHCP
server will be available, so assigning IP addresses and network masks
becomes a manual task. Also, it might not be safe to assume Auto-MDI
negotiation, meaning digging up a crossover cable, so a better
recommendation would be to use a cheap switch, where cheap means
unmanaged, but then we're back to talking about the switch that comes as
part of the router package.

On Wed, 18 Sep 2019 08:10:08 -0400, Jason
wrote:

In article ,
says...
For most home networks the router is most likely the DHCP server, that
would make it relevant, but doesn't look like it's causing any problem
in this case.

The fact that the radio can negotiate with ntp.pool.org to set its clock
tells me it's resolving names properly. In its setup I have the primary
DNS server set to the default - the router's address, and an external
one as secondary.

IIUC, the radio is not initiating the connection to your host PC. It's
the other way around, so it doesn't help that the radio has Internet
access. What you need is for the host PC to be able to resolve the
radio's address.

If you're trying to connect from the host PC to the radio via a
hostname, you need to make sure that the hostname resolves to the
radio's IP address. You can do that by pinging the radio's hostname and
checking the results to see that the proper IP address got returned in
the results. Once the host PC has learned the radio's IP address, it
should use ARP to resolve the IP address into a MAC address, and by then
you're golden.

If you're trying to connect to the radio via its IP address, it's
exactly the same except you're skipping the hostname resolution step.

Char Jackson wrote:

On Wed, 18 Sep 2019 08:10:08 -0400, Jason
wrote:

In article ,
says...
For most home networks the router is most likely the DHCP server, that
would make it relevant, but doesn't look like it's causing any problem
in this case.

The fact that the radio can negotiate with ntp.pool.org to set its clock
tells me it's resolving names properly. In its setup I have the primary
DNS server set to the default - the router's address, and an external
one as secondary.

IIUC, the radio is not initiating the connection to your host PC. It's
the other way around, so it doesn't help that the radio has Internet
access. What you need is for the host PC to be able to resolve the
radio's address.

If you're trying to connect from the host PC to the radio via a
hostname, you need to make sure that the hostname resolves to the
radio's IP address. You can do that by pinging the radio's hostname and
checking the results to see that the proper IP address got returned in
the results. Once the host PC has learned the radio's IP address, it
should use ARP to resolve the IP address into a MAC address, and by then
you're golden.

If you're trying to connect to the radio via its IP address, it's
exactly the same except you're skipping the hostname resolution step.

Could be the software he installs modifies the hosts file to equate a
hostname with an IP address. Or he could add his own entry in the hosts
file. However, if he uses the IP address of the Kenwood device
(provided he knows it) then he doesn't need a DNS lookup. While he may
not need a hostname by using an IP address to find the Kenwood, could be
the software uses a hostname.

Char Jackson wrote:

On Wed, 18 Sep 2019 11:38:14 -0500, VanguardLH wrote:

Char Jackson wrote:

On Wed, 18 Sep 2019 08:13:36 +0100, Andy Burns
wrote:

Char Jackson wrote:

That's both irrelevant and unimportant. When you're trying to connect
from within your LAN, the router has nothing to do with it.

For most home networks the router is most likely the DHCP server, that
would make it relevant, but doesn't look like it's causing any problem
in this case.

One of the questions I asked in a follow-up was whether he's using DHCP.
I would recommend not using DHCP during this troubleshooting phase, but
you never know.

Also, the router comment was in response to others suggesting that he
might have to configure his router to allow specific port forwarding.
For intraLAN operation, that kind of router configuration would be
completely irrelevant and not applicable in the slightest. When you stay
within your LAN, there is no 'router' functionality involved.

Some routers can block traffic between their ports.

That is extremely rare in consumer networking gear.

It was in a DLink router that I had. Alas, it burned up over time (they
have no fans, rely on convection current, but often decay over time due
to heat). The Linksys which replaced it didn't have the option. Oh, I
remember looking intently, because I liked being isolated from the rest
of the family. The Dlink was a consumer-priced router, not a
high-priced enterprise rack mount. Rather than physically isolating the
ports, likely it was a firewall feature in the router controlling
inbound traffic between ports.

That suggestion is incomplete without also pointing out that no DHCP
server will be available, so assigning IP addresses and network masks
becomes a manual task. Also, it might not be safe to assume Auto-MDI
negotiation, meaning digging up a crossover cable, so a better
recommendation would be to use a cheap switch, where cheap means
unmanaged, but then we're back to talking about the switch that comes as
part of the router package.

Since his Kenwood lets him specify using DHCP, it should also let him
specify a fixed IP address. A dynamic IP address is only for
convenience to users and admins.

If he is using a non-crossover cable between the router and the Kenwood
(very likely), the same cable will work between the host and Kenwood.
Both with auto-negotiate on their end to eliminate the need for a
special cable. That's what the router does, too.

Andy Burns wrote:

Mark Lloyd wrote:

Andy Burns wrote:

For most home networks the router is most likely the DHCP server

While your DHCP server is usually run on the same hardware as the
router, is doesn't have to be that way.

What percentage of homes would you estimate have the DHCP server on a
device /other/ than the router their ISP sent them?

Some folks use PCs as gateway hosts. They could run a DHCP server
there. However, as you say, typical home users don't often get into
complex configurations, yet posters here probably don't qualify as
typical home users. Most home users don't even have a router. They
just use the RJ45 ports and wifi from the cable modem.