Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - jondecker76

Pages: [1] 2 3 ... 51
1
Users / Re: ZOTAC ZBOX HD-ID11-U
« on: January 05, 2011, 10:18:36 am »
(these steps are assuming that your core doesn't need the r8169 driver

First, go to realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false#2 and download the 8.020.00 driver source (dated 11/15/2010). Then transfer this file to / on your core.
 (or, use wget on the core directly to download the file, I found it hosted on google code:
wget r8168.googlecode.com/files/r8168-8.020.00.tar.bz2)

Next, ssh into the core:
- Become super user
Code: [Select]
sudo su
Check whether the built-in driver, r8169.ko is installed.
Code: [Select]
lsmod | grep r8169
If it is installed (the command above will give you an indication), you will have to follow the r8168 wiki to download the kernel sources and apply a patch. Otherwise, continue on...

- Lets go to the driver source you placed in /
Code: [Select]
cd /

- Extract the sources, then cd into the source folder
Code: [Select]
tar -jxf r8168-8.020.00.tar.bz2
cd r8168-8.020.00

- Compile the sources
Code: [Select]
makeThe makefile SHOULD automatically put the driver file in the right place:
/lib/modules/2.6.22-14-generic/kernel/drivers/net/r8168.ko
if not, copy it over yourself:
Code: [Select]
cp ./r8168.ko /lib/modules/2.6.22-14-generic/kernel/drivers/net/r8168.ko

- Install the driver module
add a new line at the bottom of /etc/initramfs-tools-interactor/modules, then save:
Code: [Select]
vim /etc/initramfs-tools-interactor/modulesadd the following line at the bottom:
Code: [Select]
r8168then exit vim (:wq)

- Remove the r8169 module, we won't need it
rm /lib/modules/2.6.22-14-generic/kernel/drivers/net/r8169.ko

Code: [Select]
make install
depmod -a
modprobe r8168

- Make the MD ramdisk boot image
Code: [Select]
/usr/pluto/bin/Diskless_BuildDefaultImage.sh

Now you should be able to boot the MD - you'll know its working when you see "We have announced ourselves to the router" and the diskless setup runs (you should also at this time see a new Media Director in the web admin).
When the diskless setup is finished, the MD will reboot - but again it will fail with a kernel panic (the new diskless filesystem does not yet have the r8168 module, so lets fix that by copying it over from the root file system)...

Code: [Select]
cp /lib/modules/2.6.22-14-generic/kernel/drivers/net/r8168.ko /usr/pluto/diskless/<MD#>/lib/modules/2.6.22-14-generic/kernel/drivers/net/r8168.ko(make sure you replace <MD#> with the device number of your new MD - you can see this in the web admin)
(also note that your kernel version in the path could be different, change it as needed for your installation)

You need to activate the module in 2 places now, using vim:
Code: [Select]
vim /usr/pluto/diskless/<MD#>/etc/modulesand
Code: [Select]
vim /usr/pluto/diskless/<MD#>/etc/initramfs-tools/modules(Again, replace <MD#> with your actual MD device number)
add the following to the end of both above files:
Code: [Select]
r8168
-And also remove the r8169 driver from the MD's boot files
Code: [Select]
rm /usr/pluto/diskless/<MD#>/lib/modules/2.6.22-14-generic/kernel/drivers/net/r8168.ko
Now just recreate the ramdisk IN THE MD (via chroot)
Code: [Select]
cd /usr/pluto/diskless/
chroot <MD#>
depmod
cd /boot
mkinitramfs -o initrd.img-`uname -r` `uname -r`
exit

Finally, lets clean up our mess from building the driver:
Code: [Select]
rm -r /r8168-8.020.00
rm /r8168-8.020.00.tar.bz2

Now reboot, and you should come up to the A/V wizard and you're done

2
Users / Re: ZOTAC ZBOX HD-ID11-U
« on: January 05, 2011, 02:43:27 am »
ok, I got it..  I had to run
Code: [Select]
depmod -a
modprobe r8168
before running Diskless_BuildDefaultImage.sh

Its now booting

3
Users / Re: ZOTAC ZBOX HD-ID11-U
« on: January 04, 2011, 08:48:00 pm »
I just got my hands on a ZBOX, but following the Realtek 8168 and Unrecognized NIC WIKI pages still aren't doing anything for me.
(I have built the new r8168.ko file, but the wiki says to copy it to the MD's /usr/pluto/diskless directory structure... The problem is, the MD never netboots far enough in to even get as far as creating the diskless directory structure)

Has anyone else gotten one of these to work?

4
Users / Re: DHCP leases Foscam IP camera problem
« on: December 18, 2010, 03:35:20 am »
Yes, it does seem that the foscam is responsible for dropping the connection from all the logging I have done - but that doesn't explain why it works on the external network... strange!
Also, I have set up static ARP table entries for test, and even with no ARP packages being sent from LMCE, the foscam still drops connection.

5
Users / Re: DHCP leases Foscam IP camera problem
« on: December 17, 2010, 05:14:25 pm »
Been glancing over the data, and here is what I have so far....
The camera served its last image to motion at 10:05.07, and got the first disconnection grey screen at 10:05.12


Here is a small section of the tcpdump (without the actual packet data to keep it small). You can see that the foscam would send 2 packets of data to the core, then the core would send an ACK.. This repeated for over 10 minutes - 2 data packets from the foscam, and ack from the core.. repeat... repeat...
Then, look at packet 206761...  The foscam sends only a single package, and its marked as a retransmission, then the core sends a duplicate ACK.. From there, things look a little messed up for a few packages, then the ARP requests start firing, and the foscam never responds..
Code: [Select]
No.     Time        Source                Destination           Protocol Info
 206752 686.838205  192.168.80.1          192.168.80.202        TCP      60632 > http [ACK] Seq=124 Ack=189955810 Win=87872 Len=0 TSV=12705657 TSER=5021270
 206753 686.838592  192.168.80.202        192.168.80.1          HTTP     Continuation or non-HTTP traffic[Packet size limited during capture]
 206754 686.838857  192.168.80.202        192.168.80.1          HTTP     Continuation or non-HTTP traffic[Packet size limited during capture]
 206755 686.838936  192.168.80.1          192.168.80.202        TCP      60632 > http [ACK] Seq=124 Ack=189957993 Win=87872 Len=0 TSV=12705658 TSER=5021270
 206756 686.874947  192.168.80.202        192.168.80.1          HTTP     Continuation or non-HTTP traffic[Packet size limited during capture]
 206757 686.875301  192.168.80.202        192.168.80.1          HTTP     Continuation or non-HTTP traffic[Packet size limited during capture]
 206758 686.875411  192.168.80.1          192.168.80.202        TCP      60632 > http [ACK] Seq=124 Ack=189960889 Win=87872 Len=0 TSV=12705667 TSER=5021273
 206759 686.875852  192.168.80.202        192.168.80.1          HTTP     Continuation or non-HTTP traffic[Packet size limited during capture]
 206760 686.915893  192.168.80.1          192.168.80.202        TCP      60632 > http [ACK] Seq=124 Ack=189962337 Win=87872 Len=0 TSV=12705677 TSER=5021273
 206761 687.046868  192.168.80.202        192.168.80.1          HTTP     [TCP Retransmission] Continuation or non-HTTP traffic[Packet size limited during capture]
 206762 687.046942  192.168.80.1          192.168.80.202        TCP      [TCP Dup ACK 206760#1] 60632 > http [ACK] Seq=124 Ack=189962337 Win=87872 Len=0 TSV=12705710 TSER=5021273 SLE=189950018 SRE=189951466
 206763 687.178848  PcPartne_27:b8:1a     DavicomS_86:78:a6     ARP      Who has 192.168.80.202?  Tell 192.168.80.1
 206764 687.466883  192.168.80.202        192.168.80.1          HTTP     [TCP Retransmission] Continuation or non-HTTP traffic[Packet size limited during capture]
 206765 687.466960  192.168.80.1          192.168.80.202        TCP      [TCP Dup ACK 206760#2] 60632 > http [ACK] Seq=124 Ack=189962337 Win=87872 Len=0 TSV=12705815 TSER=5021273 SLE=189950018 SRE=189951466
 206766 687.832034  192.168.80.1          192.168.80.202        NBNS     Name query NBSTAT *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
 206767 688.179661  PcPartne_27:b8:1a     DavicomS_86:78:a6     ARP      Who has 192.168.80.202?  Tell 192.168.80.1
 206768 688.306900  192.168.80.202        192.168.80.1          HTTP     [TCP Retransmission] Continuation or non-HTTP traffic[Packet size limited during capture]
 206769 688.306997  192.168.80.1          192.168.80.202        TCP      [TCP Dup ACK 206760#3] 60632 > http [ACK] Seq=124 Ack=189962337 Win=87872 Len=0 TSV=12706025 TSER=5021273 SLE=189950018 SRE=189951466
 206770 689.179664  PcPartne_27:b8:1a     DavicomS_86:78:a6     ARP      Who has 192.168.80.202?  Tell 192.168.80.1
 206771 689.986923  192.168.80.202        192.168.80.1          HTTP     [TCP Retransmission] Continuation or non-HTTP traffic[Packet size limited during capture]
 206772 689.987066  192.168.80.1          192.168.80.202        TCP      [TCP Dup ACK 206760#4] 60632 > http [ACK] Seq=124 Ack=189962337 Win=87872 Len=0 TSV=12706444 TSER=5021273 SLE=189950018 SRE=189951466
 206773 693.346951  192.168.80.202        192.168.80.1          HTTP     [TCP Retransmission] Continuation or non-HTTP traffic[Packet size limited during capture]
 206774 693.350801  PcPartne_27:b8:1a     Broadcast             ARP      Who has 192.168.80.202?  Tell 192.168.80.1
 206775 694.350674  PcPartne_27:b8:1a     Broadcast             ARP      Who has 192.168.80.202?  Tell 192.168.80.1
 206776 695.351191  PcPartne_27:b8:1a     Broadcast             ARP      Who has 192.168.80.202?  Tell 192.168.80.1
 206777 696.879048  PcPartne_27:b8:1a     Broadcast             ARP      Who has 192.168.80.202?  Tell 192.168.80.1
 206778 697.879183  PcPartne_27:b8:1a     Broadcast             ARP      Who has 192.168.80.202?  Tell 192.168.80.1
 206779 698.880183  PcPartne_27:b8:1a     Broadcast             ARP      Who has 192.168.80.202?  Tell 192.168.80.1
 206780 699.939171  PcPartne_27:b8:1a     Broadcast             ARP      Who has 192.168.80.202?  Tell 192.168.80.1
 206781 700.067001  192.168.80.202        192.168.80.1          HTTP     [TCP Retransmission] Continuation or non-HTTP traffic[Packet size limited during capture]
 206782 700.939177  PcPartne_27:b8:1a     Broadcast             ARP      Who has 192.168.80.202?  Tell 192.168.80.1
 206783 701.939205  PcPartne_27:b8:1a     Broadcast             ARP      Who has 192.168.80.202?  Tell 192.168.80.1
 206784 703.203170  PcPartne_27:b8:1a     Broadcast             ARP      Who has 192.168.80.202?  Tell 192.168.80.1
 206785 704.203180  PcPartne_27:b8:1a     Broadcast             ARP      Who has 192.168.80.202?  Tell 192.168.80.1
 206786 705.203174  PcPartne_27:b8:1a     Broadcast             ARP      Who has 192.168.80.202?  Tell 192.168.80.1
 206787 709.731170  PcPartne_27:b8:1a     Broadcast             ARP      Who has 192.168.80.202?  Tell 192.168.80.1
 206788 710.730686  PcPartne_27:b8:1a     Broadcast             ARP      Who has 192.168.80.202?  Tell 192.168.80.1
 206789 711.732741  PcPartne_27:b8:1a     Broadcast             ARP      Who has 192.168.80.202?  Tell 192.168.80.1
 206790 713.507129  192.168.80.202        192.168.80.1          HTTP     [TCP Retransmission] Continuation or non-HTTP traffic[Packet size limited during capture]
(if anyone wants the full dump of this data that includes the packet data, I have that available too)




Ok, now lets look at the dhcpd log data for this time frame:
Code: [Select]
Dec 17 09:47:32 dcerouter dhcpd: For info, please visit http://www.isc.org/sw/dhcp/
Dec 17 09:47:32 dcerouter dhcpd: Wrote 0 deleted host decls to leases file.
Dec 17 09:47:32 dcerouter dhcpd: Wrote 0 new dynamic host decls to leases file.
Dec 17 09:47:32 dcerouter dhcpd: Wrote 14 leases to leases file.
Dec 17 10:05:35 dcerouter dhcpd: DHCPREQUEST for 192.168.80.200 from 00:17:ab:41:72:c5 (Wii) via eth0
Dec 17 10:05:35 dcerouter dhcpd: DHCPACK on 192.168.80.200 to 00:17:ab:41:72:c5 (Wii) via eth0
Dec 17 10:12:36 dcerouter dhcpd: DHCPREQUEST for 192.168.80.200 from 00:17:ab:41:72:c5 (Wii) via eth0
Dec 17 10:12:36 dcerouter dhcpd: DHCPACK on 192.168.80.200 to 00:17:ab:41:72:c5 (Wii) via eth0
As you can see, there are no indications that the connection was dropped by the dhcp server (it would show a DHCPNAK if it did).  There is a request at 10:05.35, but this should be totally unrelated and was after 10:05.12 anyways...



One more log I checked was /var/log/pluto/dhcp_pnp.log, and it showed nothing to indicate a a DHCP problem.


So it looks like the tcpdump data is all we have to go by and now we have to figure out how and why it goes haywire

6
Users / Re: DHCP leases Foscam IP camera problem
« on: December 17, 2010, 04:06:32 pm »
DHCP doesn't seem to be the problem.
I removed the surveillance camera from the web admin so that Motion wouldn't be requesting any images from it, and did a reboot.

Watching the DHCP logs, everything goes as it should and the foscam is given an IP address, and everything ran for over 24 hours without the foscam dropping out. I was also running tcpdump and analyzed the packets in wireshark.

Just re-added the foscam in the web admin and did a reload of the router. Motion is now grabbing images - I'm running tcpdump so I can examine what goes wrong in wireshark, and I'm also logging the DHCP stuff as well. Hopefully I'll find something!

The camera just crashed while I was writing this, going to analyze the data now...

7
Users / Re: DHCP leases Foscam IP camera problem
« on: December 16, 2010, 02:51:12 pm »
I'm going to start fresh.  I enabled dhcpd logging and I'm going to take a fresh look at what happens when connection is lost and go from there.  I just spent a bunch of time examining out DHCP setup, as well as studying al the available configuration options.

8
Users / Re: DHCP leases Foscam IP camera problem
« on: December 15, 2010, 10:16:00 am »
I checked mine, and mine are all once per minute
Sounds like maybe its detecting false motion (noise?) as it will also store images on a per second basis when there is motion.

Can you confirm if you have a genuine Foscam?

9
Users / Re: DHCP leases Foscam IP camera problem
« on: December 15, 2010, 01:58:16 am »
I would like to hear if this is working for other foscam users.
I just did some research and found out that the foscam that I'm using is a fake foscam, so my results may not be reliable!

Here is a good article that has a great example of telling a fake from a real foscam based on the stickers on the back....
http://www.gadgetvictims.com/2009/09/yet-another-firmware-for-foscam-fi8908w.html

10
Users / Re: DHCP leases Foscam IP camera problem
« on: December 15, 2010, 01:43:37 am »
unfortunately, no good news to report yet. The foscam holds on for a few hours then locks (no longer responds to arping requests at all)

Going to keep trying different settings...

11
Users / Re: DHCP leases Foscam IP camera problem
« on: December 14, 2010, 05:35:48 pm »
ok cool
since you're trying without an arp_filter, I switched and I'm trying with arp_filter=1, arp_ignore=1 and arp_announce=2. Hopefully one or both of us will have success

12
Users / Re: DHCP leases Foscam IP camera problem
« on: December 14, 2010, 04:51:30 pm »
How long does your camera usually last before it dies?  Mine was lasting 10 minutes tops (and even hard cycling power to the camera wouldn't bring it back).
The arp_filter got me 10 hours, and power cycling the camera would bring it back.

Now, lets see how the arp_announce/ignore works

13
Users / Re: DHCP leases Foscam IP camera problem
« on: December 14, 2010, 04:29:51 pm »
just a quick note.. I just tried
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1

remotely from work, and the camera was instantly unreachable. However, I'm now trying:
net.ipv4.conf.eth0.arp_announce = 2
net.ipv4.conf.eth0.arp_ignore = 1

And the camera is reachable again. I also removed the arp_filter lines from /etc/sysctl.conf, so lets see how this does...

14
Users / Re: DHCP leases Foscam IP camera problem
« on: December 14, 2010, 03:30:26 pm »
I'm at work for 12 hours today, so I won't get to test anything until tonight - but if you want to test.. Try adding these also to the bottom of /etc/sysctl.conf:

Code: [Select]
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
then reboot
(i'm quite positive that this along with the arp_filter should fix the problem)

information on their meaning here:
http://kb.linuxvirtualserver.org/wiki/Using_arp_announce/arp_ignore_to_disable_ARP


Also, if this doesn't work right out the gate, try changing them to:
Code: [Select]
net.ipv4.conf.eth0.arp_announce = 2
net.ipv4.conf.eth0.arp_ignore = 1
if your internal network is on eth0 (or use eth1 if your network is flip-flopped).  I'd rather use .all. over .eth0/1., because if it works that way then the code to implement a permanent fix will be much easier!

15
Users / Re: DHCP leases Foscam IP camera problem
« on: December 14, 2010, 03:22:03 pm »
barney: http://fixunix.com/kernel/263192-arp-bug.html
This is the exact thing you are experiencing.

My camera finally dropped out just a bit ago.  the arp_filter increased the time easily 10 fold, but it still eventually fails.  I think we're on the right track though and I'll keep poking around.
There are also sysctl variables for arp_ignore and arp_announce. I'm sure with some experimentation we will find the right combination

Pages: [1] 2 3 ... 51