Today I finally found why bgl-python wasn’t building, there was a three-line buglet in
boost/graph/astar_search.hpp found by Andy Tompkins. By applying his patch to astar_search.hpp (and including it in the bgl-python codebase, it builds without errors (only some strict-aliasing rule warnings remain).
Best is: it also compiles on Mac OS X 10.6.3 with XCode 3.2.1
But, so far I must say I really hate bjam as a building tool. I’m seriously considering going with cmake as build system. Any opinions whether or not that’s a good idea?
After spending quite some time with the firewall rules inside the openwrt kamikaze 8.09.2 installed on my Linksys WRT54GL, I thought that posting the end result might be handy for others.
- step 1, install the following packages: ip6tables, kmod-ipv6, radvd, 6scripts.
- step 2, change the following line in /etc/init.d/6tunnel
ip tunnel add $tnlifname mode sit remote $remoteip4 local $localip4 ttl $ttl
ip tunnel add $tnlifname mode sit remote any local $localip4 ttl $ttl
because if you don’t the outgoing packets are to remoteip4 (220.127.116.11), but the incoming packets are from 18.104.22.168. That’s not handled properly somewhere inside the kernel/firewall/ip6tunnel config. You can see this is happening by the “ICMP protocol 41 unreachable” messages back to 22.214.171.124.
So, what goes into /etc/config/6tunnel:
option tnlifname ‘6tunnel’
option remoteip4 '126.96.36.199'
option localip4 <insert your ipv4 address>
# convert your external ipv4 address into 8 4-nibble hex digits
option prefix ‘2002:<hex variant of ipv4>:1::1/64’
option localip6 “2002:<hex variant of ipv4>::1/16”
option ttl 64
And the last step is adding a rule admitting ipv6 packets in (/etc/config/firewall)
option '_name' ‘6tunnel’
option src wan
option proto 41 # ipv6
option target ACCEPT
And just to have everything documented, this is a sample firewall script for protection of your ipv6 stuff:
# Copyright (C) 2006 OpenWrt.org
ip6tables -t mangle -F
ip6tables -t mangle -X
# Allow everything on loopback.
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A OUTPUT -o lo -j ACCEPT
ip6tables -P INPUT DROP
ip6tables -P OUTPUT DROP
ip6tables -P FORWARD ACCEPT
# Accept only stuff incoming if there's a SYN in there.
# We really want ESTABLISHED, RELATED, but unfortunately that's not supported (yet) in ip6tables
ip6tables -A INPUT -i $PUBIF -p tcp ! --syn -j ACCEPT
ip6tables -A INPUT -i $PUBIF -p ipv6-icmp -j ACCEPT
ip6tables -A OUTPUT -o $PUBIF -p ipv6-icmp -j ACCEPT
ip6tables -A INPUT -i $PUBIF -p tcp --dport 80 -j ACCEPT # accept HTTP
ip6tables -A INPUT -i $PUBIF -p tcp --dport 22 -j ACCEPT # accept SSH
ip6tables -A INPUT -i $PUBIF -p tcp --dport 25 -j ACCEPT # accept SMTP
ip6tables -A INPUT -i br-lan -j ACCEPT
ip6tables -A OUTPUT -o br-lan -j ACCEPT
ip6tables -A INPUT -i $PUBIF -j LOG
ip6tables -A INPUT -i $PUBIF -j DROP
It is sometimes necessary to capture the content of network traffic. Most people use a tool like wireshark or tcpdump to do that. Since these tools have the need to listen in promiscuous mode to the network interface, most people run them as root. Wireshark has had a lot of vulnerabilities in the code, which is unavoidable with the enormous amount of protocols being supported by reverse engineering. They have taken steps in the past to mitigate the impact of vulnerabilities by using a separate tool, dumpcap, which has a much smaller and simpler codebase.
Still, most people run wireshark as root, ‘because then it works’. Right, Gerald Combs has written an article on how to configure your system with capabilities so you don’t have to run wireshark as root any more. It works by granting users you want to be able to capture, the capability of being able to capture. That simple.
There’s a nice library called bgl-python which can be used to handle graph related problems in python using the, in my opinion, good quality code of the boost graph library. However, bgl-python does not seem to be maintained anymore, which is quite a pity.
Following one of the comments on this blog, I tried to get bgl-python to compile and I got everything compiling with boost-1.42.0, except for one file,
astar_search.cpp, which fails with an error message of roughly 50k. Yes. One error: 50k of tekst, it’s got to be C++. The offending line, property_map.hpp:325 looks fine to me:
static_cast(pa)[k] = v;
The problem appears to be in the [k], which, for some case, is a void* instead of unsigned int. I can understand that’s a problem, but I’m currently at a loss why this is happening.
To be continued…
Nothing so far has worked, astar_search keeps getting the compile error. Any ideas are welcome!