Menu
▾
▴
astlinux-users — AstLinux Users Mailing List
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(91) |
Feb
(111) |
Mar
(226) |
Apr
(65) |
May
(197) |
Jun
(202) |
Jul
(92) |
Aug
(87) |
Sep
(120) |
Oct
(133) |
Nov
(89) |
Dec
(155) |
| 2008 |
Jan
(251) |
Feb
(136) |
Mar
(174) |
Apr
(149) |
May
(56) |
Jun
(32) |
Jul
(36) |
Aug
(171) |
Sep
(245) |
Oct
(244) |
Nov
(218) |
Dec
(272) |
| 2009 |
Jan
(113) |
Feb
(119) |
Mar
(192) |
Apr
(117) |
May
(93) |
Jun
(46) |
Jul
(80) |
Aug
(54) |
Sep
(109) |
Oct
(70) |
Nov
(145) |
Dec
(110) |
| 2010 |
Jan
(137) |
Feb
(87) |
Mar
(45) |
Apr
(157) |
May
(58) |
Jun
(99) |
Jul
(188) |
Aug
(136) |
Sep
(101) |
Oct
(100) |
Nov
(61) |
Dec
(60) |
| 2011 |
Jan
(84) |
Feb
(43) |
Mar
(70) |
Apr
(17) |
May
(69) |
Jun
(28) |
Jul
(43) |
Aug
(21) |
Sep
(151) |
Oct
(120) |
Nov
(84) |
Dec
(101) |
| 2012 |
Jan
(119) |
Feb
(82) |
Mar
(70) |
Apr
(115) |
May
(66) |
Jun
(131) |
Jul
(70) |
Aug
(65) |
Sep
(66) |
Oct
(86) |
Nov
(197) |
Dec
(81) |
| 2013 |
Jan
(65) |
Feb
(48) |
Mar
(32) |
Apr
(68) |
May
(98) |
Jun
(59) |
Jul
(41) |
Aug
(52) |
Sep
(42) |
Oct
(37) |
Nov
(10) |
Dec
(27) |
| 2014 |
Jan
(61) |
Feb
(34) |
Mar
(30) |
Apr
(52) |
May
(45) |
Jun
(40) |
Jul
(28) |
Aug
(9) |
Sep
(39) |
Oct
(69) |
Nov
(55) |
Dec
(19) |
| 2015 |
Jan
(13) |
Feb
(21) |
Mar
(5) |
Apr
(14) |
May
(30) |
Jun
(51) |
Jul
(31) |
Aug
(12) |
Sep
(29) |
Oct
(15) |
Nov
(24) |
Dec
(16) |
| 2016 |
Jan
(62) |
Feb
(76) |
Mar
(30) |
Apr
(43) |
May
(46) |
Jun
(62) |
Jul
(21) |
Aug
(49) |
Sep
(67) |
Oct
(27) |
Nov
(26) |
Dec
(38) |
| 2017 |
Jan
(7) |
Feb
(12) |
Mar
(69) |
Apr
(59) |
May
(54) |
Jun
(40) |
Jul
(76) |
Aug
(82) |
Sep
(92) |
Oct
(51) |
Nov
(32) |
Dec
(30) |
| 2018 |
Jan
(22) |
Feb
(25) |
Mar
(34) |
Apr
(35) |
May
(37) |
Jun
(21) |
Jul
(69) |
Aug
(55) |
Sep
(17) |
Oct
(67) |
Nov
(9) |
Dec
(5) |
| 2019 |
Jan
(19) |
Feb
(12) |
Mar
(15) |
Apr
(19) |
May
|
Jun
(27) |
Jul
(27) |
Aug
(25) |
Sep
(25) |
Oct
(27) |
Nov
(10) |
Dec
(14) |
| 2020 |
Jan
(22) |
Feb
(20) |
Mar
(36) |
Apr
(40) |
May
(52) |
Jun
(35) |
Jul
(21) |
Aug
(32) |
Sep
(71) |
Oct
(27) |
Nov
(11) |
Dec
(16) |
| 2021 |
Jan
(16) |
Feb
(21) |
Mar
(21) |
Apr
(27) |
May
(17) |
Jun
|
Jul
(2) |
Aug
(22) |
Sep
(23) |
Oct
(7) |
Nov
(11) |
Dec
(28) |
| 2022 |
Jan
(23) |
Feb
(18) |
Mar
(9) |
Apr
(15) |
May
(15) |
Jun
(7) |
Jul
(8) |
Aug
(15) |
Sep
(1) |
Oct
|
Nov
(11) |
Dec
(10) |
| 2023 |
Jan
(14) |
Feb
(10) |
Mar
(11) |
Apr
(13) |
May
(2) |
Jun
(30) |
Jul
(1) |
Aug
(15) |
Sep
(13) |
Oct
(3) |
Nov
(25) |
Dec
(5) |
| 2024 |
Jan
(3) |
Feb
(10) |
Mar
(9) |
Apr
|
May
(1) |
Jun
(15) |
Jul
(7) |
Aug
(10) |
Sep
(3) |
Oct
(8) |
Nov
(6) |
Dec
(15) |
| 2025 |
Jan
(3) |
Feb
(1) |
Mar
(7) |
Apr
(5) |
May
(13) |
Jun
(16) |
Jul
(1) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Michael K. <mic...@ip...> - 2020-07-07 22:53:48
|
Thanks Lonnie. I will use that.
Regards
Michael Knill
On 7/7/20, 9:33 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Michael (AU),
As the other Michael mentioned, the "/usr/lib/ssl/cert.pem" contains the constantly updated ca-certificates on AstLinux, which would be better than you having to install you own cert file on every system.
Lonnie
> On Jul 7, 2020, at 2:56 AM, Michael Keuter <li...@mk...> wrote:
>
> Hi Michael,
>
> in my example on the Wiki I also had to use:
>
> --cacert "/usr/lib/ssl/cert.pem"
>
>> Am 07.07.2020 um 09:16 schrieb Michael Knill <mic...@ip...>:
>>
>> Hi Lonnie
>>
>> Looks like I have fixed the problem by using the --cacert option and using my wildcard CA Cert file.
>> Thanks for your help.
>>
>> Regards
>> Michael Knill
>>
>> On 7/7/20, 10:56 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>>
>> Michael,
>>
>> I tested with "curl -LI https://asia.queuemetrics-live.com/" and the certificate is valid to the base URL.
>>
>> Does the QueueMetrics have it's own network SSL stack and ca-certificates database ? If so, possibly their ca-certificates is out of date. AstLinux's ca-certificates work.
>>
>> I looked at the QueueMetrics uniloader, it appears to be java based, which would have its own SSL stack and ca-certificates.
>>
>> I would talk to the QueueMetrics folks. Maybe there is an update.
>>
>> Lonnie
>>
>>
>>> On Jul 6, 2020, at 7:39 PM, Michael Knill <mic...@ip...> wrote:
>>>
>>> Hi Group
>>>
>>> I'm connecting QueueMetrics Live to an Astlinux box and I'm getting the following error from uniloader:
>>> 2020/07/07 10:35:23 Errors in HTTP: [Post https://asia.queuemetrics-live.com/detlevs-au/jsonQLoaderApi.do: x509: certificate signed by unknown authority]
>>> 2020/07/07 10:35:23 [https://asia.queuemetrics-live.com/detlevs-au] Driver error: retrying in 400 ms
>>> 2020/07/07 10:35:23 Errors in HTTP: [Post https://asia.queuemetrics-live.com/detlevs-au/jsonQLoaderApi.do: x509: certificate signed by unknown authority]
>>> 2020/07/07 10:35:23 [https://asia.queuemetrics-live.com/detlevs-au] Driver error: retrying in 2000 ms
>>>
>>> It works fine when I use HTTP.
>>>
>>> Is there any way to fix this problem as I would much rather use HTTPS?
>>>
>>> Regards
>>> Michael Knill
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>
>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>
>>
>>
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>
>>
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
> Michael
>
> http://www.mksolutions.info
>
>
>
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Lonnie A. <li...@lo...> - 2020-07-07 11:32:41
|
Michael (AU), As the other Michael mentioned, the "/usr/lib/ssl/cert.pem" contains the constantly updated ca-certificates on AstLinux, which would be better than you having to install you own cert file on every system. Lonnie > On Jul 7, 2020, at 2:56 AM, Michael Keuter <li...@mk...> wrote: > > Hi Michael, > > in my example on the Wiki I also had to use: > > --cacert "/usr/lib/ssl/cert.pem" > >> Am 07.07.2020 um 09:16 schrieb Michael Knill <mic...@ip...>: >> >> Hi Lonnie >> >> Looks like I have fixed the problem by using the --cacert option and using my wildcard CA Cert file. >> Thanks for your help. >> >> Regards >> Michael Knill >> >> On 7/7/20, 10:56 am, "Lonnie Abelbeck" <li...@lo...> wrote: >> >> Michael, >> >> I tested with "curl -LI https://asia.queuemetrics-live.com/" and the certificate is valid to the base URL. >> >> Does the QueueMetrics have it's own network SSL stack and ca-certificates database ? If so, possibly their ca-certificates is out of date. AstLinux's ca-certificates work. >> >> I looked at the QueueMetrics uniloader, it appears to be java based, which would have its own SSL stack and ca-certificates. >> >> I would talk to the QueueMetrics folks. Maybe there is an update. >> >> Lonnie >> >> >>> On Jul 6, 2020, at 7:39 PM, Michael Knill <mic...@ip...> wrote: >>> >>> Hi Group >>> >>> I'm connecting QueueMetrics Live to an Astlinux box and I'm getting the following error from uniloader: >>> 2020/07/07 10:35:23 Errors in HTTP: [Post https://asia.queuemetrics-live.com/detlevs-au/jsonQLoaderApi.do: x509: certificate signed by unknown authority] >>> 2020/07/07 10:35:23 [https://asia.queuemetrics-live.com/detlevs-au] Driver error: retrying in 400 ms >>> 2020/07/07 10:35:23 Errors in HTTP: [Post https://asia.queuemetrics-live.com/detlevs-au/jsonQLoaderApi.do: x509: certificate signed by unknown authority] >>> 2020/07/07 10:35:23 [https://asia.queuemetrics-live.com/detlevs-au] Driver error: retrying in 2000 ms >>> >>> It works fine when I use HTTP. >>> >>> Is there any way to fix this problem as I would much rather use HTTPS? >>> >>> Regards >>> Michael Knill >>> _______________________________________________ >>> Astlinux-users mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>> >>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >> >> >> >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >> >> >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > Michael > > http://www.mksolutions.info > > > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Michael K. <mic...@ip...> - 2020-07-07 08:03:22
|
Doh. I missed that!
Regards
Michael Knill
On 7/7/20, 5:56 pm, "Michael Keuter" <li...@mk...> wrote:
Hi Michael,
in my example on the Wiki I also had to use:
--cacert "/usr/lib/ssl/cert.pem"
> Am 07.07.2020 um 09:16 schrieb Michael Knill <mic...@ip...>:
>
> Hi Lonnie
>
> Looks like I have fixed the problem by using the --cacert option and using my wildcard CA Cert file.
> Thanks for your help.
>
> Regards
> Michael Knill
>
> On 7/7/20, 10:56 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Michael,
>
> I tested with "curl -LI https://asia.queuemetrics-live.com/" and the certificate is valid to the base URL.
>
> Does the QueueMetrics have it's own network SSL stack and ca-certificates database ? If so, possibly their ca-certificates is out of date. AstLinux's ca-certificates work.
>
> I looked at the QueueMetrics uniloader, it appears to be java based, which would have its own SSL stack and ca-certificates.
>
> I would talk to the QueueMetrics folks. Maybe there is an update.
>
> Lonnie
>
>
>> On Jul 6, 2020, at 7:39 PM, Michael Knill <mic...@ip...> wrote:
>>
>> Hi Group
>>
>> I'm connecting QueueMetrics Live to an Astlinux box and I'm getting the following error from uniloader:
>> 2020/07/07 10:35:23 Errors in HTTP: [Post https://asia.queuemetrics-live.com/detlevs-au/jsonQLoaderApi.do: x509: certificate signed by unknown authority]
>> 2020/07/07 10:35:23 [https://asia.queuemetrics-live.com/detlevs-au] Driver error: retrying in 400 ms
>> 2020/07/07 10:35:23 Errors in HTTP: [Post https://asia.queuemetrics-live.com/detlevs-au/jsonQLoaderApi.do: x509: certificate signed by unknown authority]
>> 2020/07/07 10:35:23 [https://asia.queuemetrics-live.com/detlevs-au] Driver error: retrying in 2000 ms
>>
>> It works fine when I use HTTP.
>>
>> Is there any way to fix this problem as I would much rather use HTTPS?
>>
>> Regards
>> Michael Knill
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
Michael
http://www.mksolutions.info
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Michael K. <li...@mk...> - 2020-07-07 07:56:25
|
Hi Michael, in my example on the Wiki I also had to use: --cacert "/usr/lib/ssl/cert.pem" > Am 07.07.2020 um 09:16 schrieb Michael Knill <mic...@ip...>: > > Hi Lonnie > > Looks like I have fixed the problem by using the --cacert option and using my wildcard CA Cert file. > Thanks for your help. > > Regards > Michael Knill > > On 7/7/20, 10:56 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > Michael, > > I tested with "curl -LI https://asia.queuemetrics-live.com/" and the certificate is valid to the base URL. > > Does the QueueMetrics have it's own network SSL stack and ca-certificates database ? If so, possibly their ca-certificates is out of date. AstLinux's ca-certificates work. > > I looked at the QueueMetrics uniloader, it appears to be java based, which would have its own SSL stack and ca-certificates. > > I would talk to the QueueMetrics folks. Maybe there is an update. > > Lonnie > > >> On Jul 6, 2020, at 7:39 PM, Michael Knill <mic...@ip...> wrote: >> >> Hi Group >> >> I'm connecting QueueMetrics Live to an Astlinux box and I'm getting the following error from uniloader: >> 2020/07/07 10:35:23 Errors in HTTP: [Post https://asia.queuemetrics-live.com/detlevs-au/jsonQLoaderApi.do: x509: certificate signed by unknown authority] >> 2020/07/07 10:35:23 [https://asia.queuemetrics-live.com/detlevs-au] Driver error: retrying in 400 ms >> 2020/07/07 10:35:23 Errors in HTTP: [Post https://asia.queuemetrics-live.com/detlevs-au/jsonQLoaderApi.do: x509: certificate signed by unknown authority] >> 2020/07/07 10:35:23 [https://asia.queuemetrics-live.com/detlevs-au] Driver error: retrying in 2000 ms >> >> It works fine when I use HTTP. >> >> Is there any way to fix this problem as I would much rather use HTTPS? >> >> Regards >> Michael Knill >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... Michael http://www.mksolutions.info |
|
From: Michael K. <mic...@ip...> - 2020-07-07 07:17:19
|
Hi Lonnie
Looks like I have fixed the problem by using the --cacert option and using my wildcard CA Cert file.
Thanks for your help.
Regards
Michael Knill
On 7/7/20, 10:56 am, "Lonnie Abelbeck" <li...@lo...> wrote:
Michael,
I tested with "curl -LI https://asia.queuemetrics-live.com/" and the certificate is valid to the base URL.
Does the QueueMetrics have it's own network SSL stack and ca-certificates database ? If so, possibly their ca-certificates is out of date. AstLinux's ca-certificates work.
I looked at the QueueMetrics uniloader, it appears to be java based, which would have its own SSL stack and ca-certificates.
I would talk to the QueueMetrics folks. Maybe there is an update.
Lonnie
> On Jul 6, 2020, at 7:39 PM, Michael Knill <mic...@ip...> wrote:
>
> Hi Group
>
> I'm connecting QueueMetrics Live to an Astlinux box and I'm getting the following error from uniloader:
> 2020/07/07 10:35:23 Errors in HTTP: [Post https://asia.queuemetrics-live.com/detlevs-au/jsonQLoaderApi.do: x509: certificate signed by unknown authority]
> 2020/07/07 10:35:23 [https://asia.queuemetrics-live.com/detlevs-au] Driver error: retrying in 400 ms
> 2020/07/07 10:35:23 Errors in HTTP: [Post https://asia.queuemetrics-live.com/detlevs-au/jsonQLoaderApi.do: x509: certificate signed by unknown authority]
> 2020/07/07 10:35:23 [https://asia.queuemetrics-live.com/detlevs-au] Driver error: retrying in 2000 ms
>
> It works fine when I use HTTP.
>
> Is there any way to fix this problem as I would much rather use HTTPS?
>
> Regards
> Michael Knill
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Michael K. <mic...@ip...> - 2020-07-07 01:04:35
|
Thanks Lonnie. I will.
Regards
Michael Knill
On 7/7/20, 10:56 am, "Lonnie Abelbeck" <li...@lo...> wrote:
Michael,
I tested with "curl -LI https://asia.queuemetrics-live.com/" and the certificate is valid to the base URL.
Does the QueueMetrics have it's own network SSL stack and ca-certificates database ? If so, possibly their ca-certificates is out of date. AstLinux's ca-certificates work.
I looked at the QueueMetrics uniloader, it appears to be java based, which would have its own SSL stack and ca-certificates.
I would talk to the QueueMetrics folks. Maybe there is an update.
Lonnie
> On Jul 6, 2020, at 7:39 PM, Michael Knill <mic...@ip...> wrote:
>
> Hi Group
>
> I'm connecting QueueMetrics Live to an Astlinux box and I'm getting the following error from uniloader:
> 2020/07/07 10:35:23 Errors in HTTP: [Post https://asia.queuemetrics-live.com/detlevs-au/jsonQLoaderApi.do: x509: certificate signed by unknown authority]
> 2020/07/07 10:35:23 [https://asia.queuemetrics-live.com/detlevs-au] Driver error: retrying in 400 ms
> 2020/07/07 10:35:23 Errors in HTTP: [Post https://asia.queuemetrics-live.com/detlevs-au/jsonQLoaderApi.do: x509: certificate signed by unknown authority]
> 2020/07/07 10:35:23 [https://asia.queuemetrics-live.com/detlevs-au] Driver error: retrying in 2000 ms
>
> It works fine when I use HTTP.
>
> Is there any way to fix this problem as I would much rather use HTTPS?
>
> Regards
> Michael Knill
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Lonnie A. <li...@lo...> - 2020-07-07 00:56:07
|
Michael, I tested with "curl -LI https://asia.queuemetrics-live.com/" and the certificate is valid to the base URL. Does the QueueMetrics have it's own network SSL stack and ca-certificates database ? If so, possibly their ca-certificates is out of date. AstLinux's ca-certificates work. I looked at the QueueMetrics uniloader, it appears to be java based, which would have its own SSL stack and ca-certificates. I would talk to the QueueMetrics folks. Maybe there is an update. Lonnie > On Jul 6, 2020, at 7:39 PM, Michael Knill <mic...@ip...> wrote: > > Hi Group > > I'm connecting QueueMetrics Live to an Astlinux box and I'm getting the following error from uniloader: > 2020/07/07 10:35:23 Errors in HTTP: [Post https://asia.queuemetrics-live.com/detlevs-au/jsonQLoaderApi.do: x509: certificate signed by unknown authority] > 2020/07/07 10:35:23 [https://asia.queuemetrics-live.com/detlevs-au] Driver error: retrying in 400 ms > 2020/07/07 10:35:23 Errors in HTTP: [Post https://asia.queuemetrics-live.com/detlevs-au/jsonQLoaderApi.do: x509: certificate signed by unknown authority] > 2020/07/07 10:35:23 [https://asia.queuemetrics-live.com/detlevs-au] Driver error: retrying in 2000 ms > > It works fine when I use HTTP. > > Is there any way to fix this problem as I would much rather use HTTPS? > > Regards > Michael Knill > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Michael K. <mic...@ip...> - 2020-07-07 00:39:41
|
Hi Group I'm connecting QueueMetrics Live to an Astlinux box and I'm getting the following error from uniloader: 2020/07/07 10:35:23 Errors in HTTP: [Post https://asia.queuemetrics-live.com/detlevs-au/jsonQLoaderApi.do: x509: certificate signed by unknown authority] 2020/07/07 10:35:23 [https://asia.queuemetrics-live.com/detlevs-au] Driver error: retrying in 400 ms 2020/07/07 10:35:23 Errors in HTTP: [Post https://asia.queuemetrics-live.com/detlevs-au/jsonQLoaderApi.do: x509: certificate signed by unknown authority] 2020/07/07 10:35:23 [https://asia.queuemetrics-live.com/detlevs-au] Driver error: retrying in 2000 ms It works fine when I use HTTP. Is there any way to fix this problem as I would much rather use HTTPS? Regards Michael Knill |
|
From: Lonnie A. <li...@lo...> - 2020-07-02 12:26:40
|
I really like the coreboot BIOS support. In my mind if a value added reseller of China-boxes takes the time/money to add coreboot BIOS support, they are in it for the long haul, not just a random reseller. Plus coreboot just works (if done correctly), no need to first navigate the AMI BIOS over a video console to set always power on, set Legacy boot, enable serial console redirection, etc. . Lonnie > On Jul 1, 2020, at 5:11 PM, Michael Knill <mic...@ip...> wrote: > > Looks nice. I like the fact that WAN/LAN ports are labelled and especially like the COM port! > Will be a little pricey though compared with the Qotom but may be worth it. > > Regards > Michael Knill > > On 2/7/20, 5:14 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > A newly released hardware description and configuration has been added to the AstLinux documentation: > > Protectli FW4B Quad Core Fanless Celeron J3160 > https://doc.astlinux-project.org/userdoc:board_protectli_fw4b > > I personally purchased a Protectli FW4B (No RAM, No SSD, coreboot BIOS) direct from Protectli, here in the US: > > FW4B – 4 Port Intel J3160 > https://protectli.com/product/fw4b/ > > $219.00 USD -- Protectli FW4B (coreboot BIOS) Celeron J3160 > > $ 7.00 USD -- Shipping (2-days from California) > > I have plenty of mSATA SSDs and SO-DIMM (DDR3L-1600, 1.35v) laying around to make it a system. > > If you don't live in the US, Protectli ships worldwide, for a price. > > The Protectli FW4B offers: > -- Small fanless case, 4.5 x 4.3 inch (115 x 108 mm) footprint (NUC-size) > -- Intel Celeron CPU J3160 @ 1.60GHz (burst to 2.24 GHz enabled) > -- Open source coreboot BIOS (recommended) > -- 4x Intel i210 NICs > -- Supports mSATA SSD > -- Supports Serial (RJ45) or Video (HDMI) Console > -- Piezo speaker > -- Power button > > No surprise, line-speed 1Gbps network routing. > > Additionally, near line-speed WireGuard VPN endpoint with ~40% CPU headroom remaining. > > This Protectli FW4B appliance makes a fine AstLinux box. > > The Good: > > * Great performance in a small footprint. slightly faster than the Qotom Q190G4N. > > * Protectli in-house QA, "Every device goes through rigorous testing before it leaves our facilities" > > * Open source coreboot BIOS > > * Protectli tech support was very responsive, spoke with Brent (Founder & CEO) and Luke. > > The Bad: > > * The only minor nit I discovered was at boot where a stray "l<CR><NL>" character sequence coreboot (sometimes) spits out over a serial connection, messing-up the boot.msg text. I informed Protectli about it. > > > The Protectli FW4B appliance has run solidly for several days, further updates as needed. > > Lonnie > > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Michael K. <mic...@ip...> - 2020-07-01 22:11:22
|
Looks nice. I like the fact that WAN/LAN ports are labelled and especially like the COM port!
Will be a little pricey though compared with the Qotom but may be worth it.
Regards
Michael Knill
On 2/7/20, 5:14 am, "Lonnie Abelbeck" <li...@lo...> wrote:
A newly released hardware description and configuration has been added to the AstLinux documentation:
Protectli FW4B Quad Core Fanless Celeron J3160
https://doc.astlinux-project.org/userdoc:board_protectli_fw4b
I personally purchased a Protectli FW4B (No RAM, No SSD, coreboot BIOS) direct from Protectli, here in the US:
FW4B – 4 Port Intel J3160
https://protectli.com/product/fw4b/
$219.00 USD -- Protectli FW4B (coreboot BIOS) Celeron J3160
$ 7.00 USD -- Shipping (2-days from California)
I have plenty of mSATA SSDs and SO-DIMM (DDR3L-1600, 1.35v) laying around to make it a system.
If you don't live in the US, Protectli ships worldwide, for a price.
The Protectli FW4B offers:
-- Small fanless case, 4.5 x 4.3 inch (115 x 108 mm) footprint (NUC-size)
-- Intel Celeron CPU J3160 @ 1.60GHz (burst to 2.24 GHz enabled)
-- Open source coreboot BIOS (recommended)
-- 4x Intel i210 NICs
-- Supports mSATA SSD
-- Supports Serial (RJ45) or Video (HDMI) Console
-- Piezo speaker
-- Power button
No surprise, line-speed 1Gbps network routing.
Additionally, near line-speed WireGuard VPN endpoint with ~40% CPU headroom remaining.
This Protectli FW4B appliance makes a fine AstLinux box.
The Good:
* Great performance in a small footprint. slightly faster than the Qotom Q190G4N.
* Protectli in-house QA, "Every device goes through rigorous testing before it leaves our facilities"
* Open source coreboot BIOS
* Protectli tech support was very responsive, spoke with Brent (Founder & CEO) and Luke.
The Bad:
* The only minor nit I discovered was at boot where a stray "l<CR><NL>" character sequence coreboot (sometimes) spits out over a serial connection, messing-up the boot.msg text. I informed Protectli about it.
The Protectli FW4B appliance has run solidly for several days, further updates as needed.
Lonnie
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Lonnie A. <li...@lo...> - 2020-07-01 19:14:10
|
A newly released hardware description and configuration has been added to the AstLinux documentation: Protectli FW4B Quad Core Fanless Celeron J3160 https://doc.astlinux-project.org/userdoc:board_protectli_fw4b I personally purchased a Protectli FW4B (No RAM, No SSD, coreboot BIOS) direct from Protectli, here in the US: FW4B – 4 Port Intel J3160 https://protectli.com/product/fw4b/ $219.00 USD -- Protectli FW4B (coreboot BIOS) Celeron J3160 $ 7.00 USD -- Shipping (2-days from California) I have plenty of mSATA SSDs and SO-DIMM (DDR3L-1600, 1.35v) laying around to make it a system. If you don't live in the US, Protectli ships worldwide, for a price. The Protectli FW4B offers: -- Small fanless case, 4.5 x 4.3 inch (115 x 108 mm) footprint (NUC-size) -- Intel Celeron CPU J3160 @ 1.60GHz (burst to 2.24 GHz enabled) -- Open source coreboot BIOS (recommended) -- 4x Intel i210 NICs -- Supports mSATA SSD -- Supports Serial (RJ45) or Video (HDMI) Console -- Piezo speaker -- Power button No surprise, line-speed 1Gbps network routing. Additionally, near line-speed WireGuard VPN endpoint with ~40% CPU headroom remaining. This Protectli FW4B appliance makes a fine AstLinux box. The Good: * Great performance in a small footprint. slightly faster than the Qotom Q190G4N. * Protectli in-house QA, "Every device goes through rigorous testing before it leaves our facilities" * Open source coreboot BIOS * Protectli tech support was very responsive, spoke with Brent (Founder & CEO) and Luke. The Bad: * The only minor nit I discovered was at boot where a stray "l<CR><NL>" character sequence coreboot (sometimes) spits out over a serial connection, messing-up the boot.msg text. I informed Protectli about it. The Protectli FW4B appliance has run solidly for several days, further updates as needed. Lonnie |
|
From: Michael K. <mic...@ip...> - 2020-06-26 06:59:33
|
Obviously I'm letting my first experience with this provider using a beta version of Mikrotik Router OS affect my troubleshooting methodology.
I didn't realise that I was getting lots of PPPoE dropouts on the link I'm having problems with and using Astlinux on my other service works fine so its not an MTU/MSS issue.
And I realised in my testing that I was not taking the overhead into account.
The PPPoE MTU setting is 1492 which includes the 28 Byte MTU header. So 1492-28=1464 which is what I was getting with the ping test which is the payload only!
Anyway thanks for your help Lonnie. Sorry to stuff you around.
Regards
Michael Knill
On 26/6/20, 12:40 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Or in the same /tmp/etc/ppp/pppoe.conf file add:
--
MTU=1452
MRU=1452
--
and leave PPPD_EXTRA alone.
Lonnie
> On Jun 25, 2020, at 9:19 PM, Lonnie Abelbeck <li...@lo...> wrote:
>
> Hi Michael,
>
> Looking at the code, to make the MTU stick would require some script changes, but you could test...
>
> After boot edit /tmp/etc/ppp/pppoe.conf
>
> You should see something like:
>
> PPPD_EXTRA="persist maxfail 0"
>
> You should be able to add pppd options to that, something like:
>
> PPPD_EXTRA="persist maxfail 0 mtu 1452 mru 1452"
>
> (Or try 1460)
>
> Then restart PPPoE.
>
> (Note 1452 is 1412+40)
>
> If that works we could add a rc.conf variable to add the mtu/mru options.
>
> Lonnie
>
>
>
>
>> On Jun 25, 2020, at 8:56 PM, Michael Knill <mic...@ip...> wrote:
>>
>> Thanks Lonnie
>>
>> Hmm MSS should be fine then assuming it is working.
>> I will do some more testing on the new service in my home office. Unfortunately the one not working is a building site and its way too cold at the moment.
>>
>> Regards
>> Michael Knill
>>
>> On 26/6/20, 11:45 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>>
>>
>>
>>> On Jun 25, 2020, at 8:05 PM, Michael Knill <mic...@ip...> wrote:
>>>
>>> Hi Group
>>>
>>> I have changed my internet provider and I am having connectivity problems to some sites on Astlinux.
>>> I am fairly certain that it is an MTU/MSS issue as I have fixed it on my Mikrotik router by adjusting this value.
>>> Funny that I'm having problems with this provider but not on my previous provider. Both are using PPPoE and I tested that the maximum MTU for both is 1464 e.g.
>>>
>>> 3035-JSainsbury-CM1 kd # fping -M -b 1465 12000.ipcaccess.net
>>> 12000.ipcaccess.net: error while sending ping: Message too long
>>> 3035-JSainsbury-CM1 kd # fping -M -b 1464 12000.ipcaccess.net
>>> 12000.ipcaccess.net is alive
>>>
>>> 3076-VisionCF-CM1 kd # fping -M -b 1465 12000.ipcaccess.net
>>> 12000.ipcaccess.net: error while sending ping: Message too long
>>> 3076-VisionCF-CM1 kd # fping -M -b 1464 12000.ipcaccess.net
>>> 12000.ipcaccess.net is alive
>>>
>>> Maybe my new provider is not allowing fragmentation?
>>>
>>> Anyway just wondering how I fix this problem. Do I just set MTU using IFMTU in user.conf? E.g.
>>> IFMTU=ppp0:1460
>>
>> No, per the /stat/etc/rc.conf file:
>> --
>> ## MTU Changes
>> ## If you need to specifically set the MTU for a given interface, do that here.
>> ## You can try to set the MTU for any valid type of interface. With ethernet it
>> ## works most of the time. Everything else, caveat emptor...
>> ## If you are using PPPoE don't worry. We automatically handle those MTU issues
>> #IFMTU="eth2.41:1496 eth0:1492"
>> --
>>
>> I don't see any configuration for the PPPoE MTU, though there may be a way.
>>
>> What is the local MTU set to by default ?
>> --
>> ip link show dev ppp0
>> --
>>
>> After the PPPoE link is up you could try to change it:
>> --
>> ip link set dev ppp0 mtu 1460
>> --
>>
>> If that works we can try to figure out how to make that stick.
>>
>>
>>> Can I set the TCP MSS anywhere?
>>
>> This is the current value hardcoded in the PPPoE config:
>>
>> CLAMPMSS=1412
>> -- PPPoE docs --
>> CLAMPMSS
>> The value at which to "clamp" the advertised MSS for TCP sessions. The default of 1412 should be fine.
>> --
>>
>> Lonnie
>>
>>
>>
>>
>>
>>>
>>> Regards
>>> Michael Knill
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>
>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>
>>
>>
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>
>>
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Lonnie A. <li...@lo...> - 2020-06-26 02:40:19
|
Or in the same /tmp/etc/ppp/pppoe.conf file add: -- MTU=1452 MRU=1452 -- and leave PPPD_EXTRA alone. Lonnie > On Jun 25, 2020, at 9:19 PM, Lonnie Abelbeck <li...@lo...> wrote: > > Hi Michael, > > Looking at the code, to make the MTU stick would require some script changes, but you could test... > > After boot edit /tmp/etc/ppp/pppoe.conf > > You should see something like: > > PPPD_EXTRA="persist maxfail 0" > > You should be able to add pppd options to that, something like: > > PPPD_EXTRA="persist maxfail 0 mtu 1452 mru 1452" > > (Or try 1460) > > Then restart PPPoE. > > (Note 1452 is 1412+40) > > If that works we could add a rc.conf variable to add the mtu/mru options. > > Lonnie > > > > >> On Jun 25, 2020, at 8:56 PM, Michael Knill <mic...@ip...> wrote: >> >> Thanks Lonnie >> >> Hmm MSS should be fine then assuming it is working. >> I will do some more testing on the new service in my home office. Unfortunately the one not working is a building site and its way too cold at the moment. >> >> Regards >> Michael Knill >> >> On 26/6/20, 11:45 am, "Lonnie Abelbeck" <li...@lo...> wrote: >> >> >> >>> On Jun 25, 2020, at 8:05 PM, Michael Knill <mic...@ip...> wrote: >>> >>> Hi Group >>> >>> I have changed my internet provider and I am having connectivity problems to some sites on Astlinux. >>> I am fairly certain that it is an MTU/MSS issue as I have fixed it on my Mikrotik router by adjusting this value. >>> Funny that I'm having problems with this provider but not on my previous provider. Both are using PPPoE and I tested that the maximum MTU for both is 1464 e.g. >>> >>> 3035-JSainsbury-CM1 kd # fping -M -b 1465 12000.ipcaccess.net >>> 12000.ipcaccess.net: error while sending ping: Message too long >>> 3035-JSainsbury-CM1 kd # fping -M -b 1464 12000.ipcaccess.net >>> 12000.ipcaccess.net is alive >>> >>> 3076-VisionCF-CM1 kd # fping -M -b 1465 12000.ipcaccess.net >>> 12000.ipcaccess.net: error while sending ping: Message too long >>> 3076-VisionCF-CM1 kd # fping -M -b 1464 12000.ipcaccess.net >>> 12000.ipcaccess.net is alive >>> >>> Maybe my new provider is not allowing fragmentation? >>> >>> Anyway just wondering how I fix this problem. Do I just set MTU using IFMTU in user.conf? E.g. >>> IFMTU=ppp0:1460 >> >> No, per the /stat/etc/rc.conf file: >> -- >> ## MTU Changes >> ## If you need to specifically set the MTU for a given interface, do that here. >> ## You can try to set the MTU for any valid type of interface. With ethernet it >> ## works most of the time. Everything else, caveat emptor... >> ## If you are using PPPoE don't worry. We automatically handle those MTU issues >> #IFMTU="eth2.41:1496 eth0:1492" >> -- >> >> I don't see any configuration for the PPPoE MTU, though there may be a way. >> >> What is the local MTU set to by default ? >> -- >> ip link show dev ppp0 >> -- >> >> After the PPPoE link is up you could try to change it: >> -- >> ip link set dev ppp0 mtu 1460 >> -- >> >> If that works we can try to figure out how to make that stick. >> >> >>> Can I set the TCP MSS anywhere? >> >> This is the current value hardcoded in the PPPoE config: >> >> CLAMPMSS=1412 >> -- PPPoE docs -- >> CLAMPMSS >> The value at which to "clamp" the advertised MSS for TCP sessions. The default of 1412 should be fine. >> -- >> >> Lonnie >> >> >> >> >> >>> >>> Regards >>> Michael Knill >>> _______________________________________________ >>> Astlinux-users mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>> >>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >> >> >> >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >> >> >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Michael K. <mic...@ip...> - 2020-06-26 02:28:33
|
Thanks Lonnie
I will test it out.
Regards
Michael Knill
On 26/6/20, 12:20 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Michael,
Looking at the code, to make the MTU stick would require some script changes, but you could test...
After boot edit /tmp/etc/ppp/pppoe.conf
You should see something like:
PPPD_EXTRA="persist maxfail 0"
You should be able to add pppd options to that, something like:
PPPD_EXTRA="persist maxfail 0 mtu 1452 mru 1452"
(Or try 1460)
Then restart PPPoE.
(Note 1452 is 1412+40)
If that works we could add a rc.conf variable to add the mtu/mru options.
Lonnie
> On Jun 25, 2020, at 8:56 PM, Michael Knill <mic...@ip...> wrote:
>
> Thanks Lonnie
>
> Hmm MSS should be fine then assuming it is working.
> I will do some more testing on the new service in my home office. Unfortunately the one not working is a building site and its way too cold at the moment.
>
> Regards
> Michael Knill
>
> On 26/6/20, 11:45 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>
>
>
>> On Jun 25, 2020, at 8:05 PM, Michael Knill <mic...@ip...> wrote:
>>
>> Hi Group
>>
>> I have changed my internet provider and I am having connectivity problems to some sites on Astlinux.
>> I am fairly certain that it is an MTU/MSS issue as I have fixed it on my Mikrotik router by adjusting this value.
>> Funny that I'm having problems with this provider but not on my previous provider. Both are using PPPoE and I tested that the maximum MTU for both is 1464 e.g.
>>
>> 3035-JSainsbury-CM1 kd # fping -M -b 1465 12000.ipcaccess.net
>> 12000.ipcaccess.net: error while sending ping: Message too long
>> 3035-JSainsbury-CM1 kd # fping -M -b 1464 12000.ipcaccess.net
>> 12000.ipcaccess.net is alive
>>
>> 3076-VisionCF-CM1 kd # fping -M -b 1465 12000.ipcaccess.net
>> 12000.ipcaccess.net: error while sending ping: Message too long
>> 3076-VisionCF-CM1 kd # fping -M -b 1464 12000.ipcaccess.net
>> 12000.ipcaccess.net is alive
>>
>> Maybe my new provider is not allowing fragmentation?
>>
>> Anyway just wondering how I fix this problem. Do I just set MTU using IFMTU in user.conf? E.g.
>> IFMTU=ppp0:1460
>
> No, per the /stat/etc/rc.conf file:
> --
> ## MTU Changes
> ## If you need to specifically set the MTU for a given interface, do that here.
> ## You can try to set the MTU for any valid type of interface. With ethernet it
> ## works most of the time. Everything else, caveat emptor...
> ## If you are using PPPoE don't worry. We automatically handle those MTU issues
> #IFMTU="eth2.41:1496 eth0:1492"
> --
>
> I don't see any configuration for the PPPoE MTU, though there may be a way.
>
> What is the local MTU set to by default ?
> --
> ip link show dev ppp0
> --
>
> After the PPPoE link is up you could try to change it:
> --
> ip link set dev ppp0 mtu 1460
> --
>
> If that works we can try to figure out how to make that stick.
>
>
>> Can I set the TCP MSS anywhere?
>
> This is the current value hardcoded in the PPPoE config:
>
> CLAMPMSS=1412
> -- PPPoE docs --
> CLAMPMSS
> The value at which to "clamp" the advertised MSS for TCP sessions. The default of 1412 should be fine.
> --
>
> Lonnie
>
>
>
>
>
>>
>> Regards
>> Michael Knill
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Lonnie A. <li...@lo...> - 2020-06-26 02:20:05
|
Hi Michael, Looking at the code, to make the MTU stick would require some script changes, but you could test... After boot edit /tmp/etc/ppp/pppoe.conf You should see something like: PPPD_EXTRA="persist maxfail 0" You should be able to add pppd options to that, something like: PPPD_EXTRA="persist maxfail 0 mtu 1452 mru 1452" (Or try 1460) Then restart PPPoE. (Note 1452 is 1412+40) If that works we could add a rc.conf variable to add the mtu/mru options. Lonnie > On Jun 25, 2020, at 8:56 PM, Michael Knill <mic...@ip...> wrote: > > Thanks Lonnie > > Hmm MSS should be fine then assuming it is working. > I will do some more testing on the new service in my home office. Unfortunately the one not working is a building site and its way too cold at the moment. > > Regards > Michael Knill > > On 26/6/20, 11:45 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > > >> On Jun 25, 2020, at 8:05 PM, Michael Knill <mic...@ip...> wrote: >> >> Hi Group >> >> I have changed my internet provider and I am having connectivity problems to some sites on Astlinux. >> I am fairly certain that it is an MTU/MSS issue as I have fixed it on my Mikrotik router by adjusting this value. >> Funny that I'm having problems with this provider but not on my previous provider. Both are using PPPoE and I tested that the maximum MTU for both is 1464 e.g. >> >> 3035-JSainsbury-CM1 kd # fping -M -b 1465 12000.ipcaccess.net >> 12000.ipcaccess.net: error while sending ping: Message too long >> 3035-JSainsbury-CM1 kd # fping -M -b 1464 12000.ipcaccess.net >> 12000.ipcaccess.net is alive >> >> 3076-VisionCF-CM1 kd # fping -M -b 1465 12000.ipcaccess.net >> 12000.ipcaccess.net: error while sending ping: Message too long >> 3076-VisionCF-CM1 kd # fping -M -b 1464 12000.ipcaccess.net >> 12000.ipcaccess.net is alive >> >> Maybe my new provider is not allowing fragmentation? >> >> Anyway just wondering how I fix this problem. Do I just set MTU using IFMTU in user.conf? E.g. >> IFMTU=ppp0:1460 > > No, per the /stat/etc/rc.conf file: > -- > ## MTU Changes > ## If you need to specifically set the MTU for a given interface, do that here. > ## You can try to set the MTU for any valid type of interface. With ethernet it > ## works most of the time. Everything else, caveat emptor... > ## If you are using PPPoE don't worry. We automatically handle those MTU issues > #IFMTU="eth2.41:1496 eth0:1492" > -- > > I don't see any configuration for the PPPoE MTU, though there may be a way. > > What is the local MTU set to by default ? > -- > ip link show dev ppp0 > -- > > After the PPPoE link is up you could try to change it: > -- > ip link set dev ppp0 mtu 1460 > -- > > If that works we can try to figure out how to make that stick. > > >> Can I set the TCP MSS anywhere? > > This is the current value hardcoded in the PPPoE config: > > CLAMPMSS=1412 > -- PPPoE docs -- > CLAMPMSS > The value at which to "clamp" the advertised MSS for TCP sessions. The default of 1412 should be fine. > -- > > Lonnie > > > > > >> >> Regards >> Michael Knill >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Michael K. <mic...@ip...> - 2020-06-26 01:56:40
|
Thanks Lonnie
Hmm MSS should be fine then assuming it is working.
I will do some more testing on the new service in my home office. Unfortunately the one not working is a building site and its way too cold at the moment.
Regards
Michael Knill
On 26/6/20, 11:45 am, "Lonnie Abelbeck" <li...@lo...> wrote:
> On Jun 25, 2020, at 8:05 PM, Michael Knill <mic...@ip...> wrote:
>
> Hi Group
>
> I have changed my internet provider and I am having connectivity problems to some sites on Astlinux.
> I am fairly certain that it is an MTU/MSS issue as I have fixed it on my Mikrotik router by adjusting this value.
> Funny that I'm having problems with this provider but not on my previous provider. Both are using PPPoE and I tested that the maximum MTU for both is 1464 e.g.
>
> 3035-JSainsbury-CM1 kd # fping -M -b 1465 12000.ipcaccess.net
> 12000.ipcaccess.net: error while sending ping: Message too long
> 3035-JSainsbury-CM1 kd # fping -M -b 1464 12000.ipcaccess.net
> 12000.ipcaccess.net is alive
>
> 3076-VisionCF-CM1 kd # fping -M -b 1465 12000.ipcaccess.net
> 12000.ipcaccess.net: error while sending ping: Message too long
> 3076-VisionCF-CM1 kd # fping -M -b 1464 12000.ipcaccess.net
> 12000.ipcaccess.net is alive
>
> Maybe my new provider is not allowing fragmentation?
>
> Anyway just wondering how I fix this problem. Do I just set MTU using IFMTU in user.conf? E.g.
> IFMTU=ppp0:1460
No, per the /stat/etc/rc.conf file:
--
## MTU Changes
## If you need to specifically set the MTU for a given interface, do that here.
## You can try to set the MTU for any valid type of interface. With ethernet it
## works most of the time. Everything else, caveat emptor...
## If you are using PPPoE don't worry. We automatically handle those MTU issues
#IFMTU="eth2.41:1496 eth0:1492"
--
I don't see any configuration for the PPPoE MTU, though there may be a way.
What is the local MTU set to by default ?
--
ip link show dev ppp0
--
After the PPPoE link is up you could try to change it:
--
ip link set dev ppp0 mtu 1460
--
If that works we can try to figure out how to make that stick.
> Can I set the TCP MSS anywhere?
This is the current value hardcoded in the PPPoE config:
CLAMPMSS=1412
-- PPPoE docs --
CLAMPMSS
The value at which to "clamp" the advertised MSS for TCP sessions. The default of 1412 should be fine.
--
Lonnie
>
> Regards
> Michael Knill
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Lonnie A. <li...@lo...> - 2020-06-26 01:44:47
|
> On Jun 25, 2020, at 8:05 PM, Michael Knill <mic...@ip...> wrote: > > Hi Group > > I have changed my internet provider and I am having connectivity problems to some sites on Astlinux. > I am fairly certain that it is an MTU/MSS issue as I have fixed it on my Mikrotik router by adjusting this value. > Funny that I'm having problems with this provider but not on my previous provider. Both are using PPPoE and I tested that the maximum MTU for both is 1464 e.g. > > 3035-JSainsbury-CM1 kd # fping -M -b 1465 12000.ipcaccess.net > 12000.ipcaccess.net: error while sending ping: Message too long > 3035-JSainsbury-CM1 kd # fping -M -b 1464 12000.ipcaccess.net > 12000.ipcaccess.net is alive > > 3076-VisionCF-CM1 kd # fping -M -b 1465 12000.ipcaccess.net > 12000.ipcaccess.net: error while sending ping: Message too long > 3076-VisionCF-CM1 kd # fping -M -b 1464 12000.ipcaccess.net > 12000.ipcaccess.net is alive > > Maybe my new provider is not allowing fragmentation? > > Anyway just wondering how I fix this problem. Do I just set MTU using IFMTU in user.conf? E.g. > IFMTU=ppp0:1460 No, per the /stat/etc/rc.conf file: -- ## MTU Changes ## If you need to specifically set the MTU for a given interface, do that here. ## You can try to set the MTU for any valid type of interface. With ethernet it ## works most of the time. Everything else, caveat emptor... ## If you are using PPPoE don't worry. We automatically handle those MTU issues #IFMTU="eth2.41:1496 eth0:1492" -- I don't see any configuration for the PPPoE MTU, though there may be a way. What is the local MTU set to by default ? -- ip link show dev ppp0 -- After the PPPoE link is up you could try to change it: -- ip link set dev ppp0 mtu 1460 -- If that works we can try to figure out how to make that stick. > Can I set the TCP MSS anywhere? This is the current value hardcoded in the PPPoE config: CLAMPMSS=1412 -- PPPoE docs -- CLAMPMSS The value at which to "clamp" the advertised MSS for TCP sessions. The default of 1412 should be fine. -- Lonnie > > Regards > Michael Knill > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Michael K. <mic...@ip...> - 2020-06-26 01:06:07
|
Hi Group I have changed my internet provider and I am having connectivity problems to some sites on Astlinux. I am fairly certain that it is an MTU/MSS issue as I have fixed it on my Mikrotik router by adjusting this value. Funny that I'm having problems with this provider but not on my previous provider. Both are using PPPoE and I tested that the maximum MTU for both is 1464 e.g. 3035-JSainsbury-CM1 kd # fping -M -b 1465 12000.ipcaccess.net 12000.ipcaccess.net: error while sending ping: Message too long 3035-JSainsbury-CM1 kd # fping -M -b 1464 12000.ipcaccess.net 12000.ipcaccess.net is alive 3076-VisionCF-CM1 kd # fping -M -b 1465 12000.ipcaccess.net 12000.ipcaccess.net: error while sending ping: Message too long 3076-VisionCF-CM1 kd # fping -M -b 1464 12000.ipcaccess.net 12000.ipcaccess.net is alive Maybe my new provider is not allowing fragmentation? Anyway just wondering how I fix this problem. Do I just set MTU using IFMTU in user.conf? E.g. IFMTU=ppp0:1460 Can I set the TCP MSS anywhere? Regards Michael Knill |
|
From: Nedeljko G. <ne...@gm...> - 2020-06-18 14:45:08
|
O. k. thanks, I will try
Beste Grüsse
Nedi
Am 18. Juni 2020, 16:43, um 16:43, Michael Keuter <li...@mk...> schrieb:
>I mean the c option only for the groupcall.
>
>Sent from a mobile device.
>
>Michael Keuter
>
>> Am 18.06.2020 um 16:31 schrieb nedi <ne...@gm...>:
>>
>> Michael do you mean c in dialpilan everywere or only where I dial
>all extension together?
>>
>>> Am 16.06.2020 um 00:11 schrieb The Cadillac Kid via Astlinux-users
><ast...@li...>:
>>>
>>> I didnt think about dial options..
>>>
>>> this is my Dial command
>>>
>>> exten =
>s,n,Dial(SIP/${receiver}${ARG5},${fbnatimer},rIM(answerme,${receiver},${origuniqueid},${cidoriginate}))
>>>
>>> im not using 'c' in it the 'r' in it pretty much means that 180 will
>be sent back to the originating phone no matter what. I had to use that
>as we had some older analog FXS gateways that refused to send ringback
>>>
>>> as for the config I sent its meant for a D700 series.. all of our
>snoms in the field are 700s.
>>>
>>>
>>> On Monday, June 15, 2020, 4:26:41 PM EDT, Michael Keuter
><li...@mk...> wrote:
>>>
>>>
>>> Have you tried in Asterisk the option „c“ of the „dial“ command?
>>>
>>> Sent from a mobile device.
>>>
>>> Michael Keuter
>>>
>>>>> Am 15.06.2020 um 22:21 schrieb nedi <ne...@gm...>:
>>>>>
>>>>
>>>
>>> Thanks , I will try tomorow.
>>> Regards nedi
>>>
>>>> Am 15.06.2020 um 22:16 schrieb The Cadillac Kid via Astlinux-users
><ast...@li...>:
>>>>
>>>> hit send too quick..
>>>>
>>>> this is the SIP sent back to it..
>>>>
>>>> CANCEL sip:5051@172.16.9.2:54836;line=up7wg15k SIP/2.0
>>>> Via: SIP/2.0/UDP 172.16.8.2:5060;branch=z9hG4bK21641ecc
>>>> Max-Forwards: 70
>>>> From: "3200" <sip:3200@172.16.8.2>;tag=as73a14520
>>>> To: <sip:5051@172.16.9.2:54836;line=up7wg15k>
>>>> Call-ID: 328a1eaf23fc726f695258ef65aa2e51@172.16.8.2:5060
>>>> CSeq: 102 CANCEL
>>>> User-Agent: Asterisk PBX 11.20.0
>>>> Reason: SIP;cause=200;text="Call completed elsewhere"
>>>> Content-Length: 0
>>>>
>>>>
>>>> my call was 3200 dials a ring group with 5002 and 5051(snom), 5002
>answers the phone and 5051 shows answered elsewhere with no missed call
>
>>>>
>>>> On Monday, June 15, 2020, 3:54:19 PM EDT, nedi <ne...@gm...> wrote:
>>>>
>>>>
>>>> The phone showing message "call completed elsewhere" on the screen
> coming but missed call is still there on all phones.
>>>> Nedi
>>>>
>>>>> Am 15.06.2020 um 21:45 schrieb The Cadillac Kid via Astlinux-users
><ast...@li...>:
>>>>>
>>>>> this was a PJ issue wasnt it? im still using Chan_sip and my snoms
>dont do it if I answer at another phone, they actually show call
>completed elsewhere on the screen... im using 10.1.49.X firmware on my
>snoms..
>>>>> I dont remember having to set anything different in the config to
>make it work.
>>>>>
>>>>>
>>>>> On Monday, June 15, 2020, 3:31:16 PM EDT, nedi <ne...@gm...>
>wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> When a call goes to a group of snom phones and is answered by one
>phone, all the other phones display a missed call notification.
>>>>>
>>>>> According to the SNOM FAQ this can be stopped by way of the
>following changes to SIP protocols:
>>>>>
>>>>> Has anyone idea how to fix that
>>>>>
>>>>> Regards
>>>>> Nedi
>>>>> _______________________________________________
>>>>> Astlinux-users mailing list
>>>>> Ast...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>>>
>>>>> Donations to support AstLinux are graciously accepted via PayPal
>to pa...@kr....
>>>>> _______________________________________________
>>>>> Astlinux-users mailing list
>>>>> Ast...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>>>
>>>>> Donations to support AstLinux are graciously accepted via PayPal
>to pa...@kr....
>>>>
>>>> _______________________________________________
>>>> Astlinux-users mailing list
>>>> Ast...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>>
>>>> Donations to support AstLinux are graciously accepted via PayPal to
>pa...@kr....
>>>> _______________________________________________
>>>> Astlinux-users mailing list
>>>> Ast...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>>
>>>> Donations to support AstLinux are graciously accepted via PayPal to
>pa...@kr....
>>>
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>
>>> Donations to support AstLinux are graciously accepted via PayPal to
>pa...@kr....
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>
>>> Donations to support AstLinux are graciously accepted via PayPal to
>pa...@kr....
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>
>>> Donations to support AstLinux are graciously accepted via PayPal to
>pa...@kr....
>>
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to
>pa...@kr....
>
>
>------------------------------------------------------------------------
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Astlinux-users mailing list
>Ast...@li...
>https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
>Donations to support AstLinux are graciously accepted via PayPal to
>pa...@kr....
|
|
From: Michael K. <li...@mk...> - 2020-06-18 14:42:59
|
I mean the c option only for the groupcall.
Sent from a mobile device.
Michael Keuter
> Am 18.06.2020 um 16:31 schrieb nedi <ne...@gm...>:
>
> Michael do you mean c in dialpilan everywere or only where I dial all extension together?
>
>> Am 16.06.2020 um 00:11 schrieb The Cadillac Kid via Astlinux-users <ast...@li...>:
>>
>> I didnt think about dial options..
>>
>> this is my Dial command
>>
>> exten = s,n,Dial(SIP/${receiver}${ARG5},${fbnatimer},rIM(answerme,${receiver},${origuniqueid},${cidoriginate}))
>>
>> im not using 'c' in it the 'r' in it pretty much means that 180 will be sent back to the originating phone no matter what. I had to use that as we had some older analog FXS gateways that refused to send ringback
>>
>> as for the config I sent its meant for a D700 series.. all of our snoms in the field are 700s.
>>
>>
>> On Monday, June 15, 2020, 4:26:41 PM EDT, Michael Keuter <li...@mk...> wrote:
>>
>>
>> Have you tried in Asterisk the option „c“ of the „dial“ command?
>>
>> Sent from a mobile device.
>>
>> Michael Keuter
>>
>>>> Am 15.06.2020 um 22:21 schrieb nedi <ne...@gm...>:
>>>>
>>>
>>
>> Thanks , I will try tomorow.
>> Regards nedi
>>
>>> Am 15.06.2020 um 22:16 schrieb The Cadillac Kid via Astlinux-users <ast...@li...>:
>>>
>>> hit send too quick..
>>>
>>> this is the SIP sent back to it..
>>>
>>> CANCEL sip:5051@172.16.9.2:54836;line=up7wg15k SIP/2.0
>>> Via: SIP/2.0/UDP 172.16.8.2:5060;branch=z9hG4bK21641ecc
>>> Max-Forwards: 70
>>> From: "3200" <sip:3200@172.16.8.2>;tag=as73a14520
>>> To: <sip:5051@172.16.9.2:54836;line=up7wg15k>
>>> Call-ID: 328a1eaf23fc726f695258ef65aa2e51@172.16.8.2:5060
>>> CSeq: 102 CANCEL
>>> User-Agent: Asterisk PBX 11.20.0
>>> Reason: SIP;cause=200;text="Call completed elsewhere"
>>> Content-Length: 0
>>>
>>>
>>> my call was 3200 dials a ring group with 5002 and 5051(snom), 5002 answers the phone and 5051 shows answered elsewhere with no missed call
>>>
>>> On Monday, June 15, 2020, 3:54:19 PM EDT, nedi <ne...@gm...> wrote:
>>>
>>>
>>> The phone showing message "call completed elsewhere" on the screen coming but missed call is still there on all phones.
>>> Nedi
>>>
>>>> Am 15.06.2020 um 21:45 schrieb The Cadillac Kid via Astlinux-users <ast...@li...>:
>>>>
>>>> this was a PJ issue wasnt it? im still using Chan_sip and my snoms dont do it if I answer at another phone, they actually show call completed elsewhere on the screen... im using 10.1.49.X firmware on my snoms..
>>>> I dont remember having to set anything different in the config to make it work.
>>>>
>>>>
>>>> On Monday, June 15, 2020, 3:31:16 PM EDT, nedi <ne...@gm...> wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> When a call goes to a group of snom phones and is answered by one phone, all the other phones display a missed call notification.
>>>>
>>>> According to the SNOM FAQ this can be stopped by way of the following changes to SIP protocols:
>>>>
>>>> Has anyone idea how to fix that
>>>>
>>>> Regards
>>>> Nedi
>>>> _______________________________________________
>>>> Astlinux-users mailing list
>>>> Ast...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>>
>>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>>> _______________________________________________
>>>> Astlinux-users mailing list
>>>> Ast...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>>
>>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>>
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>
>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>
>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: nedi <ne...@gm...> - 2020-06-18 14:31:22
|
Michael do you mean c in dialpilan everywere or only where I dial all extension together?
> Am 16.06.2020 um 00:11 schrieb The Cadillac Kid via Astlinux-users <ast...@li...>:
>
> I didnt think about dial options..
>
> this is my Dial command
>
> exten = s,n,Dial(SIP/${receiver}${ARG5},${fbnatimer},rIM(answerme,${receiver},${origuniqueid},${cidoriginate}))
>
> im not using 'c' in it the 'r' in it pretty much means that 180 will be sent back to the originating phone no matter what. I had to use that as we had some older analog FXS gateways that refused to send ringback
>
> as for the config I sent its meant for a D700 series.. all of our snoms in the field are 700s.
>
>
> On Monday, June 15, 2020, 4:26:41 PM EDT, Michael Keuter <li...@mk...> wrote:
>
>
> Have you tried in Asterisk the option „c“ of the „dial“ command?
>
> Sent from a mobile device.
>
> Michael Keuter
>
>> Am 15.06.2020 um 22:21 schrieb nedi <ne...@gm...>:
>>
>
>>
>
> Thanks , I will try tomorow.
> Regards nedi
>
>> Am 15.06.2020 um 22:16 schrieb The Cadillac Kid via Astlinux-users <ast...@li... <mailto:ast...@li...>>:
>>
>> hit send too quick..
>>
>> this is the SIP sent back to it..
>>
>> CANCEL sip:5051@172.16.9.2:54836;line=up7wg15k <> SIP/2.0
>> Via: SIP/2.0/UDP 172.16.8.2:5060;branch=z9hG4bK21641ecc
>> Max-Forwards: 70
>> From: "3200" <sip:3200@172.16.8.2 <>>;tag=as73a14520
>> To: <sip:5051@172.16.9.2:54836;line=up7wg15k <>>
>> Call-ID: 328a1eaf23fc726f695258ef65aa2e51@172.16.8.2 <mailto:328a1eaf23fc726f695258ef65aa2e51@172.16.8.2>:5060
>> CSeq: 102 CANCEL
>> User-Agent: Asterisk PBX 11.20.0
>> Reason: SIP;cause=200;text="Call completed elsewhere"
>> Content-Length: 0
>>
>>
>> my call was 3200 dials a ring group with 5002 and 5051(snom), 5002 answers the phone and 5051 shows answered elsewhere with no missed call
>>
>> On Monday, June 15, 2020, 3:54:19 PM EDT, nedi <ne...@gm... <mailto:ne...@gm...>> wrote:
>>
>>
>> The phone showing message "call completed elsewhere" on the screen coming but missed call is still there on all phones.
>> Nedi
>>
>>> Am 15.06.2020 um 21:45 schrieb The Cadillac Kid via Astlinux-users <ast...@li... <mailto:ast...@li...>>:
>>>
>>> this was a PJ issue wasnt it? im still using Chan_sip and my snoms dont do it if I answer at another phone, they actually show call completed elsewhere on the screen... im using 10.1.49.X firmware on my snoms..
>>> I dont remember having to set anything different in the config to make it work.
>>>
>>>
>>> On Monday, June 15, 2020, 3:31:16 PM EDT, nedi <ne...@gm... <mailto:ne...@gm...>> wrote:
>>>
>>>
>>> Hi,
>>>
>>> When a call goes to a group of snom phones and is answered by one phone, all the other phones display a missed call notification.
>>>
>>> According to the SNOM FAQ this can be stopped by way of the following changes to SIP protocols:
>>>
>>> Has anyone idea how to fix that
>>>
>>> Regards
>>> Nedi
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li... <mailto:Ast...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users <https://lists.sourceforge.net/lists/listinfo/astlinux-users>
>>>
>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... <mailto:pa...@kr....>_______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li... <mailto:Ast...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users <https://lists.sourceforge.net/lists/listinfo/astlinux-users>
>>>
>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li... <mailto:Ast...@li...>
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users <https://lists.sourceforge.net/lists/listinfo/astlinux-users>
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... <mailto:pa...@kr....>_______________________________________________
>> Astlinux-users mailing list
>> Ast...@li... <mailto:Ast...@li...>
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li... <mailto:Ast...@li...>
> https://lists.sourceforge.net/lists/listinfo/astlinux-users <https://lists.sourceforge.net/lists/listinfo/astlinux-users>
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... <mailto:pa...@kr....>_______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: The C. K. <eld...@ya...> - 2020-06-15 22:21:27
|
I didnt think about dial options..
this is my Dial command
exten = s,n,Dial(SIP/${receiver}${ARG5},${fbnatimer},rIM(answerme,${receiver},${origuniqueid},${cidoriginate}))
im not using 'c' in it the 'r' in it pretty much means that 180 will be sent back to the originating phone no matter what. I had to use that as we had some older analog FXS gateways that refused to send ringback
as for the config I sent its meant for a D700 series.. all of our snoms in the field are 700s.
On Monday, June 15, 2020, 4:26:41 PM EDT, Michael Keuter <li...@mk...> wrote:
Have you tried in Asterisk the option „c“ of the „dial“ command?
Sent from a mobile device.
Michael Keuter
Am 15.06.2020 um 22:21 schrieb nedi <ne...@gm...>:
Thanks , I will try tomorow.Regards nedi
Am 15.06.2020 um 22:16 schrieb The Cadillac Kid via Astlinux-users <ast...@li...>:
hit send too quick..
this is the SIP sent back to it..
CANCEL sip:5051@172.16.9.2:54836;line=up7wg15k SIP/2.0
Via: SIP/2.0/UDP 172.16.8.2:5060;branch=z9hG4bK21641ecc
Max-Forwards: 70
From: "3200" <sip:3200@172.16.8.2>;tag=as73a14520
To: <sip:5051@172.16.9.2:54836;line=up7wg15k>
Call-ID: 328a1eaf23fc726f695258ef65aa2e51@172.16.8.2:5060
CSeq: 102 CANCEL
User-Agent: Asterisk PBX 11.20.0
Reason: SIP;cause=200;text="Call completed elsewhere"
Content-Length: 0
my call was 3200 dials a ring group with 5002 and 5051(snom), 5002 answers the phone and 5051 shows answered elsewhere with no missed call
On Monday, June 15, 2020, 3:54:19 PM EDT, nedi <ne...@gm...> wrote:
The phone showing message "call completed elsewhere" on the screen coming but missed call is still there on all phones.Nedi
Am 15.06.2020 um 21:45 schrieb The Cadillac Kid via Astlinux-users <ast...@li...>:
this was a PJ issue wasnt it? im still using Chan_sip and my snoms dont do it if I answer at another phone, they actually show call completed elsewhere on the screen... im using 10.1.49.X firmware on my snoms..
I dont remember having to set anything different in the config to make it work.
On Monday, June 15, 2020, 3:31:16 PM EDT, nedi <ne...@gm...> wrote:
Hi,
When a call goes to a group of snom phones and is answered by one phone, all the other phones display a missed call notification.
According to the SNOM FAQ this can be stopped by way of the following changes to SIP protocols:
Has anyone idea how to fix that
Regards Nedi_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... _______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... _______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr...._______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Michael K. <mic...@ip...> - 2020-06-15 21:58:29
|
Thanks Dominko
Yes a number of softphones work well via VPN EXCEPT:
1) You will lose connectivity when the phone sleeps and/or
2) Your battery life will be woeful
This is why you need push notifications.
Good luck.
Regards
Michael Knill
On 16/6/20, 7:28 am, "dominko_vrljic--- via Astlinux-users" <ast...@li...> wrote:
Hi Michael,
I am also testing softphone applications and I was unsatisfied with any util now. I have installed "Calls - SIP VoIP Softphone" from Ruddy Nguyen Communication along with wiregurad on my smartphone today.
I am surprised it works very well even over VPN.
Although I tested only one day on only one smartphone a recommendation.
Regards,
Dominko
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: <dom...@ya...> - 2020-06-15 21:28:01
|
Hi Michael, I am also testing softphone applications and I was unsatisfied with any util now. I have installed "Calls - SIP VoIP Softphone" from Ruddy Nguyen Communication along with wiregurad on my smartphone today. I am surprised it works very well even over VPN. Although I tested only one day on only one smartphone a recommendation. Regards, Dominko |
|
From: Michael K. <li...@mk...> - 2020-06-15 20:25:27
|
Have you tried in Asterisk the option „c“ of the „dial“ command? Sent from a mobile device. Michael Keuter > Am 15.06.2020 um 22:21 schrieb nedi <ne...@gm...>: > > Thanks , I will try tomorow. > Regards nedi > >> Am 15.06.2020 um 22:16 schrieb The Cadillac Kid via Astlinux-users <ast...@li...>: >> >> hit send too quick.. >> >> this is the SIP sent back to it.. >> >> CANCEL sip:5051@172.16.9.2:54836;line=up7wg15k SIP/2.0 >> Via: SIP/2.0/UDP 172.16.8.2:5060;branch=z9hG4bK21641ecc >> Max-Forwards: 70 >> From: "3200" <sip:3200@172.16.8.2>;tag=as73a14520 >> To: <sip:5051@172.16.9.2:54836;line=up7wg15k> >> Call-ID: 328a1eaf23fc726f695258ef65aa2e51@172.16.8.2:5060 >> CSeq: 102 CANCEL >> User-Agent: Asterisk PBX 11.20.0 >> Reason: SIP;cause=200;text="Call completed elsewhere" >> Content-Length: 0 >> >> >> my call was 3200 dials a ring group with 5002 and 5051(snom), 5002 answers the phone and 5051 shows answered elsewhere with no missed call >> >> On Monday, June 15, 2020, 3:54:19 PM EDT, nedi <ne...@gm...> wrote: >> >> >> The phone showing message "call completed elsewhere" on the screen coming but missed call is still there on all phones. >> Nedi >> >>> Am 15.06.2020 um 21:45 schrieb The Cadillac Kid via Astlinux-users <ast...@li...>: >>> >>> this was a PJ issue wasnt it? im still using Chan_sip and my snoms dont do it if I answer at another phone, they actually show call completed elsewhere on the screen... im using 10.1.49.X firmware on my snoms.. >>> I dont remember having to set anything different in the config to make it work. >>> >>> >>> On Monday, June 15, 2020, 3:31:16 PM EDT, nedi <ne...@gm...> wrote: >>> >>> >>> Hi, >>> >>> When a call goes to a group of snom phones and is answered by one phone, all the other phones display a missed call notification. >>> >>> According to the SNOM FAQ this can be stopped by way of the following changes to SIP protocols: >>> >>> Has anyone idea how to fix that >>> >>> Regards >>> Nedi >>> _______________________________________________ >>> Astlinux-users mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>> >>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >>> _______________________________________________ >>> Astlinux-users mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>> >>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >> >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
63 messages has been excluded from this view by a project administrator.
