Posts: 24
Joined: Oct 2007
Reputation:
0
OK I have submitted the multicast ARP reply patch to the tracker. This fixes issues with some LAN drives that have a MAC address starting with 01 or 03 (basically indicating that they are multicast MAC addresses). It patches the XNET library dynamically.
JC
Posts: 3,805
Joined: Mar 2004
Reputation:
3
elupus
Team-XBMC Developer
Posts: 3,805
nice work. will add abit later. will require us to switch to xnet instead of xonline right? or works for both (they do share most code so i'd expect so).
i'm just pondering if it might be better to do offline patching, ie patching compile time instead. suppose then you can't turn it off thou.
btw, the XNET_ARP_ORIG is correct right? so we could check that the code matches that too, just for security.
Posts: 24
Joined: Oct 2007
Reputation:
0
This doesn't sort out multicasting UPNP, just ARP replies. It appears that UPNP packets are getting filtered out high up which is what I'm looking at now. I think it's either happening at the hardware level (running a linux multicast test on the xbox should answer this though) or in the BIOS. If anyone has some pointers or examples of BIOSs for educational purposes that would be good.
It will work for both xnet & xonline as it looks for offsets that don't change between them. I originally patched the libraries but that means people cant simply compile it from SVN anymore, and I thought if we make it dynamic, someone could add an option in the network settings to turn it on or off.
The XNET_ARP_ORIG will change depending on if its XNET or XONLINE. This is why I grab a copy of it before patching so it can be restored.
JC