SIP client cannot re-register in the SIP server after switching ISP (different NAT)

mTwUser · October 3, 2018, 11:30am

@NathanA,
your scenario really smells like a RouterOS bug, so support@mikrotik.com. If counting the connection timeout up actually has some special meaning, it should be stated in the documentation, which is not the case.

`
Agreed, it smells like a bug. But I’m not the first one to encounter it and it has already been discussed ad nauseam on these forums for years, so it is hard for me to believe that MT support & engineers are not already aware of it. I can also tell you from past experience that reporting it via support@ is a waste of time until I can find a way to reliably reproduce it (which I totally understand – how are they going to fix something that they themselves cannot verify? – but is still a roadblock).

I also have a feeling this is a Linux bug at the core, not a ROS bug in particular. It would be nice if MT could implement a fix in current RouterOS, but what if it is already fixed in later Linux kernels? Chances are good that we will just get the response “you will have to wait for RouterOS 7” as so many other people have received when it comes to other core engineering/structural defects. Unfortunately, ROS is not going to be off of Linux 3.3.5 (+ custom patches) until RouterOS 7, and at this point who knows when (or if) that will ever happen…

– Nathan

Yes this is a Linux Kernel Bug with UDP + PPoE, with a newer Kernel it will be fixed in v7 with a newer kernel. Im surprised your script is working, because i could only truly reset these connections by disabling the interfaces for a couple of seconds.

My updated script as of now (Only use this in SIP + PPoE environments):

/ppp profile
set *0 on-down=":local einwahlether\r\
    \n:if ([/interface get [/interface pppoe-client get [find where disabled=no] interface] type]=\"vlan\") do={:set einwahlether ([/interface vlan get [find where vlan-id=31] interface])} else={:set einwahlether ([/interface pppoe-client get [find w\
    here disabled=no] interface])}\r\
    \n\r\
    \n:local einwahlppoe\r\
    \n:set einwahlppoe  ([/interface pppoe-client get [/interface pppoe-client find disabled=no] name])\r\
    \n\r\
    \n:if ([/interface ethernet find name=\$einwahlether disabled=no] !=\"\") do={\r\
    \n:if ([/interface pppoe-client find name=\$einwahlppoe disabled=no] !=\"\") do={\r\
    \n  /interface pppoe-client disable \$einwahlppoe\r\
    \n  /interface ethernet disable \$einwahlether\r\
    \n  delay 3\r\
    \n  /interface ethernet enable \$einwahlether\r\
    \n  delay 2\r\
    \n  /interface pppoe-client enable \$einwahlppoe\r\
    \n}\r\
    \n}\r\
    \n"


/system scheduler
add interval=5m name=activate-interfaces-every-5-min on-event=\
    "\r\
    \n/interface ethernet enable [find where disabled=yes comment!=\"disabled\"]\r\
    \n/interface pptp-client enable [find where disabled=yes comment!=\"disabled\"]\r\
    \n/interface pppoe-client enable [find where disabled=yes comment!=\"disabled\"]" policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon start-time=startup

to note:
on some connections we have to use a VLAN for our PPoE Connection, in this case the script looks up which ethernet uses the vlan and turns it off for a a couple of seconds.
the scheduler script is sometimes a live safer, for some reason there is a possibility, that after a script the ethernet and the pppoe interface are down after a reboot, the script ensures that they’re getting turned back on again, if there are ether-interfaces which shall stay down: set the comment “disabled” on them.

I recommend using an own /ppp profile, as of now i just use different ones for VPNs etc, but for easier managament it would probably be the best to create an own profile.