V7.22.3 [stable] is released!

For example on my Netwatch scripts I use to have:

/tool fetch url="https://api.telegram.org/bot$token/sendmessage\?chat_id=$id&text=$Message" output=none

Now I had to replace it with this:

/tool fetch
url="https://api.telegram.org/bot$token/sendMessage"
http-method=post
http-data="{ "chat_id": "$id", "text": "$Message" }"
http-header-field="Content-Type: application/json"
output=none

In other scripts I had to do some minor variations of the same command and it was really annoying and painful to update.

Why did you have to update the fetch call? For me this looks very unrelated.

Possibly related:
Is the Telegram script failing?

The syntax change seems to have happened in the telegram API.

I get 400 Bad Request when I use inside of my script. After I changed the syntax it started working again.

So for me is related as the way to use fetch tool has changed in the context to enable Telegram notifications.

No, your code has been broken, and your new code is still broken - just differently.

This is completely unrelated to this release, and not caused by a change in RouterOS.

You did not change syntax only, you changed the http method from get to post. So instead of calling an url with some query params you now submit a json object. You just got rid of a bug in your script, namely inproper url encoding.

... and is suffering missing json quoting now.

Ok fine, call it whatever you want, it was get now is post. The bottom line is I have been using this tool fetch for years until 7.22.3 that broke my Telegram messages and some of my scripts.

Take it whatever you want. Just want to share to help others deal with same or similar issue.

I solved my problem. Done and moving on.

You have verified by downgrading to the ROS version you upgraded from? what makes you so sure this issue is related to 7.22.3?

As I found a quick fix, no I didn't bother as that's the only thing I have detected that stopped working or not working properly.

You quick fix will probably break if $Message contains one or more ".

Please keep such assumptions in a separate topic about the Telegram script.

Hi,

Since upgrade to 22.3, i see fastrack counters at 0 for ipv4 and work for ipv6...
Trying downgrade to 7.22.1 like before.

downgrade 7.22.1 don't change....I'm stupid or what ?

for v4

[admmikrotik@router70a] > /ip/settings/print                    
                            allow-fast-path: yes          
                      ipv4-fast-path-active: no           
                     ipv4-fast-path-packets: 0            
                       ipv4-fast-path-bytes: 0            
                      ipv4-fasttrack-active: yes          
                     ipv4-fasttrack-packets: 0            
                       ipv4-fasttrack-bytes: 0            
[admmikrotik@router70a] > /ip/firewall/filter/print 
Flags: X - DISABLED, I - INVALID; D - DYNAMIC 
 0  D ;;; special dummy rule to show fasttrack counters
      chain=forward action=passthrough 

 1    ;;; special dummy rule to enable fasttrack connections
      chain=forward action=fasttrack-connection connection-state=established,related log=no log-prefix="" 

 2    ;;; established/related connections
      chain=forward action=accept connection-state=established,related log=no log-prefix=""

for v6

[admmikrotik@router70a] > /ipv6/settings/print                                
                  allow-fast-path: yes     
            ipv6-fast-path-active: no      
           ipv6-fast-path-packets: 0       
             ipv6-fast-path-bytes: 0       
            ipv6-fasttrack-active: yes     
           ipv6-fasttrack-packets: 32505   
             ipv6-fasttrack-bytes: 34635720
[admmikrotik@router70a] > /ipv6/firewall/filter/print                         
Flags: X - DISABLED, I - INVALID; D - DYNAMIC 
 0  D ;;; special dummy rule to show fasttrack6 counters
      chain=forward action=passthrough 

 1    ;;; special dummy rule to enable fasttrack6 connections
      chain=forward action=fasttrack-connection connection-state=established,related log=no log-prefix=""
 
 2    ;;; established/related connections
      chain=forward action=accept connection-state=established,related log=no log-prefix="" 

You have no IPv4 traffic?

Yes, i have ipv4 traffic on this router :

[admmikrotik@router70a] > /ip/firewall/connection/print count-only
199
[admmikrotik@router70a] > /ipv6/firewall/connection/print count-only
116

Have 1 other router, same behavior, uptime 2 days, same config, no change in cfg

does the dummy rule counters rise?

Yes for the fasttrack....
Ii think i'll create a support ticket but don't remember the last time i've see value. I've downgraded the lab do 7.21.4 and same behavior, still 0. So i think it's a more older problem than 7.22.3 and i'm not in the good thread now.

The only changes sinces 6 months and lot of upgrades were add/remove others chains rules, dhcp leases.... only "exploit" actions. Thank gitted changes

But for sure, i've

[admmikrotik@router70a] /ip/firewall/filter> print stats 
Flags: X - DISABLED; D - DYNAMIC
Columns: CHAIN, ACTION, BYTES, PACKETS
  #    CHAIN               ACTION                           BYTES  PACKETS
;;; special dummy rule to show fasttrack counters
  0  D forward             passthrough                          0        0
;;; special dummy rule to enable fasttrack connections
  1    forward             fasttrack-connection     2 464 672 817  744 412
;;; established/related connections
  2    forward             accept                   2 464 672 817  744 412
;;; drop invalid connections
  3    forward             drop                             3 672       72
;;; icmp
  4    forward             accept                           2 268       27
;;; common to internet
  5    forward             jump                            44 139      616
;;; intra admin
  6    forward             jump                                 0        0
;;; intra lan
  7    forward             jump                                 0        0
;;; intra server
  8    forward             jump                           135 473    1 165

the "special dummy rule" should not be zero.
check /ip/firewall/filter/export verbose as well.

Check whether you have enabled any settings that prevent bridge FastPath from working, like DHCP Snooping for example, or bridge filter/bridge NAT, or use-ip-firewall enabled in bridge setting, or sniffer / torch / traffic gen are running. Also no firewall rules with action=set-priority.