Need to allow access to DVR in the WAN network to LAN computers
-
I did the the capture from PC directly connected to the DVR (In same subnet) but is to big for the attachments.
Do you know how can I cut the important segments and how to identify the important segments?
Or I can split the file in zip files of 5000kb and make two post because compressed is close to 15 MB.
I did an Export packet disecctions to plain text. Maybe is good enough.
-
No that is going to suck.. Just pull the data out and leave all the headers..
Or post it elsewhere.. Or yeah split up the zip file, any zip software can split up a zip to whatever size you want.
What I can tell you is I see 5 conversations starting in that sniff vs your other one, I do see a 401 error in it. Bu the last conversation goes on and on with lots of data being passed.
-
I upload it to my Google Drive and share it:
https://drive.google.com/file/d/0B5nlqqyTt-VtNGFuVnBDVnVwcjg/view?usp=sharing
I dont expect to close the account or delete the file in many years, so it will be here available in the forum for others to see.
-
I think I might need to run other capture with "Turn off TCP reassembly in the preferences for TCP."
In the critical step Wireshark went to "tcp segment of a reassembled pdu " Maybe the data behind the header lines can tell you what happen.
I am going to try do it today but probably I will have to wait to next week.
If it is not needed another capture please tell me.
-
Well the only thing I see in this capture other than the other capture is there is an extra conversation started by the client to the same port 99 that gets lots of data back
DVRPOST /dvr/cmd HTTP/1.1 Host: 192.168.0.99:99 Authorization: Basic YWRtaW46MTIzNDU2AA== Content-Length: 242 Content-Type: multipart/form-data; boundary=----DVRBoundary ------DVRBoundary Content-Disposition: form-data; name="datafile"; filename="command.xml" Content-Type: text/xml <dvr platform="Hi3520"><getconfiguration file="profile.xml"></getconfiguration></dvr>HTTP/1.1 200 Ok Content-Type: text/xml Set-Cookie: sessionid=30ea7a1c-3a96-72cc-7da6-593a3928ba54 Content-Length: 4622 <dvr platform="Hi3520"><getconfigurationresponse return="0"> <dvr platform="Hi3520"><profile> <platform hardware="Hi3521-16CH-J" model="16CH" software="2.0b49" mcuconfigurable="True"></platform> <processors> <processor id="0" encodehq="1267200" encodelq="316800" decode="633600"> <snipped>[/code] In your other first sniff that conversation never happened.. Are you doing any sort of filtering on this sniff? The start of this conversation that never happens in your first sniff is like .0001 second later, etc. This is where all that data gets sent back to the client. What happens on the client when it doesn't work?</snipped></processor></processors></profile></dvr></getconfigurationresponse></dvr> -
The iWatch App in good and bad sessions after processing the user/pass show a Vertical Color Sequence (like old TVs) with a message saying "…Loading".
In the good session it loads the stream channels, in a bad session just sits there waiting until it gives an application error (Not informative at all).
When I did the capture that I sent first I did it with the pfsense Packet Capture tool using defaults except put the DVR IP on the host field.
In the capture with the good session I did it with Wireshark using defaults, but I added a filter. I use the "host 192.168.0.99" filter. The filter was already in the Capture options but with other ip as "host otherip" and I replace the otherip but left the "host" word.
-
Filtering on that IP is not going to give us any multicast that might be going on or any layer 2 that might be going on..
Capture without any filters…
-
If he's filtering on the DVR's IP address (or MAC), as I suggested, it will show multicast traffic from the DVR. Multicast is sent to an address in the multicast range, but the source is always the devices IP address. In the capture, I saw a single multicast frame from the DVR.
-
Exactly but you wouldn't see any multicast from the client because he was filtering on the dvr IP.
Not sure why this is even an issue.. Why are you trying to put stuff on pfsense wan network? Just put all your devices on the same layer 2. Move the devices that are currently in front of pfsense to behind pfsense so it goes
isp device - pfsense - all your stuff.
-
Why would there be any multicast from the client? It doesn't normally send out multicast traffic, but may communicate with the server via it's unicast address. In IPv6, multicast is used for a lot more than in IPv4, for things like router solicitation and more. There is also an all nodes multicast, which replaces the IPv4 broadcast.
-
Do you know how this client talks to the dvr? All I see in the sniff that works is a query via port 99 that is just html with a bunch of info.. Lets get a sniff on the same layer 2 without any filtering on the capature.. And actually see start of transfer of video.
In the sniffs we have seen. There was a query from the client to port 99, and lots of stuff sent back via html. In the client that doesn't work never see that syn to dvr IP on 99.. But yes I agree in the 2nd sniff there was 1 multicast thing put out by the dvr. maybe there is something else being sent out from the client IP that we are missing?
-
From the payload of the capture there is a line about the type of DVR.
The attachment is for that DVR.
In there it says it uses something called QCIF network transfer. I dont know what that is but maybe you know what is that.
I look for it in Google but I did not see the relevance with networking.
-
I am having difficulties to do the new capture, the Owner has not being available.
I hope that by tomorrow I can get the capture.
Sorry for the delay. -
Finally.
Here is the link to the wireshark capture with no filter:
https://drive.google.com/file/d/0B5nlqqyTt-Vtc0N5bGJISXB6MlE/view?usp=sharing
This is a big file because the computer gets really slow when the app plays the streaming and to close the app the system takes much time.
As soon the app closes I stopped the capture.
-
I did a capture within the pfsense network but this time I set the detail to full and unlimited lines instead of 100.
And set to listen on WAN interface. -
Capture but on LAN interface with unlimited lines
-
When you try with Wireshark on that computer, you probably want to use a capture filter to limit what you have to sort through. When you start Wireshark, double click on the interface. Then in the capture filter box enter host <ip address="" of="" the="" dvr="">, click on OK and then on Start. You'll then see packets to or from the PVR. Multicast addresses are within the range of 224.0.0.0 to 239.255.255.255. Any multicast packets, from the PVR will have a destination address within that range and whatever it's IP address is for the source.</ip>
I look for the multicast address as 224.0.0.0 to 239.255.255.255 but did not found any, so I guess there are no multicast transmissions. The problem seems to be other thing.
I really tried to saw in the captures a difference between a good connection and a bad connection but I could not. I do not have enough knowledge for this. -
I think that the problem was fixed and did not realized it. I was barking to the wrong tree.
On Windows 7 clients the iWatch application showed the stream successfully. It seems, do not know why, the iWatch application app fails to run correctly on Windows Servers. I was doing my tests on the Server. I think the clients got fixed when I disable one of the WAN default Firewall rules (Block to private subnets).
