Sorry Ian, bit confused.I've noticed what appears to be rather a shortcoming of the trunking though. And it wasn't obvious until I stumbled on the following comment in the example 'econet-hpbridge.cfg-EconetPlusFileserverAndTrunk' file:On the plus side, authenticated TRUNK works. Yey.And it seems there's no way to TRUNK XLATE your way out of this problem... if you have called your local network '1' and your friend also has theirs as '1' (because that's the default and why would you do anything else?) then they cannot be TRUNK connected. Only when I changed one of the networks to be '2' would it then all spring in to life.Code:
# Support myfriend advertises network 1, and the bridge will automatically# drop that because net 1 is defined as a Wire above.
What's the reason for this? Why can't I have a XLATE for remotes clashing my local network numbers? (I tried, it doesn't work).
I think this could be a problem for the TNMoC LAN party, because it means anyone who happens to have used the same network number as used on the TNMoC LAN wouldn't be able to connect their home network in via TRUNK.
Sooo... what's the network number for the TNMoC LAN going to be, so we can all avoid it? Hopefully not '1', or I suspect 'everyone' is going to have to reconfigure.
For co-operating trunk operators, just put the following on each end:
Code:
TRUNK PORT xxxx XLATE DISTANT NET 1 TO LOCAL NET 100For the LAN Party, you'll be pool natted so your network 1 will never be seen by the wider world. I suspect, but do not know, that the Museum nets will be translated centrally to some relatively high numbers. If not, the same technique as above can be used to translate the announcements inbound to your bridge.
So what's the "shortcoming" the means "everyone is going to have to reconfigure" ?
Chris.
Statistics: Posted by cr12925 — Sat May 11, 2024 7:04 am