Google Groups

Re: [vt-dev] SECN Firmware 1.1RC2 Questions/Notes


Robert.Boerner Apr 22, 2012 3:18 PM
Posted in group: Village Telco Development Community
Hi Terry,

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:

http://youtu.be/ThgjoPVj6wI

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
>
>
> ---------- Forwarded message ----------
> From: Robert.Boerner <robert....@gmail.com>
> Date: Mon, Apr 16, 2012 at 10:23 AM
> Subject: [vt-dev] SECN Firmware 1.1RC2 Questions/Notes
> To: village-...@googlegroups.com
>
>
> 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 with
>
> 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
> '694af5830e8a222f5c1b51ca74b866b1@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
> '7fa2a2a87d48b4067ab3796938cc40b1@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-...@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.