Handle network change
|
02-07-2015, 04:22 PM
Post: #11
|
|||
|
|||
RE: Handle network change | |||
30-07-2015, 04:53 PM
Post: #12
|
|||
|
|||
RE: Handle network change
(02-07-2015 04:22 PM)simonc Wrote:(02-07-2015 01:40 PM)SiMet Wrote: When do you plan introduce this feature? The changes are now committed. See https://github.com/openhome/ohNet/commit...5fa7a1c719 for API names for your chosen language. |
|||
05-08-2015, 12:07 PM
(This post was last modified: 05-08-2015 12:08 PM by SiMet.)
Post: #13
|
|||
|
|||
RE: Handle network change
Thank you for this feature.
I've checked it and when I connect to other wifi source I get SubnetListChanged callback and also I see on my wireshark on computer that device sents NOTIFYs with alive. However, I found that after switch to other wifi Location header in notify message has port set to 0. ControlPoint stack also doesn't discover devices which connected to new network. I'm starting UpnpLibrary using startCombined(...) Do I have to do something extra? Additionally when I back to network which I was connected earlier it works properly |
|||
07-08-2015, 01:51 PM
Post: #14
|
|||
|
|||
RE: Handle network change
(05-08-2015 12:07 PM)SiMet Wrote: Thank you for this feature. I'm not sure what's causing this. Could you add the logging below please and let me know what output it generates when you switch to a subnet that doesn't work (reports Location with port 0) please? Code: diff --git a/OpenHome/Net/Device/DviServer.cpp b/OpenHome/Net/Device/DviServer.cpp |
|||
11-08-2015, 12:15 PM
(This post was last modified: 11-08-2015 12:29 PM by SiMet.)
Post: #15
|
|||
|
|||
RE: Handle network change
I've added code you provided.
I started my app on 192.168.43.57, then switched to 192.168.1.37. When I switch to network I didn't start your AddServer method is not called. When I back to this network I see your logs. SubnetListChanged and line which begins with -> are in my SubnetListChanged listener. Code: SubnetListChanged |
|||
20-08-2015, 12:33 PM
Post: #16
|
|||
|
|||
RE: Handle network change
I'd like to remind about this issue
|
|||
01-09-2015, 08:13 AM
(This post was last modified: 01-09-2015 08:48 AM by SiMet.)
Post: #17
|
|||
|
|||
RE: Handle network change
Hello,
I started debug this problem. I start whole Upnp using StartCombined. When I get SubnetListChanged I call SetCurrentSubnet with new Subnet. Without this call my CP doesn't work. When I added this SetCurrentSubnet call to SubnetListChange handler my ControlPoint started discover other devices after switch network. However, Device is not working properly. Currently I see that DviServer::AddServer is called and port is correct. But ALIVE Notify messages has port 0. I've checked it and DviProtocolUpnp:AddInterface creates DviProtocolUpnpAdapterSpecificData with port value 0. I do not know why is it working in that way. If I could help, give you anything which could help you to reproduce this issue do not bother to ask. Currently I'm testing it with iOS simulator. I reconnect my device from one WIFI network to another. EDIT: I found that in some cases (most of cases) DviProtocolUpnp::AddInterface is called before DviServer::AddServer and this cause that port in NOTIFY messages is 0 ( in DviServer::Port(TIpAddress aInterface) iServers.size() == 0 and 0 is returned ) |
|||
01-09-2015, 12:29 PM
Post: #18
|
|||
|
|||
RE: Handle network change
I debug and debug and probably found solution for my issue.
Could you check if that patch could be applied to official repo Code: diff --git a/OpenHome/Net/Device/Upnp/DviProtocolUpnp.cpp b/OpenHome/Net/Device/Upnp/DviProtocolUpnp.cpp |
|||
03-09-2015, 01:33 PM
Post: #19
|
|||
|
|||
RE: Handle network change
Thanks for looking into this. Your conclusions were very helpful!
While I'm sure your patch works, I think a smaller set of changes might be possible. Could you check whether the patch below also fixes the bug please? Code: diff --git a/OpenHome/Net/Device/Upnp/DviProtocolUpnp.cpp b/OpenHome/Net/Device/Upnp/DviProtocolUpnp.cpp |
|||
07-09-2015, 09:44 AM
Post: #20
|
|||
|
|||
RE: Handle network change
(03-09-2015 01:33 PM)simonc Wrote: Thanks for looking into this. Your conclusions were very helpful! I've just checked and it doesn't fix this issue. I do not investigate it a lot. In my opinion clue is to return NULL adapter if port is 0 |
|||
« Next Oldest | Next Newest »
|