6:41 p.m.
Sorry to be a bother, but ...
To recap. I have an ethernet port that's wired to a HDTV tuner that converts OTA HDTV
to ma4 and streams it down the cable to a program that collects and stores it. All of this
is known to work under Fedora 17. No so under Fedora 19. FirewallD is stopped.
The ethernet port has a ifcfg script with
HWADDR="E8:40:F2:05:DE:1C"
BOOTPROTO=none
IPADDR="198.168.20.5"
but is otherwise as created by Anaconda.
To test the interface, one asks the tuner to say what connections it has, hdhomerun_config
discover. This is the basic interface. Tracking this with Wireshark, I see:
Frame 1: 62 bytes on wire (496 bits), 62 bytes captured (496 bits) on interface 0
Ethernet II, Src: Pegatron_05:de:1c (e8:40:f2:05:de:1c), Dst: Broadcast
(ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 198.168.20.5 (198.168.20.5), Dst: 198.168.20.255
(198.168.20.255)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not
ECN-Capable Transport))
Total Length: 48
Identification: 0x30b2 (12466)
Flags: 0x02 (Don't Fragment)
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0x53b6 [validation disabled]
Source: 198.168.20.5 (198.168.20.5)
Destination: 198.168.20.255 (198.168.20.255)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 32798 (32798), Dst Port: 65001 (65001)
Source port: 32798 (32798)
Destination port: 65001 (65001)
Length: 28
Checksum: 0xb682 [validation disabled]
Data (20 bytes)
0000 00 02 00 0c 01 04 00 00 00 01 02 04 ff ff ff ff ................
0010 4e 50 7f 35 NP.5
I interpret this as saying that I sent 20 bytes of data via the UDP protocol from
198.168.20.5 to anybody on the 198.168.20 subnet. As I received no response, presumably
that's not what I wanted to do.
Is this significant? I can ping 198.168.20.5 successfully, but Wireshark does not see any
packets.
Thanks.
12:23 a.m.
On Wed, 2014-10-08 at 10:15 -0700, Geoffrey Leach wrote:
Turns out that there's an undocumented feature on the HDTV tuner
software. Said software looks for a connection in a particular range
of addresses. Assigning the ethernet configuration an IP address in
that range solves my problem.
I've seen that sort of thing before, where devices only work within a
limited range of private addresses. You're stuffed if they're not
available to you.
Imagine buying something that can only work on 192.168.1.x, so you go
around reassigning the addresses over everything on your LAN to
accommodate it (a right pain in the neck). Then, a month later, you get
some other device that can only work on 192.168.0.y! It's that sort of
half-arsed equipment design, by those who can't see past the end of
their own nose, that causes no end of trouble to people.
--
tim@localhost ~]$ uname -rsvp
Linux 3.16.3-200.fc20.i686 #1 SMP Wed Sep 17 23:07:44 UTC 2014 i686
All mail to my mailbox is automatically deleted, there is no point trying
to privately email me, I will only read messages posted to the public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
12:15 p.m.
On 10/07/2014 12:31:48 PM, Lars E. Pettersson wrote:
On 10/07/14 17:58, Tim wrote:
> Allegedly, on or about 07 October 2014, Lars E. Pettersson sent:
>> 192.168.10.3 and 198.168.20.5 are on two different networks.
>
> That depends on network configuration (where your netmask is), and
what
> hardware (if any) is between devices.
Yes, but 192.168.10.3 and 198.168.20.5 are actually two entirely
different networks. Geoffrey could of course mixed up the numbers, but
as written, they are two entirely different networks.
But as you later state, if the IP-numbers actually are 198.168.10.3
and
198.168.20.5, or 192.168.10.3 and 192.168.20.5, the solution would be
to
use a /16 netmask (255.255.0.0), as long as they are on the same
physical network.
If there is a router in-between, you have to setup a route via that
router to reach the other network where the other machine is situated.
Lars
Turns out that there's an undocumented feature on the HDTV tuner software. Said
software looks for a connection in a particular range of addresses. Assigning the ethernet
configuration an IP address in that range solves my problem. That is, a one-minute fix.
Thanks to all who assisted me on my journey into the dark caves of configuration :-)
2:31 p.m.
On 10/07/14 17:58, Tim wrote:
Allegedly, on or about 07 October 2014, Lars E. Pettersson sent:
> 192.168.10.3 and 198.168.20.5 are on two different networks.
That depends on network configuration (where your netmask is), and what
hardware (if any) is between devices.
Yes, but 192.168.10.3 and 198.168.20.5 are actually two entirely
different networks. Geoffrey could of course mixed up the numbers, but
as written, they are two entirely different networks.
But as you later state, if the IP-numbers actually are 198.168.10.3 and
198.168.20.5, or 192.168.10.3 and 192.168.20.5, the solution would be to
use a /16 netmask (255.255.0.0), as long as they are on the same
physical network.
If there is a router in-between, you have to setup a route via that
router to reach the other network where the other machine is situated.
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
10:58 a.m.
Allegedly, on or about 07 October 2014, Lars E. Pettersson sent:
192.168.10.3 and 198.168.20.5 are on two different networks.
That depends on network configuration (where your netmask is), and what
hardware (if any) is between devices.
With a netmask of 255.255.255.0 those are two different networks, and
connection attempts across the divide would go through your gateway
(even if they really didn't need to, such as if you had all of your
networked devices on the one ethernet switch).
But, with a netmask of 255.255.0.0, they're all considered to be on the
same network, and will try to connect directly between themselves. If,
however, there's something in between (such as a router), then
connections won't work, unless the router is configured to suit that
netmask, too.
--
[tim@localhost ~]$ uname -rsvp
Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64
All mail to my mailbox is automatically deleted, there is no point
trying to privately email me, I will only read messages posted to the
public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
ZNQR LBH YBBX
10:29 a.m.
On 10/07/14 02:52, Geoffrey Leach wrote:
In the /etc/hosts used by each member of my little network, the
system to which the tuner is attached is 192.168.10.3, and the tuner itself is
198.168.20.5. I can ping 198.168.20.5, but I have a sinking feeling that what I'm
pinging is the ethernet nic, and not the tuner. If that's the case, I've been
wandering around in the dark.
Ah, OK, 192.168.10.3 and 198.168.20.5 are on two different networks. If
198.168.20.5 is your computer, then you have to tell it how to reach the
network that 192.168.10.3 is part of, otherwise it will not work.
I would advice you to setup the IP-numbers so that all units that are
physically connected together (via cable or switch) are on the same
network. So change the IP-number of 192.168.10.3, into 198.168.20.3 (if
that number is not used by any other device), and it should work.
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
7:52 p.m.
On 10/06/2014 01:41:13 PM, Lars E. Pettersson wrote:
On 10/06/14 01:41, Geoffrey Leach wrote:
> To recap. I have an ethernet port that's wired to a HDTV tuner that
converts OTA HDTV to ma4 and streams it down the cable to a program
that collects and stores it. All of this is known to work under Fedora
17. No so under Fedora 19. FirewallD is stopped.
...
> IPADDR="198.168.20.5"
...
> Is this significant? I can ping 198.168.20.5 successfully, but
Wireshark does not see any packets.
Can you ping the HDTV tuner device from your 198.168.20.5 computer?
In the /etc/hosts used by each member of my little network, the system to which the tuner
is attached is 192.168.10.3, and the tuner itself is 198.168.20.5. I can ping
198.168.20.5, but I have a sinking feeling that what I'm pinging is the ethernet nic,
and not the tuner. If that's the case, I've been wandering around in the dark.
3:41 p.m.
On 10/06/14 01:41, Geoffrey Leach wrote:
To recap. I have an ethernet port that's wired to a HDTV tuner
that converts OTA HDTV to ma4 and streams it down the cable to a program that collects and
stores it. All of this is known to work under Fedora 17. No so under Fedora 19. FirewallD
is stopped.
...
IPADDR="198.168.20.5"
...
Is this significant? I can ping 198.168.20.5 successfully, but
Wireshark does not see any packets.
Can you ping the HDTV tuner device from your 198.168.20.5 computer?
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
1:18 p.m.
10/06/2014 10:37 AM, Geoffrey Leach wrote:
On 10/06/2014 06:47:16 AM, Greg Woods wrote:
> On Sun, Oct 5, 2014 at 5:41 PM, Geoffrey Leach <geoff(a)hughes.net>
> wrote:
>
>>
>> The ethernet port has a ifcfg script with
>> HWADDR="E8:40:F2:05:DE:1C"
>> BOOTPROTO=none
>> IPADDR="198.168.20.5"
>> but is otherwise as created by Anaconda.
>>
>
> Don't you need "BOOTPROTO=static"?
>
Apparently "static" is not a defined value for BOOTPRO, and when an undefined
term is used, it defaults to "none". One of the little bits of highly useful
information that I've discovered in my search for a connection :-)
There are only two defined values for BOOTPROTO: bootp and dhcp. Any
other value will result in a static assignment.
12:37 p.m.
On 10/06/2014 06:47:16 AM, Greg Woods wrote:
On Sun, Oct 5, 2014 at 5:41 PM, Geoffrey Leach
<geoff(a)hughes.net>
wrote:
>
> The ethernet port has a ifcfg script with
> HWADDR="E8:40:F2:05:DE:1C"
> BOOTPROTO=none
> IPADDR="198.168.20.5"
> but is otherwise as created by Anaconda.
>
Don't you need "BOOTPROTO=static"?
Apparently "static" is not a defined value for BOOTPRO, and when an
undefined term is used, it defaults to "none". One of the little bits of highly
useful information that I've discovered in my search for a connection :-)
Thanks.
1:08 p.m.
On Mon, Oct 6, 2014 at 11:37 AM, Geoffrey Leach <geoff(a)hughes.net> wrote:
On 10/06/2014 06:47:16 AM, Greg Woods wrote:
> Don't you need "BOOTPROTO=static"?
>
Apparently "static" is not a defined value for BOOTPRO, and when an
undefined term is used, it defaults to "none". One of the little bits of
highly useful information that I've discovered in my search for a
connection :-)
Hmm, I've been using Fedora for years and I never noticed this had changed.
My ifcfg files for statically-defined interfaces do indeed have
BOOTPROTO=none, and they work.
You might need to specify the NETMASK. In my experience, the default isn't
always what you'd expect.
Are you sure that the tuner is really on the net? Those devices normally
get their IP address via DHCP, so you would need to be running a DHCP
server on this subnet in order for it to work.
--Greg
3536
days inactive
3543
days old
11 comments
5 participants
participants (5)
-
Geoffrey Leach -
Greg Woods -
Lars E. Pettersson -
Mike Wright -
Tim