SECN Firmware 1.1RC2 Questions/Notes

55 views
Skip to first unread message

Robert.Boerner

unread,
Apr 15, 2012, 8:23:04 PM4/15/12
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 '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

Keith Williamson

unread,
Apr 15, 2012, 9:11:11 PM4/15/12
to village-...@googlegroups.com
Hi Robert,

Excellent feedback. Thanks!

Please comments in-line below.

Cheers,

Keith

On Sun, Apr 15, 2012 at 5:23 PM, Robert.Boerner <robert....@gmail.com> wrote:
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:

I believe it is but I've been meaning to bring that issue up also since I almost always do everything from the Advanced tab.
 
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.

This is just a case of the SECN development getting ahead of the documentation. We switched to SSH with default login/passwd vs Telnet until you set the root passwd.
 
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?

I'll defer to Terry and Steve on this one. 

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?

We'll check to make sure that the default pin is highlighted in the doc.
 
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.

We should probably either fix this or indicate in the IVR voice instructions to enter 3-digits for the last octet.
 
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). 

Yep..should read "Note"
 
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'?


The bad SIP file descriptor is typically the result of the default gateway IP address being unreachable by asterisk. What do you have your gateway address set to? Since you are using the default lan network address of 10.130.1.0 in your examples, the gateway address should be on that net or ping-able from 10.130.1.40. Since you used the find gateway button, it would seem we may have an issue still with that feature. It's most likely related to bug #1 on the tracker (IVR config appears to overwrite gateway setting). That is, even though you ran "find gateway", the result (if correct) didn't get applied. Can you send us the contents of your /etc/config/network and /etc/config/secn files? Also, the output of "route -n".

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.

Keith Williamson

unread,
Apr 15, 2012, 9:36:04 PM4/15/12
to village-...@googlegroups.com
Hi again,

It appears that the logic of the testgw.sh helper script implicitly trusts the gateway address returned from the first responding DHCP server. Thus, it could get an address of the DHCP server that is an unreachable address.

However, what I can't fathom is why your 10.130.1.20 and 10.130.1.30 nodes are OK and only your 10.130.1.40 node is affected (unless the IVR bug is either exacerbating or mitigating the bad gateway issue). Since you used the IVR to set the IP address of just the 10.130.1.30 and 10.130.1.40 nodes, the existing IVR bug should only affect those. So that would lead one to suspect you would have the same behavior (either broken or working) on the .30 and .40 nodes and potentially different behavior by the .20 node.

Hmm..

Cheers,

Keith

Keith Williamson

unread,
Apr 15, 2012, 9:56:13 PM4/15/12
to village-...@googlegroups.com
Hi Robert,

Rereading your email, I see you said that "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." This starts to make sense then. Your MAC gets a good address from your DHCP server which works with the gateway address from that DHCP server, so it is able to get to the Internet. The MP mesh is simply providing layer-2 switching in that case. However, the .40 machine got the gateway and dns server addresses from the DHCP server but not it's IP address. Asterisk on the .40 node is failing because the gateway address is unreachable from the 10.130.1.0 network. Since you didn't indicate that you used the "find gateway" feature for the .20 and .30 nodes, they would work fine.

If you just set the gateway address in /etc/config/network on the .40 node to what it's set for on the .20 and .30 node, the asterisk issue should be resolved.

We definitely need to rethink the "find gateway" feature. It was meant to help out under the assumption that the DHCP server is supplying IP address parameters for the local br-lan network. You've brought up a valid usage model that nevertheless poisons asterisk.

Cheers,

Keith

Robert.Boerner

unread,
Apr 15, 2012, 11:00:44 PM4/15/12
to village-...@googlegroups.com
Hi Keith,

Thank you for the many replies. Having read through all of them, it makes perfect sense now why Asterisk is failing. I have attached the contents of the requested files in a single text document attached to this post. I obviously misunderstood the functionality of the Find Gateway function. I assumed that it would set an additional route out to the internet only when it was necessary and leave the rest of the mesh and other functionality alone. I haven't had a chance to reset the configuration file with what should be the default gateway from the other two MPs but I am sure it will work to fix Asterisk, but I am unclear if the rest of it will function in the way I imagine it would. Tomorrow night I will do some more experimenting and re-read the docs again. 

Thank you again very much for your detailed replies.  Please let me know if there is any other information I might provide.

Robert Boerner

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.
Mesh Potato Config Files.rtf

T Gillett

unread,
Apr 16, 2012, 2:54:09 AM4/16/12
to village-...@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

Song, Stephen

unread,
Apr 16, 2012, 4:37:40 AM4/16/12
to village-...@googlegroups.com
Hi Robert,

Great to have you back!  and many thanks for taking the time to both test and report 1.1RC2!

I've corrected the IVR docs at http://villagetelco.org/get-started/call-to-configure/  and I've added your reports to the bug tracker at 


as well as some others reported privately.

Can I implore everyone reporting bugs, issues, etc regarding the 1.1RC2 firmware to post them there?  No problem reporting them to the list as well but the bug tracker will help us make sure we address every one.

Cheers... Steve

--
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.

For more options, visit this group at http://groups.google.com/group/village-telco-dev?hl=en.

Robert Boerner

unread,
Apr 22, 2012, 6:18:33 PM4/22/12
to T Gillett, village-...@googlegroups.com
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

> --
> 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.

Robert.Boerner

unread,
Apr 22, 2012, 6:25:34 PM4/22/12
to village-...@googlegroups.com
Hi Keith,

Sorry for the late reply. I did as you suggested and changed the gateway back to what the other two units have registered (10.130.1.1) and I can now dial between all three units properly. Connected only to the AP from from of the MPs I am still able to connect to the internet, so 'everything works'.

Perhaps I am just showing my ignorance, can you explain in a little more detail what the Find Gateway feature is supposed to do? I know you stated:

"It was meant to help out under the assumption that the DHCP server is supplying IP address parameters for the local br-lan network."

But I am not sure I understand what problem that it is meant to help solve. I am not questioning the design, I am just readying admitting I do not understand :-)

Can you expound on the process for me?

Thanks,

Bob


On Sunday, April 15, 2012 6:56:13 PM UTC-7, Keith Williamson wrote:

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.

T Gillett

unread,
Apr 22, 2012, 9:52:20 PM4/22/12
to Robert Boerner, village-telco-dev

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

Elektra

unread,
Apr 23, 2012, 11:31:54 AM4/23/12
to village-...@googlegroups.com
Hi -

> 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

enter-last-octet.gsm

Keith Williamson

unread,
Apr 23, 2012, 12:12:28 PM4/23/12
to village-...@googlegroups.com
Hi Elektra,

It sounds quite good..and who knew you could beep so well?! 

I'll add it to the RC3 builds. 

Thanks!

Keith

--
You received this message because you are subscribed to the Google Groups "village-telco-dev" group.
Reply all
Reply to author
Forward
0 new messages