Where is the new Winmx ?

[Pri]

The main effort of our network spoiling attacker is directed at keeping Pri and Josh's site in business,

Nothing will make me happier than the day we can shut the website channel list off. As you know I run a room on the network, I host two but the 2nd room isn't run by me. Both rooms feel the pain caused by a diminished user base due to the Channel List not working and I wish we could do more.

If anyone has a server in a data centre able to spoof the IP on its packet headers and wants to donate that to us so we can setup a super primary to list all the rooms on the channel list then we will be more than happy to do that and get rid of the website.

It seems that the attacker has such a server and I'm sure there are quite a few hosts that may be able to do it but I don't know of any off the top of my head and buying servers to test it would get prohibitively expensive. I tried a few hosts I already have servers with and all of them are protected against it.

[GhostShip]

What the attackers wants is simply to drive folks away from the network, having a room listing facility is most welcome and while I did make the tongue in cheek comment above you will of course also have read my own direct posts thanking both yourself and Josh for making this method of obtaining a room addy available, it is after all a public service your delivering to this community and I am very thankful you have both stepped up to the plate to take a stance against the petty minded attacks.

An alternative to your suggestion however is likely within the grasp of all of us that have the current patch src, If I can jog your memory a tad "mike" operated a cache that tossed a roomlist directly down from the cache and we could if necessary emulate this method to negate all of the fake room listing requests that mar the current system, any "local" roomlist request packets could be intercepted in a new patch release and  directed towards the caches on a specific port to obtain the current list,, to create some form of automation it should be possible to parse out chat server client ID's at the cache stage and share those amongst the other caches thus delivering a fully validated (by handshake) chat server list, all other roomlist requests could be ignored.

The only potential drawback is the loss of those rooms that dont use the community patch/caches, but we could all make efforts to minimise this number or even have the cache operators add in such rooms as we know exist into the caches data pool directly

Just an idea.

[Pri]

Yes I do remember that and I think that is a great solution. I would be more than happy to support that effort. And in-fact I think that is a better solution than spoofing IP's ever would be.

[White Stripes]

isnt beta 2 going to be released sometime late next month? or is the superprimary to help it too?

[GhostShip]

The beta 2 is in that same as ever at this "time position" we have prior to any release, the elves are working hard to finish specific bits and polish up other half implemented items, theres always still so many things to do on our lists but we have made good headway over the year, the trick is to consolidate all of that in the next  3 weeks to reach the next stage.

I think the idea of a super primary goes against the conceptual norm of a decentralised network and it has only been suggested in this time of massive network level attack. I don't see this is a valid way ahead for us and as Pri mentions above for the roomlist we could use an already tried and trusted idea with a small variant to resolve the chat roomlist  issue prior to important protocol changes that will break compatibility, due to the level of attacks no one I have spoken to feels its of worth to try to keep fighting for the network with one hand behind our back, changes are necessary and best rushed forward for beta 3 along with the opennnap engine we have started implementing in it.

I was going to announce a delay some weeks ago with regard to the next release but I was persuaded to wait to a time nearer the date to give things a chance to reach fruit, we have 3 folks working on the project now and thus we may be able to catch up on the list of goals set out for this beta, I will of course keep you all abreast of whats going on in further detail nearer the time but I may not be here to answer all of the questions that may arise in good time, the focus has to be on getting the next beta out on release, I hope you will all agree this is what the priority should be and I apologise in advance in case I am not about for a few days here and there.

[White Stripes]

so b3 has new protocols for chat? oh boy.... is zenar still around to update ZCS? cos i have a feeling KM wont be updating WCS... lol...

[GhostShip]

Zenar is "about"  figuratively speaking and no doubt stands ready to implement any changes that are proposed, he is like all of the community developers, either in full time education or full time work but can always be reached via their email addresses.

The changes wont just affect chat btw we need to look at the widest picture and start the fightback now we have a fairly solid base on which to do so.
B3 will be the start of those changes and I know it will be a step into the dark but it will restore nearly all of the network capability while holding the attackers at bay.

[CrayonWarrior2000]

It's in cyberspace, my opinion is its a lost cause and the developers know it, what they have come up with so far isn't what I would even call a beta test, beta testing is done on a product that is actually finished, running, with all the features present, the beta test has been debugged by the developers before releasing it to the public for testing purposes, not during the build process itself.

It's not even functional as a trading system at all at this point in time, and is inordinately delayed.

I believe their whole approach is flawed, it would be easier and faster to modify the existing system, piece by piece, a little at a time, one sub routine at a time, building in the ability to detect and intercept attacks, and diffuse the attack itself, much the same way that anti viral programs work, instead of trying to invent a new protocol method, which they will eventually de-code or reverse engineer and crack anyways....

So My vote is for a MxPatrol approach, not a total re-write.

Just My Two Cents.

[GhostShip]

Your input is most welcome CrayonWarrior2000, firstly let me thank you for making the effort to post as a lot of others moan but make no effort to become involved in helping the community or taking part in vital discussions.

when we set out with developing OurMX it was following on from a failed community patch update attempt, at that time it became clear that due to the nature of the protocol flaws being exploited it was not going to be possible to patch all of the various exploits being deployed, the sheer volume of traffic made that approach impossible. With this in mind we moved on to cloning the existing client, this seems to be the approach your suggesting too however where we diverge is in what to undertake to rid the network of these exploits, its not possible using the current protocol to do so, feel free to ask further around the community developers they will all confirm what I am posting here, some of the exploits are patchable but whats the point of continually playing catch up and not being ever able to add anything to the existing client, take for instance IPv6 support etc as well as newer operating system support, the existing program made nearly 10 years ago has served us well but its had its time and we can power ahead with fresh code only if we have written it, this then leads to the delays and problems , lack of coders to actually do the work, theres no lack of skill and mindpower in undertaking this task and whilst you may complain that the 2013 beta was rather non beta it was in response to claims that the program didn't exist at all and to stimulate community interest and support, it wasn't just about releasing a new program,  We have moved ahead since then with the main program growing by 500k so far this year from its initial 1m release, that's a lot of new code added and still more is required we envisage it will reach at least 2 meg or so before its finished to our satisfaction.

The program as designed is not geared towards trading , a p2p network is not a trading platform and whilst someone could add such a simple set of routines in the future to emulate the existing mxmoni features,the current developers will not be doing so and have made this public previously.

The whole of the protocol is not particularly flawed btw CrayonWarrior2000 but the parts that are are in the primary networking level, thus it affects the stability and operation of the whole network as such nodes provide the networks backbone facilities, the main annoyances are spoofed traffic with a broken message authentication routine, this requires replacing and other mechanisms added to protect against the other flaws we have seen being exploited, it stands to reason this type of attack cannot be fixed in the old application as no one has the src code for that so given the same scenario and the need to protect whats left of the current network we have taken the next most safest approach , namely that of a closed developer group with trusted community developers who give their time freely to work on both adding anti attacker code and a new client for the community to move on with, the issue that annoys many is the time delays and the fact that the developer group is a closed one, this is simply answered by making it clear that in the current ourmx builds no protocol changes have been made and so any malicious oik holding the ourmx src could copy the current attacker  and annoy everyone until we had no network left, this comes down to the same problems we face in general, with a lack of coders theres nothing to be gained and everything to lose making the code open src, its not safe to do so given the fixed nature of the current main client and only when changes have been discussed and agreed amongst the developers and anyone else who has a valid comprehension of the necessary changes and such changes are added to OurMx will the open srcing take place, its a big responsibility and one we take seriously. the community will never forgive us if we make attack ready code available, I hope I have explained our approach and rationale to your satisfaction , the main problem we face is lack of trusted coders not anything else, the reason for creating discussion on protocol changes is simply to gather the collective mind power of the community on bringing potentially unexplored solutions to our attention, the need for changes is already self evident.