discovered that the IGMP packets all have TTL's of 1. This would mean they would be limited to the one subnet and dropped before getting to the second network?
Absolutely correct, and this is completely intentional. IGMP is defined a host-router protocol, and therefore
by design it is itself unrouteable. In an environment with multiple IP subnets, the device routing between the subnets is the one required to generate IGMP queries and handle IGMP registrations, and that's the end of the story.
See, for instance, the
IGMP version 2 specification, which clearly states that IGMP packets use a TTL of 1; this is not overridden by version 3.
Although some systems do define an IGMP "proxy" concept, packet-level proxying of IGMP (i.e., that decrements the TTL of the IGMP registration) isn't something that works with IGMP as defined by the IETF. The only way a form of IGMP proxying can be implemented is for the device operating as a router on the subnet receiving the origin host's IGMP registration to generate a fresh IGMP registration (which is effectively the same as not decrementing the TTL) and send that.
My question is how can i change this.
Well, that's tricky. It's hard to offer much advice given that we don't know why you're trying to proxy IGMP in the first place.
The normal way multi-subnet, multi-router situations work are for the router serving the subnet with the end hosts to process the IGMP registrations (and perform IGMP querying) and then engage in PIM interchanges with any upstream routers to compute the spanning trees for cross-router distribution of multicastss. Do your routers not support PIM or some other multicast routing protocol?
Now, we can consider adding a setting for this in the TCP stack we use in the DOS clients. But since what you are asking for is in violation of the IGMP specification - and also, something we can't control on any other platform other than DOS since IGMP registrations are generated by the platform TCP stack in Windows - that's not something to do lightly. I think first we need to explore whether there is a way your network can be configured without bending the protocol specifications to fit it.