As quick background, I have two Lorex LNC104 security cameras. These are wireless devices and I've had them working nicely for two years. They come with a viewer program, Lview, which is supported in Windows (I use WinXP) and on Macs. I like linux when dealing with low level stuff, but Lorex does not provide any Linux support. Lview still works fine on my local network, but late this summer stopped working over the internet from remote locations which is the primary reason for having a security system. Sadly my experience with Lorex technical support has been terrible, and they are not even responding to my requests for assistance. I'd love to hear from anyone who is successfully using Lview with one of these cameras from a remote location to confirm that feature is still functional. I will try a similar query in one of the security camera forums.

I'm posting here because I am curious that I don't seem to be able to see any packets being sent between the camera's and the host system running the Lview with tcpdump. Being a retired geek I thought this would be a great way to learn more about tcpdump but so far find myself fairly frustrated. I will use <Lview-ip> as the address of the WinXP system running the Lview application, and <camera-ip> as the address of one of the cameras, both of which are connected to my local wireless router. I've been doing most of my snooping with a wireless laptop which sees some packets as described below, but no where near as many as I know must be transmitted and received. There is only one active ethernet port, the wireless wlan0, so I don't need to specify the device for tcpdump.

Lorex doesn't publish much technical information about how Lview gets past my dsl modem/router but they do say it uses H.264 video compression for the data.

tcpdump -nn host <camera-ip>
does show some traffic. It appears the system uses UPnP => universal plug and play and I see the camera broadcasting 'ssdp:alive' to the UPnP address 239.255.255.250:1900

tcpdump -nn host <Lview-ip>
shows that when Lview runs and attempts to connect to a camera it seens an 'ssdp:discovery' message to the UPnP address above, but I don't see a reply. I am suspicious of my tcpdump usage because when I use the command above and browse web pages I don't seen anything that look like HTML packets either.

I never see anything that looks like the video data packets between the <Lview-ip> and <camera-ip> although this is clearly going on as the video feed is displayed on the client screen.

I investigated UPnP a little and was able to write a simple program to send the 'sspd:discovery' message above and wait for replies. On my local system this works and I get replies directly from both cameras. When I run this on a remote network there is no reply. I fear this explains why Lview on a remote system can't connect, but don't know how to get any further with this.

Probably I'm doing something stupid as this is my first use of the tcpdump package. The only other thing I can imagine is that there is something odd/non-standard about the packets Lorex uses and tcpdump doesn't recognize them. Some suggestions would be appreciated. I assume since all devices in use are on the same wireless channel all packets are visible and nothing can be hidden by the router.

Thanks, Will

Perhaps your wireless PC doesn't see all packets. Not that I am at all knowledgeable about this, but to ensure the packets are actually detected, I would install wireshark on the <Lview-IP> PC (I believe it works on XP) and trace some more.

Since the cameras can be seen locally but not remotely there must be a problem in router - port forwarding, or with ISP - the port used is blocked. Another question is how you find your home network? Are you using some dynamic DNS service?

1 members found this post helpful.

Emerson: I guess I wasn't very clear. I have no idea how Lview gets past the router to do remote viewing. I believe that is what the UPnP ssdp:discover messages are about, its apparently an alternative to dynamic DNS, no port forwarding is required. It worked remotely for two years and suddenly stopped in August of this year although there have been no changes on the local network nor the remote client system. All configuration information is the same.
Its unfortunate that Lorex has no support for their product.

berndbausch: Not that it matters a great deal, but the wireless PC I am running tcpdump on is a linux machine running slackware 14.1, tcpdump is natively installed on the linux system. My next step will be to install tcpdump on the WinXP machine that is running Lview, but I am skeptical that the packets aren't available to all the routers local wireless clients. Why do you appear to recommend wireshark rather than tcpdump, how do they differ?

I didn't know that a Windows version of tcpdump existed. wireshark has the advantage of a pretty GUI and the ability to interpret practically any protocol known to man, but for your purpose tcpdump is quite adequate.

As I said, my network knowledge, in particular when it comes to wireless, is fairly spotty, but the investment to test the packets on the XP system is low enough to be worth a try, IMO.

I still think you are overlooking the fact there has to be some kind of DNS record for your home IP address. I think the camera manufacturers run their own DNS service, in order to use it you must register with them.
SSDP is for automatic configuring of port forwarding in your router. You can log into your router and see the setting created. SSDP does not help to discover your home IP address from remote locations.
Possible reason you suddenly lost remote access is the camera manufacturer did not renew your DNS record when your IP address changed. Or there is something else wrong with their private DNS. Workaround here would be to use some other free DNS.

it's called "tcpdump" not "frame relay dump"

if these packets are party frame relay (have data outside of tcp payload) then use tcpdump feature (i think it has one) to dump complete frame rather than tcp header or (apparent) tcp data (which depends on frame)

you of course (read the manpage) have to specify the tcp structure (if it is tcp) for packets that are not of a usual structure (packets that use tcp options to change payload)

there are many more frame packet sniffers out there.

obviously on http://www.wikipedia.com they have a map of tcp options and effect on payload.

and one important fact is that cell towers have been allowing "breaking of protocol barriers and functions stored to run on tower repeaters interpreted from illegal areas"

does your video packets use functions which break tcp layering rules that change data as it gets interpreted across cell towers ?

could anyone point me to where TCP/IP version 6 is fully described in a "final release"?

i avoided upgradeing from ipv4 to ipv6 because ipv6 was never finalized or documented "by rule of law". different isp and OS used it differently - and you didn't know if ipv6 software would change your local routes or not given any "bit settings in addresses or payload" which scared me, the discovery and such.

i'd like to run ipv6 but i dont want to hire an IT team to get it to run like ipv4

and how do i get a "static address". they promised with ipv6 32bit people could easily get a static IP. but as far as i can tell it's been a lie so far: they cost money and isp's block use of them: see [[signal jamming]]

RECAP: ipv6 has so many new features and options having nothing to do with "normal traffic" i'm unsure an individual can set it up "safely" without missing important things (ie, like whether ipv6 code allows local route changes: and how to block it if it does, or like if ipv6 allows discovery by anonymous/foreigners of local LAN networks, and etc, important things like that)

can ipv6 be "almost as easy as ipv4" ? and if so ... where is the manuals / docs to read ? last time i read "linux documentation project" they said ipv6 is experimental, isp support it differently, and software has unguessable features. is ipv6 in stone and IEEE finalized yet?

debguy: I don't off hand know the answers to your question, and am curious why they are part of this thread? Is this an accidental post, they seem to start with a comment about 'frame relay dump' which has never been mentioned?

berndbausch: thanks for your input, I installed WireShark on XP machine and am able to see many packets between IP Camera and Client program Lview this way. Will take some work to try to understand them, but at least part of the issue is solved.

Emerson: you could well be correct that the vendor, Lorex, has messed up what they call their 'Cloud Sever' which is the mechanism they say they use for these cameras. They say with this system no port forwarding or DDNS registration is required, but do not provide any information about how it really works. I freely admit I do not understand UPnP very well. It clearly uses this protocol as described in my initial post, Lview sends a discovery request and when run on the local network the cameras respond directly with the following text in a UUDP message:

HTTP/1.1 200 OK
CACHE-CONTROL: max-age=100
lOCATION: http://192.168.0.2:12040/rootDesc.xml
SERVER: UPnP/1.1 MiniUPnPd/1.7
ST: upnp:rootdevice
USN: uuid:4b710320-451a-11e2-bcfd-0800200c9a66::upnp:rootdevice

I can access the rootDesc.xml file on the camera which contains the following:

<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<device>
<deviceType>urn:schemas-upnp-org:device:Basic:1</deviceType>
<friendlyName>LOREX (192.168.0.7)</friendlyName>
<manufacturer>LOREX</manufacturer>
<modelDescription>H.264 Network Camera</modelDescription>
<modelName>H.264 Network Camera</modelName>
<modelNumber></modelNumber>
<UDN>uuid:4b710320-451a-11e2-bcfd-0800200c9a66</UDN>
<serviceList>
<service>
<controlURL>/upnp/control/BasicServiceId</controlURL>
<eventSubURL>/upnp/event/BasicServiceId</eventSubURL>
<SCPDURL>/scpd_basic.xml</SCPDURL>
</service>
</serviceList>
<presentationURL>http://192.168.0.7:80/</presentationURL>
</device>
</root>

I'm unclear what the above tells me. As I mentioned I have written a program to issue the ssdp.discovery query. It works on my local network as the two local cameras reply directly. The fact that it fails when run directly on the internet suggests that Lorex has abandoned or changed the cloud server, but then why am I the only one complaining? It would be so helpful if they had responsive tech support. Currently I am left trying to figure it out on my own.

I am interested that ssdp is used in configuring routers for port forwarding.

There is only one way it can work, regardless what they say.

Some software at your home connects to their server and reports the IP address. Their private DNS will create a record for this IP address. When you access your home system remotely you log into their service and use the DNS record they have for you to access your home.
What is unclear is how the DNS record for your home gets updated when your internet provider changes your IP address. The software you use at home must somehow react to this and contact their server again with updated IP address.

Emerson: I have no desire to dispute your knowledge base, am sure its above mine, but given the research I've done think UPnP and ssdp messages can be used for more than you are giving them credit for. I agree with most of what you just reported, but I suspect in this case the 'software at your home' that is setting up the 'private DNS' is accomplished via the UPnP ssdp messages. I believe that when a camera sends an ssdp:alive to 239.255.255.250:1900 it passes through my router which modifies both the packet's IP address to the internet address of the router and changes the sending port number to one the router can map back to the local originating camera's IPort. The server running at 239.255.255.250:1900 records the IPort for the last ssdp:alive message it recieves. This record can be used to communicate directly with the camera behind the router. The ssdp:discovery sent to 239.255.255.250:1900 can then return this record with an IPort that will reach the camera. Basically a work around for port forwarding without anyone having to setup any port forwarding on the modem. Isn't this plausible and consistent with what Lorex claims their 'Cloud Sever' does and what you suggest must be occurring? Too bad it no longer seems to work or I could confirm this.

Given time I probably will confirm this is how it works locally, but this is of much less interest.

UPnP and SSDP work locally, their services do no go out to the internet. But if I remember correctly your problem was remote access?

No I am really confused, why does it send messages to a none local IP address?

It is multicast, it keeps propagating services it is configured to. This is why it is meant only for small networks. Imagine a service that sends packets to all IP addresses in the world letting them know there is a service at your home, and everybody else's home networks would do the same. What a disaster that would be.

Got curious ... These are IP cameras, accessible without their specialized software, see ispyconnect. I have a bunch of IP cameras at my home, too. Different manufacturers. Declared to support Windows and Mac only. I watch all of them locally and remotely. They are configured to upload pictures over FTP to my router when motion is detected. I can check out these pictures remotely and I can watch the live streams remotely, all without their proprietary Windows/Mac software.