Hi Patrik, On 10/19/2015 09:29 AM, Patrik Flykt wrote:
> 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 > I managed to find the issue, for some reason the Connect() dbus call on the Client side never ended up getting sent, I don't know how I kept missing that, but it explains why Connman on the Client side obviously never tried to do a DHCP request. When I did the same steps in connmanctl everything worked like I expected from the beginning. I have to apologize for my inability to describe everything. Best regards // John Ernberg _______________________________________________ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
