CoovaChilli 1.0.12 port for FreeBSD

As v1.0.12 is finally released I’ve updated the unfinished port for the SVN builds
The todo list is kinda the same but I’m on the case this time & its fairly trivial to sort out, I just need feedback on any issues building the port & getting it up & running.

Grab the port here
If you need a main.conf to start with grab it here

Thanks to David Bird for working over the issues with coova on FreeBSD this weekend, the random coredump issue has been resolved & chilli_query now works properly aswell as coova itself! šŸ™‚
I’ve updated the port, use the link above to download & test.

Updated the port to make it build-able on FreeBSD 7.0, added rc script & sample configs, the port is nearly ready for submission, its now lacking documentation & a little cleaning up on scripts, use the link above to fetch a new copy of the port.

Tidied up the scripts by removing linux related references e.g iptables, the port has now been submitted for inclusion in the ports tree ports/130357
Use the link above to fetch a copy in the meantime.

Port Commited
Please note that the sample configs are now located in /usr/local/share/examples/cooovachilli
The chillispot port has also been updated to prevent installation of both packages.

CoovaChilli port for FreeBSD commited

11 Replies to “CoovaChilli 1.0.12 port for FreeBSD”

  1. Hi

    When running in debug mode, following is shown:
    iptables: not found

    Is there a port of iptables for FreeBSD (According to many docs, there isnt). If there isnt, please help.

    Thanks in advance.


  2. Thanks Venture37, so if not, can anyone please suggest how I can overcome this problem with coova-chilli in FreeBSD.

  3. George, the reason you where seeing error messages about iptables was because the scripts called it, the port now patches them so this should no-longer be a problem.

  4. Seeing an issue on openbsd 4.3 with msgsnd.
    The value of msg_qbytes on my openbsd is 2048, but redir.c tries to send messages up to the 8192 (Linux) limit.

    This is in the redir_msgsnd macro, leading to (for example):
    redir.c: 2407: 0 (Debug) —->>> resetting challenge: 1ec3608354d435637beef89042b06820
    redir.c: 2408: 22 (Invalid argument) msgsnd() failed! msgid=1179648 type=4 len=5302

    I am sure that the EINVAL errno crops up because the message length (5302) is greater than 2048.

    This may be specific to my build system (Soekris 4801 box); I have seen other definitions in sys/msg.h where MSGMAX is computed (often 8*2048=16384).

    Note that it isn’t possible to set msg_qbytes via IPC_SET.

    Net effect is that the original challenge reset never works and the splash login page from uamserver never gets displayed.

    I will attempt to build a custom kernel for my box with MSGMAX set appropriately, but be aware that 2048 appears to be a common setting for FreeBSD and openBSD

  5. Any chance someone can put a walk-through for getting this going under FreeBSD?

    installing the port is no worry, but i’m quite unclear as to the implications for ipfw and/or pf and how the core system should be configured.

    i am trying to migrate from coovaAP to a freebsd based gateway, as i need a server onsite for other things.

    i have a box with:
    vr0 – DHCP to the internet
    vr1 – internal LAN with access points

    i’m trying to use it as a captive portal talking to my radius server.
    i already have coovaAP working fine, so the backend work is all done.

    just need to get coovachilli running on a freebsd box and all will be well.
    (i’m quite familiar with freebsd (since 1994), but not overly conversant in linux/busybox)

    i’d appreciate some guidance.

  6. Hello!

    Have you plans to port new 1.0.14 version? It has new feature, VLAN support which is very interesting.

    And thanks for your pas work.

  7. Please port coova chilli 1.2.3
    thank you

  8. Hi

    Thanks for the port, much appreciated. I have a FreeBSD ARM-architecture based development system (See for more info), on which I tried to the build the coova-chilli port. The build was successful, and it runs for a few seconds after dhcp allocation, after which it terminates with a ‘Bus error’ message. Debugging the core dump indicated the cause to be at ippool_freeip in ippool.c, always for case 2 (static address space allocations). I was wondering if perhaps you would have any suggestions on what I could do to solve this issue (in case you are familiar with working on arm architectures). Any help would be highly appreciated, thanks.


  9. Hi

    Did some debugging and just to answer my question above (in case anyone else working on arm platform is having the same issues), specifying the ‘packed’ attribute for structs dhcp_t in dhcp.h, structs ippool_t and ippoolm_t in ippool.h helped. Now I get ‘msgsnd() failed’ during runtime, trying to see what I can do based on Stu’s post.


Comments are closed.