Hi Olliver,

On ti, 2014-10-07 at 12:50 +0200, Olliver Schinagl wrote:
> Hey Jukka,
> 
> On 07-10-14 12:06, Jukka Rissanen wrote:
> > Hi Olliver,
> >
> > On ti, 2014-10-07 at 10:44 +0200, Olliver Schinagl wrote:
> >> Hey list,
> >>
> >> for our embedded project, we are trying to use connman to take care of
> >> all the basic networking.
> >>
> >> Currently, connman is used in tethering mode to setup an access point
> >> for initial configuration of the device. We use an app for that and
> >> right now, it seems that connman's dhcp server uses a random IP for
> >> itself (ip range is of no importance). As you can guess, on some mobile
> >> OSes getting things like gateway or DHCP server information is next to
> >> impossible, we can only get our own IP.
> >>
> >> What we wanted to do, is use a dns record, connect.ultimaker.com, which
> >> points at a real site to which the app can connect. If the connection
> >> succeeds, something went wrong as we are not talking to the connman host
> >> directly. So our first plan was to have connman's dnsproxy answer to
> >> connect.ultimaker.com with its own randomly selected IP. I have found
> >> out that connman however does not support injecting DNS records into its
> >> cache. So first question is, does connman have a hostname that points to
> >> itself to obtain the tether IP from?
> > I have used avahi and mdns to do just that. So the host where connman is
> > running is also running avahi and then that host can be connected as
> > your-hostname.local from tethering client.
> Ah yes of course! We are going to use avahi eventually, so that can 
> probably used indeed! Just for my information, avahi daemon knows its IP 
> as soon as it is set by connmand, an ahavi client announces to the 
> network that it's here and listening (which is cleaner then just looking 
> for the daemon?) mdns listens on all interfaces on port 53 like a 
> regular DNS server allowing name resolution?

Only connman is listening on 53 as seen in this listing (I am tethering
wifi in this example)

root@eca:~# lsof -i :53 -n
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
connmand 350 root   10u  IPv4  14030      0t0  UDP 127.0.0.1:domain 
connmand 350 root   11u  IPv6  14034      0t0  UDP [::1]:domain 
connmand 350 root   12u  IPv4  14038      0t0  TCP 127.0.0.1:domain
(LISTEN)
connmand 350 root   13u  IPv6  14042      0t0  TCP [::1]:domain (LISTEN)
connmand 350 root   18u  IPv4  16451      0t0  UDP 192.168.0.1:domain 
connmand 350 root   19u  IPv4  16462      0t0  TCP 192.168.0.1:domain
(LISTEN)

avahi is listening on these ports in my test setup

avahi-dae  324          avahi   12u     IPv4      13879      0t0
UDP *:mdns 
avahi-dae  324          avahi   13u     IPv4      13880      0t0
UDP *:45638 
r

Avahi does its magic nicely and can co-exists with connman without any
problems.

> >> Secondly, assuming the first thing fails, we where looking for if
> >> connman has a method to redirect all traffic to a landing page of some
> >> sort, wasn't wispr something used for this? This would work equally well
> >> as the name resolving part I expect and allows for webbrowers to get a
> >> usefull page when connected to the landing page.
> > No such feature exists in connman. We are only supporting wispr when
> > connman acts as a client.
> Alright, fair enough.
> >
> >> Thirdly, we where then thinking of using a tun device, with a static IP
> >> and putting that in the tether group, allowing the device always to be
> >> reached on a fixed address and then disable connman's proxy cache and
> >> use dnsmasq to have the dns address to the tun device IP. The question
> >> here would then be, connman only uses resolv.conf to find the real dns
> >> server before replacing it with itself? E.g. no port can be specified
> >> right? (e.g. dnsmasq + connman living happily together, ugly but could
> >> work).
> > If you disable connman dnsproxy, then you can run dnsmasq in the same
> > host.
> and mdns right?

Sure, no issues there.

> >
> >> Lastly I suppose, if nothing in the above can be used to solve this
> >> issue (except for a patch which in time may come) any other thoughts of
> >> tackle the problem for a connected tethering client to connect to the
> >> tether host.
> > avahi+mdns would be the easiest choice if your client OS supports that.
> linux is our OS of choice!

I like your choices :)


Cheers,
Jukka


_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman

Reply via email to