UPnP subscription renewal fails on the device - events

When I try to renew the UPnP event subscription on the device, I have an 412 HTTP Error: Precondition Failed, bad SID.
This error occurs only on one device, all other devices works fine.
Buggy device is an D-Link XTreme N GIGABIT Router DIR-655 (Firmware Version :1.34WW, 2010/09/30), H/w ver: A4.
UPNP subscription log (catched by Wireshark)
Subscription:
SUBSCRIBE /l3fw HTTP/1.0
Host: 192.168.0.1
CALLBACK: <http://192.168.0.100:7169/evt/43E47718-E7F6-D950-A503-71346C1D9944>
NT: upnp:event
TIMEOUT: Second-60
HTTP/1.1 200 OK
SID: uuid:5B68F900-2863-104D-8000-002401F35BC2
TIMEOUT: Second-60
SERVER: ipOS/7.6 UPnP/1.0 ipGENADevice/1.0
Renewal:
SUBSCRIBE /l3fw HTTP/1.0
Host: 192.168.0.1
SID: uuid:5B68F900-2863-104D-8000-002401F35BC2
TIMEOUT: Second-60
HTTP/1.1 412 Precondition Failed, bad SID
SERVER: ipOS/7.6 UPnP/1.0 ipGENADevice/1.0
First time I try to renew subscription in 5 seconds before expiration, e.g. on 55th second after initial subscription. Second try: on 45th second, but with the same effect.
Also I tried to use HTTP/1.1 in subscription requests (and add "Connection:close" header), but there is no effect.
What I'm doing wrong?
UPD1 Updating formware to 1.37WW changes nothing
UPD2
When I try to renew subscription immediately after subscribe, it works. Wait 750ms and renew - works. Wait 900ms and renew - fails with HTTP 412. It seems that there is a bugs in D-Link equipment (another D-Link router DI-624 works in the same manner). Intel device validator (https://software.intel.com/en-us/articles/intel-tools-for-upnp-technologies) validates DIR-655 and DI-624 eventing without errors, but, I think, there is no pause between subscribing and renewal steps. So, I think, UPNP eventing is not a reliable mechanism and it is better don't to use it.
Such device behavior compromises an upnp eventing mechanism idea.

I've just hit a very similar problem with some Belkin WeMo devices.
I solved my problem by making sure I responded properly to notification messages sent to the CALLBACK URL. I sent a HTTP 200 response and things started to work properly for me.

Related

Telnet response to CAPABILITY differs from actual response

I have a problem on one of my machines.
I connect to some IMAP server and do ". CAPABILITY" request:
* OK IMAP4 ready
. CAPABILITY
* CAPABILITY IMAP4REV1 UIDPLUS
. OK completed
But if I inspect response in Wireshark I get
* CAPABILITY IMAP4 IMAP4rev1 UIDPLUS STARTTLS LOGINDISABLED which is the expected result.
And it works just fine on other machines.
What can be wrong?
Actually I have similar problem with openssl connection on that machine: Didn't find STARTTLS in server response, trying anyway..., but I think it has the same root cause.
Unfortunately, I didn't have enough time to dig deep into the problem. After some fiddling with updates, software reinstallation, changing IPs and so on I gave up, formatted C and made clean Windows installation.
It helped, as it usually is with such weird behaviors.

Frozen connection using ssh over Amazon EC2 using ubuntu

When I am connected to Amazon EC2 using the secure shell and don't type anything for a few minutes, everything freezes. I can't type anything or exit. After a few minutes I get a message from the server...
Last login: Fri Dec 6 23:21:28 2013 from pool-173-52-249-158.nycmny.east.verizon.net
ubuntu#ip-172-31-31-33:~$ Write failed: Broken pipe
Some of you have had to have this problem before. If you could shed some light on the situation for a newb using the cloud.
Try below options:
Explore ServerAliveCountMax and ServerAliveInterval. These settings are set in /etc/ssh/ssh_config on SSH client side.
from man ssh_config:
ServerAliveCountMax
Sets the number of server alive messages (see below) which may be sent without ssh(1) receiving any mes‐
sages back from the server. If this threshold is reached while server alive messages are being sent, ssh
will disconnect from the server, terminating the session. It is important to note that the use of server
alive messages is very different from TCPKeepAlive (below). The server alive messages are sent through
the encrypted channel and therefore will not be spoofable. The TCP keepalive option enabled by
TCPKeepAlive is spoofable. The server alive mechanism is valuable when the client or server depend on
knowing when a connection has become inactive.
The default value is 3. If, for example, ServerAliveInterval (see below) is set to 15 and
ServerAliveCountMax is left at the default, if the server becomes unresponsive, ssh will disconnect after
approximately 45 seconds. This option applies to protocol version 2 only; in protocol version 1 there is
no mechanism to request a response from the server to the server alive messages, so disconnection is the
responsibility of the TCP stack.
And
ServerAliveInterval
Sets a timeout interval in seconds after which if no data has been received from the server, ssh(1) will
send a message through the encrypted channel to request a response from the server. The default is 0,
indicating that these messages will not be sent to the server, or 300 if the BatchMode option is set.
This option applies to protocol version 2 only. ProtocolKeepAlives and SetupTimeOut are Debian-specific
compatibility aliases for this option.
Also similar settings are available from the server side which are ClientAliveInterval and ClientAliveCountMax. These settings palced in /etc/ssh/sshd_config on Server side.
from man sshd_config:
ClientAliveCountMax
Sets the number of client alive messages (see below) which may be sent without sshd(8) receiving any mes‐
sages back from the client. If this threshold is reached while client alive messages are being sent,
sshd will disconnect the client, terminating the session. It is important to note that the use of client
alive messages is very different from TCPKeepAlive (below). The client alive messages are sent through
the encrypted channel and therefore will not be spoofable. The TCP keepalive option enabled by
TCPKeepAlive is spoofable. The client alive mechanism is valuable when the client or server depend on
knowing when a connection has become inactive.
The default value is 3. If ClientAliveInterval (see below) is set to 15, and ClientAliveCountMax is left
at the default, unresponsive SSH clients will be disconnected after approximately 45 seconds. This
option applies to protocol version 2 only.
And
ClientAliveInterval
Sets a timeout interval in seconds after which if no data has been received from the client, sshd(8) will
send a message through the encrypted channel to request a response from the client. The default is 0,
indicating that these messages will not be sent to the client. This option applies to protocol version 2
only.
Looks like your firewall (from different locations) are dropping the sessions due to inactivity.
I would try just like #slayedbylucifer stated something like this in your ~/.ssh/config
Host *
ServerAliveInterval 60

Set fixed rport in FreeSWITCH/Sofia subscribe message

The problem is that I know next to nothing about SIP, or FreeSWITCH, yet have been tasked with figuring this out.
The setup:
The FreeSWITCH client sends a subscribe to a remote server to receive presence updates. The client is behind a fairly restrictive firewall and NAT.
The server replies with the normal unauthorized, and Sofia replies, and we receive the SIP/2.0 200 OK message, its VIA header contains an rport for a port number we don't have open or forwarding to our FreeSWITCH installation.
We never receive the notify that ought to follow the 200 OK.
Subsequent subscribes returns different rport designations.
Is there a way to configure FreeSWITCH/Sofia to always use a specific port for the rport parameter?
Edit: We never managed to solve it, but the remote service did solve it by adding the correct routes to their firewall.
Is the far end server setup to allow NOTIFY to be sent to your client?
If you receive the 200 OK response to the initial SUBSCRIBE then that sets up the SIP dialog I believe (the dialog is a end-point to end-point association).
BTW you set up FS to be the presence watcher client? Thats cool since I tried doing that but the documentation gave me a headache and moved on to other things.
Since you sent the initial subscribe NAT shouldn't be a problem right? since rport should have the port to use. I would always use port 5060, have your FW people let udp port 5060 port in and out freely, use Fail2ban to filter your traffic.
But have no idea how FS works, and NAT firewalls are the greatest evil :-). Sorry and best of luck.

DeviceNetworkInformation: Which is which?

I want to check whether any internet connection is available - i.e can I start webrequests expected to succeed.
IsCellularDataEnabled - is this true if there's GPRS/3G/etc available?
IsNetworkAvailble - is this true if VOICE CALLS are possible, or does this too have something to do with the internet?
IsCellularDataRoamingEnabled - Should I be concerned with this at all? (I know what Data Roaming is...)
IsWifiAvailable - If this false,I can still get internet from 3G.
So what I'm looking for is:
if (/*something*/){ //you can use the internet
}
thanks
(EDIT: I don't have a device readily available, otherwise I'd just try it out :) )
IsNetworkAvailable is true, if there is some kind of data connection available, no matter which (GPRS, 3G, Roaming, WiFi or via USB cable).
IsCellularDataEnabled is true if the phone is connected via a mobile data connection. It doesn't give you any status about Voice calls but only data.
IsCellularDataRoamingEnabled: The user is connected via a mobile data connection via a 3rd provider (roaming). You should only use a minimal amount of traffic because roaming data is often expensive for the user. (Because of that you can check this status)
IsWifiAvailable is true if you are connected via WiFi. If false there may be a mobile data connection via 3G and so on.
So, if you only want to know IF there is some kind of connection you can use IsNetworkAvailable - all other states are only giving you more detailed information about what kind of connection there is.
Only
if(NetworkInterface.GetIsNetworkAvailable()) {
}
http://msdn.microsoft.com/en-us/library/system.net.networkinformation.networkinterface.getisnetworkavailable.aspx
Your question contains a false assumption.
You want to know if there's a connection so your request is likely to succeed. Only the oppostie can be true though. You can only know that if there's no connection a request will definitely fail.
There are lots of reasons that it may not be possible to make a successful web request even if there's a connection to an external network available.
You MUST code to handle a request failing even if there is a connection.
Things that can stop a request from being successful even if there is a connection:
proxy servers or firewalls blocking the request
being connected to a local network which doesn't have access to the destination server
a slow network connection causing the request to timeout
the destination server being down/offline/unavailable
an error on the server
etc. ...

What to do with HTTP 412 (Precondition Failed) - The device is in an inactive state

I'm getting this error whenever I try to send a push notification to a Nokia WP7 device.
Other push URI's don't return this error but with this one, every try failed, even when the phone is "awake" and with wi-fi on.
Checking MSDN docs, I came to this:
http://msdn.microsoft.com/en-us/library/ff941100(v=vs.92).aspx
The device is in an inactive state. The web service may re-attempt sending the request one time per hour at maximum after receiving this error. If the web service violates the maximum of one re-attempt per hour, the Push Notification Service will de-register or permanently block the web service."
Which didn't help much, as all I can do is honor the "retry after 1 hour" and try to send again.
I suspect that it can be related to the device never had a SIM card in it and therefore could not "activate" but, if this is true, why does MSPN returned a push URI for the app?
Thanks in advance
I've noticed that Microsoft generates a new ChannelUri for a device often (in the past 2 days for my 2 devices i have 5 channel uris)
It may be that a new channeluri has been generated for the device.

Resources