Discussion:
How to provide DHCP on a technology
(too old to reply)
John Ernberg
2015-10-12 14:26:58 UTC
Permalink
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
Patrik Flykt
2015-10-13 08:21:48 UTC
Permalink
Hi,
Post by John Ernberg
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.
Post by John Ernberg
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
John Ernberg
2015-10-13 08:49:25 UTC
Permalink
Hi Patrik,
Post by Patrik Flykt
Hi,
Post by John Ernberg
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.
Post by Patrik Flykt
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.
Post by Patrik Flykt
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.
Post by Patrik Flykt
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
Post by Patrik Flykt
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?
Post by Patrik Flykt
Post by John Ernberg
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
https://lists.connman.net/mailman/listinfo/connman
Thank you and best regards // John Ernberg
Patrik Flykt
2015-10-13 09:32:38 UTC
Permalink
Hi,
Post by John Ernberg
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.
Post by John Ernberg
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.
Post by John Ernberg
Post by Patrik Flykt
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.
Post by John Ernberg
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.
Post by John Ernberg
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
John Ernberg
2015-10-14 06:40:44 UTC
Permalink
Hi Patrik,
Post by Patrik Flykt
Hi,
Post by John Ernberg
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.
Post by John Ernberg
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.
Post by Patrik Flykt
Post by John Ernberg
Post by Patrik Flykt
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.
Post by Patrik Flykt
Post by John Ernberg
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.
Post by John Ernberg
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?
Post by Patrik Flykt
Cheers,
Patrik
_______________________________________________
connman mailing list
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)

tether Link 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)

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
)
]
}
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
)
]
}
]


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 errors:0 dropped:0 overruns:0 frame:0
TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:104 (104.0 B) TX bytes:902 (902.0 B)

method return sender=:1.2 -> dest=:1.169 reply_serial=2
array [
struct {
object path "/net/connman/service/gadget_xxxxxxxxxxxx_usb"
array [
dict entry(
string "Type"
variant string "gadget"
)
dict entry(
string "Security"
variant array [
]
)
dict entry(
string "State"
variant string "idle"
)
dict entry(
string "Favorite"
variant boolean false
)
dict entry(
string "Immutable"
variant boolean false
)
dict entry(
string "AutoConnect"
variant boolean false
)
dict entry(
string "Name"
variant string "Wired"
)
dict entry(
string "Ethernet"
variant array [
dict entry(
string "Method"
variant string "auto"
)
dict entry(
string "Interface"
variant string "usb0"
)
dict entry(
string "Address"
variant string "xx:xx:xx:xx:xx:xx"
)
dict entry(
string "MTU"
variant uint16 1500
)
]
)
dict entry(
string "IPv4"
variant array [
]
)
dict entry(
string "IPv4.Configuration"
variant array [
dict entry(
string "Method"
variant string "dhcp"
)
]
)
dict entry(
string "IPv6"
variant array [
]
)
dict entry(
string "IPv6.Configuration"
variant array [
dict entry(
string "Method"
variant string "auto"
)
dict entry(
string "Privacy"
variant string "disabled"
)
]
)
dict entry(
string "Nameservers"
variant array [
]
)
dict entry(
string "Nameservers.Configuration"
variant array [
]
)
dict entry(
string "Timeservers"
variant array [
]
)
dict entry(
string "Timeservers.Configuration"
variant array [
]
)
dict entry(
string "Domains"
variant array [
]
)
dict entry(
string "Domains.Configuration"
variant array [
]
)
dict entry(
string "Proxy"
variant array [
]
)
dict entry(
string "Proxy.Configuration"
variant array [
]
)
dict entry(
string "Provider"
variant array [
]
)
]
}
]
Patrik Flykt
2015-10-14 08:21:54 UTC
Permalink
Post by John Ernberg
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.
Post by John Ernberg
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?
Post by 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.
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)
tether Link 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??
Post by John Ernberg
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.
Post by John Ernberg
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.
Post by John Ernberg
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 errors:0 dropped:0 overruns:0 frame:0
TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:104 (104.0 B) TX bytes:902 (902.0 B)
method return sender=:1.2 -> dest=:1.169 reply_serial=2
array [
struct {
object path "/net/connman/service/gadget_xxxxxxxxxxxx_usb"
The USB client/gadget end is not tethering, as the service
gadget_xxxxxxxxxxxx_usb shows up.

To me it seems that you have enabled gadget tethering instead of
ethernet USB host tethering for the first device. But this means the
first device has an ethernet connector (possibly a USB host?) and a USB
gadget (client) connector. Is this correct?
Post by John Ernberg
array [
dict entry(
string "Type"
variant string "gadget"
)
dict entry(
string "Security"
variant array [
]
)
dict entry(
string "State"
variant string "idle"
)
dict entry(
string "Favorite"
variant boolean false
)
dict entry(
string "Immutable"
variant boolean false
)
dict entry(
string "AutoConnect"
variant boolean false
)
dict entry(
string "Name"
variant string "Wired"
)
dict entry(
string "Ethernet"
variant array [
dict entry(
string "Method"
variant string "auto"
)
dict entry(
string "Interface"
variant string "usb0"
)
dict entry(
string "Address"
variant string "xx:xx:xx:xx:xx:xx"
)
dict entry(
string "MTU"
variant uint16 1500
)
]
)
dict entry(
string "IPv4"
variant array [
]
)
dict entry(
string "IPv4.Configuration"
variant array [
dict entry(
string "Method"
variant string "dhcp"
)
]
)
dict entry(
string "IPv6"
variant array [
]
)
dict entry(
string "IPv6.Configuration"
variant array [
dict entry(
string "Method"
variant string "auto"
)
dict entry(
string "Privacy"
variant string "disabled"
)
]
)
dict entry(
string "Nameservers"
variant array [
]
)
dict entry(
string "Nameservers.Configuration"
variant array [
]
)
dict entry(
string "Timeservers"
variant array [
]
)
dict entry(
string "Timeservers.Configuration"
variant array [
]
)
dict entry(
string "Domains"
variant array [
]
)
dict entry(
string "Domains.Configuration"
variant array [
]
)
dict entry(
string "Proxy"
variant array [
]
)
dict entry(
string "Proxy.Configuration"
variant array [
]
)
dict entry(
string "Provider"
variant array [
]
)
]
}
]
Cheers,

Patrik
John Ernberg
2015-10-14 13:09:18 UTC
Permalink
Hi Patrik
Post by Patrik Flykt
Post by John Ernberg
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.
Post by Patrik Flykt
Post by John Ernberg
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.
Post by Patrik Flykt
Post by 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.
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)
tether Link 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.
Post by Patrik Flykt
Post by John Ernberg
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.
Post by Patrik Flykt
Post by John Ernberg
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.
Post by John Ernberg
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 errors:0 dropped:0 overruns:0 frame:0
TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:104 (104.0 B) TX bytes:902 (902.0 B)
method return sender=:1.2 -> dest=:1.169 reply_serial=2
array [
struct {
object path "/net/connman/service/gadget_xxxxxxxxxxxx_usb"
The USB client/gadget end is not tethering, as the service
gadget_xxxxxxxxxxxx_usb shows up.
This is the gadget side, I only listed services on the gadget side.
Post by Patrik Flykt
To me it seems that you have enabled gadget tethering instead of
ethernet USB host tethering for the first device. But this means the
first device has an ethernet connector (possibly a USB host?) and a USB
gadget (client) connector. Is this correct?
The ethernet interface shown on the USB host side is a real ethernet port.
Post by Patrik Flykt
Post by John Ernberg
array [
dict entry(
string "Type"
variant string "gadget"
)
dict entry(
string "Security"
variant array [
]
)
dict entry(
string "State"
variant string "idle"
)
dict entry(
string "Favorite"
variant boolean false
)
dict entry(
string "Immutable"
variant boolean false
)
dict entry(
string "AutoConnect"
variant boolean false
)
dict entry(
string "Name"
variant string "Wired"
)
dict entry(
string "Ethernet"
variant array [
dict entry(
string "Method"
variant string "auto"
)
dict entry(
string "Interface"
variant string "usb0"
)
dict entry(
string "Address"
variant string "xx:xx:xx:xx:xx:xx"
)
dict entry(
string "MTU"
variant uint16 1500
)
]
)
dict entry(
string "IPv4"
variant array [
]
)
dict entry(
string "IPv4.Configuration"
variant array [
dict entry(
string "Method"
variant string "dhcp"
)
]
)
dict entry(
string "IPv6"
variant array [
]
)
dict entry(
string "IPv6.Configuration"
variant array [
dict entry(
string "Method"
variant string "auto"
)
dict entry(
string "Privacy"
variant string "disabled"
)
]
)
dict entry(
string "Nameservers"
variant array [
]
)
dict entry(
string "Nameservers.Configuration"
variant array [
]
)
dict entry(
string "Timeservers"
variant array [
]
)
dict entry(
string "Timeservers.Configuration"
variant array [
]
)
dict entry(
string "Domains"
variant array [
]
)
dict entry(
string "Domains.Configuration"
variant array [
]
)
dict entry(
string "Proxy"
variant array [
]
)
dict entry(
string "Proxy.Configuration"
variant array [
]
)
dict entry(
string "Provider"
variant array [
]
)
]
}
]
Cheers,
Patrik
_______________________________________________
connman mailing list
https://lists.connman.net/mailman/listinfo/connman
Thank you in advance and best regards // John Ernberg
Patrik Flykt
2015-10-14 13:20:58 UTC
Permalink
Hi,
Post by John Ernberg
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
John Ernberg
2015-10-15 07:57:07 UTC
Permalink
Hi Patrik,
Post by Patrik Flykt
Hi,
Post by John Ernberg
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 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
Post by Patrik Flykt
Cheers,
Patrik
_______________________________________________
connman mailing list
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
John Ernberg
2015-10-15 09:26:05 UTC
Permalink
Hi again Patrik,

I decided to tcpdump the connection, just in case that would help. Attached the output below.

Best regards // John Ernberg
Post by John Ernberg
Hi Patrik,
Post by Patrik Flykt
Hi,
Post by John Ernberg
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 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
Post by Patrik Flykt
Cheers,
Patrik
_______________________________________________
connman mailing list
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
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
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
# ping 192.168.0.1 -I usb0
PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: seq=0 ttl=64 time=0.495 ms
02:06:50.870032 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 45093, seq 0, length 64
02:06:50.870325 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 45093, seq 0, length 64
64 bytes from 192.168.0.1: seq=1 ttl=64 time=0.448 ms
02:06:51.870271 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 45093, seq 1, length 64
02:06:51.870558 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 45093, seq 1, length 64
64 bytes from 192.168.0.1: seq=2 ttl=64 time=0.489 ms
^C
--- 192.168.0.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.448/0.477/0.495 ms
02:06:52.870482 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 45093, seq 2, length 64
02:06:52.870811 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 45093, seq 2, length 64
02:06:55.874584 ARP, Request who-has 192.168.0.2 tell 192.168.0.1, length 28
02:06:55.874647 ARP, Reply 192.168.0.2 is-at 02:00:00:00:10:11 (oui Unknown), length 28
Patrik Flykt
2015-10-19 07:29:20 UTC
Permalink
Post by John Ernberg
Post by John Ernberg
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?
Post by John Ernberg
Post by John Ernberg
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?
Post by John Ernberg
Post by John Ernberg
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.
Post by John Ernberg
# ./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?
Post by John Ernberg
# 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.
Post by John Ernberg
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
John Ernberg
2015-10-22 04:49:11 UTC
Permalink
Hi Patrik,
Post by Patrik Flykt
Post by John Ernberg
Post by John Ernberg
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?
Post by John Ernberg
Post by John Ernberg
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?
Post by John Ernberg
Post by John Ernberg
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.
Post by John Ernberg
# ./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?
Post by John Ernberg
# 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.
Post by John Ernberg
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
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

Loading...