No, I'm serious. If support promised that bug is fixed in next release - Did you try the fixed release?

How do you expect MikroTik to fix bugs, magically apply fixes to your system without upgrade???

What's new in 3.11:

*) fixed bug - in some cases web proxy https with parent-proxy did not work;
*) added default-route-distance setting for DHCP client;
*) mesh protocol
*) multicast
*) user manager
*) added ability to dst. nat only address or port, not both at the same time;
*) ospf
*) ipsec
*) port remote-access
*) ethernet half duplex modes on rb400 series work now;
*) console
*) console
*) console
*) console
*) console
*) console
*) console

Where?

Changelog doesn't include all minor fixes. Too bad, but that's the way it is. That is why support specifically said that it will be fixed, You should test and see. If it still doesn't work, report to support and they will check why

As i wrote above no one told me it will be fixed in next release about the particular issue about this thread!!!!

As i wrote above i reported my feeling about the generic way MT responds. No feedback from MT about this issue.

I am running the latest release on my 2 pppoe servers but the issue is still there.

Regards
Ros

I don't know about this issue. I just commented the person who said "support told me it will be fixed in next release"

I also have noticed this problem.. All my PPPoE concentrators are running 2.9.46. I've been holding off on upgrading them until this particular problem has been addressed.

Basically what happens is a user connects, but for some reason the simple queue does not get created for their interface, thus giving them an unlimited connection. I've had users getting 10+mbps because of this. I usually catch it, and the fix is to remove their PPPoE session and it will then reconnect and recreate the queue properly. It happens inconsistently but I'd say I see it happen a few times a week.

I have 3 PPPoE concentrators with 300+ users on each of them, and it happens on all of them. I have a whole Customer Information System (CIS) that is designed around RADIUS, Mikrotik, and PPPoE.. So changing to PCQ wouldn't be my ideal solution. I do have the ability to specify an IP address pool through my CIS but that would require going through the 1000+ accounts and changing each one to match their specific connection speed. Using a dynamic address list may be possible, but can you add an account to an address list through RADIUS? If not whats the point? I'm looking to reduce administrative overhead as much as possible.

Here's the topic I started on this exact problem almost a year ago...

http://forum.mikrotik.com/viewtopic.php ... ple+queues

No, I'm serious. If support promised that bug is fixed in next release - Did you try the fixed release?

How do you expect MikroTik to fix bugs, magically apply fixes to your system without upgrade???

Sure I tested not only the "next release" but all releases after that.

In my case the queue is created but the traffic doesn´t flow thru it. I now a person who have this same problem that told me if you disable que queue and re-enable it the traffic starts to flow thru it.

I also have noticed this problem.. All my PPPoE concentrators are running 2.9.46. I've been holding off on upgrading them until this particular problem has been addressed.

Basically what happens is a user connects, but for some reason the simple queue does not get created for their interface, thus giving them an unlimited connection. I've had users getting 10+mbps because of this. I usually catch it, and the fix is to remove their PPPoE session and it will then reconnect and recreate the queue properly. It happens inconsistently but I'd say I see it happen a few times a week.

I have 3 PPPoE concentrators with 300+ users on each of them, and it happens on all of them. I have a whole Customer Information System (CIS) that is designed around RADIUS, Mikrotik, and PPPoE.. So changing to PCQ wouldn't be my ideal solution. I do have the ability to specify an IP address pool through my CIS but that would require going through the 1000+ accounts and changing each one to match their specific connection speed. Using a dynamic address list may be possible, but can you add an account to an address list through RADIUS? If not whats the point? I'm looking to reduce administrative overhead as much as possible.

in my case the queue is created too but after a while (around 4/5 days) the traffic stops to flow into it.

regards
Ros

In my case the queue is created but the traffic doesn´t flow thru it. I now a person who have this same problem that told me if you disable que queue and re-enable it the traffic starts to flow thru it.

In that case. Is it possible to write a script that at 3am or so evry night it disables then reenables all the queues on the box? Might be a temp fix?

Matt

http://forum.mikrotik.com/viewtopic.php?f=2&t=24224

Dynamic PPP Address list looks like it might be a viable solution... at least for me.. I can change the attribute in my management system so instead of passing mikrotik-rate-limit for the rate plans i can create dynamic address lists based on the same value and just change the RADIUS attribute.

Then create the PCQ's and get rid of all the simple queues.

This might be a solution... at least for my setup.

Dynamic PPP Address list looks like it might be a viable solution... at least for me.. I can change the attribute in my management system so instead of passing mikrotik-rate-limit for the rate plans i can create dynamic address lists based on the same value and just change the RADIUS attribute.

Then create the PCQ's and get rid of all the simple queues.

This might be a solution... at least for my setup.

Someone else in this thread stated they switched to PCQ like that and still had the same issues.

Matt

In my case the queue is created but the traffic doesn´t flow thru it. I now a person who have this same problem that told me if you disable que queue and re-enable it the traffic starts to flow thru it.

In that case. Is it possible to write a script that at 3am or so evry night it disables then reenables all the queues on the box? Might be a temp fix?

Matt

But at 3am just a few users are connected and this is a random problem. If the user connect in the middle of the day? Most of my users connect, use Internet and then disconnect.

Dynamic PPP Address list looks like it might be a viable solution... at least for me.. I can change the attribute in my management system so instead of passing mikrotik-rate-limit for the rate plans i can create dynamic address lists based on the same value and just change the RADIUS attribute.

Then create the PCQ's and get rid of all the simple queues.

This might be a solution... at least for my setup.

Someone else in this thread stated they switched to PCQ like that and still had the same issues.

Matt

Exactly. He said it was even worst then dynamic queues.

But at 3am just a few users are connected and this is a random problem. If the user connect in the middle of the day? Most of my users connect, use Internet and then disconnect.

In my experience this affects more users that stay connected 24/7 then those that disconnect and reconnect. Problem is on a user connected 24/7 that is a bandwidth hog they will be online with no rate-limit for weeks. Reseting the queues every 24 hours insures they will only get away with it 24 hours at most.

Matt

But at 3am just a few users are connected and this is a random problem. If the user connect in the middle of the day? Most of my users connect, use Internet and then disconnect.

In my experience this affects more users that stay connected 24/7 then those that disconnect and reconnect. Problem is on a user connected 24/7 that is a bandwidth hog they will be online with no rate-limit for weeks. Reseting the queues every 24 hours insures they will only get away with it 24 hours at most.

Matt

This is a important information. I will pay attention for how long time the user was online when this happen. But how do you disable and enable a dynamic queue? This option is not available at WinBox for this kind of queue. This can be done via script?

But how do you disable and enable a dynamic queue? This option is not available at WinBox for this kind of queue. This can be done via script?

It can be done on terminal. Not sure if disabling and enabling the queue actually causes the PPPoE user to be ratelimited again. Someone else in this thread heard it did.

Matt

i think the discovery path is the following:
1. MT says: there isn't any problem;
2. MT says: we tested your configuration and didn't find anything;
after dozen mails and supout....
3. MT says it is a kernel issue
after months of posting..............
4. MT says we will fix it.

I hope MT will fix it ASAP.

Our experience is like this one:

1. MT says: there isn't any problem;
2. MT says: we tested your configuration and didn't find anything;
after dozen mails...
3. MT says: give us password of your router and we will investigate directly
4. MT says: you see there is not a problem.. (after print screen proofs)
after posting again on mikrotik forum
5. MT says: you are banned now on forum as forum is not a place for you (to post bugs of RouterOS)

And situation on forums:

1. We post about packet loss problem
2. Mikrotik "forum specialists" says: You do not know how to use mikrotik routeros
3. Mikrotik Support warns that we should not post about bugs on forum
4. We are banned from forum
5. Other mikrotik users report pppoe packet loss issue

You can read some in: http://forum.mikrotik.com/viewtopic.php ... &sk=t&sd=a

This particular problem was about packet loss in PPPoE in 3.xx versions. We are still on 2.9.51, but the big problem is random queue missing problem. We must restart it every 10-13 days. And we will not dare to upgrade to 3.11 as possible packet loss can appear.

we have done some fixes and improvements in simple queues and pcq, and made a special "test" package. if anyone is interested to test this package, and help mikrotik solve this problem, write to support

we have done some fixes and improvements in simple queues and pcq, and made a special "test" package. if anyone is interested to test this package, and help mikrotik solve this problem, write to support

Thanks Normis.. this is what everybody here wants.. MK team trying to solve the problem.

Take a look at these screen shots and let me know what you guys think. How could pppoe account for apt79 be getting 128k/8M when he is limited to 128k/256k. Is it the same issue that you are having ? I have attached some screen shots for apartment 79 who I caught one night. He is was getting 8M at the time !
Is the Queue working correctly for the PPPoe Connection ? I am using ROS 3.11, I know that Screenshots are 3.9 but the problem is still happening.

I noticed this before because the whole building is sometimes using upto 40Mb of bandwidth and this should not be happening as most if not all users are limited to 128k/256k. There are some 1M/3M connections but even if all logged in at the same time they would not sum to a demand of 40Mb-1.

What do you think ? Can someone fool the Mikrotik to give it unlimited bandwidth when connected by pppoe ? I though that someone had hacked the pppoe queue control !! Scary thought..

It is like the PPP Interface and the Queue Control has seperated or is not counting traffic correctly.
I monitor the overall link with Dude and do not have a daily traffic chart to show you but it is dramatic when the pppoe queue control is removed. You can see some examples on the weekly chart and remember that they are averaged down so you don't see the full speed that the user got at the time.

Forget about RX - take a look at TX on the opposite interface.

RX is received speed - it is before the actual limitation takes place.

you need to check both TXs:
1) for upload - TX on public interface
2) for download - TX on local interface

The TX on ETH0 is the upload as ETH0 is the public interface.
I am just monitoring ETH0 in Dude for RX and TX as it shows me what the overall site is doing. It helps me spot inconsistancies in the sites bandwidth usage (thats all)

I do not have any IP address on ETH1 as I am using pppoe only on the local side.

The point is that pppoe user account apt79 in the screenshots is getting 9.5Mb Download as per the pppoe account dynamic interface, eventhough apt79 has a dynamic queue limitation of 256k Download/128k Upload as per the profile for his pppoe account. The queue limit appears correct eventhough the dynamic pppoe interface is not being controlled.

I used torch to check the amount of bandwidth that this user was getting by the public IP address that he is using (this is blanked out in the pictures above for privacy issues)

If I log apt79 out of the system "manually" when he reconnects he seems to be limited correctly again.

This happens with other users too randomly.

The TX on ETH0 is the upload as ETH0 is the public interface.
I am just monitoring ETH0 in Dude for RX and TX as it shows me what the overall site is doing. It helps me spot inconsistancies in the sites bandwidth usage (thats all)

I do not have any IP address on ETH1 as I am using pppoe only on the local side.

The point is that pppoe user account apt79 in the screenshots is getting 9.5Mb Download as per the pppoe account dynamic interface, eventhough apt79 has a dynamic queue limitation of 256k Download/128k Upload as per the profile for his pppoe account. The queue limit appears correct eventhough the dynamic pppoe interface is not being controlled.

I used torch to check the amount of bandwidth that this user was getting by the public IP address that he is using (this is blanked out in the pictures above for privacy issues)

If I log apt79 out of the system "manually" when he reconnects he seems to be limited correctly again.

This happens with other users too randomly.

This is exactly the same problem whe have. We will test this beta version that Normis is talking about to see what happens.

It happened again last night. I have been running ROS 3.12 (Beta) that Mikrotik gave me to test and this is the first time that I have seen it all week. It usually happened at weekends in the past. Most users are at home then in this apartment block.

See DUDE graph. The upload speed of >12.5Mb is impossible with the customer base in the building.

Does anyone have a script that I could use to detect the excess usage and disconnect the pppoe account until this issue is solved ?

It happened again last night. I have been running ROS 3.12 (Beta) that Mikrotik gave me to test and this is the first time that I have seen it all week. It usually happened at weekends in the past. Most users are at home then in this apartment block.

See DUDE graph. The upload speed of >12.5Mb is impossible with the customer base in the building.

Does anyone have a script that I could use to detect the excess usage and disconnect the pppoe account until this issue is solved ?

Bad news. I had some hope with this beta version.

ROS 3.12 is now released; change log tells that problem was fixed. Any one tested this version yet??

ROS 3.12 is now released; change log tells that problem was fixed. Any one tested this version yet??

I hope this fix is not the same as 3.12 beta because as told above the problem was not fixed with this beta version.

Crossing my fingers..

Any luck with 3.12 or 3.13?

I've been watching this with keen eyes too. Almost our whole customer base is authenticated with PPPoE and have dynamic queues to limit each connection (Usermanager rocks!).

Does release 3.12 solve the dynamic queue issue in the field?

Does release 3.12 solve the dynamic queue issue in the field?

We have been running 3.12 for over 2 days now but it typically takes at least a week to act up so am not sure yet. So far so good though. Will likely update to 3.13 here shortly though.

Matt

any update from who is testing 3.13?

then please report also the platform, RB or x86.

Regards
Ros

Anyone? I had a user getting 10+mbps for a week.. Wasn't really effecting overall performance for the network but annoys me that this user was getting something for nothing !

I'm about to bite the bullet and just try it myself...

[quote]Anyone? I had a user getting 10+mbps for a week.. Wasn't really effecting overall performance for the network but annoys me that this user was getting something for nothing ![quote]

Was running 3.12 shortly after it came out. Now running 3.13. Have not seen the issue YET. Its too soon to be sure though. Why not try it?

Matt

*** BUMP ***

Also waiting more feedback to see if this is finally done.

Anyone? I had a user getting 10+mbps for a week.. Wasn't really effecting overall performance for the network but annoys me that this user was getting something for nothing !

Was running 3.12 shortly after it came out. Now running 3.13. Have not seen the issue YET. Its too soon to be sure though. Why not try it?

Matt

For us is pretty difficult to upgrade a pppoe server because we use some voip pppoe client that some time lockup when the pppoe server reboots.
So think about 1800..........calls during early morning...,,,,,,,

I will do it when i will be sure to fix this issse and not broke everything else.

regards
ros

any update from who is testing 3.13?

then please report also the platform, RB or x86.

Regards
Ros

We updated some MK routers (x86) to 3.13 where we have more problems with this bug. But we have to wait some days to see.

BAD NEWS!!!

We had the same problem today with version 3.13. User was using more than 4Mbits while he was limit to 1Mbit. As always queue was only displaying 1Mbit in use while at interface we can see more than 4Mbits in use.

SO THIS PROBLEM WAS NOT SOLVED!!!!!!!

Can anyone confirm this?

Can anyone confirm this?

Yes,
RouterOS 3.13v + x86 not solved , the problem still lives .... unfortunately

Can anyone confirm this?

Yes,
RouterOS 3.13v + x86 not solved , the problem still lives .... unfortunately

very disappointed!!!!

we fight each day with invalid queue. They are the oldest but very annoing to catch.

it is still a great bug MT MUST FIX ASAP.

Regards
Ros

Hi all, just to add - 3.13 also x86 (WRAP) does seem to still have the queue issue, We are seeing something strange, Winbox will report some PPPoE clients moving 20Mbit/s, but that sort of speed is impossible at some of our towers, as some are only fed 5Mbit.

We are rolling back to an earlier version

Ops, maybe we are being misled to believe the clients are using the extra bandwidth without actually using it?

Hi all, just to add - 3.13 also x86 (WRAP) does seem to still have the queue issue, We are seeing something strange, Winbox will report some PPPoE clients moving 20Mbit/s, but that sort of speed is impossible at some of our towers, as some are only fed 5Mbit.

We are rolling back to an earlier version

This is not what is happening to us. The traffic we saw on PPPoE interface was the real one in use (we could see it at radio interface used for MK backhaul). When it was displaying 4Mbits on interface he was really using it (but this traffic was not displayed in queue).

Ops, maybe we are being misled to believe the clients are using the extra bandwidth without actually using it?

No, they are really using it. We can see the over traffic at all equipments (switchs, routers, radios, etc).

We usually see the traffic on the PPPoE interface but there queue displays zero for traffic. And the client is really getting that bandwidth. Kind of pain when user paying for 256k lite account pulls movies off bittorrent at 6mbps all weekend.

Matt

we too see zero bandwidth on queue and realspeed on the pppoe interface.
pushing to reauthenticating the customer fix the issue.

So during the day we are going to be the queue cop!!!! very annoing.

Ros

A very quick script to schedule every hour Where n (0, 1, 2 etc) is the column number of your PPPoE server list by issuing at the terminal : This will cycle all PPPoE clients on n interface. When they reconnect a new queue is created that works for a while MT CPE will usually reconnect seamlessly meaning an outage of around 12 seconds

anyone who can give full remote access to your router (with missing queue problem - where queue is shown, but not working for the specific customer), please contact support and we will look !

A very quick script to schedule every hour

Code: Select all

{ /interface pppoe-server
 server disable "0"
 :delay 8s
 server enable "0"
 :delay 8s
 server disable "1"
 :delay 8s
 server enable "1"
 :log info "Cycle PPPoE Servers"
}

Where n (0, 1, 2 etc) is the column number of your PPPoE server list by issuing at the terminal :

Code: Select all

/interface pppoe-server server print

This will cycle all PPPoE clients on n interface. When they reconnect a new queue is created that works for a while MT CPE will usually reconnect seamlessly meaning an outage of around 12 seconds

But this script will stop the user connection? If it break a download or a TCP session is useless for us (our users already claim a lot when we need to reboot MK for maintenance).

the best way is to contact MT to give them the access to the pppoe server to install the debug package.

I at the moment could not give this possibility so any help from the community is welcomen.

regards
Ros

anyone who can give full remote access to your router (with missing queue problem - where queue is shown, but not working for the specific customer), please contact support and we will look !

Please, if someone could do this it would be of great help!

A very quick script to schedule every hour

Code: Select all

{ /interface pppoe-server
 server disable "0"
 :delay 8s
 server enable "0"
 :delay 8s
 server disable "1"
 :delay 8s
 server enable "1"
 :log info "Cycle PPPoE Servers"
}

Where n (0, 1, 2 etc) is the column number of your PPPoE server list by issuing at the terminal :

Code: Select all

/interface pppoe-server server print

This will cycle all PPPoE clients on n interface. When they reconnect a new queue is created that works for a while MT CPE will usually reconnect seamlessly meaning an outage of around 12 seconds

This is not a very viable solution... Think of the overhead with the amount of calls to the RADIUS and MySQL servers for authentication.. Although it will fix the queue problem, it will also piss off a lot of customers.

anyone who can give full remote access to your router (with missing queue problem - where queue is shown, but not working for the specific customer), please contact support and we will look !

Normis,

Does it have to be the latest ROS release 3.13? I have three they can look at all which are running 2.9.51.


-Bill

But this script will stop the user connection? If it break a download or a TCP session is useless for us (our users already claim a lot when we need to reboot MK for maintenance).

You could try setting the delay to 3 seconds in the hope that the MT CPE's will reconnect etc before 7 seconds (after 7 seconds packets are dropped at the CPE) if that is possible they wont notice it.

Today I saw a new error behavior for pppoe and queue (at least was the first time I saw it).

A user was using a lot more bandwidth than was limit with queue. He was using more than 4Mbits and it was congesting others users. So we forced him to disconnect and reconnect. But it didn´t solve the problem. After reconnect he starts to use overlimits. We disconnect him sereval times but didn´t work this time. So I opened torch to a look at his traffic and we found a UDP connection for port 80 (weird) using more than 4Mbits. I create a firewall rule (as the first rule) on MK firewall table to block all UDP traffic over port 80. Then this rule started to capture and drop it, but when I checked the rule statistic is was only maching part of this traffic, coincidentally the same amount displayed at queue statistics (but at pppoe interface statistic we could see a lot more, and this was the really one being used).

of course it has to be v3.13 - the one that has this problem!

Hi Normis,

every mt version since 2.9.x has this bug.

Regards
Ros

Hi Normis,

every mt version since 2.9.x has this bug.

Regards
Ros

we will not modify old versions. we can ONLY fix the latest one. there are already lots of changes in the pppoe and queue programs

So, you will not attempt to correct pppoe missing queues in 2.9.51 ? If you know what is the problem, it will be very easy to make 2.9.52 with correction?

I think that here is a lot of mikrotik users, who uses 2.9.51 for pppoe and are stuck with queue missing problem like us. We use 2.9.51 and must restart pppoe server every 10 days when queue missing problem appears.

was someone able to give MT guys the access to the pppoe server?

regards
Ros

was someone able to give MT guys the access to the pppoe server?

regards
Ros

We are trying to do that.

many thanks josefranco.

Hope MT will reward you about this great help.

regards
Ros

many thanks josefranco.

Hope MT will reward you about this great help.

regards
Ros

I just hope they find the problem and fix it.

Hi josefranco,

may you update on the status of progress?
Still qaiting about the queue issue come up?

regards
Ros

Hi josefranco,

may you update on the status of progress?
Still qaiting about the queue issue come up?

regards
Ros

Nothing yet. They are unable to enter my Mk router (I created a port forward rule and it works for me outside my network but doesn´t work for them)

Were are seeing the issue on 3.13 yet as well. What makes it a real pain is a user gets like several meg upload for a few days but then later after connection goes up and down they are locked back at 512k upload. Then they call complaining the connection is not working right. Argh. Hopefully Mikrotik gets this fixed soon.

Matt

Were are seeing the issue on 3.13 yet as well. What makes it a real pain is a user gets like several meg upload for a few days but then later after connection goes up and down they are locked back at 512k upload. Then they call complaining the connection is not working right. Argh. Hopefully Mikrotik gets this fixed soon.

Matt

Can you please contact MikroTik support team and grant them access to your router so they can investigate what is going on? They prompted to help but we need someone with the problem.

Were are seeing the issue on 3.13 yet as well. What makes it a real pain is a user gets like several meg upload for a few days but then later after connection goes up and down they are locked back at 512k upload. Then they call complaining the connection is not working right. Argh. Hopefully Mikrotik gets this fixed soon.

Matt

Hi Matt, you only saw it happening for upload or already happened with download? Did you take a look at user traffic with torch for example to see what it was?

I´m asking this based on some observations I have done. There is at least one situation where the queue will not solve and there is nothing that can be done. This is when a huge upload traffic is generated using UDP protocol. If such kind of traffic is generated the queue will drop the traffic for outside (to internet) interface but the traffic can reach the internal interface of the router using entire nic or radio bandwidth, since UDP has no flow control. When this happens your internet link will not be flooded but your internal network (wired or wireless) will be, compromising other users.

I already saw this problem happening and if I can´t hardlimit user bandwidth before reaching MK router nothing can be done to solve it.

Of course this doesn´t explain when download is not limited, if upload traffic is TCP or if you can see the high traffic after queue in outside interface (I already had problems in both cases).

This is first time in a while I noticed it on upload. It was TCP traffic and not UDP so thats not the issue. We see it all the time on download traffic.

Matt

Hi josefranco,

may you update on the status of progress?
Still qaiting about the queue issue come up?

regards
Ros

Nothing yet. They are unable to enter my Mk router (I created a port forward rule and it works for me outside my network but doesn´t work for them)

I think happen because you have a multihome router behind a nat.
So their connection enter one side and exit other side.
So I think when you tri to enter, you are lucky becasue you connection enter and exit on the same internet connection.

So take a look into it.
So will be close to an end of this issue.

Or could HCI so kind to contact MT to give them access to the router?

regards
Ros

Or could HCI so kind to contact MT to give them access to the router?

I have not gotten a response from Mikrotik on the ticket I opened with them on this last week. Hopefully they got everything figured and 3.14 will solve this even so.

Matt

Hi Normis,
please may you check the HCI ticket?!?!!?!??!?!?!

it is strange asking support ro access a router with the issue and then not reply to such ticket!

Regards
Ros

Hi Normis,
please may you check the HCI ticket?!?!!?!??!?!?!

it is strange asking support ro access a router with the issue and then not reply to such ticket!

Regards
Ros

It will be great if they can give you MSN address, it will be easier.

HCI did not send us access. Support asked for access, and we didn't receive any response.

Sorry to hear that, seems that people are more into complaining than into helping...

Sorry to hear that, seems that people are more into complaining than into helping...

I don´t know about HCI but we are trying everything here to allow MK team to access our machine. We are even planning to change our MK to valid IP address just to allow it.

We have this problem every week, sometimes more than once per week. This monday he saw 3 users connected in the same MKT router consuming much more than queue download limit (as always queues shows zero usage for download when each one was using more than 2Mbits).

we got access to hci router too now

we got access to hci router too now

Good news Normis..

Gotta wait tell off peak to reboot and install test package. Then I imagine it will be a while before it acts up. Will let Mikrotik know when its in.

Matt

any update on this issue?

regards
ros

The diagnostic package Mikrotik gave me had been installed in the router this weekend. Problem is our DS3 circuit that ties us to Internet at this location went down this morning. The new DS3 was supposed to be SO much more reliable then the old T1's. The LEC has been here working on it for hours. We had a massive amount of lightning here as well.

I will email Mikrotik when they can get in.

Matt

Hi hci,

did the lec repair the damaged circuit?
Is everything back to normal?

hope so.

Regards
Ros

20 hours after it went down they got it fixed. Was not a happy camper. Argh.

Shortly after it came back up Tuesday I emailed Mikrotik. They have access. Will email them the moment I see it act up as well.

Matt

when I see the problem we have also another problem:
- little packet loss or increased jitter (for all the pppoe client) at the moment a new pppoe itnerface is added.

This bug seems fixed in an earlier version but it seems to be present again when an user is able to go over the wueue limit.

regards
Ros

* BUMP *

Hi, any news here?

Mikrotik has access to my router and has special option package installed. Its acting up as I type this and I notified them by email yesterday that it was acting up. So, its wait and see what they say. Have not heard back yet, but its monday too.

Matt

Hi HCI,

did you see some packet loss (on the others) during an addition of a pppoe client interface apart of the missing queue?
It is araisng when i have more then 900 pppoe clients with some of them are missing the queue.

regards
Ros

did you see some packet loss (on the others) during an addition of a pppoe client interface apart of the missing queue? It is araisng when i have more then 900 pppoe clients with some of them are missing the queue.

We have our PPPoE users split between two geographically seperate PPPoE access servers and neither at this time sees over 650 active connections at a given moment. Many users have single PC and/or connect on demand. I have not noticed any packet loss issues but thats not saying there are none. Perhaps you should have given Mikrotik access to your router?

Matt

any comment from Normis????

thanks
Ros

thanks to hci, we have solved this issue. we will continue working with volunteers to make sure it fixes it for good.

Wow! This is a huge accomplishment!

Congratulations MT guys, hci for the teamwork!

Normis, do you have any idea of when this fix will be rolled out?

depends on the results from people who test it

Is there anyway to help?

maybe. contact support if you have a large pppoe server with this issue

The router that Mikrotik worked on this morning has been rebooted to affect there changes. Typically after a reboot it takes a week or more for the issue to show back up or at least be noticeable. Perhaps Normis knows more on why it works that way. They seem pretty confident they found the issue though. Its really a wait and see to be sure.

Thanks Normis.

Matt

is it a test package about 3.13 or based on 3.14 rc1?

regards
Ros

is it a test package about 3.13 or based on 3.14 rc1?

regards
Ros

latest unreleased build I think

Hi Normis,

may you confirm that the fix is into the final 3.14?
In fact into the change log I don't see anything about pppoe.

regards
Ros

Hi Normis,

may you confirm that the fix is into the final 3.14?
In fact into the change log I don't see anything about pppoe.

regards
Ros

we are still testing if the fix works

Hi normis,

I am waiting a fix for a long time. I have 5 pppoe servers and all with this issue. I found a way to work around this problem without restarting the machine. If you have a static simple/tree like p2p control only you need is disable and enable this queues and the pppoe queues will work good.

Friends, try this and post if it works!

Posted accidently. Deleted.

Matt

Well - another bug found, thanks to HCI.

We were pretty lucky actually by finding and fixing this bug:

every 32768th simple queue or 65536th queue tree have no effective limitations.


In HCI's situation it took ~2days until 32768th queue was created, but if clients don't use traffic it is impossible to capture. But luckuly we managed it.

Well - another bug found, thanks to HCI.

We were pretty lucky actually by finding and fixing this bug:

every 32768th simple queue or 65536th queue tree have no effective limitations.


In HCI's situation it took ~2days until 32768th queue was created, but if clients don't use traffic it is impossible to capture. But luckuly we managed it.

Excellent news!!! signed and unsigned int variable sizes.. Do you know in which version this fix will be included?

it will be included into 3.15

regards
Ros

wow, good find!

I found a way to work around this problem without restarting the machine. If you have a static simple/tree like p2p control only you need is disable and enable this queues and the pppoe queues will work good.

Friends, try this and post if it works!

Yes this works!!!

Can you tell me if this works all the time after you disable/enable static queues or it works for period like when you restart machine?

it will be included into 3.15

What about 2.9.52 ?

What about 2.9.52 ?

I dont think there will be any backports to 2.x series anymore because the versions are too different.

I dont think there will be any backports to 2.x series anymore because the versions are too different.

But, bug is the same.

But, bug is the same.

But it will be fixed in later version, in 3.15 =)

I dont think there will be any backports to 2.x series anymore because the versions are too different.

But, bug is the same.

The problem is that, fixing bugs in two releases, duplicates the work and defeats the purpose of releasing a new version. It's true that the release system of MikroTik could be a little more sophisticated and I think they should estabilish official end of life dates to each release overlapping with new major releases and be clear about what fixes would be supported and for how long but, for now, that's the way it is...

so where's 3.15?

impatiently waiting...

I am using 2.9.50, in 2.9.50 i didnt see that problem at all.
may be i didnt see

I am using 2.9.50, in 2.9.50 i didnt see that problem at all.
may be i didnt see

You do not have enough traffic to reach 32768th simple queue.

I imagine HCI is running a fixed beta version for this problem.

Maybe he could give us a feedback if this problem was solved (or if he is still waiting for 3.15 like us).

Got to 8 days of uptime on it without it acting up. Unfortunately do to some power outages lately thats all the uptime I have on it. Twice now when we cut from UPS to generator we have had reboot issue. Time to revamp our backup system.

Anyway, usually it acted up at 5-7 days of uptime for me. I think they have it fixed. But until I have like 30 days of uptime with no issues I am not sure. Perhaps if they tested on some more heavy loaded PPPoE access servers we would know more.

Matt

I'd love to test on ours.. I have 3 PPPoE servers with 300+ users on each all with reliable power..

Had a user using 10+mbps the other day.. really was killing one of our high priority links.. luckily it happened while I was monitoring the network..

I'd love to test on ours.. I have 3 PPPoE servers with 300+ users on each all with reliable power..

Email Mikrotik and offer them access to your router to do this.

Matt

Just did.

may MT confirm the HCI fix is inside the 3.15?

I don't see it into the change log.

regards
Ros

may MT confirm the HCI fix is inside the 3.15?

I don't see it into the change log.

regards
Ros

Here we go again...

...and out of the window goes the idea of a release candidate in a feature changing release...

...good luck to us all!

may MT confirm the HCI fix is inside the 3.15?

I don't see it into the change log.

regards
Ros

I really don´t understand why they do that.

We really need this information MK guys!

hi Normis,
why you are not responding to latest question?

is it the fix inside the 3.15?????
please i need a confirmation ASAP.

regrads
Ros

I now have over 10 days of uptime on my 3.13 release patched by Mikrotik and its still not acting up. Looks like they may have gotten it fixed. No idea if the fix is in 3.15 though.

Matt

I have upgraded to 3.15 and I am running it for about a week, and I don't see this problem, I have about 50 Users. I monitor interfaces and users get the speed that they have in PPPoE profiles.

I have upgraded to 3.15 and I am running it for about a week, and I don't see this problem, I have about 50 Users. I monitor interfaces and users get the speed that they have in PPPoE profiles.

what hardware are you running?

regards
Ros

I have PC Router with this hardware configuration:
Fujitsu Siemens with Intel P4 2.0GHz procesor
512 MB RAM

And now Winbox does not freeze like before, now most of the time it does not freeze to me, sometimes yes.

Have 17+ days of uptime on 3.13 with fixes from Mikrotik and no PPPoE queues are acting up. Did anyone find out if 3.15 has these fixes in it?

Matt

Have 17+ days of uptime on 3.13 with fixes from Mikrotik and no PPPoE queues are acting up. Did anyone find out if 3.15 has these fixes in it?

Matt

No response from MK team.

Have 17+ days of uptime on 3.13 with fixes from Mikrotik and no PPPoE queues are acting up. Did anyone find out if 3.15 has these fixes in it?

Matt

Janis confirmed me that 3.15 ha the HCI fix inside.

But I am scary to upgrade my x386 boxes becasue the 3.15 has the new kernel not so compatible with the multicore cpu


Regards
Ros

Have 17+ days of uptime on 3.13 with fixes from Mikrotik and no PPPoE queues are acting up. Did anyone find out if 3.15 has these fixes in it?

Matt

Janis confirmed me that 3.15 ha the HCI fix inside.

But I am scary to upgrade my x386 boxes becasue the 3.15 has the new kernel not so compatible with the multicore cpu


Regards
Ros

So it´s useless for us.. have to wait for multi-core CPU fix now. It´s hard to believe. Can´t HCI post his 3.13 fixed version for us?

Anybody here knows if version 3.16 fixed multi-core CPU problems included in version 3.15?

I need the fix for queue but also need to use dual core CPUs.

I don't know if it's a multi-core bug, but there's still a problem with 3.15 and 3.16 with timers: clock goes at least two times faster than real clock on a dual-core CPU.

time problem is not fix in 3.16

Swap CPU's to a really fast single core for time being?

Matt

Swap CPU's to a really fast single core for time being?

Matt

This is not a solution for me. If I went to dual core CPU was because I already reach the limit for single core CPU.

Any news about this issue?

Any news about this issue?

What issue? Its gone!

Matt

Any news about this issue?

What issue? Its gone!

Matt

Really?

Any news about this issue?

What issue? Its gone!

Matt

What version are you using? We are still in 3.13 because vesions after 3.13 are not stable for dual core CPU.

Oh, do not use dual core here. Does change log say they fixed dual core issues? We are running 3.16 on single core 1.8ghz socket 775 CPU. 14 days of uptime and no queue issues.

I'm sorry but was there ever any difference between how v3.13 works with dual-core and how v3.16 works with dual core? if it works in v3.13, then it should work with the other versions too