mesh extender firmware

[Paul Gardner-Stephen]

Two more small commits to try to get the web server captive portal working again.  It should now intercept all DNS requests and show the mesh extender "don't panic" page.  If it boots without USB memory stick, it should also show a simple error page.

Paul.

[Paul Gardner-Stephen]

I have committed a few more changes that have the press-button firmware update working now:

1.  Put a serval.up on the FAT partition on the memory stick.  

2. Boot Mesh Extender.  Allow 5 or 10 minutes just to be safe.

3. Press button on PCB for <5 seconds.

4. Wait about 30 minutes while it reflashes and reinstalls everything.

Also, the captive HTTP portal should work fine again. This can be used to download the Serval Mesh application direct from the Mesh Extender.

Will be great if anyone can test at their end.

Paul.

[Claes Giljegard]

Hi,

I did a complete reinstall on one MR3020.

The captive portal works as it should.

I did a scp of serval.up to /dos and pushed the WPS button for 3 sec's.

I could see in 'top' that it started to extract the .up file and when I came back 15 minutes later it had rebooted.

ssh is no longer permitted (as it is in a fresh install)

It looks like the upgrade was successful.

Now i need to pull the usb, remove the NOROOT, ssh back in and mod the dropbear to not look at NOROOT.

One thing with the reflash script.

I need to give the root passwd several times during the install.

The copy of the ssh key is in the telnet expect script which is not run now.

Maybe the ssh and scp should be changed to pass the password?

like 

ssh <user>:<passwd>@192.168.2.1

/Claes

[Paul Gardner-Stephen]

Hello,

Glad to hear it all works for you.

Yes, entering the root password several times is really annoying. We will look to do something as you have suggested.

I think in terms of firmware function, that we now have no show-stoppers to prevent us making a release.

Paul.

--
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-dev...@googlegroups.com.
To post to this group, send email to serval-proje...@googlegroups.com.
Visit this group at http://groups.google.com/group/serval-project-developers.
For more options, visit https://groups.google.com/d/optout.

[Claes Giljegard]

Hi,

I agree. No show-stoppers.

/Claes

To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-developers+unsub...@googlegroups.com.

[Claes Giljegard]

Hi,

It seems my suggestion with 'ssh <user>:<passwd>@ip' does not work.

I know i have been using it when ftp'ing things in a browser.

You need to install sshpass on the linux host to be to do

sshpass -p '<password>' <ssh/scp command>

/Claes

[Paul Gardner-Stephen]

Hello,

The reflash-mesh-extender script now uses sshpass if it is installed to avoid you having to type "root" three times.  If it is missing, it will fall back to requiring manual entry.

Note that sshpass and generally feeding passwords into ssh via the command line is normally A Really Bad Idea(tm). The justification here is that the root password is well known, and is required to be so, but is only useful under user control via the noroot file on the USB memory stick.

Paul.

[Peyton Davari]

Hi All,

Currently I have multiple routers running the serval firmware. I have successfully gotten the routers to communicate to one another by connecting laptops to them via the adhoc IP. Is there a way to do this for the android phones via the access point IP's or do I need to find a way to bridge the two?

I was also wondering if there were any updated instructions for configuring the radios. From what I knew of the previous version the radios had to be paired with one another in some way.

Also, are the radios bridged with both adhoc traffic and access point incoming traffic or just one of them. I can't seem to find the files where these configurations or functionality are stored on the serval routers I have running now.

[Claes Giljegard]

Hi,

You need to put the serval app on your phones. Then you connect the phones to the public ap on your mesh extender and you will be able to use the serval app to send text messages and do voice between the phones.

/Claes

[Peyton Davari]

Thanks Claes. I've been able to get it to work for the phones that are all connected to the same router, but let's say I have a phone connected to one router, and another phone connected to another router. Are these two phones supposed to be able to communicate with one another via the two routers?

I can't seem to get this functionality if that is that case.

[Jeremy Lakeman]

How old is your build of servald? We had a bug that prevented mesh extenders from working properly with multiple IPv4 interfaces.

--

You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-dev...@googlegroups.com.

[Peyton Davari]

I believe it was a few weeks ago. It was after this post came out. Should I update and then it should work?

[Jeremy Lakeman]

Looks like we fixed that bug on Oct31, so it might not help.

Point a browser at port 4110 on each of the mesh extenders, that might help to work out if they are sending and receiving packets on their adhoc interfaces.

[Peyton Davari]

When I connect one laptop to each adhoc IP I am able to ping between the two. But when I have one laptop connect to each access point they can no longer ping each other.

That's why I was thinking the adhoc and access points needed to be bridged since it wasn't working. Is this how it's supposed to be?

[Jeremy Lakeman]

We don't route IP traffic between access point clients. If your laptops could ping each other on adhoc, they weren't bouncing packets off the routers at all.

Adhoc wi-fi is a messy business with multiple nasty failure modes. Getting a shell on one router and pinging the other is a much more useful metric.

[Peyton Davari]

Okay, I don't fully understand why the laptop test doesn't work, but I'll definitely try your way and let you know the results. Thanks.

My next question is if you don't route traffic via the access point then how are the android phones supposed to work? It seemed like a good simulation for how the phones would work since you can only connect to the access point.

[Jeremy Lakeman]

We built our own packet routing that works entirely in userspace.
We came up with lots of reasons for doing that;
- routing data over non-IP networks
- IP address management requiring too much specialist knowledge

- ability to run our software as an unprivileged user

- support for as many platforms as possible

- minimal setup required during random encounters in the middle of a disaster

So as long as the routers can discover and communicate with each other over adhoc (which you're obviously having trouble with), and the phones over the access point interface, our daemon should route our packets between them.

That doesn't prevent you from deploying our software on routers with more of a community network / route packets to the internet kind of focus. But that wasn't our objective.

[Peyton Davari]

Hi Jeremy,

After more testing in the way that you suggested, things seem to be working properly and the routers are communicating with one another.

My next question is what are the additional steps that are needed in order to configure the 900Mhz radios? The documentation makes it seems as if the script configures them but I don't see how. Is there any updated info I can read about how the protocol through the radios work, or how to configure a pair of them?


Thanks,
Peyton

[Paul Gardner-Stephen]

Hello,

The latest Mesh Extender firmware has a script that gets run on boot that flashes and configures the RFD900 radios if required.  In the unlikely event that this script doesn't auto-configure the radios, it can be done manually. The main thing in that case is to make sure that your RFD900 radios are configured for 115200bps.

Paul.

[Peyton Davari]

When opening a minicom session I am not able to communicate with the radio when the baud rate is configured to 115.2K but I can if the baud rate is configured to 57.6K. This led me to believe that the radios were not being flashed properly. After flashing the radios with the given binaries that are executed in your script, the problem persisted.

I believe that the default baud rate for the rfd900 radios are 57.6k, so that leads me to believe the radios are not being flashed at all. Has anyone else encountered similar problems, or have any suggestion for debugging/testing?

Thanks,
Peyton

On Monday, December 15, 2014 4:15:50 PM UTC-8, Paul Gardner-Stephen wrote:

Hello,

The latest Mesh Extender firmware has a script that gets run on boot that flashes and configures the RFD900 radios if required.  In the unlikely event that this script doesn't auto-configure the radios, it can be done manually. The main thing in that case is to make sure that your RFD900 radios are configured for 115200bps.

Paul.

On Tue, Dec 16, 2014 at 3:58 AM, Peyton Davari <pwda...@gmail.com> wrote:

Hi Jeremy,

After more testing in the way that you suggested, things seem to be working properly and the routers are communicating with one another.

My next question is what are the additional steps that are needed in order to configure the 900Mhz radios? The documentation makes it seems as if the script configures them but I don't see how. Is there any updated info I can read about how the protocol through the radios work, or how to configure a pair of them?


Thanks,
Peyton



n Wednesday, December 10, 2014 2:36:32 PM UTC-8, Jeremy Lakeman wrote:

We built our own packet routing that works entirely in userspace.
We came up with lots of reasons for doing that;
- routing data over non-IP networks
- IP address management requiring too much specialist knowledge

- ability to run our software as an unprivileged user

- support for as many platforms as possible

- minimal setup required during random encounters in the middle of a disaster

So as long as the routers can discover and communicate with each other over adhoc (which you're obviously having trouble with), and the phones over the access point interface, our daemon should route our packets between them.

--
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-developers+unsub...@googlegroups.com.

[Paul Gardner-Stephen]

If the radio is set to 57k6:

1. Connect using minicom

2. Use the AT command to set the serial speed to 115200 (ATSx=115, but I can't remember what number x should be).

3. AT&W to commit this to flash.

4. You should now be able to use the flash script.

Paul.

To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-dev...@googlegroups.com.