5:18 p.m.
Hi,
Connman assigns by default the DHCP pool 192.168.0.x to the tether interface.
If another interface comes online with a IP in this subnet, then
__connman_ippool_newaddr calls collision_cb() to restart the tether
interface so that it gets a chance to get a new pool.
Unfortunately if two technologies are tethered (WiFi and Gadget), then
this logic does not work. It fails at
__connman_tethering_set_disabled, since tethering_enabled == 2.
I really don't understand the big picture to offer a patch for this. I
guess it's not enough to just remove this check!
Thanks,
Nuno
9:52 a.m.
Hi Nuno,
On 7/23/19 7:18 PM, Nuno Gonçalves wrote:
Hi,
Connman assigns by default the DHCP pool 192.168.0.x to the tether interface.
If another interface comes online with a IP in this subnet, then
__connman_ippool_newaddr calls collision_cb() to restart the tether
interface so that it gets a chance to get a new pool.
Unfortunately if two technologies are tethered (WiFi and Gadget), then
this logic does not work. It fails at
__connman_tethering_set_disabled, since tethering_enabled == 2.
Indead, the code was not written having two tethered technologies in mind :)
Anyway, it looks like tethering_enabled is used for two things. First in
which state of the initialization phase we are and second how many users
of the bridge are there. I think you just need to split this into two
separate variables.
When reconfiguring the bridge the code should already take care of
sending the corresponding DCHP messages etc. So in theory it should be
fairly simple. Famous last words...
Thanks,
Daniel
1068
days inactive
1069
days old
1 comments
2 participants
participants (2)
-
Daniel Wagner -
Nuno Gonçalves