Everything is fine. The user uses his eMule and I can see that the queue is limiting the traffic correctly, so, the queue is completelly in red and limiting up and down to 190-205k. When I list on connections I can see that P2P columm marks “eDonkey”.
Next to my Internet connection I use a QoS structure as described in http://wiki.mikrotik.com/wiki/Mangle%2C_Queue_Tree_and_prio_by_fly_man_…_almost_done and it is more or less the same that what my trainers explained me in my Mikrotik’s Certification Course. I try to mark in mangle all connections and packets P2P. When I list on connections list I am just able to see in the P2P columm “bit-torrent”. I thought that I was doing something wrong so I just disabled all mangle marks and queue trees and I added a simple queue like the one I added in my user’s CPE. The simple queue is not detecting the “eDonkey”.
The only difference that I can appreciate is the RouterOS version. My user has a 133C with 2.9.46 and next to the Internet connection I use a 600 with 3.4. With the SAME queue rule the first detects eDonkey and the second no. But the traffic is there!
I really think that there is a serious problem with the Connection Tracking in 3.6 al least on RB600.
I have just upgraded from 3.2 to 3.6 and the Connection Tracking is not working well:
The TCP established timeout is up to 5d when the limit is set to 10 minutes. I have tried to flush all connections, rebooting and the problem persists.
There is no P2P connections detected spite I have eMules working.
I have ICMP pakets that in the Connection list appear with source and destination port (really).
The first I detected was the P2P problem but I think that all has to do with the Connection Tracking problem on 3.6.
You are right about connection tracking in Ver 3.6 in MT OS the TCP established timeout shows 4 days but I have put 1 day in that option. I don’t know what is wrong!
I am seriously considering to use PCs and 2.9.x again.
I wanted to give a try to the new RB600 and RB1000 to substitute PCs because all seemed to be advantages: high performance, no HD, no coolers, less power consumption. But the problem is that al these routerboards need 3.x. Spite 3.x has new interesting features like layer7 detections is not working as well as 2.9.x used as a QoS Router.
My final choice: PCs with 2.9.x for QoS and RBs with 3.4 or latter for wireless connections.
As a friend of mine says: “The Best OS is the one that was released a year ago”.
It is greatfull to listen about others having the same problem that means that I am not alone in this world
Have You experienced also strange mangle marks like I detected ICMP with source and destination ports?
I don’t know if You have the way to check it but have You experienced a bad P2P detection? Do You see packets marked with eDonkey in the Connection Tracking?
I try to attach You the CPE in the user side and what I see in the QoS Router. The CPE has 2.9.x and the QoS Router 3.6 and the queues are as simple as “detect all-p2p”. I detect P2P traffic on the user side but not in the QoS Router side. How could it be possible?
I have recently seen problems with P2P detection too..
I have mangle rules to mark P2P. The mangle detects nothing until you turn on connection tracking.
Can anyone confirm that you must have connection tracking turned on to enable P2P detection ? I thought connection tracking was only required for NAT functionality.
Anyway, When I turn on connection tracking and P2P mangle I start to get problems connecting into remote routers via winbox (eventhough I can ping the routers and FTP into them) I thought that this was a MAC address issue but I have rebooted them and cleared the MAC tables as well. The problem continues until I turn off connection tracking and all resumes as normal !! but now I cannot use P2P detection because connection tracking seems to be required. I am stuck…
I have also seen ICMP being detected as P2P and could not ping remote equipment until I moved the P2P filter so that it was after the ICMP filter in the firewall chain, in otherwords the destiny of the ICMP had to be determined before it got to the P2P filter in the firewall chain otherwise it would be detected as P2P and dropped.
