diff options
author | Kevin Cernekee <cernekee@chromium.org> | 2017-01-05 13:42:20 -0800 |
---|---|---|
committer | Pablo Neira Ayuso <pablo@netfilter.org> | 2017-02-12 15:03:02 +0100 |
commit | b61c4543cbdef8eb34ba1e59f617593180249738 (patch) | |
tree | 8f77dec8e1779c57b7e119152e2ea138a2372178 /src/read_config_yy.y | |
parent | ff843bcb3b9059e95e12630faad322809bde33de (diff) |
conntrackd: cthelper: ssdp: Track UPnP eventing
The UPnP Device Architecture spec provides a way for devices to connect
back to control points, called "Eventing" (chapter 4). This sequence can
look something like:
1) Outbound multicast M-SEARCH packet (dst: 1900/udp)
- Create expectation for unicast reply from <any host> to source port
2) Inbound unicast reply (there may be several of these from different devices)
- Find the device's URL, e.g.
LOCATION: http://192.168.1.123:1400/xml/device_description.xml
- Create expectation to track connections to this host:port (tcp)
3) Outbound connection to device's web server (there will be several of these)
- Watch for a SUBSCRIBE request
- Find the control point's callback URL, e.g.
CALLBACK: <http://192.168.1.124:3500/notify>
- Create expectation to open up inbound connections to this host:port
4) Inbound connections to control point's web server
- The device will send NOTIFY HTTP requests to inform the control point
of new events. These can continue indefinitely. Each NOTIFY
request arrives on a new TCP connection and may have a different
source port.
Add the necessary code to create expectations for each of these
connections and rewrite the IP in the CALLBACK URL. Tested with and
without NAT.
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Diffstat (limited to 'src/read_config_yy.y')
0 files changed, 0 insertions, 0 deletions