Post by: P79 on January 22, 2004, 10:32:00 AM
How´s it going?
Xlink for OSX to the people!
Post by: A@ron on April 01, 2004, 04:10:00 PM
A@ron
Post by: nathanstrach on April 03, 2004, 04:19:00 PM
| QUOTE (neonman @ Sep 15 2003, 02:59 PM) |
| If you guys are looking for testers on OSX, sign me up. Ive been waiting for a bout a year and a half for a good OSX client, and to play online would be awesome. |
likewise - OS X tester right here, ready and waiting.
Post by: sanone on September 01, 2003, 04:30:00 AM
Post by: jhurliman on September 01, 2003, 12:33:00 PM
It's coming... The core devs appear to be really busy right now though, and I'm going to be busy during the weekdays, but I hope things will start moving quickly.
Post by: sanone on September 01, 2003, 11:21:00 PM
That would make things easier because my server doesn't run X11
The frontend doesn't have to be availible for the commandline version because we can enter rooms/set status from the xbox client. Just a simple tunneling deamon would do.. If you need some help porting it to FreeBSD I'd be glad to help out.
Post by: jhurliman on September 03, 2003, 01:17:00 PM
DEVELOPERS: I need either detailed docs of the protocol, or (preferably) some source code sent my way if this thing is going to happen any time soon. I haven't played in Visual Basic for a while, but I'll get it installed and send a couple bugfixes back your way.
Post by: T u r b o on September 03, 2003, 03:14:00 PM
Does anybody have some code or protocol documentation? This sounds like just a couple hours of coding work w/ a protocol spec to go from, and I'd like to get it going if possible.
I'm also interested in getting a "micro" version going for linux, so you could even run the daemon on the TiVo in your living room or similar, which would help out with at least one friend of mine who has a tivo+xbox in one room wirelessly connected to the rest of his house.
- Turbo
Post by: jhurliman on September 04, 2003, 12:10:00 AM
| QUOTE (T u r b o @ Sep 4 2003, 12:14 AM) |
| I'd really like to get this moving. Since it's simply using libpcap, an almost universal back-end could be created for linux/freebsd/mac OSX. This back end could communicate with an X11/curses/cocoa/whatever client for the UI (though, since there's the xbox client itself the UI would be a pretty low priority methinks). Does anybody have some code or protocol documentation? This sounds like just a couple hours of coding work w/ a protocol spec to go from, and I'd like to get it going if possible. I'm also interested in getting a "micro" version going for linux, so you could even run the daemon on the TiVo in your living room or similar, which would help out with at least one friend of mine who has a tivo+xbox in one room wirelessly connected to the rest of his house. - Turbo |
In my roadmap I've designated two distinct projects. One is xlink, a reimplementation of xlink.exe, which will have all the functionality of the Windows client (plus a bit more of course
), then there's xlinkd, a server with no interface whatsoever, that interacts with Bo-XLink only. I've posted a thread called "Devs: Technical Questions" which we should use for protocol discussion, I posted the login sequence for the messenger client already. There's no official documentation on the tunneling aspect which is the real purpose of the app, but it would be much appreciated if someone could post it. I've got the code for xlink layed out how I want it finally, and while it doesn't do much at this point I'm going to start using CVS or nightly tarballs to get the information out there and people moving.
Post by: Lebowski on September 04, 2003, 01:24:00 AM
Quick q, would it be possible to be have some of server running on a high bandwidth connection (100mbit) that has no xbox connected to it but could serve the data to a lot of dsl users?
Post by: jhurliman on September 04, 2003, 10:34:00 AM
| QUOTE (Lebowski @ Sep 4 2003, 10:24 AM) |
| xlinkd sounds good, also run a linux gateway with no X windows. Quick q, would it be possible to be have some of server running on a high bandwidth connection (100mbit) that has no xbox connected to it but could serve the data to a lot of dsl users? |
Serve what data? If there's no XBox connected to it, I'm not sure I understand what you would do...
Post by: flat235 on September 04, 2003, 03:34:00 PM
Couple of requests thou - before u start - your xlinkd.... i think this could also be ported easily into an NT service when complete - that would be very nice...
Also, we get a lot of requests from OSX people - ive never used it - but its similar to linux i believe - are any of the linux GUI contruction tools able to create code which runs on OSX?
TD
ps. im constantly updating the server - and the next bo-xlink will have different comms messages - its all a bit messy at the moment... but the changes will be easy for you to make - even if u start implementing what we have now..
This post has been edited by flat235: Sep 4 2003, 10:35 PM
Post by: jhurliman on September 05, 2003, 01:05:00 AM
http://sf.net/projects/xboxlink/
I didn't want to create a new project name and add even MORE confusion, with XLink Messenger, Bo-XLink, and all the X-names floating around already. Hope this doesn't cause confusion between the GPL XLink and the official project. I just needed the CVS server so other developers and some of my friends can see what I'm up to and submit patches.
EDIT: You're going to need QT 3.2.1 (very latest version) to compile this, as the new designer files seem to not compile with the older uic versions. When the project is ready for a release I'll have OSX and Win32 guys compile binaries and pre-generate all the source files for Linux/BSD guys. That's probably a little ways down the road though, XLink is an awesome project and will be a worthy task to recreate.
This post has been edited by jhurliman: Sep 5 2003, 08:08 AM
Post by: sanone on September 05, 2003, 05:55:00 AM
| QUOTE (jhurliman @ Sep 5 2003, 10:59 AM) |
| My machines run Linux, but I don't code for a specific platform. First and foremost priority is seeing that every project I create compiles on ALL platforms that I'm aware of. As the code stands right now, it will compile and run exactly the same on Linux / BSD / OSX / Win32, and my goal is to not change this. If anyone wants to confirm or deny, checkout the CVS and tell me how it works: http://sf.net/projects/xboxlink/ |
I checked you projectpage but didn't see anything on the CVS Repository not could I browse CVS.
- CVS Repository ( 0 commits, 0 adds )
You said the the code you have so far can be compiled and run on any platform.. how do you do this with the sockets, as far as I know BSD has another socket implementation as linux.
Anyway good to see some people already started this deamon/service. When I found some I'll check the source out (when it's online) and try to compile/run it on BSD.
Post by: T u r b o on September 05, 2003, 08:55:00 AM
| QUOTE (flat235 @ Sep 5 2003, 01:28 AM) |
| I like this project - Ill do whatever i can to help you... the xlinkd idea is excellent Couple of requests thou - before u start - your xlinkd.... i think this could also be ported easily into an NT service when complete - that would be very nice... Also, we get a lot of requests from OSX people - ive never used it - but its similar to linux i believe - are any of the linux GUI contruction tools able to create code which runs on OSX? TD ps. im constantly updating the server - and the next bo-xlink will have different comms messages - its all a bit messy at the moment... but the changes will be easy for you to make - even if u start implementing what we have now.. |
No, but it is a simple task to create a Cocoa front-end in Project Builder to build a native OSX gui for whatever daemon/back-end is available.
Where can we find the "what we have now", though?
- Mike
Post by: jhurliman on September 06, 2003, 10:17:00 PM
QSocket controls compile just fine on OSX. And designer 3.2.1 is really the best GUI designer I've found hands down, regardless of the fact it has libraries on all major platforms. The only trick is going to be getting libpcap and wincap in one project. *Hint look at Ethereal*
I'm looking forward to the 2.6 server protocol, maybe that would be a good starting point for collaboration?
This post has been edited by jhurliman: Sep 8 2003, 01:51 AM
Post by: dfunked on September 07, 2003, 12:45:00 AM
http://games.mess.be/
I've already told TD that my leaked MSN6.1 BETA has 'Start XLink Messenger' in the actions section and I have no idea how
It'd be awesome to somehow get XLINK integrated, if only to have it automatically load when an invitation is sent from MSN
Post by: jhurliman on September 07, 2003, 07:52:00 PM
| QUOTE (sanone @ Sep 1 2003, 02:24 PM) |
| I was wondering if the source of the XLink client will be made open source so people (like me) can port this great piece of software to other platforms. It would be nice if you can run a deamon on your server so you haven't got to start up windows every time you want to play online... |
The developers seemed to be dancing around the issue of making the source code available to porting developers, but the final answer it seems is no. The source code will not be released, but all the information needed to write a replacement is out there so the source code would be of little assistance at this point.
If you are a GPL-friendly developer and ready to prove that OSS coders do it better, do a CVS checkout and get involved. http://www.sourcefor...jects/xboxlink/
Post by: flat235 on September 08, 2003, 08:55:00 AM
As soon as I have the information you need, you will have it... until that time, I have recommended a series of objectives which you could try to meet in your code - mainly around lipbcap - which will allow you to just drop the protocol code in when its ready..
Cheers
TD
Post by: jhurliman on September 08, 2003, 02:13:00 PM
Everything related to reverse engineering the XBox system link protocol OR the xboxlink protocol(s) can be posted there.
Side note: One problem I have with the sourceforge CVS server is the 24 hour lag between :ext: and :pserver: access. Meaning if one of our developers commits something, and I post here and say "functionality X is now implemented!", it might not be available for anonymous or webcvs access for another day. I can live with it for now though, unless I find myself with an excess of spare time and setup CVS/Web/etc locally here.
If you are checking out the code and want to help out, the best thing at this point would be getting it to compile on as many platforms as possible. We need to start with a solid base before getting to the end of the road and realizing compatibility is broken under several different OSes. That means getting it to compile under win32 (we were having some linking problems associated with not setting up MSVC correctly), #ifdefing the pcapture.h/pcapture.cpp files to use winpcap when appropriate, testing the pcap filters under different versions of BSD, OSX and other OSes, and making sure the UI looks fine in OSX and other platforms that handle UI a bit more radically.
Post by: GaMMa on September 11, 2003, 04:35:00 PM
Post by: jhurliman on September 11, 2003, 08:23:00 PM
------
Initializing packet capture interface
pcapture.o: Using device eth0
*UDP PACKET*
Source MAC: 00:50:F2:35:41:A1
Destination MAC: FF:FF:FF:FF:FF:FF
Source Port: 3074
Destination Port: 3074
Payload: ffffffffffffff4d59832cb8d319da185df77dbbcda491e5f1d69a707f6e24d8ce649c4a1b748ddbd4519e3c4861251b9f4847cb2fb214b320d1410
*UDP PACKET*
Source MAC: 00:50:F2:35:41:A1
Destination MAC: FF:FF:FF:FF:FF:FF
Source Port: 3074
Destination Port: 3074
Payload: ffffffffffffffc260f98bd3127f2237303116399b8097b0f950acaccd33183623dbf52d5d97d7dc7a4a52e7135ea21baa8dd97ed3607e137cf60
*UDP PACKET*
Source MAC: 00:50:F2:35:41:A1
Destination MAC: FF:FF:FF:FF:FF:FF
Source Port: 3074
Destination Port: 3074
Payload: ffffffffffffffdc227e3c611e215b8336afe080e5172f43b26e851c45073fd8b6ceeb932bcc2521aadd9cdf71f16642c37273836bf67c437de00
------
I don't suppose anyone has analyzed the game packet payloads themselves? The tunnelling program is just shipping them across the wire so it doesn't need to know the contents, but it would be interesting.
Post by: T u r b o on September 11, 2003, 11:22:00 PM
My main focus right now is getting something going for OSX. This has one major barrier that I'm trying to dive into, the ability to spoof the source MAC address in a raw ethernet frame on a stock kernel.
See http://slagheap.net/etherspoof/ for more info.
Apparently it IS possible though, because Virtual PC is able to do it, and xlink in fact works very well under VPC (and makes it much easier to debug/trace on a switched network).
I'm looking into how VPC is doing it now, and I have some test code to do some of what flat235 outlined in another thread that does work.
I'll try to check out cvs@medialinux again tomorrow, anonymous login wasn't enabled when I tried today.
- Mike
Post by: flat235 on September 11, 2003, 11:30:00 PM
... But as u say, it can simply be shipped over the net, although certain parts of it can be synthesised by the target machine etc....
TD
Post by: jhurliman on September 12, 2003, 11:05:00 AM
| QUOTE (T u r b o @ Sep 12 2003, 08:22 AM) |
| A couple things... My main focus right now is getting something going for OSX. This has one major barrier that I'm trying to dive into, the ability to spoof the source MAC address in a raw ethernet frame on a stock kernel. See http://slagheap.net/etherspoof/ for more info. Apparently it IS possible though, because Virtual PC is able to do it, and xlink in fact works very well under VPC (and makes it much easier to debug/trace on a switched network). I'm looking into how VPC is doing it now, and I have some test code to do some of what flat235 outlined in another thread that does work. I'll try to check out cvs@medialinux again tomorrow, anonymous login wasn't enabled when I tried today. - Mike |
Libnet.
http://www.packetfac...rojects/Libnet/
Basically we set a pcap callback in the packet capturing code, analyze what to do with it and if necessary call a function in the packet creation code that builds packets from the ground up. Sets the source / destination MAC, source / destination IP, source / destination ports, appends the payload, checksums each frame and sends the packet. Cache grinding has shown that this is done pretty quick; if need be we can rewrite the packet construction in assembly but it doesn't seem necessary. We're trying to avoid LibnetNT since it's based on the 1.0.x API which is completely different than 1.1.x, and the new Libnet (coming out any day now) has full Win32 support. If anyone has luck compiling the current latest release on Windows though, it would be helpful information.
Post by: T u r b o on September 12, 2003, 03:49:00 PM
In the mean time I'm thinking an abstraction layer to isolate the packet injection code from the underlying platform (special kext on OSX, libnet on linux/bsd, ??? on windoze?)
Is that cvs stuff up today?
- Mike
Post by: jhurliman on September 12, 2003, 04:17:00 PM
| CODE |
| :pserver:[email protected]:/home/cvsroot |
Do you have any references to libnet not working on MacOSX? I've read several posts mentioning it successfully compiles on OSX, and I would be amazed if everything linked together but nothing worked. One note: on *NIX/BSD based systems, xlinkd needs to run with root permissions since it's sniffing/injecting packets at a very low level.
Post by: T u r b o on September 12, 2003, 11:05:00 PM
I'm not sure about the legality of distributing a modified kernel binary.
See the site at http://slagheap.net/etherspoof/
for any additional info on the MAC address spoofing limitation in OSX (required for xlink).
- Mike
Post by: jhurliman on September 13, 2003, 12:45:00 AM
| QUOTE (T u r b o @ Sep 13 2003, 08:05 AM) |
| For clarification, libnet works on OSX for everything except injecting raw ethernet frames, because of a couple of changes that Apple put into the darwin kernel. It will work with a modified and recompiled kernel, but I'd say that's not an option for most users. I'm not sure about the legality of distributing a modified kernel binary. See the site at http://slagheap.net/etherspoof/ for any additional info on the MAC address spoofing limitation in OSX (required for xlink). - Mike |
Wow I never realized that. The patch to add ethernet frame building looks very simple, I know little to none about the Apple platforms though. If you could write a module to do the spoofing that would be great, but I don't see how you could override the existing code to make it work flawlessly; it would be an interesting port. It might be worthwhile to contact the Aquaduct ( http://www.postpose.com/aquaduct/ ) team and pick their brain. For right now I think we're going to require a patched kernel for OSX support. Without OSX in front of me to hack on I'll have to wait for someone else to get it figured out.
As far as distributing a modified binary it wouldn't be a problem under the BSD license (unless Apple's using a different license?) as long as you provided the source for all the modifications. I'd be wary of handing people a new kernel; imagine the support issues with people mis-installing and thrashing their system.
Post by: jhurliman on September 13, 2003, 02:36:00 PM
Post by: flat235 on September 13, 2003, 02:46:00 PM
Anyway - lets forget all that shit, I hope you can get this thing going - and I will try to help as much as I can, time permitting...
The protocol itself is, as far as i can tell, almost complete, as of revision 27.. although it will be optimised now to reduce server load - which may affect some calls (most notably fold some 2 segment PHP calls into 1 etc.)
I will then create a seperate server instance for your development.... subsituting"27" in all the filenames for "27exp" or something... Then I think we would be safe to start looking at protocol implementations...
TD
Post by: flat235 on September 14, 2003, 03:59:00 PM
Here is it.. in a sort of pseudo-code..
The prepended chr(99) distinguished this xbox data as "Messenger mode" .. as opposed to other modes...
strip(raw as SIMPLEBYTEARRAYTHING)
{
output = Chr(99) + left(raw, 14) + Mid(raw, 17, 4) + Mid(raw, 25, 2) + Mid(raw, 31, 1) + Mid(raw, 39)
return output;
}
synth(RAW AS STRIPPEDBYTEARRAY)
{
output = left(raw, 14) + Chr(69) + Chr(0) + Mid(raw, 15, 4) + Chr(0) + Chr(0) + Chr(64) + Chr(17) + Mid(raw, 19, 2) + Chr(0) + Chr(0) + Chr(0) + Chr(1)
If Mid(raw, 21, 1) = Chr(255) Then
output = output + Chr(255) + Chr(255) + Chr(255) + Chr(255)
Else
output = output + Chr(0) + Chr(0) + Chr(0) + Chr(1)
End If
output = output + Chr(12) + Chr(2) + Chr(12) + Chr(2) + Mid(raw, 22)
return output;
}
This doesnt include any of the fancier stuff - caching etc.. but that comes later anyway..
Cheers
TD
Post by: neonman on September 15, 2003, 05:59:00 AM
Post by: jhurliman on September 17, 2003, 04:37:00 PM
| QUOTE (flat235 @ Sep 15 2003, 12:59 AM) |
| The prepended chr(99) distinguished this xbox data as "Messenger mode" .. as opposed to other modes... |
I need codes for the other modes (chat, wgn) now, thanks.
Post by: flat235 on September 18, 2003, 10:09:00 AM
.. Any chance we can meet up again? I'd love to see how it'd coming on - and I can give you the other details you need then... Rooms mode should be fairly straight forward, but the packet semantics of WGN are absolutely horribly convoluted.. and it can be easy to disrupt the mesh if it doesnt work right Also, im finishing off server 28 - which includes a few new bits you will need to know about.. I'd like to run the changes past you guys first, so if you notice any horrible mistakes / flaws in it, we can get them sorted before 28 goes to production..
I'll be in the IRC room for most of tonight...
TD
Post by: jhurliman on September 18, 2003, 03:44:00 PM
CVS is always frequently updated, and we have cvsweb going too now @ http://xlink.mediali...web.cgi/xlinkd/ for the curious. The code should always compile, but no guarantees you'll get anything other than a segfault until the codebase gets a little less chaotic.
Post by: flat235 on September 18, 2003, 04:14:00 PM
WGN = chr(88)
Just had a brief look over the source.. not fully digested yet, but it look good so far.. One query though.. You seem to be examing ICMP packets which come over the ethernet? The XBox Syslink stack doesnt implement ICMP - or ARP for that matter.. ARP is useless because all the xboxes in syslink all always have the ip address 0.0.0.1, and ICMP simply isnt used...
All we do, on the PCapture side is:
"Is the incoming frame a.) from a 0050F2 mac b.) A UDP frame c.) On port 3074 d.) From IP 0.0.01"
If so, handle it.. if not, totally discard it...
Yes - homebrew xbox apps work a little differently (ARP must be implemented and IP addressing is "normal" ie not all 0.0.0.1), but I would personally leave that till later - as it's easy to snap in..
Thanks,
TD
Post by: jhurliman on September 18, 2003, 04:32:00 PM
Also, why are two ports (34518 and 34519) used instead of one? Right now we're implementing all the routing on 34518; where does the other port come in to play?
I would just chat all this over IRC but I won't be here tonight and I'm leaving soon. Hopefully tomorrow will be a free day for me.
Post by: jhurliman on September 22, 2003, 06:24:00 PM
| QUOTE (flat235 @ Sep 15 2003, 12:59 AM) |
| output = Chr(99) + left(raw, 14) + Mid(raw, 17, 4) + Mid(raw, 25, 2) + Mid(raw, 31, 1) + Mid(raw, 39) |
Finally got around to implementing this function... what is the purpose of Mid(raw, 31, 1)? The first byte of the destination address in the IP header? Since this will always be 00 or FF my guess is you are using it to distinguish between broadcast and non-broadcast packets, but isn't that done by looking at the destination MAC?
Post by: neonman on September 30, 2003, 05:33:00 AM
Post by: flat235 on September 30, 2003, 02:13:00 PM
TD
Post by: jhurliman on October 01, 2003, 11:54:00 AM
| QUOTE (flat235 @ Sep 30 2003, 11:13 PM) |
| Excellent stuff.. I'll give it a go under MSVC tomorrow at work... Keep it up TD |
I'll get .dsp/.dsw files in CVS, otherwise it can be a huge hassle getting the project file setup correctly. You'll also need to install the QT library to compile: http://www.trolltech...qt/noncomm.html
Post by: jhurliman on October 19, 2003, 01:13:00 AM
http://xlink.mediali...iles/xlinkd.exe
CVS will be updated when I wake up.
Post by: flat235 on October 19, 2003, 03:10:00 AM
I'll try to allocate some time to testing this today, and I'll repin the topic (dont know how it got unpinned)
Cheers
TD
Post by: flat235 on October 19, 2003, 03:18:00 AM
| QUOTE |
| How do you tell if a host isn't up without ICMP? UDP is a connectionless protocol, so you can't just check a socket state to see what's happening. If you know of a better way than looking at ICMP_DEST_UNREACH messages though please let me know, because it's a real pain integrating the ICMP code with the everything else. It's not completely done yet but right now we send out test packets to hosts across the net and add them to our list by default; if any ICMP_DEST_UNREACH messages come back from that host they get dropped. |
Well, to be perfectly honest, the xlink client takes the "totally ignore it" approach.. You see, with the xlink clients, you arent allowed to log in unless the 34518/9 ports are open - it tests them by sending 2 UDP packets from the xserver each time u log in. Hence, if someone shows "online" in xlink, it's guaranteed that any UDP you send will land (well - as close to guaranteed as we need)... Hence, ICMP is completely ignored, and the UDP packets just get piled out to online ppl.. I know, it's not particulary good practice - but we just kept it as simple as possible... no problems seem to have arisen yet with it..
TD
Post by: jhurliman on October 29, 2003, 09:42:00 PM
| QUOTE |
| See? It does work. -- Mike Schiffman, CISSP Doveryay No Proveryay http://www.packetfac.../schiffman.html -----Original Message----- From: Henrik Lund Kramshøj [mailto:[email protected]] Sent: Wednesday, October 29, 2003 7:52 AM To: Mike D.Schiffman Subject: libnet-1.1.1-almostgold-02 works for me on Mac OS X 10.2.8 Hi Mike Thanks for making libnet great This is just to say that I downloaded http://www.packetfac...1.1.1-almostgol d-02.tar.gz It worked GREAT - I seem to remember having some issues with spoofing addresses on Mac OS X I tried only a few samples, icmp6 and synflooding with spoofed addresses seemed to work right out of the box further info: I compiled on Mac OS X 10.2.8 $ uname -a Darwin otto 6.8 Darwin Kernel Version 6.8: Wed Sep 10 15:20:55 PDT 2003; root:xnu/xnu-344.49.obj~2/RELEASE_PPC Power Macintosh powerpc using $ gcc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.1/specs Thread model: posix Apple Computer, Inc. GCC version 1151, based on gcc version 3.1 20020420 (prerelease) The above is Mac OS X 10.2 updated using the builtin software update Best regards -- Henrik Lund Kramshøj, cand.scient, CISSP e-mail: [email protected], tlf: +45 2026 6000 www.security6.net - Sikkerhed, netværk, IPv6 og UNIX <!DSPAM:3f9fe27320861977812888> |
Post by: MrMario64 on December 08, 2003, 03:40:00 AM
I would love to see Xlink on linux as I will be able to use it for gamecube to.
Thanx for the effort thusfar
Post by: Oggy2003 on December 10, 2003, 05:12:00 AM
)keep up the good work...