Caller ID Superfecta » Winunciator

Ok - I like the idea of multiple subnet support.
You would need to loop through all the active ones within the confines of the data source script.

Im not sure how the debug output would be effected - hopefully it can be maintained satisfactorily. Be sure to consdier that when you code it.

Hopefully, the worst of it will be that all the destinations in the source get grouped together for debug reporting.

I think the port needs to be speficied seprately for each subnet that is configured.

Also - do you intend to limit support for class c subnets? Im sure they aremost common for home use, but not exclusive. For completely utility, we should probably let them specify the subnet mask for the subnet also and be able to support non class c nets.

This no longer sounds like such a zero config proposition - but the flexability blow me away with possibilities.

Don't forget - you get to write the docs that explain to joe the plumber how to configure it - hehehehe.

Well, to prevent a support nightmare I think the best approach would be to get all ip/broadcasts current assiged to the pbx machine, and then auto populate a gui menu and have the user assign what port to use for each broadcast ip.

Example looking at my pbx box here right now would have 2 ip/bc/port sets: eth0 - 192.168.0.2, 192.168.0.255, 8080 and ham0 - 5.154.143.221, 5.255.255.255, 8080. so we just take the 2nd part of the data set retrieved from the box and get a port for that broadcast.

As long as their network interface(s) are correctly setup (and they should before they get to this module) we should not have to explain the broadcast netmask setup?

This would like for example different sales departments on different subnets all be allowed to receive the data on whatever port their admin decides to use.

So instead of zero config, minimal config? :) true zero config would have to hard code the port number, but that will just cause problems

also as short as this info is gonna be sent - I think UDP broadcast would be the best approach - it should not get split like TCP, but the benefit of UDP - it does not expect a acknowledge. Were like if I do a debug and don't have my XBOX on, i get a timeout error in the debug window for it - UDP just sends it does not wait - at least that is my understanding - correct me if i am wrong.....

Well, to prevent a support nightmare I think the best approach would be to get all ip/broadcasts current assiged to the pbx machine, and then auto populate a gui menu and have the user assign what port to use for each broadcast ip.

I completely agree.

Example looking at my pbx box here right now would have 2 ip/bc/port sets: eth0 - 192.168.0.2, 192.168.0.255, 8080 and ham0 - 5.154.143.221, 5.255.255.255, 8080. so we just take the 2nd part of the data set retrieved from the box and get a port for that broadcast.

I agree. Also, we should populate a default port value in the data source - and use a matching default in the Boradcast winunciator exe - to provide a "defaults work fine" installation experience. What do you think?

also as short as this info is gonna be sent - I think UDP broadcast would be the best approach

We agree A LOT :-) Thats how Ill go for the Windows exe part then.

Example looking at my pbx box here right now would have 2 ip/bc/port sets: eth0 - 192.168.0.2, 192.168.0.255, 8080 and ham0 - 5.154.143.221, 5.255.255.255, 8080. so we just take the 2nd part of the data set retrieved from the box and get a port for that broadcast.

I was thinking we could populate with what we get from the box, but still let them edit in case our divination goes wrong, or they have subnetted subnets. What do you think about that?

ya, i was thinking of just prepopulating the broadcast ips of the config ui, but still let them edit what they need to edit.

next question: is the output of ifconfig the same on every platform?

home ifconfig:
eth0 Link encap:Ethernet HWaddr 00:08:74:0B:49:FE
inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::208:74ff:fe0b:49fe/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4454790 errors:0 dropped:0 overruns:0 frame:0
TX packets:4615227 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1191583141 (1.1 GiB) TX bytes:4031874141 (3.7 GiB)
Base address:0xe8c0 Memory:ff8c0000-ff8e0000

ham0 Link encap:Ethernet HWaddr 6A:9A:E9:C4:1A:B0
inet addr:5.154.143.221 Bcast:5.255.255.255 Mask:255.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1200 Metric:1
RX packets:1828915 errors:0 dropped:0 overruns:0 frame:0
TX packets:3357488 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:141593809 (135.0 MiB) TX bytes:3475457990 (3.2 GiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:6188985 errors:0 dropped:0 overruns:0 frame:0
TX packets:6188985 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:620822034 (592.0 MiB) TX bytes:620822034 (592.0 MiB)

hosting vps ifconfig
ham0 Link encap:Ethernet HWaddr 06:49:43:7A:A8:8D
inet addr:5.36.157.196 Bcast:5.255.255.255 Mask:255.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1200 Metric:1
RX packets:55713 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:10016360 (9.5 MiB) TX bytes:168 (168.0 b)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:11831662 errors:0 dropped:0 overruns:0 frame:0
TX packets:11831662 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1823389582 (1.6 GiB) TX bytes:1823389582 (1.6 GiB)

venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:127.0.0.1 P-t-P:127.0.0.1 Bcast:0.0.0.0 Mask:255.255.255.255
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
RX packets:9442625 errors:0 dropped:0 overruns:0 frame:0
TX packets:9299276 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2500716718 (2.3 GiB) TX bytes:3747837187 (3.4 GiB)

venet0:0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:207.58.143.121 P-t-P:207.58.143.121 Bcast:207.58.143.121 Mask:255.255.255.255
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1

venet0:1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:207.58.143.122 P-t-P:207.58.143.122 Bcast:207.58.143.122 Mask:255.255.255.255
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1

venet0:2 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:207.58.143.123 P-t-P:207.58.143.123 Bcast:207.58.143.123 Mask:255.255.255.255
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1

venet0:3 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:207.58.143.124 P-t-P:207.58.143.124 Bcast:207.58.143.124 Mask:255.255.255.255
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1

I cant search reliability by interface type as in my example i have 3 different interfaces to look for. On my vps listing the venet0 aliases dont do any good because they are pointopoint aliases - the ip and bc are exactly the same.

But someone can have eth0 eth1 etc aliases and they would have completly different ips and bcs. On VPS servers, venet0 venet1 etc are always the same - so i should just skip and filter that interface description out completly.

ethX is ethernet, ham0 is hamachi, what do the other vps systems use to describe their interfaces?

maybe the best way is to just scan thru the output looking for inet addr: lines, they will contain both ip and bc, filter out 127.0.0.1 and and others that the ip and bc are the same?

another thing we are gonna have to watch/check for - is most non root access the /sbin is not in the path for the user, they can still run ifconfig in a read only mode, but will have to be called direct with full path - which is not a problem - as long as their ifconfig is in /sbin. guess i should do a check to see if it is not in /sbin and add a path line to the gui asking them where their ifconfig program is? its the only util I know of to get all the interface information from.

any other ideas?

another thing we are gonna have to watch/check for - is most non root access the /sbin is not in the path for the user, they can still run ifconfig in a read only mode, but will have to be called direct with full path - which is not a problem - as long as their ifconfig is in /sbin. guess i should do a check to see if it is not in /sbin and add a path line to the gui asking them where their ifconfig program is? its the only util I know of to get all the interface information from.

One thing to remember is that the modules run with the permissions of the `maint` user. Modules can symlink to about 3 or 4 paticular folders. In general terms, if you can do it with Maint permissions, you can do it from within a module.

please run this on as many systems (they all seem to have different ifconfig output :( ) and let me know if you just get the broadcast addresses back.

ifconfig | perl -nle'/cast:(\S+)/ && print $1'

thanks

Foncordiax / Fonica PABX yeilds correct answer. 192.168.x.255

two hosted PBXIAF systems yields: 0.0.0.0 AND their own IP address (I dont know what their subnet actually is)

Trixbox CE return valid result.

tshif wrote:

Foncordiax / Fonica PABX yeilds correct answer. 192.168.x.255

two hosted PBXIAF systems yields: 0.0.0.0 AND their own IP address (I dont know what their subnet actually is)

if it is on a VPS system - its comming from the main venet0 device - will have to filter those out of the list, their own ip address (i get 4 of them on my vps) is using a point to point mapping scheme - so i am going to have to filter those out as well.

the hosted machines are going to be the hardest to get the correct info from - because every virtual system deals with their network interface differently.

Trixbox CE return valid result.

next question after looking at how the configs are stored in the database, it looks like im not going to be able to define a 2 dimension array to store this info. So is like 10 broadcast addresses enough along with the single direct access entry? I will have to make variable sets - _1 _2 _3 etc to store the config in?

I was wondering if it would be practicle to have an "add" function that lets the user add subnets untill they dont need any more, and a DEL button to remove the ones they decide to remove, etc.

If that wont fly - I would think 10 is a pretty big number of subnets to want to send out notification for. I dont object to it, but Id also be just as happy with 5. Or the add/del scenario where they have exactly as many as they want.

Just my thoughts atm - not married to any of them.

please run this on as many systems (they all seem to have different ifconfig output :( ) and let me know if you just get the broadcast addresses back.

Works on Elastix 1.5 (centos 5.4)

I have tested this in a virtualization (windows virtual server 2005 r2) and found it returns a sane and correct value.

Has anything happened with this new datasource? Im very interested in trying it out - anything I can do to help also?

bsau wrote:

Has anything happened with this new datasource? Im very interested in trying it out - anything I can do to help also?

I will be back after the new year to get it finished asap - movies at the cinema has been keeping me going 12-14 hrs a day.... sorry for the delay

Hi guys - anything new to test on this ticket?

Ok, with my busy holiday spree over, I will be back fulltime on Sunday 1/31/10 to continue on what we started - sorry for the delay - but the holiday season had me going 14+ hrs a day at my theater....

Thanks
Myk

mykroft - any progress?

tshif wrote:

mykroft - any progress?

I completly forgot about this with the new position and location move. I will get started on this again, just gotta find my files :)

Myk

Im not sure your getting your Projects related emails. COuld you check your spam filters? They come from projects@project.colsolgrp.net.

Without a complete re-write of the get_url_contents function (which will effect every source model) broadcasting is not possible, I will look into changing it maybe for a future major release. But for now, so people don't have to have multiple copies of the source module to send to multiple Winunciator clients, I am just going to add multiple sendto URL/IP address lines.

send-to source updated to allow up to 5 clients to be configued. This should be enough for now?

Where is he new code posted? I dont see it here on this case, nor in the SVN. I'd like to jump in and test it for release.

Ok - Im Blind. It is in the SVN. Code is now in QS test.

QS: Pass. Unit now sends to up to 5 Winunciator destinations. While this is not broadcast enabled, that would take changes to the main module (and may be addressed in the future there).

Released to live update as of now.