PfSense stopping my IP security camera from working correctly :(
-
Color me confused… I searched for static port related stuff and it all seems to apply to NAT and internet based stuff. My issue is on the LAN :(
I followed this doc located here (http://doc.pfsense.org/index.php/Static_Port) Static port is turned on, but it did not put a dent in my issue... any other ideas?
-
Before the upgrade everything was working fine, but now my browser times out attempting to connect to the camera.
Connect by name (e.g. http://mycamera.example.org) or by IP address (e.g. http://192.168.1.2)?
Where is the connection initiated? Does the connection attempt need to go through pfSense? (Some information on your network configuration would help.)
Changing the port from 80 has no effect and the only way to get it going WITH pfSense is to shut down my pfSense VM and THEN start up the camera. Once the camera has loaded I can power the pfSense box back up and everything will work fine. However, if I power cycle the camera while pfSense is turned on the camera will stop responding… it seems like pfSense is telling it something it does not like when it starts... :(
Presumably when you power cycle the camera there is the possibility it will get a different IP address. If you are attempting to connect by name then are you allowing time for for the new name to address mapping to propagate? If you are connecting by IP address, what address are you using: the old or new?
-
Let me first apologize for the lack of hardcore details. I honestly assumed it was some stupid setting or filter I have turned on that would cause this whole mess….
Here is my full setup:
–------
To simplify things the camera is set with a static IP as shown in the diagram. I attempt to connect to the camera by going to http://192.168.5.200 on my LAN. I am not messing with pushing data to or from pfSense as best as I can tell. The only link the camera has to the router is that pfSense is set as the default gateway. Honestly, that is what strikes me as odd... I am moving data on the same subnet from 192.168.5.x to 192.168.5.200 and it should not have anything to do with the router :(
I have also found another work around that sorta fixes the issue. If I change the default gateway of the camera away from pfSense to a bogus IP it will work. While it works there are obvious issues with using a bad gateway and the only way I can remotely access my cameras is by my VPN. So, it seems the camera boots up, contacts pfSense and then tanks for some unknown reason. I have tried testing it with a small linksys router and using that as the default gateway without any problems removing pfSense from the picture. I can not figure out what pfSense has going on that will tank the camera when it works fine with a cheapo linksys router in my lab :(
-
Let me first apologize for the lack of hardcore details. I honestly assumed it was some stupid setting or filter I have turned on that would cause this whole mess….
No problem. Its not always easy to answer the question: What are the relevant details?
To simplify things the camera is set with a static IP as shown in the diagram. I attempt to connect to the camera by going to http://192.168.5.200 on my LAN. I am not messing with pushing data to or from pfSense as best as I can tell. The only link the camera has to the router is that pfSense is set as the default gateway. Honestly, that is what strikes me as odd… I am moving data on the same subnet from 192.168.5.x to 192.168.5.200 and it should not have anything to do with the router :(
Have you verified the network mask is the same on all the systems? If at some stage the camera thinks its on a different subnet to all the systems and it doesn't have a router on its own subnet it will have difficulty.
I have also found another work around that sorta fixes the issue. If I change the default gateway of the camera away from pfSense to a bogus IP it will work. While it works there are obvious issues with using a bad gateway and the only way I can remotely access my cameras is by my VPN. So, it seems the camera boots up, contacts pfSense and then tanks for some unknown reason. I have tried testing it with a small linksys router and using that as the default gateway without any problems removing pfSense from the picture. I can not figure out what pfSense has going on that will tank the camera when it works fine with a cheapo linksys router in my lab :(
What IP address do you use for the "bogus gateway"?
Do you have some evidence the camera contacts pfSense? (Other than the camera behaves differently when pfSense is there?) A tcpdump trace on pfSense would be useful to figure out if there is such a conversation and what is being exchanged.
When you have the linksys router involved does that replace pfSense, inheriting the pfSense IP address? If not, what IP address and network mask does it use? Does the camera have a configured DNS? If so, what is it and does it change when the linksys is used?
Does the camera allow only one connection at a time? If so, how is the camera notified the current user has finished and the camera should now accept a new connection?
It is not obvious pfSense would be involved in a conversation between the camera and any of the other computers on your diagram. One possibility that occurred to me is that on accepting a connection the camera might ask the name server (pfSense?) for the hostname of the system that just connected. The camera might be over zealous concerning the answer and (for example) "go quiet" for a time if the answer was not to its liking. (I'm guessing the camera would have some means of restricting access - a "security" camera that allowed anyone to access and control it doesn't seem to me as if it would be very effective.)
-
First let me thank you quick and detailed replied. My first draft diagram might of been a little too simplified… but then again I did whip it up in like 5mins before bed :)
Here is a 2nd draft that shows a much better picture of my network:
The info you requested:
1. All the subnets have been verified to match, so the camera should never think it is on another subnet as far as I can tell…
2. My bogus IP address is simply 192.168.5.2 which does not exist on my LAN.
3. Evidence of the camera talking to pfSense:
Packet Capture on Normal with bogus gateway of 192.168.5.2 and client that successfully accessed the camera is 192.168.5.147-11:10:44.935173 arp who-has 192.168.5.2 (ff:ff:ff:ff:ff:ff) tell 192.168.5.200
11:10:46.228533 arp who-has 192.168.5.2 tell 192.168.5.200
11:10:47.370202 arp who-has 192.168.5.2 tell 192.168.5.200
11:10:48.432390 arp who-has 192.168.5.2 tell 192.168.5.200
11:10:51.421371 IP 192.168.5.200.1024 > 239.255.255.250.1900: UDP, length 137
11:10:51.510344 IP 192.168.5.200 > 224.0.0.22: igmp
11:10:51.730277 IP 192.168.5.200.5353 > 224.0.0.251.5353: UDP, length 145
11:10:51.995332 IP 192.168.5.200.5353 > 224.0.0.251.5353: UDP, length 145
11:10:52.260003 IP 192.168.5.200.5353 > 224.0.0.251.5353: UDP, length 145
11:10:52.520314 IP 192.168.5.200.5353 > 224.0.0.251.5353: UDP, length 283
11:10:53.424499 IP 192.168.5.200.1024 > 239.255.255.250.1900: UDP, length 132
11:10:53.536204 IP 192.168.5.200.5353 > 224.0.0.251.5353: UDP, length 283
11:10:55.456074 IP 192.168.5.200.1024 > 239.255.255.250.1900: UDP, length 133
11:10:55.590013 IP 192.168.5.200.5353 > 224.0.0.251.5353: UDP, length 283
11:10:55.642764 arp who-has 192.168.5.147 tell 192.168.5.200
11:10:57.463394 IP 192.168.5.200.1024 > 239.255.255.250.1900: UDP, length 101
11:10:59.596056 IP 192.168.5.200.5353 > 224.0.0.251.5353: UDP, length 283
11:11:01.266401 arp who-has 192.168.5.10 tell 192.168.5.200
11:11:01.267558 arp who-has 192.168.5.200 tell 192.168.5.10
11:11:01.282686 arp who-has 192.168.5.2 tell 192.168.5.200
11:11:02.282200 arp who-has 192.168.5.2 tell 192.168.5.200-------------Log with gateway set to pfSense (192.168.5.1) Does Not respond to port 80-----------
11:21:07.648163 arp who-has 192.168.5.1 (ff:ff:ff:ff:ff:ff) tell 192.168.5.200
11:21:07.648217 arp reply 192.168.5.1 is-at 00:0c:29:a8:ac:0e
11:21:09.082009 IP 192.168.5.200 > 192.168.5.1: ICMP echo request, id 58368, seq 0, length 84
11:21:09.082111 IP 192.168.5.1 > 192.168.5.200: ICMP echo reply, id 58368, seq 0, length 84
11:21:14.233985 IP 192.168.5.200 > 224.0.0.22: igmp
11:21:14.343808 IP 192.168.5.200.1025 > 239.255.255.250.1900: UDP, length 137
11:21:14.472163 IP 192.168.5.200.5353 > 224.0.0.251.5353: UDP, length 145
11:21:14.741277 IP 192.168.5.200.5353 > 224.0.0.251.5353: UDP, length 145
11:21:15.010346 IP 192.168.5.200.5353 > 224.0.0.251.5353: UDP, length 145
11:21:15.284609 IP 192.168.5.200.5353 > 224.0.0.251.5353: UDP, length 283
11:21:16.291753 IP 192.168.5.200.5353 > 224.0.0.251.5353: UDP, length 283
11:21:16.370751 IP 192.168.5.200.1025 > 239.255.255.250.1900: UDP, length 132
11:21:18.307379 IP 192.168.5.200.5353 > 224.0.0.251.5353: UDP, length 283
11:21:18.417083 IP 192.168.5.200.1025 > 239.255.255.250.1900: UDP, length 133
11:21:18.572079 IP 192.168.5.200.80 > 192.168.5.147.60473: tcp 0
11:21:19.499068 IP 192.168.5.200.80 > 192.168.5.147.60473: tcp 0
11:21:20.423491 IP 192.168.5.200.1025 > 239.255.255.250.1900: UDP, length 101
11:21:20.485776 IP 192.168.5.200.80 > 192.168.5.147.60473: tcp 0
11:21:21.485623 IP 192.168.5.200.80 > 192.168.5.147.60473: tcp 0
11:21:22.314307 IP 192.168.5.200.5353 > 224.0.0.251.5353: UDP, length 283
11:21:22.522809 IP 192.168.5.200.80 > 192.168.5.147.60473: tcp 0
11:21:23.503124 IP 192.168.5.200.80 > 192.168.5.147.60473: tcp 0
11:21:23.778666 IP 192.168.5.200.1026 > 192.168.5.10.53: UDP, length 31
11:21:23.778752 IP 192.168.5.200.1026 > 192.168.5.10.53: UDP, length 31
11:21:23.785570 IP 192.168.5.200.1025 > 192.43.244.18.123: UDP, length 48
11:21:23.883946 IP 192.43.244.18.123 > 192.168.5.200.1025: UDP, length 48
11:21:23.977519 IP 192.168.5.200.80 > 192.168.5.147.60473: tcp 0
11:21:25.484998 IP 192.168.5.200.80 > 192.168.5.147.60473: tcp 0===============
4. The camera in it's current state allows for 10 viewers at a time on the web interface. I'm not 100% sure of the workings of the camera, but I "think" when you go to the web GUI it makes a request to stream the video to your browser via the camera's streaming server. Once you disconnect the feed should be broken and it frees up a seat. That is my best guess based on the limited info and clueless tech support people. The camera is running BusyBox Linux, so it works differently than say my existing Panasonic cams.
5. I share your line of thinking that it should have no reason to talk to pfSense. The default gateway and DNS are all set to my WIN 2K8 domain controller which manages all those services. The WIN 2K8 box stays running 100% of the time when the cam works or fails and the only variable is pfSense.Here are some camera logs that "Might" shed some light on the puzzle:
---------Log with bogus gateway (192.168.5.2) that works------------
Nov 8 20:15:00 MegaCam 4210 syslog.info syslogd started: BusyBox v1.1.0 (2009.06.25-02:09+0000)
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: Linux version 2.4.19-pl1029 (richard@richard) (gcc version 3.3.4) #338 Thu Jun 25 10:09:01 CST 2009
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: CPU: Faraday FA526id(wb) revision 1
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: ICache:16KB enabled, DCache:16KB enabled, BTB support, IDLE support
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: Machine: Prolific ARM9v4 - PL1029
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: Prolific arm arch version 1.0.12
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: On node 0 totalpages: 8192
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: zone(0): 8192 pages.
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: zone(1): 0 pages.
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: zone(2): 0 pages.
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: Kernel command line: root=/dev/norblock/disc0/disc rootfstype=cramfs nor=b:0x6029312@0xe0000,c:40960@0x4000,c:8192@0xe000
Nov 8 20:15:00 MegaCam 4210 user.debug kernel: Relocating machine vectors to 0xffff0000
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: plser console driver v2.0.0
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: Calibrating delay loop... 147.56 BogoMIPS
Nov 8 20:15:00 MegaCam 4210 user.info kernel: Memory: 32MB = 32MB total
Nov 8 20:15:00 MegaCam 4210 user.notice kernel: Memory: 30668KB available (1289K code, 350K data, 68K init)
Nov 8 20:15:00 MegaCam 4210 user.info kernel: Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
Nov 8 20:15:00 MegaCam 4210 user.info kernel: Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: POSIX conformance testing by UNIFIX
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: PCI: Probing PCI hardware on host bus 0.
Nov 8 20:15:00 MegaCam 4210 user.info kernel: Linux NET4.0 for Linux 2.4
Nov 8 20:15:00 MegaCam 4210 user.info kernel: Based upon Swansea University Computer Society NET3.039
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: Initializing RT netlink socket
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: tts/%d0 at MEM 0x1b000400 (irq = 2) is a PLSER
Nov 8 20:15:00 MegaCam 4210 user.info kernel: Prolific addr driver v0.0.4
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: Starting kswapd
Nov 8 20:15:00 MegaCam 4210 user.info kernel: devfs: v1.12a (20020514) Richard Gooch (rgooch@atnf.csiro.au)
Nov 8 20:15:00 MegaCam 4210 user.info kernel: devfs: boot_options: 0x1
Nov 8 20:15:00 MegaCam 4210 user.info kernel: i2c-core.o: i2c core module version 2.8.1 (20031005)
Nov 8 20:15:00 MegaCam 4210 user.info kernel: i2c-dev.o: i2c /dev entries driver module version 2.8.1 (20031005)
Nov 8 20:15:00 MegaCam 4210 user.info kernel: Prolific i2c algorithm module v1.2
Nov 8 20:15:00 MegaCam 4210 user.info kernel: Initialize Prolific I2C adapter module v1.2.1
Nov 8 20:15:00 MegaCam 4210 user.debug kernel: i2c-dev.o: Registered 'prolific-i2c-adapter' as minor 0
Nov 8 20:15:00 MegaCam 4210 user.info kernel: found i2c adapter at 0xd9440000 irq 17. Data tranfer clock is 100000Hz
Nov 8 20:15:00 MegaCam 4210 user.info kernel: i2c-proc.o version 2.8.1 (20031005)
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: pty: 256 Unix98 ptys configured
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: PL-1029 NOR flash driver, version 0.8.4
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: NOR flash type: ppi-amd 8x8 64x63
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: NOR flash id = 0xf9
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: nor interrupt 30 registered
Nov 8 20:15:00 MegaCam 4210 user.info kernel: Partition check:
Nov 8 20:15:00 MegaCam 4210 user.info kernel: norblocka: unknown partition table
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Nov 8 20:15:00 MegaCam 4210 user.info kernel: PPP generic driver version 2.4.2
Nov 8 20:15:00 MegaCam 4210 user.info kernel: 8139too Fast Ethernet driver 0.9.25
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: read_eeprom for addr_len in init_one of 8139.too.c = c280f000
Nov 8 20:15:00 MegaCam 4210 user.info kernel: eth0: RealTek RTL8139 Fast Ethernet at 0xc280f000, 00:0e:ae:a1:2c:d3, IRQ 5
Nov 8 20:15:00 MegaCam 4210 user.debug kernel: eth0: Identified 8139 chip type 'RTL-8139C'
Nov 8 20:15:00 MegaCam 4210 user.info kernel: SCSI subsystem driver Revision: 1.00
Nov 8 20:15:00 MegaCam 4210 user.err kernel: kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
Nov 8 20:15:00 MegaCam 4210 user.info kernel: Prolific Real-Time Clock Driver version 1.0.0 (2003-04-02)
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: Prolific keypad driver v1.0.8
Nov 8 20:15:00 MegaCam 4210 user.info kernel: PL UART driver version 1.1.0-1 (2007-02-15)
Nov 8 20:15:00 MegaCam 4210 user.info kernel: Initializing Cryptographic API
Nov 8 20:15:00 MegaCam 4210 user.info kernel: NET4: Linux TCP/IP 1.0 for NET4.0
Nov 8 20:15:00 MegaCam 4210 user.info kernel: IP Protocols: ICMP, UDP, TCP, IGMP
Nov 8 20:15:00 MegaCam 4210 user.info kernel: IP: routing cache hash table of 512 buckets, 4Kbytes
Nov 8 20:15:00 MegaCam 4210 user.info kernel: TCP: Hash tables configured (established 2048 bind 4096)
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: ip_tables: (C) 2000-2002 Netfilter core team
Nov 8 20:15:00 MegaCam 4210 user.info kernel: NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Nov 8 20:15:00 MegaCam 4210 user.alert kernel: 802.1Q VLAN Support v1.8 Ben Greear greearb@candelatech.comNov 8 20:15:00 MegaCam 4210 user.alert kernel: All bugs added by David S. Miller davem@redhat.comNov 8 20:15:00 MegaCam 4210 user.emerg kernel: Fast Floating Point Emulator V0.9 (c) Peter Teichmann.
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: VFS: Mounted root (cramfs filesystem) readonly.
Nov 8 20:15:00 MegaCam 4210 user.info kernel: Mounted devfs on /dev
Nov 8 20:15:00 MegaCam 4210 user.info kernel: Freeing init memory: 68K
Nov 8 20:15:00 MegaCam 4210 user.emerg kernel: pl serial only support even parity
Nov 8 20:15:05 MegaCam 4210 user.notice 0: /script/chk_ap : ptz_model : yes
Nov 8 20:15:05 MegaCam 4210 user.emerg kernel: Prolific Audio AC97 driver version 2.2.2 for 63 and 29 Audio Module 2006/03/21
Nov 8 20:15:05 MegaCam 4210 user.info kernel: ac97_codec: AC97 Audio codec, id: 0x414c:0x4770 (Realtek ALC203/203LF)
Nov 8 20:15:05 MegaCam 4210 user.alert kernel: OV7725.o version 1.0.0.0 (20070327)
Nov 8 20:15:05 MegaCam 4210 user.alert kernel: CMOS sensor OV7725 is avaliable now
Nov 8 20:15:05 MegaCam 4210 user.alert kernel: Set 75 registers value
Nov 8 20:15:05 MegaCam 4210 user.alert kernel: plmedia version 1.2.9
Nov 8 20:15:05 MegaCam 4210 user.alert kernel: Hello Grabber!
Nov 8 20:15:05 MegaCam 4210 user.alert kernel: Hello Encoder!
Nov 8 20:15:05 MegaCam 4210 user.alert kernel: Hello PLMD!
Nov 8 20:15:05 MegaCam 4210 user.emerg kernel: aes interrupt 12 registered
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: gpio daemon start up ...
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: setting : NA[0] active=0
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: setting : NA[1] active=0
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: setting : NA[2] active=0
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: setting : NA[3] active=0
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: setting : IRLED[4] active=0
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: setting : Reset[5] active=0
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: setting : NC[6] active=0
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: setting : NC[7] active=0
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: setting : NC[8] active=0
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: setting : WirelessLED[10] active=0
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: setting : videoreset[11] active=0
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: gpio[0] set output
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: gpio[1] set output
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: gpio[2] set output
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: gpio[3] set output
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: gpio[4] set output
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: gpio[5] set input
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: gpio[6] set output
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: gpio[7] set output
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: gpio[8] set output
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: gpio[9] set output
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: gpio[10] set output
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: GPIO_SETENB 10
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: gpio[11] set output
Nov 8 20:15:06 MegaCam 4210 user.debug gpio: send msg /tmp/gpio_state [Reset Disabled]
Nov 8 20:15:06 MegaCam 4210 user.err network: network start
Nov 8 20:15:07 MegaCam 4210 user.err network: network start
Nov 8 20:15:07 MegaCam 4210 user.err network: dips: 105665291
Nov 8 20:15:07 MegaCam 4210 user.emerg kernel: UART baudrate clock is 48000
Nov 8 20:15:07 MegaCam 4210 user.emerg kernel: UART baudrate clock is 48000
Nov 8 20:15:07 MegaCam 4210 user.err ptz: ccm_module_load /lib/libA-MTK.so
Nov 8 20:15:07 MegaCam 4210 user.err ptz: Stop RS485 control
Nov 8 20:15:07 MegaCam 4210 user.emerg kernel: RS485_STOP
Nov 8 20:15:07 MegaCam 4210 user.err network: Wireless device not present
Nov 8 20:15:08 MegaCam 4210 user.info kernel: eth0: Setting 100mbps full-duplex based on auto-negotiated partner ability 45e1.
Nov 8 20:15:08 MegaCam 4210 user.err network: network : start linkstatus 1
Nov 8 20:15:08 MegaCam 4210 user.err network: ethernet_init ifconfig eth0 0.0.0.0 up
Nov 8 20:15:08 MegaCam 4210 user.err httpd: Model name MegaCam 4210 Firmware version 3.0.3.3308
Nov 8 20:15:08 MegaCam 4210 user.err httpd: pthread_create audio_receive_loop
Nov 8 20:15:08 MegaCam 4210 user.err network: ifconfig eth0 192.168.5.200 netmask 255.255.255.0 up
Nov 8 20:15:08 MegaCam 4210 user.debug rtsp-svr: listening on control socket /tmp/spook.sock
Nov 8 20:15:09 MegaCam 4210 user.debug rtsp-svr: listening on tcp port 554
Nov 8 20:15:09 MegaCam 4210 user.debug rtsp-svr: session count 0
Nov 8 20:15:09 MegaCam 4210 user.info kernel: eth0: Setting 100mbps full-duplex based on auto-negotiated partner ability 45e1.
Nov 8 20:15:09 MegaCam 4210 user.err network: ethernet: route del default
Nov 8 20:15:09 MegaCam 4210 user.debug AVControl: snd codec=3,ena=1
Nov 8 20:15:09 MegaCam 4210 user.debug AVControl: profile=-1,type=4,vbr=1,bps=524288,fps=30,w=320,h=240
Nov 8 20:15:09 MegaCam 4210 user.debug AVControl: profile=-1,keyframerate=30,q=3
Nov 8 20:15:09 MegaCam 4210 user.debug AVControl: sensor type [ov7725]
Nov 8 20:15:09 MegaCam 4210 user.debug AVControl: profile=0,type=2,vbr=0,bps=4194304,fps=30,w=640,h=480
Nov 8 20:15:09 MegaCam 4210 user.debug AVControl: profile=0,keyframerate=30,q=4
Nov 8 20:15:09 MegaCam 4210 user.debug AVControl: md[0]ena=0,(0,0),(0,0),det=0,sens=0,type=0
Nov 8 20:15:09 MegaCam 4210 user.debug AVControl: md[1]ena=0,(0,0),(0,0),det=0,sens=0,type=0
Nov 8 20:15:09 MegaCam 4210 user.debug AVControl: md[2]ena=0,(0,0),(0,0),det=0,sens=0,type=0
Nov 8 20:15:09 MegaCam 4210 user.debug AVControl: md[3]ena=0,(0,0),(0,0),det=0,sens=0,type=0
Nov 8 20:15:09 MegaCam 4210 user.debug AVControl: profile=1,type=2,vbr=1,bps=524288,fps=30,w=320,h=240
Nov 8 20:15:09 MegaCam 4210 user.debug AVControl: profile=1,keyframerate=30,q=9
Nov 8 20:15:09 MegaCam 4210 user.debug AVControl: profile=2,type=2,vbr=1,bps=131072,fps=30,w=160,h=120
Nov 8 20:15:09 MegaCam 4210 user.debug AVControl: profile=2,keyframerate=30,q=9
Nov 8 20:15:09 MegaCam 4210 user.debug AVControl: profile=3,type=4,vbr=1,bps=524288,fps=30,w=320,h=240
Nov 8 20:15:09 MegaCam 4210 user.debug AVControl: profile=3,keyframerate=30,q=3
Nov 8 20:15:10 MegaCam 4210 user.debug AVControl: grab loop …
Nov 8 20:15:10 MegaCam 4210 user.debug AVControl: enc_thread start 0
Nov 8 20:15:10 MegaCam 4210 user.debug AVControl: enc_thread start 1
Nov 8 20:15:10 MegaCam 4210 user.debug AVControl: enc_thread start 2
Nov 8 20:15:10 MegaCam 4210 user.debug AVControl: enc_thread start 3
Nov 8 20:15:10 MegaCam 4210 user.debug AVControl: Open /dev/pl_grab successfully
Nov 8 20:15:10 MegaCam 4210 user.debug AVControl: nSType = 1
Nov 8 20:15:10 MegaCam 4210 user.debug AVControl: cap: set grab format!
Nov 8 20:15:10 MegaCam 4210 user.debug AVControl: cap: request image buffer information!
Nov 8 20:15:10 MegaCam 4210 user.debug AVControl: cap: get buffer information!
Nov 8 20:15:10 MegaCam 4210 user.debug AVControl: cap: set buffer validate!
Nov 8 20:15:10 MegaCam 4210 user.debug AVControl: enc_thread start 4
Nov 8 20:15:10 MegaCam 4210 user.debug AVControl: cap: grab on .
Nov 8 20:15:10 MegaCam 4210 user.debug AVControl: osd type=6,bgcolor=00000000,fgcolor=00ffffff,str=
Nov 8 20:15:10 MegaCam 4210 user.debug AVControl: waiting connect 0
Nov 8 20:15:10 MegaCam 4210 user.debug AVControl: snd codec=3,ena=1
Nov 8 20:15:10 MegaCam 4210 user.debug AVControl: Sound loop start .enable=1!
Nov 8 20:15:10 MegaCam 4210 user.err network: connect_log: ARPING to 192.168.5.2 from 192.168.5.200 via eth0
Nov 8 20:15:10 MegaCam 4210 user.err network: connect_log: Sent 1 probes (1 broadcast(s))
Nov 8 20:15:10 MegaCam 4210 user.err network: connect_log: Received 0 reply
Nov 8 20:15:10 MegaCam 4210 user.err network: ethernet: route add default gw 192.168.5.2 dev eth0
Nov 8 20:15:10 MegaCam 4210 user.debug AVControl: pthread join all thread
Nov 8 20:15:10 MegaCam 4210 user.err network: /scripts/ZeroConfig restart eth0
Nov 8 20:15:10 MegaCam 4210 user.err network: /scripts/LinkLocalAddr eth0:0
Nov 8 20:15:11 MegaCam 4210 user.debug AVControl: pMDStart = 0x40006000 pMDAddr = 25395200
Nov 8 20:15:11 MegaCam 4210 user.debug AVControl: enc connect to grab 0
Nov 8 20:15:11 MegaCam 4210 user.debug AVControl: profile 0 init ok
Nov 8 20:15:11 MegaCam 4210 user.debug AVControl: grab loop accept socket connect[0]
Nov 8 20:15:11 MegaCam 4210 user.debug AVControl: waiting connect 1
Nov 8 20:15:11 MegaCam 4210 user.debug AVControl: enc connect to grab 1
Nov 8 20:15:11 MegaCam 4210 user.debug AVControl: profile 1 init ok
Nov 8 20:15:11 MegaCam 4210 user.debug AVControl: grab loop accept socket connect[1]
Nov 8 20:15:11 MegaCam 4210 user.debug AVControl: waiting connect 2
Nov 8 20:15:11 MegaCam 4210 user.debug AVControl: grab loop accept socket connect[2]
Nov 8 20:15:11 MegaCam 4210 user.debug AVControl: waiting connect 3
Nov 8 20:15:11 MegaCam 4210 user.debug AVControl: enc connect to grab 3
Nov 8 20:15:11 MegaCam 4210 user.debug AVControl: profile 3 init ok
Nov 8 20:15:11 MegaCam 4210 user.debug AVControl: grab loop accept socket connect[3]
Nov 8 20:15:11 MegaCam 4210 user.debug AVControl: waiting connect 4
Nov 8 20:15:11 MegaCam 4210 user.debug AVControl: enc connect to grab 2
Nov 8 20:15:11 MegaCam 4210 user.debug AVControl: profile 2 init ok
Nov 8 20:15:11 MegaCam 4210 user.debug AVControl: enc connect to grab 4
Nov 8 20:15:11 MegaCam 4210 user.debug AVControl: profile 4 init ok
Nov 8 20:15:11 MegaCam 4210 user.debug AVControl: grab loop accept socket connect[4]
Nov 8 20:15:11 MegaCam 4210 user.debug AVControl: profile[2] running 0
Nov 8 20:15:11 MegaCam 4210 user.debug AVControl: profile[3] running 0
Nov 8 20:15:11 MegaCam 4210 user.debug AVControl: profile[1] running 0
Nov 8 20:15:11 MegaCam 4210 user.debug AVControl: profile[0] running 0
Nov 8 20:15:13 MegaCam 4210 daemon.info init: Starting pid 266, console /dev/tts/0: '/bin/sh'
Nov 8 20:15:13 MegaCam 4210 user.debug AVControl: audio running 0
Nov 8 20:15:13 MegaCam 4210 user.debug AVControl: audio amr running 0
Nov 8 20:15:20 MegaCam 4210 user.err httpd: Httpd listen port 80, fd 7
Nov 8 20:15:20 MegaCam 4210 user.err httpd: Httpd listen port 32768, fd 8
Nov 8 20:15:21 MegaCam 4210 user.debug httpd: software_protect initialize
Nov 8 20:15:21 MegaCam 4210 user.emerg kernel: tts/s0, from user=1 data count=7
Nov 8 20:15:21 MegaCam 4210 user.emerg kernel: exit successfully, ret=7
Nov 8 20:15:24 MegaCam 4210 user.err network: IP notification
Nov 8 20:15:24 MegaCam 4210 user.err network: content: IP Address : http://192.168.5.200:80
Nov 8 20:15:24 MegaCam 4210 user.err network: system_time_init
Nov 8 20:15:25 MegaCam 4210 user.err network: settime -a "reset" -s "NTP" -S "time.nist.gov" -i "24:00:00" -z "GMT-5" -d "2007-8-20" -t "00:00:00" -D "no" -O "01:00:00" -l "2" -m "11" -n "02:00:00" -o "10" -p "4" -q "02:00:00" &
Nov 8 20:15:25 MegaCam 4210 user.err network: iptables -F
Nov 8 20:15:25 MegaCam 4210 user.err network: iptables -X
Nov 8 20:15:25 MegaCam 4210 user.err network: iptables -P INPUT ACCEPT
Nov 8 20:15:25 MegaCam 4210 user.err network: iptables -P OUTPUT ACCEPT
Nov 8 20:15:25 MegaCam 4210 user.err network: Update network.asp
Nov 8 20:15:25 MegaCam 4210 user.err network: Update wireless.asp
Nov 8 20:15:25 MegaCam 4210 user.err network: Update pppoe.asp
Nov 8 20:15:25 MegaCam 4210 user.err network: Update upnp.asp
Nov 8 20:15:25 MegaCam 4210 user.err network: Update system.asp
Nov 8 20:15:25 MegaCam 4210 user.err network: Update index_mobile.asp
Nov 8 20:15:25 MegaCam 4210 user.debug httpd: add still image channel 9
Nov 8 20:15:51 MegaCam 4210 user.debug settime: Set system time
Nov 8 20:15:58 MegaCam 4210 user.debug httpd: remove still image channel 9–------No log for when it is set to 192.168.5.1 since it never responds :( ----------
Sorry if it is info over load, but I did not want to waste anyone's time by not giving up all the facts this time around.
Thanks again,
-Brann/davem@redhat.com/greearb@candelatech.com -
Is the Linksys AP an actual AP or a router that you are using as an AP?
-
It's a WRT that only has the switch LAN ports used which serves as an AP. I flashed it a few times with different firmware, but the linksys stock connected to my RADIUS server to run WPA2 enterprises does the trick for me.
-
Are you absolutely sure the dhcp server on it is shut off?
-
110% sure it's turned off. Plus the only dhcp services are on my window server AND the camera is set with a static IP. Trust me I wish it was something that simple :(
-
We had a Dlink we used this way. The DHCP server would turn on by itself sometimes for no reason… So alway gotta ask. If it gave something else on the network the .200 address then things would be a mess..
-
I don't know if its significant to the problem under discussion, but it in the second trace it appears the camera pings the specified gateway. (Perhaps you told it to, but you didn't say that.)
In the first trace the camera issues an ARP request to find the MAC address of the gateway and gets no response.
If you didn't tell the camera to ping the gateway then it might be worth adding a firewall rule to pfSense to block ping requests from the camera to see if that makes a difference. If blocking the ping requests make a difference then I think it would be worth heavily leaning on the camera tech support for an explanation.
The second trace shows an alive TCP connection between the camera http server (port 80) and 192.168.5.147 which doesn't seem to appear in your diagram. What is that system? Should it be sending something back?
-
The camera system log reports a probe attempt on the gateway - perhaps that ping I mentioned earlier is significant.
The camera log also reports use of iptables which, if I recall correctly, is one type of Linux firewall. Is there something strange about those rules?
What is the version of pfSense you are using? You mention 1.2.2 which I presume is what you mean by "the current version". Do you see different behaviour with one of the 1.2.3 snapshot builds?
-
Do you have pfSense set to suppress arp broadcasts?
System = Advanced = Shared Physical Network (This will suppress ARP messages when interfaces share the same physical network)
-
Ok after reading the posts these are the results from my testing this morning:
Info:
192.168.5.147 is just the dhcp IP assigned to my test machine that I am attempting to access the camera with. The appearance of that IP in the trace is just me trying to see if the camera loads in my browser on the test machine. iptables is/was an older linux firewall that I believe was replaced by ipchains. The camera is built onto of BusyBox which is a tiny linux distro for embed systems and sadly I do not have any access to the shell to check or change any of the system stuff like the firewall. It seems that it configures some iptables rules based on what it finds when it starts up. I have to assume it is finding something it does not like when it talk to pfSense and makes a rule blocking port 80 which makes NO! sense at all…
I spoke to the tech support people that are 100% useless and know less than I do about their own product. They only have trouble shooting docs for small home setups with a single linksys/dlink/whatever home router. When I explained my network details they just seemed to get very confused. The only solutions they offered was to downgrade the firmware which would work, but I would lose the features I want. Or I could Return the camera and they could care less since they plan on getting out of camera business in the next year or so. Looks Like they have no clue wtf their device is doing or how it works with the new firmware I am on my own over here :(1. Loaded the snapshot of 1.2.3 VM into my server and it did not resolve my issue. I could not see any difference in the way it was dealing with the camera from the packet capture.
2. Suppress arp broadcasts was not enable and turning it on does not appear to resolve the issue.
3. Attempt to block the ping from the camera to the router:
This seems like it should work, but I seem to be having problems with setting the rule. I went to Firewall -> Rules -> Lan and added a rule to block all ICMP traffic from 192.168.5.200 to anything device... Hell I even made a 2nd rule block all ICMP from 192.168.5.1 TO 192.168.5.200. I also tried rebooting the router after applying the rules... but it still seems to be replying back and I can't figure out what I am doing wrong. Here is the capture:11:20:02.638895 arp who-has 192.168.5.1 (ff:ff:ff:ff:ff:ff) tell 192.168.5.200
11:20:02.638953 arp reply 192.168.5.1 is-at 00:0c:29:a8:ac:0e
11:20:03.999850 IP 192.168.5.200 > 192.168.5.1: ICMP echo request, id 58880, seq 0, length 84
11:20:03.999976 IP 192.168.5.1 > 192.168.5.200: ICMP echo reply, id 58880, seq 0, length 84
11:20:09.152778 IP 192.168.5.200 > 224.0.0.22: igmp
11:20:09.235169 IP 192.168.5.200.1025 > 239.255.255.250.1900: UDP, length 137
11:20:09.416343 IP 192.168.5.200.5353 > 224.0.0.251.5353: UDP, length 145
11:20:09.681894 IP 192.168.5.200.5353 > 224.0.0.251.5353: UDP, length 145
11:20:09.954680 IP 192.168.5.200.5353 > 224.0.0.251.5353: UDP, length 145
11:20:10.387143 IP 192.168.5.200.5353 > 224.0.0.251.5353: UDP, length 283
11:20:11.243418 IP 192.168.5.200.1025 > 239.255.255.250.1900: UDP, length 132
11:20:11.407955 IP 192.168.5.200.5353 > 224.0.0.251.5353: UDP, length 283What am I doing wrong to not correctly block the ping?
-
From the look of your network diagram, pfSense doesn't have exclusive use of the LAN interface. It looks as if it is shared with Windows. MAYBE Windows is answering the ping. (I have no knowledge of the workings of the Windows VM host.) To check this you could do a trace on pfSense and see if the pings show up. (The trace is done BEFORE application of firewall rules.)
I haven't tried to block pings with pfSense firewall rules. I'd be surprised if pfSense didn't allow that.
Oh, and just to check all the details: the MAC address in the ARP response for 192.168.5.1 is the correct MAC address?
-
I will have to mess with trying to find a way to block that ping. I use VMware server and the way my server is configured pfSense has 100% unfiltered control over that network card and windows does not really even see it as a working card. The MAC address is correct and I am still scratching my head over here :(
The only thing that I could try is to match the hardware MAC (true mac address) with the virtual mac address since pfSense does not share the interface with any other OS. But, seriously I want to choke the tech support people because it worked perfect until they changed the firmware to do something funky at startup… no fun :(