Hi -
I have been cursed with having to deal with a Crestron system for which nobody has the source code. The transporter it controls died recently, and the software in the Crestron controlling it is designed to be configured with a transporter's particular MAC ADDRESS (a horrible idea - but there it is!).
So, there is no way to update the Crestron without finding a huge amount of cash for someone to resign the entire system from scratch, which isn't in the cards, at all. So, I have a Crestron trying to control a Slim unit by its mac address identifier, as opposed to a unit name. (sigh).
However, I am wondering about this:
Is there a way I could have the LMS software essentially "translate" the MAC address, using an algorithm like this. Assume the IP address of the NEW transporter is IP_NEW, and the MAC address of the ORIGINAL transporter is MAC_OLD, and the MAC address of the NEW transporter is MAC_NEW.
a) On packets coming TO the LMS from IP_NEW: Translate all uses of MAC_NEW in the incoming packet stream to MAC_OLD in whatever internal data structures exist.
b) On packets coming FROM the LMS to IP_NEW: Translate all uses of MAC_OLD in the internal datastructure to be sent as MAC_NEW in the outgoing packet stream.
c) On packets going anywhere else, do NO translation. Those devices use MAC_OLD all the time.
Yes, this is a horrible horrible thing to do; I am not doubting that. But we don't have the money to do other things, and we are stuck with this crappy Crestron control software we've inherited, all written by a company that has since gone bankrupt and the sources are nowhere to be found!
Essentially this is configuring an LMS to have a divice with mac address MAC_NEW 'mimic' a device with mac address MAC_OLD. Of course, this is not done at layer 2, but at layer 4, because the logitech slim devices seem to use the mac addresses above layer 2 as unique unit identifiers!!
Again, I hate this idea but if it is something trivial to add - wow - it would help so much.
I have been cursed with having to deal with a Crestron system for which nobody has the source code. The transporter it controls died recently, and the software in the Crestron controlling it is designed to be configured with a transporter's particular MAC ADDRESS (a horrible idea - but there it is!).
So, there is no way to update the Crestron without finding a huge amount of cash for someone to resign the entire system from scratch, which isn't in the cards, at all. So, I have a Crestron trying to control a Slim unit by its mac address identifier, as opposed to a unit name. (sigh).
However, I am wondering about this:
Is there a way I could have the LMS software essentially "translate" the MAC address, using an algorithm like this. Assume the IP address of the NEW transporter is IP_NEW, and the MAC address of the ORIGINAL transporter is MAC_OLD, and the MAC address of the NEW transporter is MAC_NEW.
a) On packets coming TO the LMS from IP_NEW: Translate all uses of MAC_NEW in the incoming packet stream to MAC_OLD in whatever internal data structures exist.
b) On packets coming FROM the LMS to IP_NEW: Translate all uses of MAC_OLD in the internal datastructure to be sent as MAC_NEW in the outgoing packet stream.
c) On packets going anywhere else, do NO translation. Those devices use MAC_OLD all the time.
Yes, this is a horrible horrible thing to do; I am not doubting that. But we don't have the money to do other things, and we are stuck with this crappy Crestron control software we've inherited, all written by a company that has since gone bankrupt and the sources are nowhere to be found!
Essentially this is configuring an LMS to have a divice with mac address MAC_NEW 'mimic' a device with mac address MAC_OLD. Of course, this is not done at layer 2, but at layer 4, because the logitech slim devices seem to use the mac addresses above layer 2 as unique unit identifiers!!
Again, I hate this idea but if it is something trivial to add - wow - it would help so much.