an even number eg 02, 04, 06 etc."
Should the first word be 'Note' instead of 'Not'?
Now to my real question...after making what I thought were rudimentary changes I seem to no longer be able to dial the one MP that is physically connected to my internet gateway. All other functions seem to be fine but attempting to dial the problematic MP from the other two always fails, and trying to call the working MPs from the problematic one also always fails. I have simply addressed the MPs with the IPs 10.130.1.20, 10.130.1.30, and 10.130.1.40. In this instance, .20 is directly connected to my MacBook to admin, .30 is by itself and .40 is directly connected to my ethernet switch which is turn connected to my home router (they are all within 30 feet of one another). The automatic discovery of the local gateway worked as expected on the .40 unit and I was able to join one of the client APs from the mesh and reach the internet. I am not quite sure what I changed that caused the inter MP dialing to fail so I reset them all to defaults and tried to go through step by step with the changes I made, calling each node along the way. Here are the changes I made on each MP after flashing with the SECN firmware and resetting everything to the defaults:
1. Changed the last octet of the IP on two of the MPs via the IVR (from .20 to .30 and from .20 to .40 respectively) and rebooting as instructed.
2. Changed the WiFI AP from WPA to WPA2 encryption and change the channel from 1 to 11 on all three units.
3. Set the root password on all three devices and enabled SSL and web authentication.
4. On the unit with last octet .40, directly connected the ethernet interface to a gigabit switch which is in turn uplinked to a Netgear router connected to a cable modem. I used the find gateway Test to set the gateway to that of my local router. This worked as expected and then joining the WiFi AP from one of the Mesh units allowed me to reach the internet.
During these changes I kept dialing from each unit to each other and it seemed to work for a time. Now, after a short period I cannot dial from .20 or .30 into .40. .20 and .30 can call each other just fine. I can still access the internet. I ssh'd into each unit and set verbose logging from Asterisk to catch an attempt to call from .20 to .40 and the results are below. The first section is from the MP with .20 as the last octet attempting to call the .40 unit and the second section is from the unit with .40 (which cannot receive or send calls) trying to call the .20 unit:
-- start mp_new
-- event_dtmf 4
-- event_dtmf 0
-- event_digit_timer
-- extension exists, starting PBX 40
-- Executing [40@default:1] Dial("MP/1", "SIP/40...@10.130.1.40") in new stack
-- Called 40...@10.130.1.40
[Jan 1 00:32:03] NOTICE[777]: chan_sip.c:2880 auto_congest: Auto-congesting SIP/10.130.1.40-0057d6c8
-- SIP/10.130.1.40-0057d6c8 is circuit-busy
== Everyone is busy/congested at this time (1:0/1/0)
== Auto fallthrough, channel 'MP/1' status is 'CONGESTION'
-- Asked to indicate 'Congestion (circuits busy)' condition on channel MP/1
-- event_onhook
-- default: hangup sound_on = 1
-- start mp_hangup
-- event_offhook
-- AST_STATE_DOWN:
-- start mp_new
-- event_onhook
-- AST_STATE_OFFHOOK, AST_STATE_DIALING : hangup
-- start mp_hangup
Really destroying SIP dialog '694af5830e8a222f...@10.130.1.20' Method: INVITE
MP-20*CLI>
MP-040*CLI> exit
root@MP-040:~# asterisk -vvvvvrddd
Asterisk 1.4.11, Copyright (C) 1999 - 2007 Digium, Inc. and others.
Created by Mark Spencer <mark...@digium.com>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type 'core show license' for details.
=========================================================================
== Parsing '/etc/asterisk/asterisk.conf': Parsing /etc/asterisk/asterisk.conf
Found
== Parsing '/etc/asterisk/extconfig.conf': Parsing /etc/asterisk/extconfig.conf
Found
Connected to Asterisk 1.4.11 currently running on MP-040 (pid = 1084)
No entry for terminal type "xterm-256color";
using dumb terminal settings.
Verbosity was 0 and is now 5
Core debug was 0 and is now 3
-- event_offhook
-- AST_STATE_DOWN:
-- start mp_new
-- event_dtmf 2
-- event_dtmf 0
-- event_digit_timer
-- extension exists, starting PBX 20
-- Executing [20@default:1] Dial("MP/1", "SIP/40...@10.130.1.20") in new stack
[Jan 1 00:25:52] WARNING[2142]: chan_sip.c:1775 __sip_xmit: sip_xmit of 0x57daa8 (len 782) to 10.130.1.20:5060 returned -2: Bad file descriptor
-- Called 40...@10.130.1.20
[Jan 1 00:26:24] NOTICE[1092]: chan_sip.c:2880 auto_congest: Auto-congesting SIP/10.130.1.20-00581ff0
-- SIP/10.130.1.20-00581ff0 is circuit-busy
== Everyone is busy/congested at this time (1:0/1/0)
== Auto fallthrough, channel 'MP/1' status is 'CONGESTION'
-- Asked to indicate 'Congestion (circuits busy)' condition on channel MP/1
-- event_onhook
-- default: hangup sound_on = 1
-- start mp_hangup
Really destroying SIP dialog '7fa2a2a87d48b406...@10.130.1.40' Method: INVITE
MP-040*CLI>
Have I managed to mess up the configuration in some way, or did I find a bug? I know the firmware is still in development but I wanted to run it past the last before I filed a bug in the tracker, and quite honestly I don't know enough about Asterisk to know what I really broke.
Thanks in advance for any assistance and thank you to all of those who have contributed to this project. I am constantly amazed and how powerful the MP and how it is being put to use throughout the world.
Robert Boerner
Hello,I just updated my three Mesh Potato units to the excellent SECN 1.1RC2 firmware and I would like to share some basic feedback and ask a question.The Potato Flash utility and instructions were straightforward and easy to follow. I was able to update all of my units (which still had the factory MP firmware on them) without incident. 'Out of the box' with the new firmware everything worked as advertised. I set about exploring and making a few changes and here are some things I found:
1. When Saving configuration changes from the Advanced page, the web interface always returns to the Basic page after the save is complete. Is this by design? I would have thought that it would stay on the Advanced page.
2. Looking at the latest docs for the SECN firmware, it states that telnet should be running until a root password is set. I did not find this to be true, only SSH was being accepted on the ethernet interface. Looking closer at the docs, is telnet only an option on the fallback IP address as opposed to the IP I have set?
3. When Saving and Rebooting from the web interface, there seems to be a broken link to an image file on the top of the page. The countdown after the reboot is initiated is nice, but is there any reason it does not auto-refresh after say, three minutes?
4. I initially used the blog post on Villagetelco.org to flash the MPs and started to configure them via the IVR. It was a little difficult to find the default IVR pin until I dug through the PDF SECN firmware document.
5. When setting the IP of the MP via the IVR for just the last octet (2662), it is required to input three digits. If you only input two or one assuming the device will presume leading zeros it fails, but it doesn't tell you why. Interestingly enough, after configuring the IP via the IVR the web interface shows three digits in the last octet (like .040) but if you configure the IP via the web interface it only shows as two digits (.40).
6. On page 17 of the current SECN firmware manual, the last line on the page says this:"Not that it is a requirement of the OpenWrt operating system that the BSSID must commence withan even number eg 02, 04, 06 etc."
Should the first word be 'Note' instead of 'Not'?
Robert Boerner
--
You received this message because you are subscribed to the Google Groups "village-telco-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/village-telco-dev/-/j_PeWb5DAM4J.
To post to this group, send email to village-...@googlegroups.com.
To unsubscribe from this group, send email to village-telco-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/village-telco-dev?hl=en.
Really destroying SIP dialog '694af5830e8a222f5c1b51ca74b866...@10.130.1.20' Method: INVITE
Really destroying SIP dialog '7fa2a2a87d48b4067ab3796938cc40...@10.130.1.40' Method: INVITE
MP-040*CLI>
Have I managed to mess up the configuration in some way, or did I find a bug? I know the firmware is still in development but I wanted to run it past the last before I filed a bug in the tracker, and quite honestly I don't know enough about Asterisk to know what I really broke.
Thanks in advance for any assistance and thank you to all of those who have contributed to this project. I am constantly amazed and how powerful the MP and how it is being put to use throughout the world.
Robert Boerner
--
You received this message because you are subscribed to the Google Groups "village-telco-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/village-telco-dev/-/j_PeWb5DAM4J.
To post to this group, send email to village-telco-dev@googlegroups.com.
To unsubscribe from this group, send email to village-telco-dev+unsubscribe@googlegroups.com.
Hi Robert
Thanks for the detailed feedback.
Just to add to Keith's comments:
1. Returning to the Basic page is 'correct' operation but agree it is desirable to return to Adv page if we can work out how to do it within the tab metaphor without losing the speed advantage of loading both pages at once.
2. Docs are lagging the firmware.
3. The page is configured to refresh at the same time interval as the counter but there is obviously something amiss and also with the image link. One thing I have found is that browser caching can make the behaviour vary also.
4. Improved docs required
5. Sounds like a bug in the 2662 handler.
Regards
Terry
--
You received this message because you are subscribed to the Google Groups "village-telco-dev" group.
To post to this group, send email to village-...@googlegroups.com.
To unsubscribe from this group, send email to village-telco-...@googlegroups.com.
Sorry for my late reply. I meant to work more on testing during the
week but life intervened.
Here is a link to a video I just made documenting the failure:
In the course of catching that on video I believe I realize the source
of the failure. Depending on what exact moment I start typing the last
octet of the IP address determines if the process fails.
If I wait a few extra seconds after Elektra stops speaking, the
process works as you describe. I am able to enter a single digit, two
digits, or three and have the process complete successfully.
If I start just after she stops speaking, but just a moment before I
hear a faint 'click' (which I assume is the end of the audio file of
her voice) the first digit of my entry is not recorded. Since in my
initial setup I was trying to set the last octet to a two digit number
with a trailing zero, this lead the Mesh Potato to think I just
entered a zero by itself and caused the failure.
When I first encountered the failure and assumed I had to enter the
last octet with leading zeros, the time it took for me to enter the
first zero was enough to allow the last two (and most important digits
in this case) be registered.
Of course I could be wrong :-)
Is it possible to have some kind of audio indicator to tell the
operator when to start the entry? Maybe after a beep on an answering
machine?
I hope you don't mind I cc'd the Village Telco Dev list on this post.
I thought it might be best to keep the thread together.
In regard to the reboot patch, anything you want me to test just let
me know. I am more than happy to try it out.
Thanks,
Bob Boerner
On Sun, Apr 22, 2012 at 4:35 AM, T Gillett <tgil...@gmail.com> wrote:
> Hi Robert
>
> I looked at the 2662 issue but it seems to be working ok for me, ie I
> can dial 1, 2 or 3 digits for the octet.
>
> The failure message will occur if the octet dialled is not in the
> range 1 to 254, or if the IP address is already in use. Unfortunately
> you get the same message in either case.
>
> Can you confirm that your test is valid, and if so could you send me
> the details of exactly how you tested so I can replicate it here
> please?
>
> Also I have done some work on the Reboot page issue and I will post a
> patch if you care to try it out.
>
> regards
> Terry
> --
> You received this message because you are subscribed to the Google
> Groups "village-telco-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/village-telco-dev/-/j_PeWb5DAM4J.
Really destroying SIP dialog '694af5830e8a222f5c1b51ca74b866...@10.130.1.20' Method: INVITE
Really destroying SIP dialog '7fa2a2a87d48b4067ab3796938cc40...@10.130.1.40' Method: INVITE
MP-040*CLI>
Have I managed to mess up the configuration in some way, or did I find a bug? I know the firmware is still in development but I wanted to run it past the last before I filed a bug in the tracker, and quite honestly I don't know enough about Asterisk to know what I really broke.
Thanks in advance for any assistance and thank you to all of those who have contributed to this project. I am constantly amazed and how powerful the MP and how it is being put to use throughout the world.
Robert Boerner
--
You received this message because you are subscribed to the Google Groups "village-telco-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/village-telco-dev/-/j_PeWb5DAM4J.
To post to this group, send email to village-telco-dev@googlegroups.com.
To unsubscribe from this group, send email to village-telco-dev+unsubscribe@googlegroups.com.
Hi Robert
Thanks for the feedback.
I have found the same issue with that particular IVR message and I believe that is the root cause of the problem. Fortunately it is fairly easy to fix by making a new recording and including a tone at the end as you suggest.
Regards
Terry
> I have found the same issue with that particular IVR message and I believe
> that is the root cause of the problem. Fortunately it is fairly easy to fix
> by making a new recording and including a tone at the end as you suggest.
I didn't like the recording anyway so made a new one with a beep at the end. Attached.
Cheers,
Elektra
--
You received this message because you are subscribed to the Google Groups "village-telco-dev" group.