Re: [Astlinux-users] IPv6 SOHO Integrator Solutions

2017-06-04 Thread David Kerr
Adding to Lonnie's notes... Right now (current SVN builds) configuring
static or auto-configured ULA's for the internal interfaces is somewhat
complicated.  True it is probably a one-time-thing but I have been working
to simplify the process such that it can be truly automatic and can be done
without requiring any knowledge of IPv6.

That said... Lonnie and I are very interested in thoughts and suggestions
on IPv6 configuration.  Its new and we are just getting our heads around it
ourselves now.  If anyone is familiar with IPv6 please weigh in on your
experience configuring it (particularly ULA's) and suggestions.

David

On Sun, Jun 4, 2017 at 7:22 PM, Lonnie Abelbeck 
wrote:

> Greetings,
>
> Native IPv6 on dual stack IPv4/IPv6 is becoming common offerings for ISPs
> today, while my COX Business Internet was one of the last to do so, I have
> had "Static IPv4 / DHCPv6" working for a few weeks.
>
> This note is a request for comments on how integrators and power users
> deploy IPv6 service to their customers, or would like to be able to.
>
> First, David Kerr and myself have been working on polishing more IPv6
> features in AstLinux, some made possible with the kernel bump to Linux 3.16.
>
> I created and David prompted edits to this WiKi documentation (please
> read) ...
>
> IPv6 ULA / NPTv6 Configuration
> https://doc.astlinux-project.org/userdoc:tt_ipv6_ula_nptv6_config
>
> Acronym reference:
> --
> Global Unicast Addresses (GUA)
> Unique Local Addresses (ULA)
> Network Prefix Translation (NPTv6)
> --
>
> The curent SVN checkout of AstLinux allows a user to specify an interface
> to advertise both GUA and ULA prefixes, GUA only or ULA only prefixes, or
> no routable IPv6.
>
> Personally, I have configured only one interface with both GUA and ULA
> prefixes and all the other interfaces are either ULA or no routable IPv6.
> Downstream I have several AstLinux boxes all configured with ULA addresses
> and prefixes.  OpenVPN Server has a ULA network. So far I'm quite happy
> with this approach.
>
> Every ULA in my network can reach the internet via NPTv6 using the new
> "net-prefix-translation" plugin.  If/when DHCPv6 offers a different GUA
> prefix, the edge firewall rules update instantly and the ULA's continue to
> work like nothing happened.
>
> GUA or ULA ?  The hidden secret is the priority a client uses to connect
> to a server, (RFC 6724), I did some testing and a common order by network
> stacks is, (top to bottom)
> --
> IPv6 GUA
> IPv4
> IPv6 ULA
> --
> So a ULA gives IPv6 connectivity when an  record is resolved, but sill
> prefers IPv4.  iOS mostly works this way.
> (some newer browsers try to find the shortest paths and pick IPv4/IPv6
> that way)
>
> My CentOS development VM previously had a GUA and IPv4, so wget preferred
> IPv6.  But, IPv6 is not always better, for an Asterisk download it takes
> 10x longer to download a source tarball using IPv6 vs. IPv4, (not new, been
> that way for years).  My CentOS development VM now has a ULA and IPv4 so
> wget prefers IPv4, but will use IPv6 if a  DNS record is returned.
>
> Another thought, the FireHOL blocklists have proven to be a valuable tool,
> but the IPv6 blocklists are not near as developed as IPv4 lists are.
>
> Inbound EXT->LAN firewall forward rules can be static with ULA's.
>
> So, if you have a IPv4-only customer and they want to add IPv6
> connectivity, minimizing GUA subnets and providing ULA subnets wherever
> they want IPv6 connectivity may be a good approach.  The latest development
> AstLinux can do that.
>
> Please pass on your insights.
>
> Lonnie
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Astlinux-users mailing list
> Astlinux-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pay...@krisk.org.
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Astlinux-users mailing list
Astlinux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/astlinux-users

Donations to support AstLinux are graciously accepted via PayPal to 
pay...@krisk.org.

Re: [Astlinux-users] Asterisk stopped

2017-06-04 Thread Michael Knill
Thanks Darrick

Yes I know (hand slapped). Interesting it's the first time it has happened. I 
don't have Zabbix enabled on these two systems so not sure.
Looks like I will need a big push of my latest release.

Regards
Michael Knill

From: Darrick Hartman 
Reply-To: AstLinux List 
Date: Monday, 5 June 2017 at 11:53 am
To: AstLinux List 
Subject: Re: [Astlinux-users] Asterisk stopped

Michael,

We always recommend running on the latest version of AstLinux to mitigate 
security risks.  If possible, you should upgrade both to 1.2.9 and move the 1.8 
box to a current version of Asterisk.

It looks like some process was consuming a considerable amount of ram (unknown 
how much you have installed).  It is possible that this was an attack.  It 
could have been some other sort of memory leak, but the only ones we’re 
commonly aware of are related to Zabbix over time.

Darrick

From: Michael Knill [mailto:michael.kn...@ipcsolutions.com.au]
Sent: Sunday, June 4, 2017 8:30 PM
To: AstLinux List 
Subject: [Astlinux-users] Asterisk stopped

Hmm its been a bad morning.

I had two separate sites this morning with the same issue in that Asterisk had 
crashed. Yes these two sites don't have Safe Asterisk configured  but its still 
VERY unusual as Asterisk crashes are rare enough but on the same morning?

Unfortunately one site did not have ANY logs regarding the crash which was very 
unusual. Astlinux 1.2.7 Asterisk 11.22.0
Another site did as added below. Astlinux 1.2.0 Asterisk 1.8.30

.. lots of these ..
Jun  5 10:01:00 3003-ATP-CM1 local0.warn asterisk[1094]: WARNING[20995]: 
channel.c:1513 in __ast_queue_frame: Exceptionally long voice queue length 
queuing to Local/430@DialPlan1-26ea;2
Jun  5 10:01:00 3003-ATP-CM1 local0.warn asterisk[1094]: WARNING[20995]: 
channel.c:1513 in __ast_queue_frame: Exceptionally long voice queue length 
queuing to Local/430@DialPlan1-26ea;2
Jun  5 10:01:00 3003-ATP-CM1 local0.warn asterisk[1094]: WARNING[20995]: 
channel.c:1513 in __ast_queue_frame: Exceptionally long voice queue length 
queuing to Local/430@DialPlan1-26ea;2

Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel: crond invoked oom-killer: 
gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel: Pid: 330, comm: crond Tainted: G 
  O 3.2.62-astlinux #1
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel: Call Trace:
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] T.499+0x6b/0x18e
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
___ratelimit+0x9e/0xbc
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] T.498+0x2f/0x23e
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
has_capability_noaudit+0x2e/0x3a
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
out_of_memory+0x214/0x2b9
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
__alloc_pages_nodemask+0x3f7/0x47e
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
do_read_cache_page+0x39/0x105
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
ext2_writepages+0xf/0xf
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
read_cache_page_async+0x16/0x1b
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
read_cache_page+0xb/0x12
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
ext2_get_page+0x1c/0x1e3
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
vfsmount_lock_local_unlock+0xd/0x22
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
terminate_walk+0x30/0x32
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
ext2_find_entry+0x72/0x188
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
ext2_inode_by_name+0x12/0x31
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
ext2_lookup+0x22/0x65
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
d_alloc_and_lookup+0x38/0x4f
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
__lookup_hash+0x9a/0xa5
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
lookup_one_len_nd+0x8f/0x9e
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
lookup_whiteout+0x66/0xd9
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
unionfs_lookup_full+0x157/0x6b8
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
__unionfs_d_revalidate+0x337/0x363
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
__krealloc+0x38/0x50
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
krealloc+0x2d/0x33
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
new_dentry_private_data+0x7a/0xdc
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
unionfs_lookup+0x6b/0x105
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
d_alloc_and_lookup+0x38/0x4f
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
do_lookup+0x1ca/0x2a4
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] do_last+0xe3/0x5ef
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
path_openat+0x9c/0x2c2
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
do_filp_open+0x21/0x60
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
alloc_fd+0xbf/0xe2
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
do_sys_open+0xf6/0x179

Re: [Astlinux-users] Asterisk stopped

2017-06-04 Thread Darrick Hartman
Michael,

We always recommend running on the latest version of AstLinux to mitigate 
security risks.  If possible, you should upgrade both to 1.2.9 and move the 1.8 
box to a current version of Asterisk.

It looks like some process was consuming a considerable amount of ram (unknown 
how much you have installed).  It is possible that this was an attack.  It 
could have been some other sort of memory leak, but the only ones we’re 
commonly aware of are related to Zabbix over time.

Darrick

From: Michael Knill [mailto:michael.kn...@ipcsolutions.com.au]
Sent: Sunday, June 4, 2017 8:30 PM
To: AstLinux List 
Subject: [Astlinux-users] Asterisk stopped

Hmm its been a bad morning.

I had two separate sites this morning with the same issue in that Asterisk had 
crashed. Yes these two sites don't have Safe Asterisk configured  but its still 
VERY unusual as Asterisk crashes are rare enough but on the same morning?

Unfortunately one site did not have ANY logs regarding the crash which was very 
unusual. Astlinux 1.2.7 Asterisk 11.22.0
Another site did as added below. Astlinux 1.2.0 Asterisk 1.8.30

.. lots of these ..
Jun  5 10:01:00 3003-ATP-CM1 local0.warn asterisk[1094]: WARNING[20995]: 
channel.c:1513 in __ast_queue_frame: Exceptionally long voice queue length 
queuing to Local/430@DialPlan1-26ea;2
Jun  5 10:01:00 3003-ATP-CM1 local0.warn asterisk[1094]: WARNING[20995]: 
channel.c:1513 in __ast_queue_frame: Exceptionally long voice queue length 
queuing to Local/430@DialPlan1-26ea;2
Jun  5 10:01:00 3003-ATP-CM1 local0.warn asterisk[1094]: WARNING[20995]: 
channel.c:1513 in __ast_queue_frame: Exceptionally long voice queue length 
queuing to Local/430@DialPlan1-26ea;2

Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel: crond invoked oom-killer: 
gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel: Pid: 330, comm: crond Tainted: G 
  O 3.2.62-astlinux #1
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel: Call Trace:
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] T.499+0x6b/0x18e
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
___ratelimit+0x9e/0xbc
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] T.498+0x2f/0x23e
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
has_capability_noaudit+0x2e/0x3a
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
out_of_memory+0x214/0x2b9
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
__alloc_pages_nodemask+0x3f7/0x47e
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
do_read_cache_page+0x39/0x105
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
ext2_writepages+0xf/0xf
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
read_cache_page_async+0x16/0x1b
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
read_cache_page+0xb/0x12
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
ext2_get_page+0x1c/0x1e3
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
vfsmount_lock_local_unlock+0xd/0x22
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
terminate_walk+0x30/0x32
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
ext2_find_entry+0x72/0x188
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
ext2_inode_by_name+0x12/0x31
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
ext2_lookup+0x22/0x65
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
d_alloc_and_lookup+0x38/0x4f
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
__lookup_hash+0x9a/0xa5
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
lookup_one_len_nd+0x8f/0x9e
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
lookup_whiteout+0x66/0xd9
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
unionfs_lookup_full+0x157/0x6b8
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
__unionfs_d_revalidate+0x337/0x363
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
__krealloc+0x38/0x50
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
krealloc+0x2d/0x33
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
new_dentry_private_data+0x7a/0xdc
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
unionfs_lookup+0x6b/0x105
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
d_alloc_and_lookup+0x38/0x4f
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
do_lookup+0x1ca/0x2a4
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] do_last+0xe3/0x5ef
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
path_openat+0x9c/0x2c2
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
do_filp_open+0x21/0x60
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
alloc_fd+0xbf/0xe2
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
do_sys_open+0xf6/0x179
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] sys_open+0x1e/0x26
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
syscall_call+0x7/0x7
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
ip_rt_do_proc_exit+0x15/0x30
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel: Mem-Info:
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel: DMA per-cpu:
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel

[Astlinux-users] Asterisk stopped

2017-06-04 Thread Michael Knill
Hmm its been a bad morning.

I had two separate sites this morning with the same issue in that Asterisk had 
crashed. Yes these two sites don't have Safe Asterisk configured  but its still 
VERY unusual as Asterisk crashes are rare enough but on the same morning?

Unfortunately one site did not have ANY logs regarding the crash which was very 
unusual. Astlinux 1.2.7 Asterisk 11.22.0
Another site did as added below. Astlinux 1.2.0 Asterisk 1.8.30

.. lots of these ..
Jun  5 10:01:00 3003-ATP-CM1 local0.warn asterisk[1094]: WARNING[20995]: 
channel.c:1513 in __ast_queue_frame: Exceptionally long voice queue length 
queuing to Local/430@DialPlan1-26ea;2
Jun  5 10:01:00 3003-ATP-CM1 local0.warn asterisk[1094]: WARNING[20995]: 
channel.c:1513 in __ast_queue_frame: Exceptionally long voice queue length 
queuing to Local/430@DialPlan1-26ea;2
Jun  5 10:01:00 3003-ATP-CM1 local0.warn asterisk[1094]: WARNING[20995]: 
channel.c:1513 in __ast_queue_frame: Exceptionally long voice queue length 
queuing to Local/430@DialPlan1-26ea;2

Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel: crond invoked oom-killer: 
gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel: Pid: 330, comm: crond Tainted: G 
  O 3.2.62-astlinux #1
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel: Call Trace:
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] T.499+0x6b/0x18e
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
___ratelimit+0x9e/0xbc
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] T.498+0x2f/0x23e
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
has_capability_noaudit+0x2e/0x3a
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
out_of_memory+0x214/0x2b9
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
__alloc_pages_nodemask+0x3f7/0x47e
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
do_read_cache_page+0x39/0x105
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
ext2_writepages+0xf/0xf
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
read_cache_page_async+0x16/0x1b
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
read_cache_page+0xb/0x12
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
ext2_get_page+0x1c/0x1e3
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
vfsmount_lock_local_unlock+0xd/0x22
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
terminate_walk+0x30/0x32
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
ext2_find_entry+0x72/0x188
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
ext2_inode_by_name+0x12/0x31
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
ext2_lookup+0x22/0x65
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
d_alloc_and_lookup+0x38/0x4f
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
__lookup_hash+0x9a/0xa5
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
lookup_one_len_nd+0x8f/0x9e
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
lookup_whiteout+0x66/0xd9
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
unionfs_lookup_full+0x157/0x6b8
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
__unionfs_d_revalidate+0x337/0x363
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
__krealloc+0x38/0x50
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
krealloc+0x2d/0x33
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
new_dentry_private_data+0x7a/0xdc
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
unionfs_lookup+0x6b/0x105
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
d_alloc_and_lookup+0x38/0x4f
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
do_lookup+0x1ca/0x2a4
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] do_last+0xe3/0x5ef
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
path_openat+0x9c/0x2c2
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
do_filp_open+0x21/0x60
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
alloc_fd+0xbf/0xe2
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
do_sys_open+0xf6/0x179
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] sys_open+0x1e/0x26
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] 
syscall_call+0x7/0x7
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  [] ? 
ip_rt_do_proc_exit+0x15/0x30
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel: Mem-Info:
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel: DMA per-cpu:
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel: CPU0: hi:0, btch:   1 
usd:   0
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel: Normal per-cpu:
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel: CPU0: hi:   90, btch:  15 
usd:  12
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel: active_anon:33674 
inactive_anon:25254 isolated_anon:0
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  active_file:5 inactive_file:6 
isolated_file:0
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  unevictable:0 dirty:0 
writeback:0 unstable:0
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  free:611 slab_reclaimable:896 
slab_unreclaimable:1423
Jun  5 10:01:01 3003-ATP-CM1 user.warn kernel:  mapped:2804 shmem:2902

[Astlinux-users] Problems with losing SIP Trunk

2017-06-04 Thread Michael Knill
Hi group

I have actually reported this problem before but it was using a different 
network connection.
Im on Astlinux 1.2.8 with a SIP Trunk e.g. not registered. This site is via a 
firewall so it is using NAT but I don't think it should matter.
It appears that when there is a particular event that there is a temporary loss 
of connectivity, but not a link down event, qualify or SIP OPTIONS pings do not 
make it to the trunk provider (or back again as I have not been able to test). 
Performing an Asterisk reload fixes the problem immediately.

Before reload:
I managed to check the reload before and after firewall states:
Source   Port (#'s)   Destination  PortProtocol 
Packets  Bytes  TTL
192.168.2.5 5060   192.168.2.38   5060   UDP28535   
 16835829 2:59
192.168.2.5 5060   192.168.2.39   5060   UDP17450   
 10280235 2:58
192.168.2.5 5060   192.168.2.35   5060   UDP16930   
 99481452:59
192.168.2.5 5060   192.168.2.42   5060   UDP12961   
 76045922:54
192.168.2.5 5060   192.168.2.37   5060   UDP3561
   20191232:57
192.168.2.5 5060   192.168.2.36   5060   UDP3454
   19527482:53
124.171.212.15550133172.30.10.2 7123   TCP  
   222 564307199:59
192.168.2.22   17500192.168.2.255 17500UDP200 
456000:55
192.168.2.22   17500255.255.255.25517500UDP
100 228000:55
192.168.2.30   138 192.168.2.255 138 UDP1   
   229 0:58
172.30.10.2 8272 (10)  8.8.8.8   53   UDP2  
211 0:59
172.30.10.2 56406 (2)  113.20.24.94   10051TCP  
   2  120 1:11
48 Total Firewall States

After reload:
Source   Port (#'s)   Destination  PortProtocol 
Packets  Bytes  TTL
192.168.2.5 5060   192.168.2.38   5060   UDP28773   
 16975982 2:57
192.168.2.5 5060   192.168.2.35   5060   UDP17821   
 10475864 2:59
192.168.2.5 5060   192.168.2.39   5060   UDP17596   
 10365993 2:58
192.168.2.5 5060   192.168.2.42   5060   UDP13069   
 76675522:50
192.168.2.5 5060   192.168.2.37   5060   UDP3591
   20359542:50
192.168.2.5 5060   192.168.2.36   5060   UDP3484
   19695532:58
124.171.212.15550133172.30.10.2 7123   TCP  
   548 132258  7199:59
192.168.2.22   17500192.168.2.255 17500UDP214 
487920:43
192.168.2.22   17500255.255.255.25517500UDP
107 243960:43
172.30.10.2 5060   125.213.162.1125060   UDP
2  1042   0:50
172.30.10.2 31249 (3)  8.8.8.8   53   UDP2  
211 0:59
172.30.10.2 56424 (2)  113.20.24.94   10051TCP  
   2  120 1:39
28 Total Firewall States

My provider 125.213.162.112 is now there so I assume that the problem is not in 
the firewall that Astlinux traverses but the Astlinux firewall itself.
I am sending OPTIONS pings every 30 seconds. Why would this not just set up the 
firewall state again? Maybe its an Asterisk problem?

Any ideas? What should I check when it happens again?

Regards
Michael Knill
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Astlinux-users mailing list
Astlinux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/astlinux-users

Donations to support AstLinux are graciously accepted via PayPal to 
pay...@krisk.org.

[Astlinux-users] IPv6 SOHO Integrator Solutions

2017-06-04 Thread Lonnie Abelbeck
Greetings,

Native IPv6 on dual stack IPv4/IPv6 is becoming common offerings for ISPs 
today, while my COX Business Internet was one of the last to do so, I have had 
"Static IPv4 / DHCPv6" working for a few weeks.

This note is a request for comments on how integrators and power users deploy 
IPv6 service to their customers, or would like to be able to.

First, David Kerr and myself have been working on polishing more IPv6 features 
in AstLinux, some made possible with the kernel bump to Linux 3.16.

I created and David prompted edits to this WiKi documentation (please read) ...

IPv6 ULA / NPTv6 Configuration
https://doc.astlinux-project.org/userdoc:tt_ipv6_ula_nptv6_config

Acronym reference:
--
Global Unicast Addresses (GUA)
Unique Local Addresses (ULA)
Network Prefix Translation (NPTv6)
--

The curent SVN checkout of AstLinux allows a user to specify an interface to 
advertise both GUA and ULA prefixes, GUA only or ULA only prefixes, or no 
routable IPv6.

Personally, I have configured only one interface with both GUA and ULA prefixes 
and all the other interfaces are either ULA or no routable IPv6.  Downstream I 
have several AstLinux boxes all configured with ULA addresses and prefixes.  
OpenVPN Server has a ULA network. So far I'm quite happy with this approach.

Every ULA in my network can reach the internet via NPTv6 using the new 
"net-prefix-translation" plugin.  If/when DHCPv6 offers a different GUA prefix, 
the edge firewall rules update instantly and the ULA's continue to work like 
nothing happened.

GUA or ULA ?  The hidden secret is the priority a client uses to connect to a 
server, (RFC 6724), I did some testing and a common order by network stacks is, 
(top to bottom)
--
IPv6 GUA
IPv4
IPv6 ULA
--
So a ULA gives IPv6 connectivity when an  record is resolved, but sill 
prefers IPv4.  iOS mostly works this way.
(some newer browsers try to find the shortest paths and pick IPv4/IPv6 that way)

My CentOS development VM previously had a GUA and IPv4, so wget preferred IPv6. 
 But, IPv6 is not always better, for an Asterisk download it takes 10x longer 
to download a source tarball using IPv6 vs. IPv4, (not new, been that way for 
years).  My CentOS development VM now has a ULA and IPv4 so wget prefers IPv4, 
but will use IPv6 if a  DNS record is returned.

Another thought, the FireHOL blocklists have proven to be a valuable tool, but 
the IPv6 blocklists are not near as developed as IPv4 lists are.

Inbound EXT->LAN firewall forward rules can be static with ULA's.

So, if you have a IPv4-only customer and they want to add IPv6 connectivity, 
minimizing GUA subnets and providing ULA subnets wherever they want IPv6 
connectivity may be a good approach.  The latest development AstLinux can do 
that.

Please pass on your insights.

Lonnie


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Astlinux-users mailing list
Astlinux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/astlinux-users

Donations to support AstLinux are graciously accepted via PayPal to 
pay...@krisk.org.