off network

[Jim Lill]

Has anyone solved how to run ka9q-radio without being connected to the
internet?

73

-Jim

WA2ZKD

[Franco Venturi]

Jim,

what is the specific error message you are seeing there when running ka9q-radio without being connected to the Internet?

73,

Franco K4VZ

[Jim Lill]

No Network Access...   I think it is an avahi issue

--
You received this message because you are subscribed to the Google Groups "ka9q-radio" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ka9q-radio+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ka9q-radio/caa5054b-bca8-4092-97bb-2971b1334b14n%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[st...@ecsykes.com]

Here is the message when the network drops.

Steve KD2OM

[Jim Lill]

Thanks for capturing that Steve.....  

[Phil Karn]

I think it's a Linux kernel issue. The network interface has to be
physically up for multicast to work *even if* the multicasts are all
directed back at the same computer with TTL=0. To test this, just plug
the interface into an Ethernet switch (or another computer) and things
should start working, even if there's nothing else for your computer to
talk to. The bridge pseudo-interface should self-assign an address in
the 169.254.0.0/16 block, which might take a while. But it *should* work.

I've thought of a workaround, but I haven't tried it yet. Linux has a
"bridge" pseudo-interface that, as the name implies, emulates a hardware
Ethernet bridge. Ie., an Ethernet switch; in the early days Ethernet
hubs and bridges were separate functions, but today's switches all
incorporate bridging, which automatically learns which port has which
Ethernet address(es) and sends packets only where they have to go.
Broadcast/multicast packets "flood" to every port other than the one
they come in on, and so do unicast packets before the switch has seen a
packet from a given address.

Linux has a pseudo-hardware device "bridge" that emulates a regular
network interface to the host computer. You attach the physical
interfaces to the bridge pseudo-device and it performs the filtering
functions of an external switch. Most importantly, it always appears
"up" to the host computer even if the hardware devices attached to it
are down. This should solve the common problem of looping back
ka9q-radio multicast traffic within the same machine without an active
physical connection.

I *believe* the bridge module also performs IGMP snooping. If so, this
should make it unnecessary to set TTL=0 in ka9q-radio config files to
suppress unwanted multicast traffic on the physical interface. But it
will still come out if there's at least one external computer that wants it.

IGMP snooping requires something to generate periodic IGMP query packets
that trigger the IGMP membership messages from each host on which the
switches snoop. The original idea was for every LAN to have a distinct
multicast router somewhere generate these queries, but multicast routing
seems stillborn; multicast is almost always used exclusively on a LAN
without routing. So many (but not all) switches can configured to send
IGMP. So can Linux hosts with the right daemon.

Phil