If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#1
|
|||
|
|||
Troubleshooting Enet-attached device
My home network is both wireless and wired.
Several PC's, printers, an AV receiver and UPS backup are attached to Enet ports via 4-port switches. All of them show up when I open Devices & Printers. Now I have a new gadget (a Kenwood TS-890 ham transceiver) that supports Enet but does NOT show in that listing and I'm seeking help troubleshooting. I believe the transceiver is "talking" to Enet; it can query a NTP server to set its clock. That function worked properly once I configured the server info. (I suspect there's Linux running inside.) I can find the device when I open up the router settings, and I can ping it successfully, but when I try to connect to it with Kenwood-supplied software it fails. (It also has a USB port. That connection works fine.) The built-in troubleshooter didn't find it. Where should I look? |
Ads |
#2
|
|||
|
|||
Troubleshooting Enet-attached device
Jason wrote:
My home network is both wireless and wired. Several PC's, printers, an AV receiver and UPS backup are attached to Enet ports via 4-port switches. All of them show up when I open Devices & Printers. Now I have a new gadget (a Kenwood TS-890 ham transceiver) that supports Enet but does NOT show in that listing and I'm seeking help troubleshooting. I believe the transceiver is "talking" to Enet; it can query a NTP server to set its clock. That function worked properly once I configured the server info. (I suspect there's Linux running inside.) I can find the device when I open up the router settings, and I can ping it successfully, but when I try to connect to it with Kenwood-supplied software it fails. (It also has a USB port. That connection works fine.) The built-in troubleshooter didn't find it. Where should I look? According to what little I saw in the manual that I downloaded from Kenwood's site, the scenarios they show are with the TS-890 connected to the broadband modem (with its internal router) or via a "hub" (which might be just another router or switch in an intranet setup). Okay, but the modem or router very likely have their own internal firewall. Did you punch a hole in the modem/router's security to allow unsolicited traffic to get to the TS-890, like define a port-forwarding rule in the modem/router's firewall? A diagram of your network setup would better help diagnose the situation instead of assuming we know what you have. You could be using a gateway host between segments of your intranet with its own firewalling or rules, or you're trying to use access points between segments of your intranet, or the host where you run the remoting software is on the other side of a router or switch in your intranet from the network segment where is your TS-890 and you need to punch holes in the security settings in the router or switch. |
#3
|
|||
|
|||
Troubleshooting Enet-attached device
Jason wrote:
My home network is both wireless and wired. Several PC's, printers, an AV receiver and UPS backup are attached to Enet ports via 4-port switches. All of them show up when I open Devices & Printers. Now I have a new gadget (a Kenwood TS-890 ham transceiver) that supports Enet but does NOT show in that listing and I'm seeking help troubleshooting. I believe the transceiver is "talking" to Enet; it can query a NTP server to set its clock. That function worked properly once I configured the server info. (I suspect there's Linux running inside.) I can find the device when I open up the router settings, and I can ping it successfully, but when I try to connect to it with Kenwood-supplied software it fails. (It also has a USB port. That connection works fine.) The built-in troubleshooter didn't find it. Where should I look? https://www.kenwood.com/i/products/i...S-890S_IDM.pdf The ARCP890 program probably needs an opened port on the firewall. When the program is installed, it should be setting this up itself. However, if you can find the port requirements in the documentation, you might open the port manually. There is more bilge in a second manual. Page 42 or so. https://www.kenwood.com/i/products/i...s_manual_e.pdf They mention, for example, port forwarding 60001 for some thru-the-router function. But only show a firewall "permission" dialog where you're supposed to "allow" anything the program wants to do. Since the function claims to be VOIP, it might well be opening multiple ports (as VOIP tends to separate the control and data plane). The executable is an Installshield, so I cannot quickly check to see if there is yet another manual inside this. https://www.kenwood.com/i/products/i...arcp890_e.html It may be "free software" (whatever that means), but no source is offered. A 25MB installer is big enough for a Linux package to be packaged with QT5 for usage on a Windows machine. It's an awfully big package for a simple remote control. Since it has a .NET 4.7 dependency, if that is missing, either the program should install it by itself, or there should be a dialog requesting that you install it. Paul |
#4
|
|||
|
|||
Troubleshooting Enet-attached device
VanguardLH and Paul, thanks for your replies. I have not
had a chance to fiddle with anything for a few days, but will have some time later this week. To my simple mind, locally connecting to the radio should be about as hard as connecting a shared printer. There is another publication that's just about networking, https://www.kenwood.com/i/products/info/amateur/ts_ 890/pdf/ts890_kns_manual_e.pdf It shows how to configure everything both locally (simple) and for control over the Internet. There is a diagram for the simple case in section 3.1. That's my setup. The router "sees" the device. Windows' Devices and Printers page does not find it when I click Find a Device however. More to follow. |
#5
|
|||
|
|||
Troubleshooting Enet-attached device
On Mon, 16 Sep 2019 19:14:36 -0400, Jason wrote:
VanguardLH and Paul, thanks for your replies. I have not had a chance to fiddle with anything for a few days, but will have some time later this week. To my simple mind, locally connecting to the radio should be about as hard as connecting a shared printer. There is another publication that's just about networking, https://www.kenwood.com/i/products/i...s_manual_e.pdf It shows how to configure everything both locally (simple) and for control over the Internet. There is a diagram for the simple case in section 3.1. That's my setup. I agree with you. Connecting from within your LAN looks simple. The router "sees" the device. 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. That's how unimportant the router is. Later, when connecting from within the LAN is working properly, you can consider connecting from across the Internet and in that case the router becomes important, from a port forwarding perspective. Obviously, no port forwarding is required if you stay within your LAN. Windows' Devices and Printers page does not find it when I click Find a Device however. That's also irrelevant and won't affect operation. More to follow. |
#6
|
|||
|
|||
Troubleshooting Enet-attached device
|
#7
|
|||
|
|||
Troubleshooting Enet-attached device
On Tue, 17 Sep 2019 21:49:56 -0400, Jason wrote:
In article , 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. |
#8
|
|||
|
|||
Troubleshooting Enet-attached device
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. 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". Paul |
#9
|
|||
|
|||
Troubleshooting Enet-attached device
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. |
#10
|
|||
|
|||
Troubleshooting Enet-attached device
|
#11
|
|||
|
|||
Troubleshooting Enet-attached device
|
#12
|
|||
|
|||
Troubleshooting Enet-attached device
Jason wrote:
In article , lid says... 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". Windows is silent on the matter. I'd expect the behavior you cite, but it doesn't happen. Can you test on Windows 7 ? As a baseline. Paul |
#13
|
|||
|
|||
Troubleshooting Enet-attached device
Paul wrote:
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. 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". Paul But Windows Firewall doesn't monitor outbound connections. Well, normally the Windows Firewall doesn't block outbound connections, but it can be configured to do so yet few users would do that, especially since the Windows Firewall won't issue an alert that lets the user allow or block the connection. A blocked outbound connection would log an event, and there are programs that will monitor the events to check if there was a block and then present an Allow/Block prompt. I would not expect outbound connections from ARPC890 to trigger the Windows Firewall (it may with 3rd party firewalls). Although Jason says his setup is simple and the diagram in section 3.1 of the manual is similar to his setup, we don't know what is between the host (where he runs the ARPC890 program) and the Kenwood device. For example, he might have a router or switch between the two instead of directly hooking the Kenwood's RJ45 Ethernet jack straight into the host's RJ45 Ethernet jack. If there is more than just a cable between the two, might help to know what other devices are between them. A router and even a switch could restrict traffic between its RJ45 Ethernet jacks. I had a DLink router that would let me do that, so I could connect to the cable modem without allowing any of my family's network traffic from reaching my host. The router or switch might be configured to use different subnets on its different RJ45 ports. That the router should see the Kenwood or any other device connected to it doesn't mean the devices can see each other across the ports on the router. To test just the ARPC890 software and the Kenwood device, cable the Kenwood directly to the host running ARPC890. That means losing Internet connectivity on the host (unless it is also using wifi) during the test. Jason has never mentioned how much he paid for the Kenwood shortwave. If he paid the $3000+ retail price, I would think he'd be talking to Kenwood support. Likely the Kenwood is used, and maybe the prior owner sold it off because of problems with the embedded OS inside the Kenwood. I did not see mention of how to update the OS or burn new firmware into the Kenwood in its manual. From: https://www.kenwood.com/i/products/i..._download.html there is new firmware for the TS-890S (didn't find a TS-890 listed at Kenwood's site). There's also a newer version of the ARCP890 software. Both are dated Jan 2019. Testing with the Kenwood directly connected to the Windows host would eliminate interference from the router or anything else in the network between the two endpoints. |
#14
|
|||
|
|||
Troubleshooting Enet-attached device
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. They merely pass the requests received on port 53 to whatever DNS server is upstream of them (typically the ISP's DNS server). If your workstation is using DHCP and uses the DNS server reported by the DHCP server, then you are likely using the DNS server from your ISP. You can configure TCP properties in your host to use a different DNS server than the one DHCP reports to your host. Routers have their own DHCP servers, but they don't have their own DNS servers. In fact, the DHCP server in the router should simply pass the DNS server's IP address that it got from its upstream DHCP server (what it gets from your ISP's DHCP server to get its WAN-side IP address and also the DNS server's IP address). Some routers do have a DNS cache, and why specifying your router as the DNS server can result in a faster response time than using the upstream DNS server (try GRC's DNS Benchmark tool). |
#15
|
|||
|
|||
Troubleshooting Enet-attached device
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. |
Thread Tools | |
Display Modes | Rate This Thread |
|
|