ODK Aggregate running on custom port - problems with ODK Collect

What is the problem? Please be detailed.

I've setup Aggregate from the VM package on my server. I have the VM setup as a NAT device, with port forwarding that forwards requests from port 1337 on the host system to port 80 on the guest device.

I can navigate a web browser to http://my.ip.address:1337/ and Aggregate loads just fine. I can login, go to submit?, and everything looks like it works great.

The problem is that when I try to configure ODK Collect on my Android device to connect to this server, I enter
http://my.ip.address:1337/ and after typing in the login details, sending forms always result in a "No route to host" error. Further, it looks like it's trying to talk on port 80 which obviously won't work. I can open a web browser to the aggregate interface on this device.

Does Collect not have a way of recognizing a custom port on the server URL?

What ODK tool and version are you using? And on what device and operating system version?

Latest ODK Aggregate and last ODK Collect from the app store. Aggregate runs as a VM on a CentOS system I have, Collect on a Samsung tablet.

What steps can we take to reproduce the problem?

Run an aggregate server on a custom port and try to connect to it with Collect.

What you have you tried to fix the problem?

I've changed the applet path to http://my.ip.address:1337/ODK/ since I thought maybe having a subfolder in the URL would help.

This all works if my aggregate server runs on port 80 (forward 80->80) but I don't want to tie up port 80 on my host.

Anything else we should know or have? If you have a test form or screenshots or logs, attach here.

Hi @Gunn777

Checkout this responce from Yaw, it may be of help

Also you are encouraged to complete your profile to make this a better community.



1 Like

Hi @Gunn777! When you installed Aggregate, it asked you for a fully qualified domain name that s publicly accessible on the Internet. You'll need to re-run the installer and put http://my.ip.address:1337 as that fully qualified domain name.

Hi @dicksonsamwel and @yanokwa,

Thank you both for the responses! I installed Aggregate via the VM installation, so I would need to find the FQDN setting if that's the case.

However, I have a sneaking suspicion that this is an issue with ODK Collect. Or, at least, an issue with my URL formatting in the Collect settings. Here's why:

  1. If I setup the VM as a bridged network adapter (where it grabs a new IP address from my network) I can successfully upload forms in collect by using the standard port 80.
  2. I can navigate successfully to the ODK Aggregate server (running on port 1337) from Chrome on my ODK Collect tablet:
  3. If I set the ODK Collect settings to http://my.ip.address:1337:
    3b) it returns an error message with the following:cap1

So I think it's trying to talk to the ODK Aggregate server on port 80, even though I am setting the port in the URL string.

I might just decide to run aggregate as a bridged VM, where it has its own IP. But there might be a situation in the future where I can't take another IP on my network so I'll be forced to use a custom port on my VM host.

thanks for the help!

The form download (but not the form listing) relies on the FQDN. If you want to use Collect to interact with Aggregate, you need to configure Aggregate with that FQDN.

I understand that you can navigate to Aggregate via your tablet's browser, but that doesn't matter in this case because, again, Aggregate uses the FQDN to build the URLs that Collect uses to download the forms. That is, it'll happily get a form list from port 1337, but it will expect to download the actual forms from port 80.


Thank you, Yaw...I will test this tomorrow and update!


Just to follow up @yanokwa:

This worked! For anyone reading this in the future, here's what I changed:

  1. On the VM, go to /var/lib/tomcat6/webapps/ROOT/WEB-INF/lib
  2. Make a temp folder, copy ODKAggregate-settings.jar to this folder
  3. unzip ODKAggregate-settings.jar in this temp folder
  4. change security.properties file to security.server.hostname = my.ip.address, security.server.port = mycustomport
  5. zip all files in temp folder back into ODKAggregate-settings.jar
  6. overwrite /var/lib/tomcat6/webapps/ROOT/WEB-INF/lib/ODKAggregate-settings.jar with this edited jar
  7. restart VM

I suppose Tomcat could overwrite\refresh these custom files with ROOT.war at some point but it seems to be working OK so far.

Thanks for the help!

1 Like

Glad it's working! I usually remove ROOT.war so there is no chance that Tomcat will overwrite the files you've changed.

1 Like

@Gunn777 I know your VM is working, but we've just shipped ODK Aggregate v1.5 Beta which has a nice little VM with some scripts that let you set the FQDN. We'd love your feedback!

1 Like

I've been struggling with issues to do with external access of my Aggregate Server. My ISP has done a static mapping from my internal address to the public IP address. So i followed your method (before i encountered this post) and edited security.properties file to reflect the outside IP address. When i enter the inside IP address,that works properly but redirects me to the outside public address after i enter authentication credentials, which of course throws a '400' error at me. I'm still working at it.