Re: How to provide DHCP on a technology
Hi Patrik, On 10/19/2015 09:29 AM, Patrik Flykt wrote: > On Thu, 2015-10-15 at 09:26 +, John Ernberg wrote: > >>> USB Host USB Gadget >>> +--+ +--+ >>> | eth0| | | >>> |ES|USB cable |Dev | >>> | usb0|--|usb0 | >>> +--+ +--+ >>> cdc_ether g_ether >>> DHCP ServerDHCP 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_' 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
Re: How to provide DHCP on a technology
On Thu, 2015-10-15 at 09:26 +, John Ernberg wrote: > > USB Host USB Gadget > > +--+ +--+ > > | eth0| | | > > |ES|USB cable |Dev | > > | usb0|--|usb0 | > > +--+ +--+ > >cdc_ether g_ether > >DHCP ServerDHCP 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_' 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
Re: How to provide DHCP on a technology
Hi Patrik, On 10/14/2015 03:20 PM, Patrik Flykt wrote: > Hi, > > On Wed, 2015-10-14 at 13:09 +, John Ernberg wrote: >> All I know is that cdc_ether interfaces shows up as usb0, the eth0 >> ethernet is a real ethernet port. When looking in /sys/class/net/usb0 >> it indeed shows up as a gadget in the uevent file. > This now looks like you are connecting an USB client end on the USB host > system to a USB client on the USB client system. A USB client - USB > client connection between two devices won't work. If this is a correct > interpretation of your setup, the USB controller on the USB host system > needs to be configured to support USB host and not USB client as it > looks like its doing now. > > I think we need to start drawing figures in ascii art to get the picture > complete, there are too many USBs in the explanation above... USB Host USB Gadget +--+ +--+ | eth0| | | |ES|USB cable |Dev | | usb0|--|usb0 | +--+ +--+ cdc_ether g_ether DHCP ServerDHCP 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 > Cheers, > > Patrik > > > ___ > connman mailing list > connman@connman.net > https://lists.connman.net/mailman/listinfo/connman However, progress! 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. This makes me think there is something with the DHCP Client that ConnMan starts on the USB gadget side. So I enabled DHCP debug logging in ConnMan on the USB Gadget side, and turned on regular debug prints, and I don't see any DHCP activity. Did I miss to enable some setting in ConnMan, or in the debug logging? Is there something specific I should be looking for in the ConnMan logs to understand why it doesn't work? Thank you in advance and best regards // John Ernberg ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: How to provide DHCP on a technology
Hi again Patrik, I decided to tcpdump the connection, just in case that would help. Attached the output below. Best regards // John Ernberg On 10/15/2015 09:57 AM, John Ernberg wrote: > Hi Patrik, > > On 10/14/2015 03:20 PM, Patrik Flykt wrote: > >> Hi, >> >> On Wed, 2015-10-14 at 13:09 +, John Ernberg wrote: >>> All I know is that cdc_ether interfaces shows up as usb0, the eth0 >>> ethernet is a real ethernet port. When looking in /sys/class/net/usb0 >>> it indeed shows up as a gadget in the uevent file. >> This now looks like you are connecting an USB client end on the USB host >> system to a USB client on the USB client system. A USB client - USB >> client connection between two devices won't work. If this is a correct >> interpretation of your setup, the USB controller on the USB host system >> needs to be configured to support USB host and not USB client as it >> looks like its doing now. >> >> I think we need to start drawing figures in ascii art to get the picture >> complete, there are too many USBs in the explanation above... > USB Host USB Gadget > +--+ +--+ > | eth0| | | > |ES|USB cable |Dev | > | usb0|--|usb0 | > +--+ +--+ >cdc_ether g_ether >DHCP ServerDHCP 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 > >> Cheers, >> >> Patrik >> >> >> ___ >> connman mailing list >> connman@connman.net >> https://lists.connman.net/mailman/listinfo/connman > However, progress! > 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. > This makes me think there is something with the DHCP Client that ConnMan > starts on the > USB gadget side. > So I enabled DHCP debug logging in ConnMan on the USB Gadget side, and turned > on regular debug prints, > and I don't see any DHCP activity. Did I miss to enable some setting in > ConnMan, or in the debug logging? > Is there something specific I should be looking for in the ConnMan logs to > understand why it doesn't work? > > Thank you in advance and best regards // John Ernberg > ___ > connman mailing list > connman@connman.net > https://lists.connman.net/mailman/listinfo/connman # ./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 # udhcpc -i usb0 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
Re: How to provide DHCP on a technology
Hi Patrik, On 10/13/2015 11:32 AM, Patrik Flykt wrote: > Hi, > > On Tue, 2015-10-13 at 08:49 +, John Ernberg wrote: > >> ConnMan runs on the embedded system, which is the USB host side. >> And when an USB gadget connects, I want to start a DHCP server on the >> interface provided by cdc_ether so that the USB gadget that connects >> can receive an IP by using a DHCP client. > USB host side is counted as a regular ethernet. So 'ethernet' tethering > is the one you want to configure. > >> I have parts of the file system as read only, so ConnMan does not >> remember things between reboots. > ConnMan stores its technology state into /var/lib/connman/settings, if > this file is not perserved over reboots maybe tmpfiles from systemd can > create a suitable one into that directory? Or some other shell scripting > during boot. I made a ramdisk out of /var/ when I made the file system read only. Nothing is however preserved after a reboot, and that has not been problem for me yet. >>> The networks that show up as services are the ones where ConnMan is a >>> end host/client. Tethering creates a local network bridge, 'tether', and >>> starts a DHCP server on it. The tethered network does not show up as a >>> service, as it is not an upstream connection. >> Ok, got it. I found the tether interface, the USB gadget side does not >> receive an IP however. > In the USB client/gadget end, especially when running Linux also here, > it usually is a matter of being able to (automatically) load the proper > drivers for the gadget device. It also is a matter of USB client mode > setting, the USB client/gadget is probably registered automatically for > some other (Linux kernel module) profile instead of networking. I attached some dumps at the bottom, because after 10 minutes I have still not received an IP on the USB gadget end. I made sure that the USB host side loaded cdc_ether and that the USB gadget side loaded g_ether. >> Could this be caused by that we do not always have any other active >> connections? > The upstream connections in ConnMan, i.e. services, do not need to be > enabled for thethering to work. Only routing/internet connectivity is > affected by the presence or absence of a connected service. > >> I.e. should this be done differently if I want to have a connection >> that is end-to-end, without bridging? > The connection between the USB host device running ConnMan and the other > device with the USB client connection already provide an end-to-end > connection over IP. If ConnMan has an service connected providing an > upstream internet connection, ConnMan sets up a NAT to get the tethered > devices connecting to the internet. The brigde interface comes into play > as it is the smartest way of connecting all tethering technologies and > interfaces into one network served by a single DHCP server. On the > winning side all devices tethered can now connect to each other via IP, > be they connected via Bluetooth, USB, ethernet or wifi. If I have other services that reach the internet, and possibly want to tether on these in the future, but want to keep this link private (not share it with the other connections). Would this then be out of scope for what ConnMan is designed for? > > Cheers, > > Patrik > > ___ > connman mailing list > connman@connman.net > https://lists.connman.net/mailman/listinfo/connman Thank you and best regards // John Ernberg I had to obfuscate the MAC addresses, but it should still give a picture of what the setup looks like. Our cdc_ether driver publishes the Ethernet-over-USB interface as usb0, and shows up in ConnMan as a gadget technology. USB Host side: eth0 Link encap:Ethernet HWaddr yy:yy:yy:yy:yy:yy UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) tetherLink encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::d838:94ff:fe48:389b/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:364 (364.0 B) TX bytes:620 (620.0 B) usb0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx inet6 addr: fe80::ff:fe02:1201/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:11 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:748 (748.0 B) TX bytes:132 (132.0
Re: How to provide DHCP on a technology
On Wed, 2015-10-14 at 06:40 +, John Ernberg wrote:
> I made a ramdisk out of /var/ when I made the file system read only.
> Nothing is however preserved after a reboot, and that has not been
> problem for me yet.
That's actually a problem, as /var (especially /var/lib) is the only
location that per definition can hold application state over reboot. In
this case it presents a problem, as ConnMan will now not know its state
over reboot. /var/run (or /run) is the proper location for run-time
data, which can be cleared.
> If I have other services that reach the internet, and possibly want to
> tether on these in the future, but want to keep this link private (not
> share it with the other connections). Would this then be out of scope
> for what ConnMan is designed for?
What do you mean by keeping the link private?
> I had to obfuscate the MAC addresses, but it should still give a
> picture of what the setup looks like. Our cdc_ether driver publishes
> the Ethernet-over-USB interface as usb0, and shows up in ConnMan as a
> gadget technology.
> USB Host side:
> eth0 Link encap:Ethernet HWaddr yy:yy:yy:yy:yy:yy
>UP BROADCAST MULTICAST MTU:1500 Metric:1
>RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>collisions:0 txqueuelen:1000
>RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
>
> tetherLink encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
>inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
>inet6 addr: fe80::d838:94ff:fe48:389b/64 Scope:Link
>UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>RX packets:5 errors:0 dropped:0 overruns:0 frame:0
>TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
>collisions:0 txqueuelen:0
>RX bytes:364 (364.0 B) TX bytes:620 (620.0 B)
>
> usb0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
>inet6 addr: fe80::ff:fe02:1201/64 Scope:Link
>UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>RX packets:11 errors:0 dropped:0 overruns:0 frame:0
>TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
>collisions:0 txqueuelen:1000
>RX bytes:748 (748.0 B) TX bytes:132 (132.0 method)
Thethering has been enabled on the USB host. If you enabled 'ethernet'
technology tethering, eth0 will be tethered. If you enabled 'gadget'
tethering usb0 will be tethered. The fact that usb0 shows up with an
IPv6 address makes me think that ethernet tethering is enabled.
So your USB host end also has a gadget connector??
> return sender=:1.2 -> dest=:1.22 reply_serial=2
> array [
>struct {
> object path "/net/connman/technology/gadget"
> array [
> dict entry(
> string "Name"
> variant string "Gadget"
> )
> dict entry(
> string "Type"
> variant string "gadget"
> )
> dict entry(
> string "Powered"
> variant boolean true
> )
> dict entry(
> string "Connected"
> variant boolean false
> )
> dict entry(
> string "Tethering"
> variant boolean true
> )
> ]
>}
Gadget is tethering. Which means this is the USB client end. If it's the
same situation as above, there is a bug somewhere as usb0 should not
have an IP address.
>struct {
> object path "/net/connman/technology/ethernet"
> array [
> dict entry(
> string "Name"
> variant string "Wired"
> )
> dict entry(
> string "Type"
> variant string "ethernet"
> )
> dict entry(
> string "Powered"
> variant boolean true
> )
> dict entry(
> string "Connected"
> variant boolean false
> )
> dict entry(
> string "Tethering"
> variant boolean false
> )
> ]
>}
Ok, ethernet is not tethering. Is this the same situation as above where
you listed the interfaces? Networks created in the USB host end of
things will show up as 'ethernet' devices.
> USB gadget side:
> usb0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
>inet6 addr: fe80::ff:fe00:1011/64 Scope:Link
>UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>RX packets:2
Re: How to provide DHCP on a technology
Hi Patrik
On 10/14/2015 10:21 AM, Patrik Flykt wrote:
> On Wed, 2015-10-14 at 06:40 +, John Ernberg wrote:
>
>> I made a ramdisk out of /var/ when I made the file system read only.
>> Nothing is however preserved after a reboot, and that has not been
>> problem for me yet.
> That's actually a problem, as /var (especially /var/lib) is the only
> location that per definition can hold application state over reboot. In
> this case it presents a problem, as ConnMan will now not know its state
> over reboot. /var/run (or /run) is the proper location for run-time
> data, which can be cleared.
How would it be a problem? I can re-configure the interface every start-up,
it's not a problem for me.
>> If I have other services that reach the internet, and possibly want to
>> tether on these in the future, but want to keep this link private (not
>> share it with the other connections). Would this then be out of scope
>> for what ConnMan is designed for?
> What do you mean by keeping the link private?
Not letting the link have access to the internet, while other technologies,
which may in the future also tether, have access to the internet.
>> I had to obfuscate the MAC addresses, but it should still give a
>> picture of what the setup looks like. Our cdc_ether driver publishes
>> the Ethernet-over-USB interface as usb0, and shows up in ConnMan as a
>> gadget technology.
>> USB Host side:
>> eth0 Link encap:Ethernet HWaddr yy:yy:yy:yy:yy:yy
>> UP BROADCAST MULTICAST MTU:1500 Metric:1
>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
>>
>> tetherLink encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
>> inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
>> inet6 addr: fe80::d838:94ff:fe48:389b/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:5 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:0
>> RX bytes:364 (364.0 B) TX bytes:620 (620.0 B)
>>
>> usb0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
>> inet6 addr: fe80::ff:fe02:1201/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:11 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:748 (748.0 B) TX bytes:132 (132.0 method)
> Thethering has been enabled on the USB host. If you enabled 'ethernet'
> technology tethering, eth0 will be tethered. If you enabled 'gadget'
> tethering usb0 will be tethered. The fact that usb0 shows up with an
> IPv6 address makes me think that ethernet tethering is enabled.
>
> So your USB host end also has a gadget connector??
All I know is that cdc_ether interfaces shows up as usb0, the eth0 ethernet is
a real ethernet port.
When looking in /sys/class/net/usb0 it indeed shows up as a gadget in the
uevent file.
>
>
>> return sender=:1.2 -> dest=:1.22 reply_serial=2
>> array [
>> struct {
>>object path "/net/connman/technology/gadget"
>>array [
>> dict entry(
>> string "Name"
>> variant string "Gadget"
>> )
>> dict entry(
>> string "Type"
>> variant string "gadget"
>> )
>> dict entry(
>> string "Powered"
>> variant boolean true
>> )
>> dict entry(
>> string "Connected"
>> variant boolean false
>> )
>> dict entry(
>> string "Tethering"
>> variant boolean true
>> )
>>]
>> }
> Gadget is tethering. Which means this is the USB client end. If it's the
> same situation as above, there is a bug somewhere as usb0 should not
> have an IP address.
I only listed Technologies on the USB host side.
>> struct {
>>object path "/net/connman/technology/ethernet"
>>array [
>> dict entry(
>> string "Name"
>> variant string "Wired"
>> )
>> dict entry(
>> string "Type"
>> variant string "ethernet"
>> )
>> dict entry(
>> string "Powered"
>> variant boolean true
>> )
>>
Re: How to provide DHCP on a technology
Hi, On Wed, 2015-10-14 at 13:09 +, John Ernberg wrote: > All I know is that cdc_ether interfaces shows up as usb0, the eth0 > ethernet is a real ethernet port. When looking in /sys/class/net/usb0 > it indeed shows up as a gadget in the uevent file. This now looks like you are connecting an USB client end on the USB host system to a USB client on the USB client system. A USB client - USB client connection between two devices won't work. If this is a correct interpretation of your setup, the USB controller on the USB host system needs to be configured to support USB host and not USB client as it looks like its doing now. I think we need to start drawing figures in ascii art to get the picture complete, there are too many USBs in the explanation above... Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: How to provide DHCP on a technology
Hi Patrik, On 10/13/2015 10:21 AM, Patrik Flykt wrote: > Hi, > > On Mon, 2015-10-12 at 14:26 +, John Ernberg wrote: > >> I'm using Connman in an embedded environment where a device will connect >> to us over USB, this device will provide an ethernet interface on the >> USB port, and the device will be in gadget mode. >> Thus when they connect to us we load the cdc_ether driver and create an >> Ethernet interface over the USB port. >> >> Being completely new to tethering in Connman and how it works, I'm >> having some issues setting up Connman to provide a DHCP server on this >> interface so the other device will receive an IP automatically once it >> starts a DHCP client. > If I understood the above thing correctly, ConnMan runs on a device that > has a USB client and ConnMan needs to set up a DHCP server on it? ConnMan runs on the embedded system, which is the USB host side. And when an USB gadget connects, I want to start a DHCP server on the interface provided by cdc_ether so that the USB gadget that connects can receive an IP by using a DHCP client. > This > is achieved by ensuring that both 'gadget' technology and 'gadget' > tethering are enabled. Also verify that the interface is not listed > in /etc/connman/main.conf NetworkInterfaceBlacklist option and that > 'gadget' is either listed in TetheringTechnologies or > TetheringTechnologies is unset. I ensured that this is already configured as suggested in the /etc/connman/main.conf. > > Now that the 'gadget' technology has been enable once, ConnMan will > remember its enabled state over reboots. With that in mind, one can then > set PersistentTetheringMode to true in /etc/connman/main.conf. This > preserves tethering state for all technologies over reboot, including > 'gadget'. I have parts of the file system as read only, so ConnMan does not remember things between reboots. > > If it is the opposite, i.e. ConnMan runs on the USB host end, the > procedure is the same, but the technology is instead 'ethernet'. This > affects the all ethernet devices on the machine, as USB ethernet dongles > are indistinguishable from internal PCI connected ones. This is configured as well in the /etc/connman/main.conf > > The networks that show up as services are the ones where ConnMan is a > end host/client. Tethering creates a local network bridge, 'tether', and > starts a DHCP server on it. The tethered network does not show up as a > service, as it is not an upstream connection. Ok, got it. I found the tether interface, the USB gadget side does not receive an IP however. Could this be caused by that we do not always have any other active connections? I.e. should this be done differently if I want to have a connection that is end-to-end, without bridging? > >> I have googled and read the documentation but I cannot figure out how to >> do this properly. >> The current method on the server side is to enable the gadget-technology >> when it shows up, configure an IP, netmask and gateway, and then enable >> tethering on it. Which results in the services not being listable, and >> no IP being given to the other side. If I run ifconfig on my side, the >> interface is up, but unconfigured. > Here I lost track of which device is which. Please check the above and > see if that fixes your problem. > > Cheers, > > Patrik > > ___ > connman mailing list > connman@connman.net > https://lists.connman.net/mailman/listinfo/connman Thank you and best regards // John Ernberg ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: How to provide DHCP on a technology
Hi, On Mon, 2015-10-12 at 14:26 +, John Ernberg wrote: > I'm using Connman in an embedded environment where a device will connect > to us over USB, this device will provide an ethernet interface on the > USB port, and the device will be in gadget mode. > Thus when they connect to us we load the cdc_ether driver and create an > Ethernet interface over the USB port. > > Being completely new to tethering in Connman and how it works, I'm > having some issues setting up Connman to provide a DHCP server on this > interface so the other device will receive an IP automatically once it > starts a DHCP client. If I understood the above thing correctly, ConnMan runs on a device that has a USB client and ConnMan needs to set up a DHCP server on it? This is achieved by ensuring that both 'gadget' technology and 'gadget' tethering are enabled. Also verify that the interface is not listed in /etc/connman/main.conf NetworkInterfaceBlacklist option and that 'gadget' is either listed in TetheringTechnologies or TetheringTechnologies is unset. Now that the 'gadget' technology has been enable once, ConnMan will remember its enabled state over reboots. With that in mind, one can then set PersistentTetheringMode to true in /etc/connman/main.conf. This preserves tethering state for all technologies over reboot, including 'gadget'. If it is the opposite, i.e. ConnMan runs on the USB host end, the procedure is the same, but the technology is instead 'ethernet'. This affects the all ethernet devices on the machine, as USB ethernet dongles are indistinguishable from internal PCI connected ones. The networks that show up as services are the ones where ConnMan is a end host/client. Tethering creates a local network bridge, 'tether', and starts a DHCP server on it. The tethered network does not show up as a service, as it is not an upstream connection. > I have googled and read the documentation but I cannot figure out how to > do this properly. > The current method on the server side is to enable the gadget-technology > when it shows up, configure an IP, netmask and gateway, and then enable > tethering on it. Which results in the services not being listable, and > no IP being given to the other side. If I run ifconfig on my side, the > interface is up, but unconfigured. Here I lost track of which device is which. Please check the above and see if that fixes your problem. Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: How to provide DHCP on a technology
Hi, On Tue, 2015-10-13 at 08:49 +, John Ernberg wrote: > ConnMan runs on the embedded system, which is the USB host side. > And when an USB gadget connects, I want to start a DHCP server on the > interface provided by cdc_ether so that the USB gadget that connects > can receive an IP by using a DHCP client. USB host side is counted as a regular ethernet. So 'ethernet' tethering is the one you want to configure. > I have parts of the file system as read only, so ConnMan does not > remember things between reboots. ConnMan stores its technology state into /var/lib/connman/settings, if this file is not perserved over reboots maybe tmpfiles from systemd can create a suitable one into that directory? Or some other shell scripting during boot. > > The networks that show up as services are the ones where ConnMan is a > > end host/client. Tethering creates a local network bridge, 'tether', and > > starts a DHCP server on it. The tethered network does not show up as a > > service, as it is not an upstream connection. > > Ok, got it. I found the tether interface, the USB gadget side does not > receive an IP however. In the USB client/gadget end, especially when running Linux also here, it usually is a matter of being able to (automatically) load the proper drivers for the gadget device. It also is a matter of USB client mode setting, the USB client/gadget is probably registered automatically for some other (Linux kernel module) profile instead of networking. > Could this be caused by that we do not always have any other active > connections? The upstream connections in ConnMan, i.e. services, do not need to be enabled for thethering to work. Only routing/internet connectivity is affected by the presence or absence of a connected service. > I.e. should this be done differently if I want to have a connection > that is end-to-end, without bridging? The connection between the USB host device running ConnMan and the other device with the USB client connection already provide an end-to-end connection over IP. If ConnMan has an service connected providing an upstream internet connection, ConnMan sets up a NAT to get the tethered devices connecting to the internet. The brigde interface comes into play as it is the smartest way of connecting all tethering technologies and interfaces into one network served by a single DHCP server. On the winning side all devices tethered can now connect to each other via IP, be they connected via Bluetooth, USB, ethernet or wifi. Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
How to provide DHCP on a technology
Hi, I'm using Connman in an embedded environment where a device will connect to us over USB, this device will provide an ethernet interface on the USB port, and the device will be in gadget mode. Thus when they connect to us we load the cdc_ether driver and create an Ethernet interface over the USB port. Being completely new to tethering in Connman and how it works, I'm having some issues setting up Connman to provide a DHCP server on this interface so the other device will receive an IP automatically once it starts a DHCP client. I have googled and read the documentation but I cannot figure out how to do this properly. The current method on the server side is to enable the gadget-technology when it shows up, configure an IP, netmask and gateway, and then enable tethering on it. Which results in the services not being listable, and no IP being given to the other side. If I run ifconfig on my side, the interface is up, but unconfigured. How is this supposed to be done? Doing this using Connman 1.29 on my side. Thank you in advance for any assistance, and best regards // John Ernberg ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
