An update for those interested. I've been hoping for a solution to
test IPv6 multicast using only the loopback interface. Unfortunately,
the only working (on Linux) solution I've found is to manually add a
route for the multicast prefix used in the tests.
E.g. ip -6 route add ff01::/16 dev lo
W
> By default, the "multicast" flag is not enabled for the loopback interface
> on Linux. Does running "ip link set dev lo multicast on" help here?
> (Although requiring this would then be rather problematic for testing, as
> doing this in containerized environments and restricted environments like
On Thu, 4 Aug 2016 at 18:04 Jason Litzinger wrote:
> I did try specifying the loopback index, however, I received a
> "Network Unreachable" error. I didn't have time to dig into whether
> it was possible to do what I wanted with the loopback interface last
> night.
>
By default, the "multicast"
> On 4 Aug 2016, at 17:03, Jason Litzinger wrote:
>
>> When you say *no* interfaces, do you mean actually no interfaces? As in, no
>> loopback as well?
>
> I do not, sorry, that was poorly worded. The loopback interface was
> up for all test runs, and all other interfaces on my machine (ether
> When you say *no* interfaces, do you mean actually no interfaces? As in, no
> loopback as well?
I do not, sorry, that was poorly worded. The loopback interface was
up for all test runs, and all other interfaces on my machine (ethernet
and wifi) were down. Down in this context has two meanings
> On 4 Aug 2016, at 04:59, Jason Litzinger wrote:
>
Testing multicast is ... challenging. I barely have any idea how to set
up a test environment for IPv4, and no idea what to do for IPv6. If you
can speak to this in your tests (and hopefully docs as well) that would be
> >> Testing multicast is ... challenging. I barely have any idea how to set
> >> up a test environment for IPv4, and no idea what to do for IPv6. If you
> >> can speak to this in your tests (and hopefully docs as well) that would be
> >> super helpful.
On that note, one effect of actually tes
> > +def _joinAddrIPv6(self, interface, addr, join):
> > +addr = socket.inet_pton(socket.AF_INET6, addr)
> > +interface = socket.inet_pton(socket.AF_INET6, interface)
> > +if join:
> > +cmd = socket.IPV6_JOIN_GROUP
> > +else:
> > +cmd = so
> Nothing specific, although any conclusions drawn on the mailing list, or any
> specific thoughts you have about how you're going to proceed, are always
> helpful to record on the ticket for future reference. Even if you think
> you're going to get it done in the next couple of days, chances a
> On Jul 26, 2016, at 11:00 PM, Jason Litzinger wrote:
>
>>
>> Thanks for taking this up!
> No problem, do I need to reflect anything in the Ticket to indicate I'm
> looking at it?
Nothing specific, although any conclusions drawn on the mailing list, or any
specific thoughts you have about ho
>
> Thanks for taking this up!
No problem, do I need to reflect anything in the Ticket to indicate I'm
looking at it?
>
> 'twisted.internet.udp', as an importable module; not 'udp' as a feature of
> Twisted (or of the Internet, for that matter).
My question was poorly phrased, I assumed that i
> On Jul 25, 2016, at 9:43 PM, Jason Litzinger wrote:
>
>
> Hello,
>
> I'm looking at making the changes to support IPv6 multicast groups as
> described
> in ticket 6597 but wanted to get some feedback (and get a feel whether this is
> even desirable) before formally submitting any patches.
12 matches
Mail list logo
