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 |
#16
|
|||
|
|||
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. |
Ads |
#17
|
|||
|
|||
Troubleshooting Enet-attached device
In article , VanguardLH
wrote: Consumer-grade routers don't do DNS lookups. some do |
#18
|
|||
|
|||
Troubleshooting Enet-attached device
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. |
#19
|
|||
|
|||
Troubleshooting Enet-attached device
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 |
#20
|
|||
|
|||
Troubleshooting Enet-attached device
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 |
#21
|
|||
|
|||
Troubleshooting Enet-attached device
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. |
#22
|
|||
|
|||
Troubleshooting Enet-attached device
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? |
#23
|
|||
|
|||
Troubleshooting Enet-attached device
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. |
#24
|
|||
|
|||
Troubleshooting Enet-attached device
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" |
#25
|
|||
|
|||
Troubleshooting Enet-attached device
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. |
#26
|
|||
|
|||
Troubleshooting Enet-attached device
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. |
#27
|
|||
|
|||
Troubleshooting Enet-attached device
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. |
#28
|
|||
|
|||
Troubleshooting Enet-attached device
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. |
#29
|
|||
|
|||
Troubleshooting Enet-attached device
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. |
#30
|
|||
|
|||
Troubleshooting Enet-attached device
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. |
Thread Tools | |
Display Modes | Rate This Thread |
|
|