This is frustrating, because it works for me under ifconfig, but not under ip (iproute2). I have 3 devices in this scenario... * my desktop PC 192.168.123.251/29 * an HDHomerun TV tuner that comes up in the 169.254.0.0/16 block * the ADSL router/modem at 192.168.123.254/29 to which the PC and the tuner are connected. I'm trying to get my desktop PC to talk to the TV tuner using ip. What am I doing wrong in the following set of commands? ip address flush dev eth0 ip link set eth0 down ip link set eth0 up ip address add 192.168.123.251/29 dev eth0 ip route add default via 192.168.123.254 ip address add 169.254.1.1/16 dev eth0 ip route delete 169.254.0.0/16 dev eth0 ip route add 169.254.0.0/16 via 192.168.123.254 ip address show ip route show The ouput from the 2 "show" commands is... 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo valid_lft forever preferred_lft forever 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 00:1d:09:96:6c:1c brd ff:ff:ff:ff:ff:ff inet 192.168.123.251/29 scope global eth0 valid_lft forever preferred_lft forever inet 169.254.1.1/16 scope global eth0 valid_lft forever preferred_lft forever default via 192.168.123.254 dev eth0 127.0.0.0/8 dev lo scope host 169.254.0.0/16 via 192.168.123.254 dev eth0 192.168.123.248/29 dev eth0 proto kernel scope link src 192.168.123.251 -- Walter Dnes <waltdnes@waltdnes.org>
Not really enough to go on. If the adsl router/modem is a hub/switch to these two devices, give one of the devices a 2nd ip on the others subnet range. If you have to go via a gateway, make sure the gateway can route/forwarding. Just use tcpdump or similar on the devices where you can and see where the issue is, you may even see some "who has....." broadcasts that are not answered. maybe you had a ifconfig ........ eth0:1 in your other set up. Post your ifconfig -a netstat -rn arp -an also have iptables active? having said all that, how can you do this: ip address add 192.168.123.251/29 dev eth0 ip route add default via 192.168.123.254 ip address add 169.254.1.1/16 dev eth0 you are overriding the previous, make it eth0:1 unless ip address add some how auto assigns the virtual eth0:#? been a while since i used iproute2. In a quick google, i do see iproute2 using eth#:# notation. -tl On Fri, Feb 27, 2015 at 2:21 AM, Walter Dnes <waltdnes@waltdnes.org> wrote:
This is frustrating, because it works for me under ifconfig, but not under ip (iproute2). I have 3 devices in this scenario...
* my desktop PC 192.168.123.251/29 * an HDHomerun TV tuner that comes up in the 169.254.0.0/16 block * the ADSL router/modem at 192.168.123.254/29 to which the PC and the tuner are connected.
I'm trying to get my desktop PC to talk to the TV tuner using ip. What am I doing wrong in the following set of commands?
ip address flush dev eth0 ip link set eth0 down ip link set eth0 up ip address add 192.168.123.251/29 dev eth0 ip route add default via 192.168.123.254 ip address add 169.254.1.1/16 dev eth0 ip route delete 169.254.0.0/16 dev eth0 ip route add 169.254.0.0/16 via 192.168.123.254 ip address show ip route show
The ouput from the 2 "show" commands is... 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo valid_lft forever preferred_lft forever 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 00:1d:09:96:6c:1c brd ff:ff:ff:ff:ff:ff inet 192.168.123.251/29 scope global eth0 valid_lft forever preferred_lft forever inet 169.254.1.1/16 scope global eth0 valid_lft forever preferred_lft forever default via 192.168.123.254 dev eth0 127.0.0.0/8 dev lo scope host 169.254.0.0/16 via 192.168.123.254 dev eth0 192.168.123.248/29 dev eth0 proto kernel scope link src 192.168.123.251
-- Walter Dnes <waltdnes@waltdnes.org> --- Talk Mailing List talk@gtalug.org http://gtalug.org/mailman/listinfo/talk
On 02/27/2015 02:21 AM, Walter Dnes wrote:
ip route add 169.254.0.0/16 via 192.168.123.254
The 169.254.0.0 range is not supposed to be routed. Why are you forwarding to your router? Why are you even using it? Can that tuner not obtain an address via DHCP? That 169.254.0.0 network is intended for peer to peer use, when DHCP fails.
On Fri, Feb 27, 2015 at 07:54:40AM -0500, James Knott wrote:
On 02/27/2015 02:21 AM, Walter Dnes wrote:
ip route add 169.254.0.0/16 via 192.168.123.254
The 169.254.0.0 range is not supposed to be routed. Why are you forwarding to your router? Why are you even using it? Can that tuner not obtain an address via DHCP? That 169.254.0.0 network is intended for peer to peer use, when DHCP fails.
I second that. Link local addresses are not to be routed, and any sane tool will prevent you from doing so. ifconfig is NOT a sane tool these days. Fix the network config so the HDHomeRun gets a real address. -- Len Sorensen
On 02/27/2015 04:03 PM, Lennart Sorensen wrote:
ifconfig is NOT a sane tool these days.
It predates the 169.254.00 link local addresses, so it likely wouldn't "know" they aren't to be routed. With IPv6, link local addresses are based on the MAC address and start with FE80. Since they're based on the MAC address, there's no need to pick a random number.
Lennart Sorensen wrote:
ifconfig is NOT a sane tool these days.
I hadn't noticed it change at all over the decades. It did look lonely without thenconfig and elseconfig commands to keep it company somehow. Granted, the ip command on a Linux box has access to a lot more functionality and uses CIDR notation, so navigating one's way through what it does in lieu of proper documentation and learning to use it does pay off. -- Anthony de Boer
169.254. looks awfully familiar, and it only comes up when device can't get IP. Things would go easier if HDHomerun got an IP from the router. -- William On Fri, Feb 27, 2015 at 02:21:36AM -0500, Walter Dnes wrote:
This is frustrating, because it works for me under ifconfig, but not under ip (iproute2). I have 3 devices in this scenario...
* my desktop PC 192.168.123.251/29 * an HDHomerun TV tuner that comes up in the 169.254.0.0/16 block * the ADSL router/modem at 192.168.123.254/29 to which the PC and the tuner are connected.
I'm trying to get my desktop PC to talk to the TV tuner using ip. What am I doing wrong in the following set of commands?
ip address flush dev eth0 ip link set eth0 down ip link set eth0 up ip address add 192.168.123.251/29 dev eth0 ip route add default via 192.168.123.254 ip address add 169.254.1.1/16 dev eth0 ip route delete 169.254.0.0/16 dev eth0 ip route add 169.254.0.0/16 via 192.168.123.254 ip address show ip route show
The ouput from the 2 "show" commands is... 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo valid_lft forever preferred_lft forever 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 00:1d:09:96:6c:1c brd ff:ff:ff:ff:ff:ff inet 192.168.123.251/29 scope global eth0 valid_lft forever preferred_lft forever inet 169.254.1.1/16 scope global eth0 valid_lft forever preferred_lft forever default via 192.168.123.254 dev eth0 127.0.0.0/8 dev lo scope host 169.254.0.0/16 via 192.168.123.254 dev eth0 192.168.123.248/29 dev eth0 proto kernel scope link src 192.168.123.251
-- Walter Dnes <waltdnes@waltdnes.org> --- Talk Mailing List talk@gtalug.org http://gtalug.org/mailman/listinfo/talk
On 02/27/2015 10:26 AM, William Park wrote:
169.254. looks awfully familiar, and it only comes up when device can't get IP. Things would go easier if HDHomerun got an IP from the router.
Here's some info on it: https://en.wikipedia.org/wiki/Link-local_address#IPv4 Note that it says you shouldn't use it and regular IP addresses together. This is because computers will use either a regular IP address or a link local address, but not both. It takes more configuration to provide both on the same interface. It can be done, but shouldn't be. I agree the cause of this problem is that device using a 169.254.0.0 /16 address. It should use DHCP or a static address.
On 02/27/2015 02:21 AM, Walter Dnes wrote:
ip address add 169.254.1.1/16 dev eth0
One other issue. When those addresses are used, a device picks a random number within the range and then does an arp request to see if it's in use. That doesn't happen when you assign an address as you've done here. This means that if your computer comes up after that tuner and the tuner has already picked 169.254.1.1, you will have an address conflict.
On Fri, Feb 27, 2015 at 02:21:36AM -0500, Walter Dnes wrote:
This is frustrating, because it works for me under ifconfig, but not under ip (iproute2). I have 3 devices in this scenario...
* my desktop PC 192.168.123.251/29 * an HDHomerun TV tuner that comes up in the 169.254.0.0/16 block * the ADSL router/modem at 192.168.123.254/29 to which the PC and the tuner are connected.
I'm trying to get my desktop PC to talk to the TV tuner using ip. What am I doing wrong in the following set of commands?
ip address flush dev eth0 ip link set eth0 down ip link set eth0 up ip address add 192.168.123.251/29 dev eth0 ip route add default via 192.168.123.254 ip address add 169.254.1.1/16 dev eth0 ip route delete 169.254.0.0/16 dev eth0 ip route add 169.254.0.0/16 via 192.168.123.254 ip address show ip route show
The ouput from the 2 "show" commands is... 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo valid_lft forever preferred_lft forever 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 00:1d:09:96:6c:1c brd ff:ff:ff:ff:ff:ff inet 192.168.123.251/29 scope global eth0 valid_lft forever preferred_lft forever inet 169.254.1.1/16 scope global eth0 valid_lft forever preferred_lft forever default via 192.168.123.254 dev eth0 127.0.0.0/8 dev lo scope host 169.254.0.0/16 via 192.168.123.254 dev eth0 192.168.123.248/29 dev eth0 proto kernel scope link src 192.168.123.251
Assuming 192.168.123.254 complies with standards, it should refuse to route link local addreses, which is what 169.254.0.0/16 is for. The only time you see 169.254.0.0/16 is when DHCP fails, or if someone really knows what they are doing and have a reason to use addresses that can not be routed. -- Len Sorensen
On 02/27/2015 04:05 PM, Lennart Sorensen wrote:
The only time you see 169.254.0.0/16 is when DHCP fails, or if someone really knows what they are doing and have a reason to use addresses that can not be routed.
Even so, according to RFC 3927, you're not supposed to have routable and link local addresses on an interface at the same time.
On Fri, Feb 27, 2015 at 04:44:08PM -0500, James Knott wrote:
On 02/27/2015 04:05 PM, Lennart Sorensen wrote:
The only time you see 169.254.0.0/16 is when DHCP fails, or if someone really knows what they are doing and have a reason to use addresses that can not be routed.
Even so, according to RFC 3927, you're not supposed to have routable and link local addresses on an interface at the same time.
Well IPv6 does it all the time and requires it in the standard. Not IPv4 though. And I have not done them at the same time for IPv4, only ever when link local traffic was the only thing the interface was supposed to carry. -- Len Sorensen
On 02/27/2015 05:35 PM, Lennart Sorensen wrote:
Well IPv6 does it all the time and requires it in the standard. Not IPv4 though.
Yep, with IPv6, an interface may have several addresses. They always have at least the link local and 1 or more routable addresses. Also, link local addresses are used for much more than on IPv4. For example, routers are generally reached via the link local address.
On 27 February 2015 at 18:00, James Knott <james.knott@rogers.com> wrote:
Yep, with IPv6, an interface may have several addresses. They always have at least the link local and 1 or more routable addresses.
Shouldn't that be "[...] and 0 or more routable addresses"? I thought you needed only a link local address, if the device doesn't need to talk any further than its local net. -- Scott
On 02/27/2015 06:22 PM, Scott Allen wrote:
On 27 February 2015 at 18:00, James Knott <james.knott@rogers.com> wrote:
Yep, with IPv6, an interface may have several addresses. They always have at least the link local and 1 or more routable addresses. Shouldn't that be "[...] and 0 or more routable addresses"? I thought you needed only a link local address, if the device doesn't need to talk any further than its local net.
Technically yes, but you won't get very far with only a link local address. You also have to specify which interface to use, even if there's only one. For example, ping6 has an option "-I" which you have to use if you ping an IPv6 link local address. You have to do something similar with browsers etc. One thing that uses IPv6 link local addresses is the Windows Home Group networking. It won't even work without IPv6 enabled.
On 27 February 2015 at 18:35, James Knott <james.knott@rogers.com> wrote:
You also have to specify which interface to use, even if there's only one.
That's not necessarily a requirement. The interface wouldn't have to be specified if there was only one. It's just what whoever wrote the software decided to do, due to laziness, or wanting consistency, or being unable to determine if there was only one interface. -- Scott
On 02/27/2015 06:50 PM, Scott Allen wrote:
That's not necessarily a requirement. The interface wouldn't have to be specified if there was only one. It's just what whoever wrote the software decided to do, due to laziness, or wanting consistency, or being unable to determine if there was only one interface.
Try it. I have, with ping, browsers and ssh. They all require the interface to be specified. With ping6, it the -I option. With ssh & browsers it's %<interface>. Unlike routable addresses, there is nothing in an IPv6 link local address to specify what network it's on and, in fact, it's possible to have the same link local address on multiple networks connected to the same device.
On 27 February 2015 at 19:01, James Knott <james.knott@rogers.com> wrote:
Try it. I have, with ping, browsers and ssh. They all require the interface to be specified.
But it's only a requirement because that's the way those programs were written. I could write a new version of ping6, or any other program, that first checked if there was only one interface and, if so, didn't require the user to specify it. I could also write a ping6 version that tried each interface until it got a response. So, like I said it's a convention, not a requirement. BTW, the %<interface> format is a standard and can also be used with ping6 instead of -I. -- Scott
On 02/27/2015 07:18 PM, Scott Allen wrote:
Try it. I have, with ping, browsers and ssh. They all require the interface to be specified. But it's only a requirement because that's the way those programs were written. I could write a new version of ping6, or any other program,
On 27 February 2015 at 19:01, James Knott <james.knott@rogers.com> wrote: that first checked if there was only one interface and, if so, didn't require the user to specify it. I could also write a ping6 version that tried each interface until it got a response.
So, like I said it's a convention, not a requirement.
BTW, the %<interface> format is a standard and can also be used with ping6 instead of -I.
Then you'd have to worry about different ways of using those apps when there's one or more than one interface. Right now, you have to specify the interface no matter how many there are. And yes I know about % with ping6, but -I is listed in the man page.
On 27 February 2015 at 19:27, James Knott <james.knott@rogers.com> wrote:
And yes I know about % with ping6, but -I is listed in the man page.
So is %<interface>, at the end of the -I option description: "For ping6, when doing ping to a link-local scope address, link specification (by the '%'-notation in destination, or by this option) is required." -- Scott
A general reply to everybody telling me I'm doing it wrong... 1) It's WAD (Working As Designed). I'm doing what the instructions told me to do. YES!!! 2) It's an ancient model, that does not allow setting a static IP address 3) The setup works fine under ifconfig; but not under ip (iproute2). Gentoo recently changed to iproute2 as the default networking suite. I have to over-ride the default to get it working again. 4) A change of the default is usually a precursor to eventually getting rid of support for the old default alltogether. I want to get it working under ip (iproute2) before Gentoo dumps support for ifconfig. -- Walter Dnes <waltdnes@waltdnes.org>
On 02/27/2015 10:08 PM, Walter Dnes wrote:
A general reply to everybody telling me I'm doing it wrong...
1) It's WAD (Working As Designed). I'm doing what the instructions told me to do. YES!!!
2) It's an ancient model, that does not allow setting a static IP address
3) The setup works fine under ifconfig; but not under ip (iproute2). Gentoo recently changed to iproute2 as the default networking suite. I have to over-ride the default to get it working again.
4) A change of the default is usually a precursor to eventually getting rid of support for the old default alltogether. I want to get it working under ip (iproute2) before Gentoo dumps support for ifconfig.
Does it not even allow DHCP? If not then that is a really crappy piece of hardware. As mentioned, the setup you were running violates the IPv4 link local RFC, so I doubt iproute2 will ever support it.
On 02/27/2015 10:15 PM, James Knott wrote:
As mentioned, the setup you were running violates the IPv4 link local RFC, so I doubt iproute2 will ever support it.
One other possibility, put another NIC in the computer just to handle that tuner. Configure it for DHCP and it will fail to link local.
On Fri, Feb 27, 2015 at 10:15:13PM -0500, James Knott wrote
Does it not even allow DHCP? If not then that is a really crappy piece of hardware.
No. I have an ancient HDHR-US model. Looking back at my archived emails, I figure that I got it sometime around June 2010. The output from "get help" is... Supported configuration options: /ir/target <protocol>://<ip>:<port> /lineup/location <countrycode>:<postcode> /sys/copyright /sys/debug /sys/features /sys/hwmodel /sys/model /sys/restart <resource> /sys/version /tuner<n>/channel <modulation>:<freq|ch> /tuner<n>/channelmap <channelmap> /tuner<n>/debug /tuner<n>/filter "0x<nnnn>-0x<nnnn> [...]" /tuner<n>/lockkey /tuner<n>/program <program number> /tuner<n>/streaminfo /tuner<n>/status /tuner<n>/target <ip>:<port> According to the manufacturer's site, the latest models support a lot more stuff, including... /sys/ipaddr dhcp|"<ip> <mask> <gw> <dns>" ... which allows to get/set ipaddress, or work as a dhcp client.
As mentioned, the setup you were running violates the IPv4 link local RFC, so I doubt iproute2 will ever support it.
Interesting. I'll keep going with over-riding the iproute2 default and force ifconfig, as the network-utility stack. By the time ifconfig support is deprecated in Gentoo, I'll probably be looking at getting a new tuner, rather than another NIC. Thanks for the info anyways. Now I can stop pounding my head against the brick wall. -- Walter Dnes <waltdnes@waltdnes.org>
On 02/28/2015 09:46 PM, Walter Dnes wrote:
Interesting. I'll keep going with over-riding the iproute2 default and force ifconfig, as the network-utility stack. By the time ifconfig support is deprecated in Gentoo, I'll probably be looking at getting a new tuner, rather than another NIC.
Thanks for the info anyways. Now I can stop pounding my head against the brick wall.
-
Why not go with the other option I mentioned, add another NIC. They're cheap and you can do what you want without violating the RFC. All you'll need to connect the tuner is a cross over Ethernet cable. All new hardware might set you back $10-$15
On Sat, Feb 28, 2015 at 09:51:12PM -0500, James Knott wrote
Why not go with the other option I mentioned, add another NIC. They're cheap and you can do what you want without violating the RFC. All you'll need to connect the tuner is a cross over Ethernet cable. All new hardware might set you back $10-$15
Even easier is to include the line... modules=( "!iproute2" ) ...in my /etc/conf.d/net (probably Gentoo specific) and it keeps working using ifconfig. I got the tuner sometime around May 2010. When ifconfig support is totally deprecated, it'll probably be time for a new tuner anyways. -- Walter Dnes <waltdnes@waltdnes.org>
On 02/28/2015 10:30 PM, Walter Dnes wrote:
...in my /etc/conf.d/net (probably Gentoo specific) and it keeps working using ifconfig. I got the tuner sometime around May 2010. When ifconfig support is totally deprecated, it'll probably be time for a new tuner anyways.
That's only 5 years old. There is absolutely no reason why it shouldn't support both static config and DHCP other than incompetence.
On Sat, Feb 28, 2015 at 09:46:02PM -0500, Walter Dnes wrote:
On Fri, Feb 27, 2015 at 10:15:13PM -0500, James Knott wrote
Does it not even allow DHCP? If not then that is a really crappy piece of hardware.
No. I have an ancient HDHR-US model. Looking back at my archived emails, I figure that I got it sometime around June 2010. The output
June 2010 is not "ancient". Now I know what to avoid. -- William
| From: Walter Dnes <waltdnes@waltdnes.org> | 1) It's WAD (Working As Designed). I'm doing what the instructions told | me to do. YES!!! There are indications that it will pay attention to DHCP. See, for example, <http://en.wikipedia.org/wiki/HDHomeRun#General_details> last sentence, first paragraph. Of course it could be wrong. You could consider doing a tcpdump to see what the thing does when it is turned on. I don't know what you have as a dhcp server -- it is handy if it can run tcpdump. Still, enough of the protocol is broadcast that you should be able to get a clue whether the HDHR is DHCPing. There are also indications that it doesn't want the stream to be routed; it wants to be communicating only on the network segment <https://help.ubuntu.com/community/HDHomeRun#Requirements> A little bit confusing. | 2) It's an ancient model, that does not allow setting a static IP address 2010 isn't ancient. The iproute2 was added to Linux perhaps 15 years ago. ifconfig has been emulated for a long long time. So anything you can do with ifconfig out to be possible with the ip command.
From ip(8): HISTORY ip was written by Alexey N. Kuznetsov and added in Linux 2.2.
| 3) The setup works fine under ifconfig; but not under ip (iproute2). | Gentoo recently changed to iproute2 as the default networking suite. | I have to over-ride the default to get it working again. I don't know what that means. I haven't looked. But I'm pretty sure that the kernel stuff hasn't changed recently. | 4) A change of the default is usually a precursor to eventually getting | rid of support for the old default alltogether. I want to get it | working under ip (iproute2) before Gentoo dumps support for ifconfig. As far as I know, "real" ifconfig is long gone. The documentation of the ip command is so terrible that I still use ifconfig.
On Sun, Mar 01, 2015 at 01:49:50AM -0500, D. Hugh Redelmeier wrote
| From: Walter Dnes <waltdnes@waltdnes.org>
| 1) It's WAD (Working As Designed). I'm doing what the instructions told | me to do. YES!!!
There are indications that it will pay attention to DHCP. See, for example, <http://en.wikipedia.org/wiki/HDHomeRun#General_details> last sentence, first paragraph. Of course it could be wrong.
This particular model does not... period... end of story. I've already posted the results of "get help" for this device. My model does ***NOT*** show... /sys/ipaddr dhcp|"<ip> <mask> <gw> <dns>" ...as one of the supported commands. Later models do. I've done the latest firmware upgrade, just in case.
| 2) It's an ancient model, that does not allow setting a static IP address
2010 isn't ancient.
See https://www.youtube.com/watch?v=JXmi-6nVhCM which is the exact same model I have. I bought mine in 2010, but the reviewer notes that it won some award at CES2008. Consider it a 2008, possibly 2007, model.
| 3) The setup works fine under ifconfig; but not under ip (iproute2). | Gentoo recently changed to iproute2 as the default networking suite. | I have to over-ride the default to get it working again.
I don't know what that means. I haven't looked. But I'm pretty sure that the kernel stuff hasn't changed recently.
Kernel hasn't changed, but the Gentoo linux distribution has. This is a Gentoo-specific item.
| 4) A change of the default is usually a precursor to eventually getting | rid of support for the old default alltogether. I want to get it | working under ip (iproute2) before Gentoo dumps support for ifconfig.
As far as I know, "real" ifconfig is long gone.
It waddles like a duck, quacks like a duck, flies like a duck; as far as I'm concerned it is a duck. Some people argue that current Intel X86 isn't really a CISC processor. That it's actually a RISC processor that emulates a CISC processor. That's nitpicking. -- Walter Dnes <waltdnes@waltdnes.org>
This is what I get for TTFM (Trusting The Fine Manual). I did Google and RTFM. Page 6 of the PDF document at the manufacturer's website... http://www.silicondust.com/hdhomerun/hdhomerun_tech.pdf lists the output from a "get help" command ***FOR CURRENT MODELS***. It includes, amongst other items... /sys/ipaddr dhcp|"<ip> <mask> <gw> <dns>" On my machine, "get help" produces... Supported configuration options: /ir/target <protocol>://<ip>:<port> /lineup/location <countrycode>:<postcode> /sys/copyright /sys/debug /sys/features /sys/hwmodel /sys/model /sys/restart <resource> /sys/version /tuner<n>/channel <modulation>:<freq|ch> /tuner<n>/channelmap <channelmap> /tuner<n>/debug /tuner<n>/filter "0x<nnnn>-0x<nnnn> [...]" /tuner<n>/lockkey /tuner<n>/program <program number> /tuner<n>/streaminfo /tuner<n>/status /tuner<n>/target <ip>:<port> There is no mention of "/sys/ipaddr" ***ON MY MACHINE***. I also remember various people asking on the HDHomerun support forum years ago about IP addresses, and hearing that this model did not have any other addressing options. One correction on the date of my machine. See https://www.youtube.com/watch?v=JXmi-6nVhCM which discusses the exact same model I have. I bought mine in 2010, but the reviewer notes that it won some award at CES2008. Consider it a 2008 model. Due to the documentation, and lack of mention of DHCP in "get help", I assumed it wouldn't work. However, just for ####s and giggles, I enabled the DHCP server on my router, set the DHCP address pool to 192.168.123.241-to-192.168.123.247, and expanded my local LAN subnet from a /29 to a /28 like so... config_eth0=" 192.168.123.251/28 broadcast 192.168.123.255" routes_eth0=" default via 192.168.123.254 metric 20 192.168.123.240/28 via 192.168.123.254 metric 0" Notice the lack of a 'modules=( "!iproute2" )' line. I installed the latest firmware update from the manufacturer's website... (hdhomerun_atsc_firmware_20141124.bin). Lo and behold, it actually works, coming up at 192.168.123.241. This is notwithstanding the documentation and "get help" output, which both say nothing about DHCP. Maybe this was a feature that was backported into a firmware update. Anyhow, I apologize for wasting peoples' time. -- Walter Dnes <waltdnes@waltdnes.org>
| From: Walter Dnes <waltdnes@waltdnes.org> | Anyhow, I apologize for wasting peoples' time. No problem: it was educational for us. And only you had to suffer :-) That's why I post war stories to this list.
On Mon, Mar 02, 2015 at 01:58:17AM -0500, Walter Dnes wrote:
This is what I get for TTFM (Trusting The Fine Manual). I did Google and RTFM. Page 6 of the PDF document at the manufacturer's website... http://www.silicondust.com/hdhomerun/hdhomerun_tech.pdf lists the output from a "get help" command ***FOR CURRENT MODELS***. It includes, amongst other items...
/sys/ipaddr dhcp|"<ip> <mask> <gw> <dns>"
On my machine, "get help" produces...
Supported configuration options: /ir/target <protocol>://<ip>:<port> /lineup/location <countrycode>:<postcode> /sys/copyright /sys/debug /sys/features /sys/hwmodel /sys/model /sys/restart <resource> /sys/version /tuner<n>/channel <modulation>:<freq|ch> /tuner<n>/channelmap <channelmap> /tuner<n>/debug /tuner<n>/filter "0x<nnnn>-0x<nnnn> [...]" /tuner<n>/lockkey /tuner<n>/program <program number> /tuner<n>/streaminfo /tuner<n>/status /tuner<n>/target <ip>:<port>
There is no mention of "/sys/ipaddr" ***ON MY MACHINE***. I also remember various people asking on the HDHomerun support forum years ago about IP addresses, and hearing that this model did not have any other addressing options. One correction on the date of my machine. See https://www.youtube.com/watch?v=JXmi-6nVhCM which discusses the exact same model I have. I bought mine in 2010, but the reviewer notes that it won some award at CES2008. Consider it a 2008 model.
Due to the documentation, and lack of mention of DHCP in "get help", I assumed it wouldn't work. However, just for ####s and giggles, I enabled the DHCP server on my router, set the DHCP address pool to 192.168.123.241-to-192.168.123.247, and expanded my local LAN subnet from a /29 to a /28 like so...
config_eth0=" 192.168.123.251/28 broadcast 192.168.123.255" routes_eth0=" default via 192.168.123.254 metric 20 192.168.123.240/28 via 192.168.123.254 metric 0"
Notice the lack of a 'modules=( "!iproute2" )' line. I installed the latest firmware update from the manufacturer's website... (hdhomerun_atsc_firmware_20141124.bin). Lo and behold, it actually works, coming up at 192.168.123.241. This is notwithstanding the documentation and "get help" output, which both say nothing about DHCP. Maybe this was a feature that was backported into a firmware update. Anyhow, I apologize for wasting peoples' time.
Hey we learned something too. I think the idea always was that it should use dhcp. Newer models started allowing static IP, but they all do dhcp. dhcp is complicated though and sometimes compatibility issues happen. When dhcp does not fail, it is very common to default to a link local address of 169.254.x.x, which is certainly what windows does, and apparently also what the HDHR does. -- Len Sorensen
On Sun, Mar 01, 2015 at 06:27:49AM -0500, Walter Dnes wrote:
It waddles like a duck, quacks like a duck, flies like a duck; as far as I'm concerned it is a duck. Some people argue that current Intel X86 isn't really a CISC processor. That it's actually a RISC processor that emulates a CISC processor. That's nitpicking.
Well the firmware updates claim improved dhcp compatibility with new routers as one of the things they have done. Are you running the latest firwmare on the box? https://www.silicondust.com/support/downloads/firmware-changelog/ Latest firwmare for the HDHR-US appears to be from 20141124: http://download.silicondust.com/hdhomerun/hdhomerun_atsc_firmware_20141124.b... -- Len Sorensen
participants (8)
-
Anthony de Boer -
D. Hugh Redelmeier -
James Knott -
Lennart Sorensen -
Scott Allen -
ted leslie -
Walter Dnes -
William Park