So, you're suffering from the pretty-much-universal newbie confusion between "tagged" and "untagged" traffic. We've all been there.
The term "tagged", as applied to switch ports, means "packets that go out this port for this VLAN will have a 802.1q header saying "this is a packet for VLAN
<foo>", and "I will accept packets coming into this port that have an 802.1q header saying "this is a packet for VLAN
<foo>". That's great, because it's the only way you can have multiple switches all "know" that packets are on the same VLAN. It's not so great, however, when you're sending packets to a device that isn't expecting it. This most commonly happens when you're plugging in a general-purpose computer, but it can also cause problems when a switch connected to that port doesn't expect the tagged traffic.
An "untagged" VLAN, on the other hand, means "packets that go out this port for this (untagged) VLAN will not have an 802.1q header, and they will look like VLANs never happened", and "packets that come in on this port will be carried on VLAN
<untagged>". In effect, this looks identical to the "dumb (VLAN-free) switch" configuration, and is typically what edge devices expect.
The question you've got to ask yourself, when thinking VLANs, is "do both devices at each end of this piece of cable know that they'll be told this traffic is part of this VLAN?". If "yes", you tag it. If not, you don't.
In your case, I'm almost certain the device you've got plugged into port 42 is not expecting VLAN-tagged traffic, and thus it's discarding those packets with a quiet "WTF?" and a raised eyebrow. You can either untag that VLAN on that port, or tell the device that it should be looking at that traffic with a VLAN perspective. End-devices can usually do that, by the way; we use it to tag VLANs all the way into our VPS servers, for instance (and tags VLANs onto Linux-based routers, firewalls, load-balancers, and some end-customer devices).