![]() |
|
Register | FAQ | The Twelve Commandments | Members List | Calendar | Arcade | Find the Best VPN | Today's Posts | Search |
General Discussion For anything which doesn't fit somewhere else (for PHEX users) |
![]() |
| LinkBack | Thread Tools | Display Modes |
|
| ||||
![]() That's quite an impressive test you did. I'm not sure I understand all specifics, but as far as I see it, you managed to avoid their attack by just telling your router to reject it. If I understand it correctly, this also means, that the utilized TCP implementation of the program is the target. Does the TCP management happen at the OS level, or at the program level? If it is at the program level, it might be possible to add some code which detects excess levels of reset packets in the pipe and just ignores them. Maybe that's what LimeWire already does...
__________________ ![]() -> put this banner into your own signature! <- -- Erst im Spiel lebt der Mensch. Nur ludantaj homoj vivas. GnuFU.net - Gnutella For Users Draketo.de - Shortstories, Poems, Music and strange Ideas. |
| |||
![]() From what I understand, the "device" in the pipeline will take packets and essentially clone them, with the exception of setting the RST control bit in the header. There must be some way of identifying Gnutella packets, possibly by the usual ports most P2P software uses. I don't believe they're simply nailing all the packets at a specific address, since most other traffic is getting through (and going out) just fine. Also, I don't think that whatever they're using is 100% effective, which is probably why my brute force response gave them a little more work than they could handle. With Limewire (vs. Bearshare or Phex), if the software can handle sufficient incoming requests then *some* valid ones are getting through, hence Limewire's ability to find the good amid all the crap coming in. Of course, that's just a theory, and isn't really based on anything other than observation, which means it could be completely wrong. I don't know enough about Limewire's internals to hazard a real (intelligent) guess. So, if your question is "are they aiming this at P2P apps?" and not just all TCP packets, I'd say yes, my testing would seem to indicate that it is targeting P2P. Which also would mean that it is indeed Cox, or some other anti-sharing entity, who's behind the attacks. I'm going to try and think up some more tests, and I may bring another (not quite so fast) Sparc online to do it with, since there's a little more control with TCP than under WinXP. Idea's would be appreciated. Cheers Nick |
![]() |
| |