Control/Dimming Pathport PWPP Portable DMX Gateway

[Crisp image]

Good dat to you all,
I have a handful of the pathport pwpp portable gate ways that have never been installed and I decided I would use one today. So I have connected it to the switch (pathport via) and then using the front panel buttons, set the universe to my desired setting (2 in this case). Nothing was being sent to the fixtures. So I checked the cable and still nothing.
I looked at the address of the pwpp and also the via switch. The Via was set to 192.168.50.200/24 and the node was set to something else. I changed the node to 192.168.50.167 (subnet mask is 255.0.0.0) and still nothing. So thinking there could be an IP conflict I changed to 192. 172.50.167 or something like that figuring with the subnet mask set the way it is only needs the first octet to be the same and still nothing.
What am I missing? As far as I am aware there has been no security added to the device so I should be able to configure it.
Inwill be back in the venue on Thursday so can have another go at it then.

Geoff

 

[Rob]

Hi Geoff,
Sorry for the trouble. You said no security has been added. If the device running firmware v4 or greater? If so, then you will need to opt out of security or use Pathscape to set up a domain. Please see this article. Other instructions on how to enable the Rx protocols are on page 33 of this manual.
What are the other devices on the network that do work? What is the console? Does sACNView see things fine on your PC?

 

[Crisp image]

Hi Geoff,
Sorry for the trouble. You said no security has been added. If the device running firmware v4 or greater? If so, then you will need to opt out of security or use Pathscape to set up a domain. Please see this article. Other instructions on how to enable the Rx protocols are on page 33 of this manual.
What are the other devices on the network that do work? What is the console? Does sACNView see things fine on your PC?

Thanks Rob for your reply. I knew you would be here somewhere. How do I know what firmware I am running without connecting to a computer? I also don't have scan view on a computer so proberly should get it. My LX network consists of the Via switch, 3 quatro nodes and 5 of these PWPP nodes. The quatros say security disabled by user so maybe that is the key here. Console is ETC ION Classic (ver 3.2.?).I will look at the documents you linked to and report back after my day tomorrow.
Regards
Geoff

 

[Rob]

How do I know what firmware I am running without connecting to a computer?

If you scroll to the port the Pathport is connected to, click and roll down to "NETWORK PARTNER (LLDP)", click then scroll, you'll see the Label, IP, MAC, and f/w version it's running.

 

[Jay Ashworth]

Wrong subnet. .0.0.0 is a /8. 192.168.x.y is usually a /24: 255.255.255.0.

Doesn't matter so much what the subnet is on isolated networks, but every node has to have the same one, or weird stuff will happen.

 

[Rob]

sACN will get to the gateways regardless of the subnet mask. By default (without IGMP) sACN is broadcast. Everybody will see it.

 

[Jay Ashworth]

sACN will get to the gateways regardless of the subnet mask. By default (without IGMP) sACN is broadcast. Everybody will see it.

Well, multicast. Though a number of the sources I got hits for on that search suggested that unicast was gaining popularity. Our Ion, on reflection, is probably multicasting, since I don't remember having to tell it the IPs of our nodes...

 

[Rob]

WARNING: Serious geek talk follows:
Jay. I actually didn’t misspeak when I said Broadcast. The Broadcast bit is set when addressing sACN addresses 239.255.x.y. It’s up to switches to determine if Group Management is employed. Without IGMP, sACN _IS_ Broadcast. Quoting this article:

IPv4 multicast packets are delivered using the Ethernet MAC address range 01:00:5E:00:00:00 through 01:00:5E:7F:FF:FF This range has 23 bits of available address space. The first octet (01) includes the broadcast/multicast bit. The lower 23 bits of the 28-bit multicast IP address are mapped into the 23 bits of available Ethernet address space. This means that there is ambiguity in delivering packets. If two hosts on the same subnet each subscribe to a different multicast group whose address differs only in the first 5 bits, Ethernet packets for both multicast groups will be delivered to both hosts, requiring the network software in the hosts to discard the unrequired packets.

There are switches that listen to IGMP traffic and maintain a state table of which network systems are subscribed to a given multicast group. This table is then used to forward traffic destined to a given group only to a limited set of hosts (ports). This process of listening to the IGMP traffic is called IGMP snooping.

 

[Jay Ashworth]

That's definitely more weedy than the sources I was looking at.

But that's only the *last* /16 of the Multicast range, which starts at 224.0/16; is it only that one /16 which behaves this way?

It's still not *actual* broadcast, though, which on ethernet...

"Broadcast is possible also on the underlying data link layer in Ethernet networks. Frames are addressed to reach every computer on a given LAN segment if they are addressed to MAC address FF:FF:FF:FF:FF:FF. Ethernet frames that contain IP broadcast packages are usually sent to this address."

Multicast is handled at the IP driver level, with the Ethernet PHY in promiscuous mode, if I'm not mistaken.

This article seems pretty clear that's a multicast flag bit, and ETH broadcast is only the all-ones address:

https://en.wikipedia.org/wiki/MAC_address#Unicast_vs._multicast_(I/G_bit)

[ This argument brought to you by Asperger Syndrome. Ask your doctor if Aspergers is right for you! ]

 

[Rob]

Oh - you want weedy Jay ? lol
Thanx to one of me engineers, Maurits, I've been further educated reading this. Referring to 2.1.1. Special First Octet Bits, this chart show the 'bit' (sic) we're talking about, which is '1' for all sACN addresses (in fact, for all multicast traffic in general).

M bit - This bit is frequently referred to as the group or multicast bit. If it is zero, the MAC address is unicast. If it is a one, the address is groupcast (multicast or broadcast).

I guess the M bit is better called the 'groupcast' bit. As we both said, it depends on your Layer 2 switch whether it ends up being multicast or broadcast.

BTW @Crisp image - this has nothing to do with your sACN problems. Have you been sorted?

 

[Crisp image]

Hi @Rob,
I have had success getting the node working. What I did was from the 3 buttons on the front I disabled the security and "accepted the risk". I also changed the IP address to 192.168.XXX.XXX and the subnet to 255.255.0.0. The screen then said "live output" and so I am happy. I tested the system and found it all to be perfect.
Thanks for the documentation and help with this product. I have another 4 units to set up now so they are plug and play for the others in our house.
In this case it has allowed me to move some intelligent lights to a different bar and send a 2nd universe to the bar so I didn't have to readdress them and it just works. Then on Monday I will be putting them back where they belong and remove the node again.
I must say I love the flexibility using nodes gives us in the theatre. Another venue I am at has them everywhere and it makes life so easy.
I will leave you and Jay to discuss the finer points of networking without me.

Regards
Geoff

 

[RonaldBeal]

In the weeds--> Broadcast v Multicast:

1. L2 switches switch solely based on ethernet MAC addresses. (as a generalization)
2. Multicast IP addresses have a predetermined MAC address which is used as a destination only.
3. L2 switches "learn" which physical ports correspond to MAC addresses by looking at the source address on each ethernet frame and put that into the switches MAC table
4. That means that multicast traffic should never have a multicast range MAC address as a source, and thus switches never add multicast addresses to their MAC table.
5. Default behavior for switches is that BUM traffic (Broadcast, Unknown destination, and Multicast) is flooded to all ports except to the one it is received on.
6. Ergo a "dumb" switch, or a switch without multicast features, since it does not know the source port for multicast MAC addresses, treats multicast traffic identically to broadcast traffic.
7. Those "dumb" switches do not even look at the "M" bit.. they don't need to.

8. If IGMP snooping is enabled, the switch looks for traffic on 224.0.0.2 (IGMPv2) and/or 224.0.0.22(IGMPv3), Which are both "multicast addresses"
9. the switches "snoop" on this traffic by listening, but also passing on that traffic unaltered
10. IGMP messages typically are endpoints/hosts subscribing to or unsubscribing to multicast streams.
11. Those switches will add the subscribing port to it's own multicast table, and filter multicast traffic so it only goes subscribing ports
12. some switches still flood some specific multicast traffic to all ports for reliability reasons (IGMP addresses, PTPv1 & V2 addresses, etc...)
13. that still works, because the endpoints/hosts have a socket open on their NIC's with the desired multicast IP address as a class D network (255.255.255.255) so they will "see" the desired multicast traffic. Makes it easy to communicate between devices without knowing any other information.

14. IGMP Queriers synchronize subscriptions among switches.

Understanding these "rules" helps in troubleshooting Multicast/igmp issues. (It can get a bit deeper, but is a good start)

 

[RonaldBeal]

Multicast is handled at the IP driver level, with the Ethernet PHY in promiscuous mode, if I'm not mistaken.

At the endpoints it is, (sort of) ...
On an ethernet network, All IP packets get "wrapped" in an Ethernet frame.
Part of the NIC software stack uses ARP (Address resolution protocol) to match local IP addresses to local MAC addresses.
When the endpoint wants to send to IP Multicast, that part of the software stack "knows" that there is a pre assigned MAC address, and looks it up without sending an ARP request over the network. (Point of minor trivia, Every multicast MAC address corresponds to 32 different IP addresses.)
Also, the endpoints create a socket looking at that address as a class D network for receivers.

On the network side, it is handled almost exclusively by MAC address. (faster and cheaper vs processing IP information, also works well with TCAM memory for faster response.) Most snoopers look at the IGMP subscribe request and simply add that corresponding MAC address to a multicast filter table, with a bitmap of ports that have subscribed. The snoopers do look at IP information, but for speed, most filtering is based on mac addresses. (varies by mfg)

 

[TimMc]

At the endpoints it is, (sort of) ...
On an ethernet network, All IP packets get "wrapped" in an Ethernet frame.
Part of the NIC software stack uses ARP (Address resolution protocol) to match local IP addresses to local MAC addresses.
When the endpoint wants to send to IP Multicast, that part of the software stack "knows" that there is a pre assigned MAC address, and looks it up without sending an ARP request over the network. (Point of minor trivia, Every multicast MAC address corresponds to 32 different IP addresses.)
Also, the endpoints create a socket looking at that address as a class D network for receivers.

On the network side, it is handled almost exclusively by MAC address. (faster and cheaper vs processing IP information, also works well with TCAM memory for faster response.) Most snoopers look at the IGMP subscribe request and simply add that corresponding MAC address to a multicast filter table, with a bitmap of ports that have subscribed. The snoopers do look at IP information, but for speed, most filtering is based on mac addresses. (varies by mfg)

Friends, let Brother Ron preach it!

That's well put, Ron, you just cleared 5 years of my muddled, presumed understanding. Thank you.