PHP PDO Debugging

When you use PDO in PHP to access your database, make sure you enable debugging, otherwise you will not know what is going on because PDO discards all errors.

$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

lua for web development on embedded systems

It is documented HERE

It looks fairly complicated to set it up with something like minihttpd. Not sure whether it is worth it. We can do it directly with C using cgi.

zigbee stacks, open source or not

• TI, z-stack, free but closed-source
  
• ATMEL, bit-cloud, free but closed-source
  
• MicroChip, zig-bee 2006 stack, FREE AND OPEN SOURCE, See it
  

PDF417 bar code decoder

http://forums.morovia.com/free-pdf417-decoder-pdf417decode-t231.html

cross platform (windows and Linux) serial port library

http://www.teuniz.net/RS-232/

use <fieldset> in your html code

Example:

Software List

Base 32 Encoding

The Crockford Keyboard

The Tilton Macro Processor

php login system

http://www.evolt.org/article/PHP_Login_System_with_Admin_Features/17/60384/index.html

http://phpgacl.sourceforge.net/

http://mktgdept.com/php-login-script.zip

javascript "this" pointer

"this" pointer is important and handy in DOM and Javascript. Read more here.

rpm list of files

To list files in a local RPM file:
rpm -qlp techrx.rpm

To list files in a installed rpm package:
rpm --query --filesbypkg techrx

Google map markers download

http://www.benjaminkeen.com/?p=105

vim tab and space

set smartindent
set tabstop=4
set shiftwidth=4
set expandtab

and use the following command to change existing tab to space:
:%retab

also see: 
:help auto-setting

PHP pdo apache sqlite3

I got my php+pdo+sqlite3 to work under apache now. Some tips to remember:

1. The folder that houses the database file must be writeable by the user "apache"
2. Database files has to be writable by the user "apache"
3. after installing php-pdo package, remember to restart apache/httpd service, because mod_php is in memory.
4. remeber to put the following code at the beginning of the php code to enable debugging:


ini_set('display_errors', 'On');
error_reporting(E_ALL);


5. remember to enable PDO debugging


try {$handle = new PDO("sqlite:".$db); }
catch(PDOException $e) { echo $e->getMessage(); return;}
$handle->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);


sqlite commands

To delete all rows in a table do:

delete from TABLE;

Need Good Fertilizer?

Pro Terra: http://www.proterratechnologies.com/testresults.htm

Difference Between AES CCM and AES CCM* (CCM-Star) used by 802.15.4

This is from 802.15.4 standard itself p.253:

With regard to security of the CCM* mode of operation, the CCM* mode coincides with the original CCM mode specification (ANSI X9.63-2001 [B1]) for messages that require authentication and, possibly, encryption, but also offers support for messages that require only encryption. Moreover, it can be used in implementation environments for which the use of variable-length authentication tags, rather than fixed-length authentication tags only, is beneficial. As with the CCM mode, the CCM* mode requires only one key. The CCM* specification differs from the CCM specification, as follows:

— The CCM* mode allows the length of the Authentication field M to be zero as well (the value M = 0 correspond-
ing to disabling authenticity because then the Authentication field is the empty string).
— The CCM* mode imposes a further restriction on the nonce N: it shall encode the potential values for M so that one can uniquely determine from N the actually used value of M.
As a result, if M is fixed and the value M = 0 is not allowed, then there are no additional restrictions on N, in which case the CCM* mode reduces to the CCM mode. In particular, the proof of the CCM mode applies (Jonsson [B13] and [B14]).
For fixed-length authentication tags, the CCM* mode is equally secure as the original CCM mode. For variable-length authentication tags, the CCM* mode completely avoids, by design, the vulnerabilities that do apply to the original CCM mode.
For fixed-length authentication tags, the security proof of the original CCM mode carries over to that of the CCM* mode (also for M = 0), by observing that the proof of the original CCM mode relies on the following properties, which slightly relax those stated in Jonsson [B13] and [B14] (relaxed property indicated in italics):
— The B0 field uniquely determines the value of the nonce N.
— The authentication transformation operates on input strings B0 || B1 || B2 || … || Bt from which one can uniquely
determine the input strings a and m (as well as the nonce N). In fact, for any two input strings corresponding to distinct triples (N, m, a), neither one is a prefix string of the other.
— All the Ai fields are distinct from the B0 fields that are actually used (over the lifetime of the key), as those have a Flags field with a nonzero encoding of M in the positions where all Ai fields have an all-zero encoding of the integer 0.
Hence, if M is fixed, then the CCM* mode offers the same security properties as the original CCM mode: confidentiality over the input string m and data authenticity over the input strings a and m, relative to the length of the authentication tag. Obviously, if M = 0, then no data authenticity is provided by the CCM* mode itself (but may be provided by an external mechanism).
For variable-length authentication tags, the original CCM mode is known to be vulnerable to specific attacks (see, e.g., Section 3.4 of Rogaway and Wagner [B17]). These attacks may arise with the original CCM mode because the decryption transformation does not depend on the length of the authentication tag itself. The CCM* mode avoids these attacks altogether, by requiring that one shall be able to uniquely determine the length of the applicable authentication tag from the Ai fields (i.e., from the counters blocks).
NOTE 2—With regard to the interoperability between CCM mode and CCM* mode of operation, the CCM* mode reduces to the CCM mode in all implementation environments where the length of the authentication tag is fixed and where the value M = 0 (encryption-only) is not allowed. In particular, the CCM* mode is compatible with the CCM mode, as specified in IEEE Std 802.11i™-2004 (for WLANs) [B7], IEEE Std 802.15.3™-2003 (for WPANs) [B10], and IEEE Std 802.15.4-2003 (for older WPANs).

Good VPN IPsec overview, from cisco

http://www.cisco.com/en/US/docs/net_mgmt/vpn_solutions_center/2.2/ip_security/provisioning/guide/IPsecPG1.html

Or download it local now

ike-scan: a great ipsec tool

If you want to learn IPsec, start with ike-scan

And the wiki page is also one of the best ipsec documents.

http://www.nta-monitor.com/wiki/index.php/Ike-scan_User_Guide#IPsec_VPN_Fingerprinting

cisco vpn 3000 xauth configuration

http://www.ciscopress.com/articles/article.asp?p=421514

Example 4-1. Cisco IOS XAUTH Configuration on the IPSec Gateway

vpn-gw1-east#
!
hostname vpn-gw1-east
!
username ezvpn password 0 east
username ezvpn1@vpngroup password 0 ezvpn1east                                        

  username ezvpn2@vpngroup password 0 ezvpn2east                                        
aaa new-model
!
aaa authentication login vpn local                                                    
aaa authorization network vpn local
aaa session-id common
ip subnet-zero
!
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp keepalive 10 10
!
crypto ipsec transform-set vpn esp-3des esp-sha-hmac
!
crypto dynamic-map dynamic 1
set transform-set vpn
reverse-route remote-peer 9.1.1.33
!
!
crypto map vpn client authentication list vpn                                         
crypto map vpn isakmp authorization list vpn
crypto map vpn client configuration address respond
crypto map vpn 3 ipsec-isakmp dynamic dynamic

The addition of the following command on the crypto map enables XAUTH and triggers the XAUTH transaction after IKE phase 1 and before IKE phase 2:

crypto map map-name client authentication list list-name

Explanation of Cisco VPN Authentication mode

1. XAUTH, which really is PSK + XAUTH
2. mutual group authentication, also known as hybrid
3. certificate based authentication

so, to be more specific on the cisco side, there are three types of
phase 1/1.5 that work with the cisco road warrior ``vpndialer''
program.  You can tell which one your VPN is using by right-clicking
on its row in Connection Entries, picking Modify, and noting which of
the following three radio buttons is checked in the Authentication
tab:

 Group Authentication -- this is pre-shared key + XAUTH, where any
                         roadwarrior VPN client has enough
                         passphrases loaded into it to impersonate
                         the head-end.  The PSK is obfuscated in the
                         config file, but if you can un-rot13 it, you
                         can set up a spoof head-end and MITM nearby
                         wireless coworkers' passwords, not only
                         hijaaking your way into the VPN without a
                         password but probably also getting their
                         Master Windows Password to Everything, too,
                         thus imagineably making them LESS secure
                         than if they'd had no VPN at all.


 Mutual Group Authentication -- This uses a certificate on the
                                head-end, but the road warrior
                                presents no certificate.  Road
                                warriors validate the cert against a
                                CA certificate pubkey which you must
                                load into roadwarriors and use to
                                issue the head-end's cert, to stop
                                the MITM attack above.  It seems to
                                be un-confusing, so a lot of sites
                                probably use it.  It only works in
                                aggressive mode, though, because the
                                ``client has no identity,'' or some
                                other weird IPsec standards-ism.

                                This is probably the 'hybrid' you are
                                talking about, also known as 'hybrid
                                XAUTH'.  I understood once but am now
                                a bit rusty on how all Cisco's messy
                                configuration stanzas reference each
                                other, but have this in my notes (for
                                requesting it on PIX7.x/ASA head-end):

tunnel-group RoadWarrior ipsec-attributes
isakmp ikev1-user-authentication hybrid


 Certificate Authentication -- This uses certificates on both clients
                               and servers, and can work in main mode
                               instead of aggressive mode.  It's
                               possible to load a different cert into
                               each client and not use XAuth at all,
                               like in a site-to-site VPN.  The VPN
                               dialer supports this, but almost
                               everyone uses XAuth.

                               But some shops load all their road
                               warriors with the same cert, same
                               private key, and then use XAuth to
                               distinguish one client from another.
                               Sometimes the VPN client .zip with the
                               client cert, private key and all, is
                               available for download on some open
                               external web page.  Even with the
                               common client cert so freely
                               distributed, this behaves the same as
                               Mutual Group Authentication.  It's
                               older, and it's probably better than
                               mutual group auth / hybrid xauth.

                               upside: works in Main Mode, not as
                               cisco-proprietary.  downside: confuses
                               netadmins, fails-open on
                               misconfiguration (if you don't add
                               XAuth).  And the configuration is a
                               tangled mess.

I don't think you have to configure XAuth in their VPN dialer at all.
It pops up a box if asked.  That's it.

I don't know racoon well, but it's more likely to support Certificate
Authentication and PSK, less likely to support Mutual Group
Authentication.

There is also MTU fun.  Two IOS devices supposedly will to PMTU-D on
various kinds of tunnels including gre and ipsec.  I'm not sure PIXen
or the Windows/Mac VPNClient _ever_ do PMTU-D---in some packet dumps
they seem to punt by quietly defaulting to a small MTU like 1200 -
1300.  and I think BSD/Linux doesn't do PMTU-D either but might
confuse you by having a larger default.

source: http://mail-index.netbsd.org/current-users/2009/01/27/msg007643.html

Linux IPSec VPN client

1. vpnc, my favorate
2. http://www.shrew.net/software , this one looks really good but I have not tested it
3. linux kernel ipsec + user land tools such as ipsec-tools

Other things to read:
http://www.tjhsst.edu/admin/livedoc/index.php/IPSec_VPN

mini2440 nand issue

I had a lot of bad blocks in my mini2440/micro2440 device. I tried format, bon part, etc, and nothing seemed to work.

Today, I uploaded the 128M root file system instead of the 64M one, and it started to work, still with a bunch of bad blocks. Then I did "f" to format the NAND flash and "x" to format nand flash for linux, and re-downloaded the 128M root file system, and no bad block appeared, and everything is working.

The weird thing is that my flash chip says 64M. However, my kernel detects 128M. Why is 128M working? not sure. All I know is that it works now.