Good morning all, Just hoping for a sanity check... we have a fleet of RBSXTLTE3-7 units out in the field which have proven to be quite reliable. Since upgrading one of the units which was previously working fine from 6.39.2 to 6.45.2 for the security fixes (and doing associated firmware upgrade) - the unit is locking up even with no traffic after about 4 hours of uptime. I'm still able to SSH into it and do some tasks (eg issuing "/system reboot" works, albeit takes quite a while to actually do the reboot), but other tasks don't work (eg if I type in "/ping 1" it will reliably and totally lock the SSH session before I can even enter the full IP address). I've tried a full factory reset of configuration and rebuilding from scratch, as well as going back to 6.44.5 and up to 6.46beta16, the only idea I haven't tried yet is to netinstall it (which is a bit of a challenge as it isn't something I can easily access physically so I'm hoping to avoid that!). I'm not game to upgrade another one of our units to see if it is the unit or the upgrade that is the problem quite yet. Is there anything obvious with the upgrade path that I've missed perhaps? Kind regards, Thomas
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Thomas Jackson Sent: Friday, 26 July 2019 11:28 AM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: [MT-AU Public] SXTLTE dropouts after upgrade
Good morning all,
Just hoping for a sanity check... we have a fleet of RBSXTLTE3-7 units out in the field which have proven to be quite reliable.
Since upgrading one of the units which was previously working fine from 6.39.2 to 6.45.2 for the security fixes (and doing associated firmware upgrade) - the unit is locking up even with no traffic after about 4 hours of uptime. I'm still able to SSH into it and do some tasks (eg issuing "/system reboot" works, albeit takes quite a while to actually do the reboot), but other tasks don't work (eg if I type in "/ping 1" it will reliably and totally lock the SSH session before I can even enter the full IP address).
I've tried a full factory reset of configuration and rebuilding from scratch, as well as going back to 6.44.5 and up to 6.46beta16, the only idea I haven't tried yet is to netinstall it (which is a bit of a challenge as it isn't something I can easily access physically so I'm hoping to avoid that!). I'm not game to upgrade another one of our units to see if it is the unit or the upgrade
Hi Thomas, Two thoughts that may be worth considering in such circumstances: 1. did you update the routerboot before or after the routeros update? Does the current firmware shown by '/system routerbard print' match the 'upgrade firmware' value? 2. if you do need to netinstall, you can enter netinstall mode without physical access to the device (but still need direct L2 access - which could be over tunnel such as EoIP bridged to other device on same broadcast domain) by use of routeros command: /system routerboard bios set boot-device=try-etherboot-once etherboot-timeout=30 /system reboot Cheers, Mike. that is
the problem quite yet.
Is there anything obvious with the upgrade path that I've missed perhaps?
Kind regards,
Thomas
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Thomas Jackson Sent: Friday, 26 July 2019 11:28 AM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: [MT-AU Public] SXTLTE dropouts after upgrade
Good morning all,
Just hoping for a sanity check... we have a fleet of RBSXTLTE3-7 units out in the field which have proven to be quite reliable.
Since upgrading one of the units which was previously working fine from 6.39.2 to 6.45.2 for the security fixes (and doing associated firmware upgrade) - the unit is locking up even with no traffic after about 4 hours of uptime. I'm still able to SSH into it and do some tasks (eg issuing "/system reboot" works, albeit takes quite a while to actually do the reboot), but other tasks don't work (eg if I type in "/ping 1" it will reliably and totally lock the SSH session before I can even enter the full IP address).
I've tried a full factory reset of configuration and rebuilding from scratch, as well as going back to 6.44.5 and up to 6.46beta16, the only idea I haven't tried yet is to netinstall it (which is a bit of a challenge as it isn't something I can easily access physically so I'm hoping to avoid that!). I'm not game to upgrade another one of our units to see if it is the unit or the upgrade
Thanks Mike The firmware was updated after the RouterOS update - and yes, the upgrade firmware is matching the current firmware in "/system routerboard print" I think I'll have to do the remote netinstall - I was hoping there might have been a better way around it but not to be! -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Mike Everest Sent: Friday, 26 July 2019 12:19 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SXTLTE dropouts after upgrade Hi Thomas, Two thoughts that may be worth considering in such circumstances: 1. did you update the routerboot before or after the routeros update? Does the current firmware shown by '/system routerbard print' match the 'upgrade firmware' value? 2. if you do need to netinstall, you can enter netinstall mode without physical access to the device (but still need direct L2 access - which could be over tunnel such as EoIP bridged to other device on same broadcast domain) by use of routeros command: /system routerboard bios set boot-device=try-etherboot-once etherboot-timeout=30 /system reboot Cheers, Mike. that is
the problem quite yet.
Is there anything obvious with the upgrade path that I've missed perhaps?
Kind regards,
Thomas
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Thomas Jackson Sent: Friday, 26 July 2019 11:28 AM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: [MT-AU Public] SXTLTE dropouts after upgrade
Good morning all,
Just hoping for a sanity check... we have a fleet of RBSXTLTE3-7 units out in the field which have proven to be quite reliable.
Since upgrading one of the units which was previously working fine from 6.39.2 to 6.45.2 for the security fixes (and doing associated firmware upgrade) - the unit is locking up even with no traffic after about 4 hours of uptime. I'm still able to SSH into it and do some tasks (eg issuing "/system reboot" works, albeit takes quite a while to actually do the reboot), but other tasks don't work (eg if I type in "/ping 1" it will reliably and totally lock the SSH session before I can even enter the full IP address).
I've tried a full factory reset of configuration and rebuilding from scratch, as well as going back to 6.44.5 and up to 6.46beta16, the only idea I haven't tried yet is to netinstall it (which is a bit of a challenge as it isn't something I can easily access physically so I'm hoping to avoid that!). I'm not game to upgrade another one of our units to see if it is the unit or the upgrade
I've managed to do the remote netinstall (using EOIP over SSTP on another device on the network) - but unfortunately it still falls over after almost exactly 4 hours of uptime. I'm thinking the next step is to roll right back to 6.39.2 -----Original Message----- From: Thomas Jackson Sent: Friday, 26 July 2019 5:26 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: RE: [MT-AU Public] SXTLTE dropouts after upgrade Thanks Mike The firmware was updated after the RouterOS update - and yes, the upgrade firmware is matching the current firmware in "/system routerboard print" I think I'll have to do the remote netinstall - I was hoping there might have been a better way around it but not to be! -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Mike Everest Sent: Friday, 26 July 2019 12:19 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SXTLTE dropouts after upgrade Hi Thomas, Two thoughts that may be worth considering in such circumstances: 1. did you update the routerboot before or after the routeros update? Does the current firmware shown by '/system routerbard print' match the 'upgrade firmware' value? 2. if you do need to netinstall, you can enter netinstall mode without physical access to the device (but still need direct L2 access - which could be over tunnel such as EoIP bridged to other device on same broadcast domain) by use of routeros command: /system routerboard bios set boot-device=try-etherboot-once etherboot-timeout=30 /system reboot Cheers, Mike. that is
the problem quite yet.
Is there anything obvious with the upgrade path that I've missed perhaps?
Kind regards,
Thomas
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Thomas Jackson Sent: Saturday, 27 July 2019 12:53 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SXTLTE dropouts after upgrade
I've managed to do the remote netinstall (using EOIP over SSTP on another device on the network) - but unfortunately it still falls over after almost exactly 4 hours of uptime.
I'm thinking the next step is to roll right back to 6.39.2
-----Original Message----- From: Thomas Jackson Sent: Friday, 26 July 2019 5:26 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: RE: [MT-AU Public] SXTLTE dropouts after upgrade
Thanks Mike
The firmware was updated after the RouterOS update - and yes, the upgrade firmware is matching the current firmware in "/system routerboard print"
I think I'll have to do the remote netinstall - I was hoping there might have been a better way around it but not to be!
-----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Mike Everest Sent: Friday, 26 July 2019 12:19 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SXTLTE dropouts after upgrade
Hi Thomas,
Two thoughts that may be worth considering in such circumstances:
1. did you update the routerboot before or after the routeros update? Does the current firmware shown by '/system routerbard print' match the 'upgrade firmware' value?
2. if you do need to netinstall, you can enter netinstall mode without
access to the device (but still need direct L2 access - which could be over tunnel such as EoIP bridged to other device on same broadcast domain) by use of routeros command: /system routerboard bios set boot-device=try-etherboot-once etherboot-timeout=30 /system reboot
Cheers, Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Thomas Jackson Sent: Friday, 26 July 2019 11:28 AM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: [MT-AU Public] SXTLTE dropouts after upgrade
Good morning all,
Just hoping for a sanity check... we have a fleet of RBSXTLTE3-7 units out in the field which have proven to be quite reliable.
Since upgrading one of the units which was previously working fine from 6.39.2 to 6.45.2 for the security fixes (and doing associated firmware upgrade) - the unit is locking up even with no traffic after about 4 hours of uptime. I'm still able to SSH into it and do some tasks (eg issuing "/system reboot" works, albeit takes quite a while to actually do the reboot), but other tasks don't work (eg if I type in "/ping 1" it will reliably and totally lock the SSH session before I can even enter the full IP address).
I've tried a full factory reset of configuration and rebuilding from scratch, as well as going back to 6.44.5 and up to 6.46beta16, the only idea I haven't tried yet is to netinstall it (which is a bit of a challenge as it isn't something I can easily access physically so I'm hoping to avoid that!). I'm not game to upgrade another one of our units to see if it is the unit or the upgrade that is the problem quite yet.
Is there anything obvious with the upgrade path that I've missed
Anything useful in the logs? Try turning on full debug mode and write logs to disk? Can you get any output from "system resource print", or "system health" or "tool profiler"? Can you manage to get a supout file from it? Cheers! physical perhaps?
Kind regards,
Thomas
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Thomas Jackson Sent: Saturday, 27 July 2019 12:53 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SXTLTE dropouts after upgrade
I've managed to do the remote netinstall (using EOIP over SSTP on another device on the network) - but unfortunately it still falls over after almost exactly 4 hours of uptime.
I'm thinking the next step is to roll right back to 6.39.2
-----Original Message----- From: Thomas Jackson Sent: Friday, 26 July 2019 5:26 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: RE: [MT-AU Public] SXTLTE dropouts after upgrade
Thanks Mike
The firmware was updated after the RouterOS update - and yes, the upgrade firmware is matching the current firmware in "/system routerboard print"
I think I'll have to do the remote netinstall - I was hoping there might have been a better way around it but not to be!
-----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Mike Everest Sent: Friday, 26 July 2019 12:19 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SXTLTE dropouts after upgrade
Hi Thomas,
Two thoughts that may be worth considering in such circumstances:
1. did you update the routerboot before or after the routeros update? Does the current firmware shown by '/system routerbard print' match the 'upgrade firmware' value?
2. if you do need to netinstall, you can enter netinstall mode without
access to the device (but still need direct L2 access - which could be over tunnel such as EoIP bridged to other device on same broadcast domain) by use of routeros command: /system routerboard bios set boot-device=try-etherboot-once etherboot-timeout=30 /system reboot
Cheers, Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Thomas Jackson Sent: Friday, 26 July 2019 11:28 AM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: [MT-AU Public] SXTLTE dropouts after upgrade
Good morning all,
Just hoping for a sanity check... we have a fleet of RBSXTLTE3-7 units out in the field which have proven to be quite reliable.
Since upgrading one of the units which was previously working fine from 6.39.2 to 6.45.2 for the security fixes (and doing associated firmware upgrade) - the unit is locking up even with no traffic after about 4 hours of uptime. I'm still able to SSH into it and do some tasks (eg issuing "/system reboot" works, albeit takes quite a while to actually do the reboot), but other tasks don't work (eg if I type in "/ping 1" it will reliably and totally lock the SSH session before I can even enter the full IP address).
I've tried a full factory reset of configuration and rebuilding from scratch, as well as going back to 6.44.5 and up to 6.46beta16, the only idea I haven't tried yet is to netinstall it (which is a bit of a challenge as it isn't something I can easily access physically so I'm hoping to avoid that!). I'm not game to upgrade another one of our units to see if it is the unit or the upgrade that is the problem quite yet.
Is there anything obvious with the upgrade path that I've missed
It's a really strange one - after 4 hours it will reliably start misbehaving, every single time, so I'm thinking there is some resource being starved. But /system resource print looks normal, /system health print looks normal, and /tool profiler shows minimal usage. Once it hits this point, issuing a /system reboot always takes two tries - the first try will exit the SSH session but do nothing, opening a new SSH session then issuing the command again will actually reboot. Entering /ping 1 will reliably crash the SSH session before even pressing enter, but other commands like /log print are fine (and don't show anything useful, although I haven't gone to the step of debug logs yet). I did manage to get a supout file (after quite a bit of waiting), and putting that into the supout reader on the Mikrotik website shows the message "failed: std failure: timeout (13)" under most sections. Under the instchk section there is "ERROR: bad image file" which makes me wonder if there is some corruption sitting somewhere which wasn't fixed by the netinstall. As a temporary workaround, I've put in a 2-hourly /system reboot, and it looks like we'll have to swap the unit out for further testing -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Mike Everest Sent: Saturday, 27 July 2019 3:15 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SXTLTE dropouts after upgrade Anything useful in the logs? Try turning on full debug mode and write logs to disk? Can you get any output from "system resource print", or "system health" or "tool profiler"? Can you manage to get a supout file from it? Cheers! physical perhaps?
Kind regards,
Thomas
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Thomas Jackson Sent: Saturday, 27 July 2019 6:01 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SXTLTE dropouts after upgrade
It's a really strange one - after 4 hours it will reliably start misbehaving, every single time, so I'm thinking there is some resource being starved.
But /system resource print looks normal, /system health print looks normal, and /tool profiler shows minimal usage.
Once it hits this point, issuing a /system reboot always takes two tries -
first try will exit the SSH session but do nothing, opening a new SSH session then issuing the command again will actually reboot.
Entering /ping 1 will reliably crash the SSH session before even pressing enter, but other commands like /log print are fine (and don't show anything useful, although I haven't gone to the step of debug logs yet).
I did manage to get a supout file (after quite a bit of waiting), and
Hi Thomas, If you purchased via us, send the supout file to support@duxtel.com - it sounds like something we'd like to take a look at! At this stage, I tend to agree that a downgrade would be a sensible move. Cheers, Mike. the putting
that into the supout reader on the Mikrotik website shows the message "failed: std failure: timeout (13)" under most sections. Under the instchk section there is "ERROR: bad image file" which makes me wonder if there is some corruption sitting somewhere which wasn't fixed by the netinstall.
As a temporary workaround, I've put in a 2-hourly /system reboot, and it looks like we'll have to swap the unit out for further testing
-----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Mike Everest Sent: Saturday, 27 July 2019 3:15 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SXTLTE dropouts after upgrade
Anything useful in the logs? Try turning on full debug mode and write logs to disk?
Can you get any output from "system resource print", or "system health" or "tool profiler"?
Can you manage to get a supout file from it?
Cheers!
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Thomas Jackson Sent: Saturday, 27 July 2019 12:53 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SXTLTE dropouts after upgrade
I've managed to do the remote netinstall (using EOIP over SSTP on another device on the network) - but unfortunately it still falls over after almost exactly 4 hours of uptime.
I'm thinking the next step is to roll right back to 6.39.2
-----Original Message----- From: Thomas Jackson Sent: Friday, 26 July 2019 5:26 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: RE: [MT-AU Public] SXTLTE dropouts after upgrade
Thanks Mike
The firmware was updated after the RouterOS update - and yes, the upgrade firmware is matching the current firmware in "/system routerboard print"
I think I'll have to do the remote netinstall - I was hoping there might have been a better way around it but not to be!
-----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Mike Everest Sent: Friday, 26 July 2019 12:19 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SXTLTE dropouts after upgrade
Hi Thomas,
Two thoughts that may be worth considering in such circumstances:
1. did you update the routerboot before or after the routeros update? Does the current firmware shown by '/system routerbard print' match the 'upgrade firmware' value?
2. if you do need to netinstall, you can enter netinstall mode without physical access to the device (but still need direct L2 access - which could be over tunnel such as EoIP bridged to other device on same broadcast domain) by use of routeros command: /system routerboard bios set boot-device=try-etherboot-once etherboot-timeout=30 /system reboot
Cheers, Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Thomas Jackson Sent: Friday, 26 July 2019 11:28 AM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: [MT-AU Public] SXTLTE dropouts after upgrade
Good morning all,
Just hoping for a sanity check... we have a fleet of RBSXTLTE3-7 units out in the field which have proven to be quite reliable.
Since upgrading one of the units which was previously working fine from 6.39.2 to 6.45.2 for the security fixes (and doing associated firmware upgrade) - the unit is locking up even with no traffic after about 4 hours of uptime. I'm still able to SSH into it and do some tasks (eg issuing "/system reboot" works, albeit takes quite a while to actually do the reboot), but other tasks don't work (eg if I type in "/ping 1" it will reliably and totally lock the SSH session before I can even enter the full IP address).
I've tried a full factory reset of configuration and rebuilding from scratch, as well as going back to 6.44.5 and up to 6.46beta16, the only idea I haven't tried yet is to netinstall it (which is a bit of a challenge as it isn't something I can easily access physically so I'm hoping to avoid that!). I'm not game to upgrade another one of our units to see if it is the unit or the upgrade that is the problem quite yet.
Is there anything obvious with the upgrade path that I've missed perhaps?
Kind regards,
Thomas
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Thomas Jackson Sent: Saturday, 27 July 2019 6:01 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SXTLTE dropouts after upgrade
It's a really strange one - after 4 hours it will reliably start misbehaving, every single time, so I'm thinking there is some resource being starved.
But /system resource print looks normal, /system health print looks normal, and /tool profiler shows minimal usage.
Once it hits this point, issuing a /system reboot always takes two tries -
first try will exit the SSH session but do nothing, opening a new SSH session then issuing the command again will actually reboot.
Entering /ping 1 will reliably crash the SSH session before even pressing enter, but other commands like /log print are fine (and don't show anything useful, although I haven't gone to the step of debug logs yet).
I did manage to get a supout file (after quite a bit of waiting), and
To close this out, it looks like the downgrade has been the fix; now up to almost 13 hours uptime with no issues after rolling back to 6.39.2 - and supout sent to Duxtel. Not sure if it is just this unit or something with the new versions, not entirely game to try on another unit though! -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Mike Everest Sent: Saturday, 27 July 2019 11:21 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SXTLTE dropouts after upgrade Hi Thomas, If you purchased via us, send the supout file to support@duxtel.com - it sounds like something we'd like to take a look at! At this stage, I tend to agree that a downgrade would be a sensible move. Cheers, Mike. the putting
that into the supout reader on the Mikrotik website shows the message "failed: std failure: timeout (13)" under most sections. Under the instchk section there is "ERROR: bad image file" which makes me wonder if there is some corruption sitting somewhere which wasn't fixed by the netinstall.
As a temporary workaround, I've put in a 2-hourly /system reboot, and it looks like we'll have to swap the unit out for further testing
-----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Mike Everest Sent: Saturday, 27 July 2019 3:15 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SXTLTE dropouts after upgrade
Anything useful in the logs? Try turning on full debug mode and write logs to disk?
Can you get any output from "system resource print", or "system health" or "tool profiler"?
Can you manage to get a supout file from it?
Cheers!
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Thomas Jackson Sent: Saturday, 27 July 2019 12:53 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SXTLTE dropouts after upgrade
I've managed to do the remote netinstall (using EOIP over SSTP on another device on the network) - but unfortunately it still falls over after almost exactly 4 hours of uptime.
I'm thinking the next step is to roll right back to 6.39.2
-----Original Message----- From: Thomas Jackson Sent: Friday, 26 July 2019 5:26 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: RE: [MT-AU Public] SXTLTE dropouts after upgrade
Thanks Mike
The firmware was updated after the RouterOS update - and yes, the upgrade firmware is matching the current firmware in "/system routerboard print"
I think I'll have to do the remote netinstall - I was hoping there might have been a better way around it but not to be!
-----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Mike Everest Sent: Friday, 26 July 2019 12:19 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SXTLTE dropouts after upgrade
Hi Thomas,
Two thoughts that may be worth considering in such circumstances:
1. did you update the routerboot before or after the routeros update? Does the current firmware shown by '/system routerbard print' match the 'upgrade firmware' value?
2. if you do need to netinstall, you can enter netinstall mode without physical access to the device (but still need direct L2 access - which could be over tunnel such as EoIP bridged to other device on same broadcast domain) by use of routeros command: /system routerboard bios set boot-device=try-etherboot-once etherboot-timeout=30 /system reboot
Cheers, Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Thomas Jackson Sent: Friday, 26 July 2019 11:28 AM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: [MT-AU Public] SXTLTE dropouts after upgrade
Good morning all,
Just hoping for a sanity check... we have a fleet of RBSXTLTE3-7 units out in the field which have proven to be quite reliable.
Since upgrading one of the units which was previously working fine from 6.39.2 to 6.45.2 for the security fixes (and doing associated firmware upgrade) - the unit is locking up even with no traffic after about 4 hours of uptime. I'm still able to SSH into it and do some tasks (eg issuing "/system reboot" works, albeit takes quite a while to actually do the reboot), but other tasks don't work (eg if I type in "/ping 1" it will reliably and totally lock the SSH session before I can even enter the full IP address).
I've tried a full factory reset of configuration and rebuilding from scratch, as well as going back to 6.44.5 and up to 6.46beta16, the only idea I haven't tried yet is to netinstall it (which is a bit of a challenge as it isn't something I can easily access physically so I'm hoping to avoid that!). I'm not game to upgrade another one of our units to see if it is the unit or the upgrade that is the problem quite yet.
Is there anything obvious with the upgrade path that I've missed perhaps?
Kind regards,
Thomas
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
participants (2)
-
Mike Everest -
Thomas Jackson