6.33 - strange packets outgoing

onlineuser · Mon Nov 09, 2015 6:19 pm

Hello,

since I have upgraded from 6.32.3 to 6.33 the RB wants to send strange packets.

6.33.PNG

Where does this come from?

pukkita · Mon Nov 09, 2015 9:05 pm

Are you masquerading?

onlineuser · Mon Nov 09, 2015 9:25 pm

Yes, but I did not change anything from the 6.32.3 up to 6.33.

But why will the packets out from my public IP to port 169.254.169.254:80?

bjornr · Mon Nov 09, 2015 9:52 pm

[quote="onlineuser"]Yes, but I did not change anything from the 6.32.3 up to 6.33.

But why will the packets out from my public IP to port 169.254.169.254:80?[/quote]

These seem to be leftovers from autoconfiguration, possibly from testing. The traffic is requests for an ssh key and a hostname. If you provide a hostname, the device will use it to set its identity/name.

See the discussion in the 6.33 release announcement thread.

onlineuser · Mon Nov 09, 2015 10:01 pm

Yes, it seems to be the same problem.

How did you sniff the URL which is always treid to open?

x.x.x.x - - [09/Nov/2015:00:12:04 +0100] "GET /latest/meta-data/public-keys/0/openssh-key HTTP/1.1" 200 604 "-" "-"
x.x.x.x - - [09/Nov/2015:00:12:05 +0100] "GET /latest/meta-data/hostname HTTP/1.1" 200 230 "-" "-"

In Log I only see that a TCP connection to 169.254.169.254:80 want to go out (I have set a hostname).

I hope that it will be fixed soon, because it's flooding my logserver (in meantime I will add a rule that just drops this packets without logging before last-drop rule).

bjornr · Tue Nov 10, 2015 7:22 am

[quote="onlineuser"]Yes, it seems to be the same problem.

How did you sniff the URL which is always treid to open?[/quote]

I simply set up DST-NAT firewall rules to send the request to my laptop, with a small web server running on it. The important part was to let the devices receive a response to the SYN packet, then they could proceed with the request.

It seems like a part of a bootstrap process. Once the devices can successfully complete the request, they will stop trying afterwards - even if they do not receive the files they search for.

Tue Nov 10, 2015 8:22 am

Thank you for your reports. We managed to reproduce this issue and are trying to make a fix as soon as possible.

As a temporary workaround you can use this solution:
/ip route add distance=1 dst-address=169.254.0.0/16 type=blackhole

onlineuser · Tue Nov 10, 2015 10:45 am

Thx.

Is there any real stable 6.xx firmware available?

I think ROS is good but such bugs should not pass the quality management - how long will new releases be tested by your engineers before publication?

P.S. Here the reference link for the hint before: http://forum.mikrotik.com/viewtopic.php ... 48#p506700

pukkita · Tue Nov 10, 2015 11:13 am

From the September Newsletter:

New software release strategy
We have introduced a new software release strategy, where bug fixes will be separated from new features. Now, you will be able to upgrade RouterOS without adding any new features, just the most important fixes.

Starting from v6.31 you are able to select a release “branch” in the quickset upgrade menu and web download site. The choices are “Bugfix only”, “Current” and “Release candidate”. Bugfix only will only contain verified fixes, and no new features. Any version can be chosen to be a bugfix version, it is not indicated by the version number, but RouterOS will show the version type (starting v6.33).

The Current release contains the same fixes but also new features and other improvements, sometimes also less critical fixes than in Bugfix. And finally the Release Candidate is more likely to a nightly build. We will not do intensive testing before publishing these, only check if the upgrade can be done and if most features work fine.

Tue Nov 10, 2015 11:17 am

Is there any real stable 6.xx firmware available?

If you need stable firmware- use 6.32.3 (the previous stable was 6.30.4).
The 6.33 is currently considered "current"- consider it "bleeding edge".

P.S. Do you follow the newsletters and forum posts? Have you tried searching before posting?

onlineuser · Tue Nov 10, 2015 11:21 am

Yes, yesterday I found the graphics.

The strategy of the 3 ways is good butthis bug is easy to find / detecting should be found by any tester before publication.
This is a bug which can be found without knowing the source code.

onlineuser · Thu Nov 19, 2015 6:29 pm

On my testing router I upgraded to 6.33.1.

licensing - fix unneeded connection attempts to 169.254.x.x must be CHR only (introduced in 6.33);

This is now solved.

Because it was a licensing bug, will the router send any data to any of your servers for checking the registration?

What does CHR mean?

Fri Nov 20, 2015 1:54 pm

What does CHR mean?

Cloud Hosted Router. See http://forum.mikrotik.com/viewtopic.php?p=508335.

onlineuser · Fri Nov 20, 2015 2:26 pm

Thx, very much!

6.33 - strange packets outgoing

6.33 - strange packets outgoing

Re: 6.33 - strange packets outgoing

Re: 6.33 - strange packets outgoing

Re: 6.33 - strange packets outgoing

Re: 6.33 - strange packets outgoing

Re: 6.33 - strange packets outgoing

Re: 6.33 - strange packets outgoing

Re: 6.33 - strange packets outgoing

Re: 6.33 - strange packets outgoing

Re: 6.33 - strange packets outgoing

Re: 6.33 - strange packets outgoing

Re: 6.33 - strange packets outgoing

Re: 6.33 - strange packets outgoing

Re: 6.33 - strange packets outgoing

Who is online