Hi Grant,

Thanks for the great report.

> Connman marks the Tank network as connected.
> 
> connmand[364]:                         --> (6) connman_network_set_connected: 
> network 0x8c1d8 connected 1
> connmand[364]:                             --> (7) set_connected: service 
> 0x997f8
> connmand[364]: network connected 1
> 
> The network layer now attempts to start DHCP for this service.
> 
> connmand[364]:                                 --> (8) set_connected_dhcp: 
> network 0x8c1d8
> connmand[364]:                                     --> (9) 
> __connman_service_indicate_state: service 0x997f8 
> wifi_000c294c56a2_54616e6b_managed_psk new_state 3 (configuration) type 1 
> (IPv4)
> 
> Connman now moves to the configuration state for the service and should now 
> request a DHCP address.
> 
> connmand[364]: service 0x997f8 state association/idle => association new 
> configuration/1 => configuration
> connmand[364]: mmap error Invalid argument for 
> /var/lib/connman/stats/wifi_000c294c56a2_54616e6b_managed_psk.data
> connmand[364]: 
> /var/lib/connman/stats/wifi_000c294c56a2_54616e6b_managed_psk.data might be 
> on a file system, such as JFFS2, that does not allow shared writable mappings.
> connmand[364]:                                     <-- (9) 
> __connman_service_indicate_state: err 0
> 
> This looks like it might be a latent set of operations from the prior network 
> disconnect. Though,
> there'd certainly be no way to release the prior DHCP lease until a network 
> connection comes back,
> so maybe this is OK here.
> 
> connmand[364]:                                     --> (9) remove_network: 
> dhcp 0x97f40
> connmand[364]:                                         --> (10) dhcp_release: 
> dhcp 0x97f40
> connmand[364]: ********* DHCP RELEASE ***********
> connmand[364]: DHCP: switch listening mode (0 ==> 0)
> connmand[364]: DHCP: RELEASE of 10.2.0.70 on wlan0 to 10.2.0.1 port 67
> connmand[364]: DHCP: switch listening mode (0 ==> 0)
> connmand[364]:                                         <-- (10) dhcp_release: 
> 0 (1)
> connmand[364]:                                     <-- (9) remove_network: 
> 
> The "old" network is removed and we reinitiate a DHCP discover.

ConnMan creates new network before it is deleting the old one? Is that
right?

 - The new network is 0x8c1d8, dhcp ?
 - The old network is 0x879e0, dhcp 0x97f40

Anyway, the IP configuration is only invalidated iff a lease is
lost. So the remove_network path doesn't remove the configatution.

I think dhcp_release() should also call dhcp_invalid() before
destroying the dhcp data structure.

> connmand[364]: DHCP: switch listening mode (0 ==> 1)
> connmand[364]: DHCP: DISCOVER on wlan0 to 255.255.255.255 port 67 interval 3
> connmand[364]:                                 <-- (8) set_connected_dhcp: 
> connmand[364]:                             <-- (7) set_connected: FALSE: 5
> connmand[364]:                         <-- (6) connman_network_set_connected: > 0
> 
> Connman is a little late to the supplicant state change party and just now 
> catches up with the COMPLETED state.
> 
> connmand[364]: state 9 (completed)
> connmand[364]: connman-0.71/gsupplicant/supplicant.c:interface_property() 
> state completed (9)
> connmand[364]:                     <-- (5) interface_property: (2)
> connmand[364]:                     --> (5) interface_property: key CurrentBSS 
> iter 0xbef0c9ac interface 0x88f80
> connmand[364]: connman-0.71/gsupplicant/supplicant.c:interface_property() 
> CurrentBSS
> connmand[364]: 
> connman-0.71/gsupplicant/supplicant.c:interface_bss_added_without_keys() 
> connmand[364]: connman-0.71/gsupplicant/supplicant.c:interface_bss_added() 
> connmand[364]: connman-0.71/gsupplicant/supplicant.c:interface_bss_added() 
> /fi/w1/wpa_supplicant1/Interfaces/0/BSSs/1
> connmand[364]:                     <-- (5) interface_property: (2)
> connmand[364]: connman-0.71/gsupplicant/supplicant.c:merge_network() ssid 
> "Tank" mode 0
> connmand[364]: connman-0.71/gsupplicant/supplicant.c:merge_network() 
> 2254616e6b22_managed_psk
> connmand[364]: wlan0 {add} route ff00:: gw :: scope 0 <UNIVERSE>
> connmand[364]: wlan0 {add} route fe80:: gw :: scope 0 <UNIVERSE>
> connmand[364]: wlan0 {update} flags 69635 <UP,LOWER_UP>
> connmand[364]: wlan0 {newlink} index 2 address 00:0c:29:4c:56:a2 mtu 1500
> connmand[364]: wlan0 {RX} 30549 packets 9412553 bytes
> connmand[364]: wlan0 {TX} 2705 packets 1550615 bytes
> connmand[364]: wlan0 {newlink} index 2 address 00:0c:29:4c:56:a2 mtu 1500
> connmand[364]: wlan0 {newlink} index 2 operstate 5 <DORMANT>
> connmand[364]: wlan0 {RX} 30552 packets 9412930 bytes
> connmand[364]: wlan0 {TX} 2708 packets 1550998 bytes
> connmand[364]: wlan0 {update} flags 69699 <UP,RUNNING,LOWER_UP>
> connmand[364]: wlan0 lower up
> connmand[364]: wlan0 lower up
> connmand[364]: wlan0 {newlink} index 2 address 00:0c:29:4c:56:a2 mtu 1500
> connmand[364]: wlan0 {newlink} index 2 operstate 6 <UP>
> 
> The DHCP server returns with a lease OFFER.
> 
> connmand[364]: DHCP: received DHCPOFFER (0x2) packet (current state 0)
> connmand[364]: DHCP: OFFER of 10.2.0.70 from 10.2.0.1
> connmand[364]: DHCP: start request (retries 0)
> connmand[364]: DHCP: switch listening mode (1 ==> 1)
> connmand[364]: DHCP: REQUEST of 10.2.0.70 on wlan0 to 255.255.255.255 port 67 
> interval 3
> connmand[364]: DHCP: received DHCPACK (0x5) packet (current state 1)
> connmand[364]: DHCP: switch listening mode (1 ==> 0)
> 
> Connman acknowledges the lease.
> 
> connmand[364]: DHCP: ACK of 10.2.0.70 from 10.2.0.1
> connmand[364]:                     --> (5) lease_available_cb: 
> connmand[364]: Lease available
> connmand[364]: DHCP lease available for service 
> wifi_000c294c56a2_54616e6b_managed_psk
> 
> Connman still, INCORRECTLY, believes it has a valid address, gateway and 
> netmask for this service. It SHOULD NOT.
> 
> connmand[364]: c_address: 10.2.0.70
> connmand[364]: c_gateway: 10.2.0.1
> connmand[364]: c_prefixlen: 16
> connmand[364]: new address: 10.2.0.70
> connmand[364]: new gateway: 10.2.0.1
> connmand[364]: new prefixlen: 16

Yeah, this makes sense. The IP configuration is not stored inside
dhcp.c. It's in the ipconfig which is propablely not recreated and
therefore stays even if the network object is destroyed and a new one
is created. The ipconfig owner is the Service object, IIRC.

> Connman thinks the DHCP lease is the same as it already has for this service, 
> so it doesn't bother setting it. THIS IS WRONG!
> 
> connmand[364]: ip_change: 0
> connmand[364]: Setting domainname to domain.actdsltmp
> connmand[364]:                     <-- (5) lease_available_cb: 
> connmand[364]: DHCP: bound to 10.2.0.70 -- renewal in 864000 seconds.
> connmand[364]: DHCP: processed DHCPACK (0x5) packet (new state 2)
> 1306168983.519011: EAPOL: startWhen --> 0
> 1306168983.519164: EAPOL: disable timer tick
> 
> We are now in the unfortunate spot of being associated but not having a valid 
> IP configuration.

Can you try and add the dhcp_invalid() call to the dhcp_remove() code
path? 

HTH!

cheers,
daniel

_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman

Reply via email to