On Thu, 2015-10-15 at 09:26 +0000, John Ernberg wrote:
> > USB Host USB Gadget
> > +----------+ +----------+
> > | eth0| | |
> > | ES | USB cable | Dev |
> > | usb0|------------------|usb0 |
> > +----------+ +----------+
> > cdc_ether g_ether
> > DHCP Server DHCP Client
> >
> > Interface usb0 Always has usb0
> > created when DEVTYPE=gadget
> > gadget is connected
> > by USB cable.
> > DEVTYPE=gadget
> > in uevent file in
> > /sys/class/net/usb0
The above looks fishy. You now have a gadget-gadget connection over USB,
which is something I didn't knew existed. Which end runs ConnMan and in
which direction is the USB cable connected? Is this an USB OTG device?
> > I should have tried this much earlier, I started an udhcpc instance on the
> > USB Gadget side,
> > and that gave the interface an IP almost immediately.
On the gadget side you also run 'connmanctl enable gadget' and
'connmanctl connect gadget_XXXX' or something 100% compatible?
> > This makes me think there is something with the DHCP Client that ConnMan
> > starts on the
> > USB gadget side.
It's the same DHCP client as for all other connections. Please check
that you don't have other dhcp, ntp or dns clients running. If you have,
ConnMan's clients won't start.
> # ./tcpdump -i usb0 &
> [ 3026.487670] device usb0 entered promiscuous mode
> tcpdump: WARNING: usb0: no IPv4 address assigned
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on usb0, link-type EN10MB (Ethernet), capture size 65535 bytes
> [ 3061.146682] g_ether gadget: high-speed config #1: CDC Ethernet (ECM)
> [ 3061.196880] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
> 02:02:35.646716 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1
> group record(s), length 28
> 02:02:36.526704 IP6 :: > ff02::1:ff00:1011: ICMP6, neighbor solicitation, who
> has fe80::ff:fe00:1011, length 24
> 02:02:37.526725 IP6 fe80::ff:fe00:1011 > ff02::2: ICMP6, router solicitation,
> length 16
> 02:02:41.536686 IP6 fe80::ff:fe00:1011 > ff02::2: ICMP6, router solicitation,
> length 16
> 02:02:43.866697 IP6 fe80::ff:fe00:1011 > ff02::16: HBH ICMP6, multicast
> listener report v2, 1 group record(s), length 28
> 02:02:45.546687 IP6 fe80::ff:fe00:1011 > ff02::2: ICMP6, router solicitation,
> length 16
> 02:02:51.224212 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1
> group record(s), length 28
> 02:02:52.254225 IP6 fe80::ff:fe02:1201 > ff02::2: ICMP6, router solicitation,
> length 16
> 02:02:52.304195 IP6 fe80::ff:fe02:1201 > ff02::16: HBH ICMP6, multicast
> listener report v2, 1 group record(s), length 28
> 02:02:56.264202 IP6 fe80::ff:fe02:1201 > ff02::2: ICMP6, router solicitation,
> length 16
> 02:03:00.274210 IP6 fe80::ff:fe02:1201 > ff02::2: ICMP6, router solicitation,
> length 16
> 02:03:01.534275 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 2
> group record(s), length 48
> 02:03:01.754226 IP6 :: > ff02::1:ff7c:e91f: ICMP6, neighbor solicitation, who
> has fe80::886c:91ff:fe7c:e91f, length 24
> 02:03:02.754255 IP6 fe80::886c:91ff:fe7c:e91f > ff02::2: ICMP6, router
> solicitation, length 16
> 02:03:06.764221 IP6 fe80::886c:91ff:fe7c:e91f > ff02::2: ICMP6, router
> solicitation, length 16
> 02:03:09.834262 IP6 fe80::886c:91ff:fe7c:e91f > ff02::16: HBH ICMP6,
> multicast listener report v2, 1 group record(s), length 28
> 02:03:10.774317 IP6 fe80::886c:91ff:fe7c:e91f > ff02::2: ICMP6, router
> solicitation, length 16
>From the above one does not know whether the device is tethering or not.
If tethering is enabled, the interface to tcpdump is 'tether'. Which
device is this, USB "host" which now is a gadget according to the above
or the USB gadget device...? And why are you backgrounding the tcpdump
command?
> # udhcpc -i usb0
If this is the next command, you're on the same device. I don't think
this is the case, but there is nothing indicating otherwise either.
> udhcpc (v1.22.1) started
> Sending discover...
> Sending select for 192.168.0.2...
> Lease of 192.168.0.2 obtained, lease time 86400
> /etc/udhcpc.d/50default: Adding DNS 192.168.0.1
> 02:04:48.286721 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
> Request from 02:00:00:00:10:11 (oui Unknown), length 300
> 02:04:48.324435 IP 192.168.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP,
> Reply, length 548
> 02:04:48.366696 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
> Request from 02:00:00:00:10:11 (oui Unknown), length 300
> 02:04:48.404440 IP 192.168.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP,
> Reply, length 548
> 02:04:48.733158 ARP, Request who-has 192.168.0.1 tell 192.168.0.2, length 28
> 02:04:48.733448 ARP, Reply 192.168.0.1 is-at 02:00:00:02:12:01 (oui Unknown),
> length 28
> 02:04:48.733486 IP 192.168.0.2.60101 > 192.168.0.1.domain: 27667+ PTR?
> 0.0.0.0.in-addr.arpa. (38)
> 02:04:48.737303 IP 192.168.0.1.domain > 192.168.0.2.60101: 27667 ServFail-
> 0/0/0 (38)
> 02:04:48.737657 IP 192.168.0.2.34812 > 192.168.0.1.domain: 27667+ PTR?
> 0.0.0.0.in-addr.arpa. (38)
> 02:04:48.741111 IP 192.168.0.1.domain > 192.168.0.2.34812: 27667 ServFail-
> 0/0/0 (38)
> 02:04:48.741467 IP 192.168.0.2.39136 > 192.168.0.1.domain: 28579+ PTR?
> 255.255.255.255.in-addr.arpa. (46)
> 02:04:48.742805 IP 192.168.0.1.domain > 192.168.0.2.39136: 28579 ServFail-
> 0/0/0 (46)
> 02:04:48.742983 IP 192.168.0.2.54389 > 192.168.0.1.domain: 28579+ PTR?
> 255.255.255.255.in-addr.arpa. (46)
> 02:04:48.749828 IP 192.168.0.1.domain > 192.168.0.2.54389: 28579 ServFail-
> 0/0/0 (46)
> 02:04:48.750434 IP 192.168.0.2.47298 > 192.168.0.1.domain: 30038+ PTR?
> 1.0.168.192.in-addr.arpa. (42)
> 02:04:48.757854 IP 192.168.0.1.domain > 192.168.0.2.47298: 30038 ServFail-
> 0/0/0 (42)
> 02:04:48.758063 IP 192.168.0.2.49953 > 192.168.0.1.domain: 30038+ PTR?
> 1.0.168.192.in-addr.arpa. (42)
> 02:04:48.765064 IP 192.168.0.1.domain > 192.168.0.2.49953: 30038 ServFail-
> 0/0/0 (42)
> 02:04:49.766984 IP 192.168.0.2.48934 > 192.168.0.1.domain: 457+ PTR?
> 2.0.168.192.in-addr.arpa. (42)
> 02:04:49.767719 IP 192.168.0.1.domain > 192.168.0.2.48934: 457 ServFail-
> 0/0/0 (42)
> 02:04:49.767914 IP 192.168.0.2.38700 > 192.168.0.1.domain: 457+ PTR?
> 2.0.168.192.in-addr.arpa. (42)
> 02:04:49.771230 IP 192.168.0.1.domain > 192.168.0.2.38700: 457 ServFail-
> 0/0/0 (42)
> 02:04:53.744389 ARP, Request who-has 192.168.0.2 tell 192.168.0.1, length 28
> 02:04:53.744452 ARP, Reply 192.168.0.2 is-at 02:00:00:00:10:11 (oui Unknown),
> length 28
So someone is handing giving addresses. Good. What is giving out
addresses is unknown, though. Is it ConnMan or something else?
Could you list the set of connmanctl commands you end up using when
setting up the connection between the devices? I.e. omitting all
automatic features from main.conf.
I'm still thoroughly confused what is running on which device.
Cheers,
Patrik
_______________________________________________
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
